What’s My Function…Or Is It Non-Function?

January 27, 2017

One of the substantial differences between an architect and a software developer is regarding requirements. In general, a developer is concerned with functional requirements while an architect is concerned with non-functional requirements. Of course, there is some overlap between each requirement type and the type of person focusing on each, but that is generally how it’s divided. Read more



Bank Secrecy Act Compliance

May 6, 2016

Map of Countries Under Sanction by the US Government

Compliance with regulations coming from governments and from industry associations is a big problem for our clients – whatever the industry. In working with several banks over the years, we’ve become adept at identifying gaps and designing solutions for one of the most wide-reaching regulations for such organizations: the Bank Secrecy Act – aka “BSA”.

The BSA was passed by the US Congress nearly 50 years ago. It stipulates reporting and auditing that banks must perform on themselves and their customers to identify potential money laundering, terrorist financing, and other criminal financial activities. Its requirements have only grown over the years – especially since the 2001 terrorist attacks in the US – when the federal government heightened requirements on banks and financial institutions to “partner” with it in fighting terrorists and their financial networks. Read more



Avoiding a Leaky Scope Bucket

July 1, 2014

There’s a hole in the bucket, dear Liza, dear Liza,
There’s a hole in the bucket, dear Liza, a hole.
– children’s song, Bergliederbüchlein (c 1700)

In my prior article, I introduced the concept of a scope bucket to explain the concept of project scope to your stakeholders.  In this article, I continue the theme with some tips for managing and delivering the scope in your project scope bucket.

Read more



A Bucket of Scope

May 13, 2014

An architect relies on a clear understanding of scope.  In prior articles we have discussed the business context diagram, a great tool for establishing solution scope.  We also provided a technique for setting expectations regarding the scope of architecture activities.  In this article, I intend to expand on the importance of understanding (or establishing, if you are in a project lead role) the scope of a project.

Read more



Identify Indirect Stakeholders with System Context Diagrams

April 16, 2014

A Systems Flow consultant has skills that tend to fall in the triangle of technical, business and organizational excellence. One common and repetitive case of project dysfunction where this overlap brings real benefits is that of the “Operational Business Stakeholders Missing from Business Requirements.” Here’s how it usually goes:

  1. Architect is engaged to design project’s solution architecture (using the Investigative Architecture™ method)
  2. He/she is provided business requirements to review and comment on, to ensure they are fit for high-level design
  3. The requirements (hopefully) clearly state the end-user and product/service-centric objectives
  4. But how the end-users and the new/enhanced product or service will be supported operationally is completely missing
    Read more


“Make it Work Like Our Current System” and Other Requirement Pitfalls

March 18, 2014

This is the final article in in the series for implementing “Custom Off The Shelf” (COTS) solutions; a follow up to our Buy vs. Build Your Software  and “Off the Shelf” Implementation Pitfalls articles. In this we want to address requirement approaches that are sometimes proposed, but rarely successful in such an implementation.

Read more



Lies, Damn Lies, and Traceability

December 17, 2012

In my last post, Traceability 101, I talked about the essential role traceability plays in the success of a project. By writing business requirements, functional requirements, and then drawing traces between them you can create a traceability matrix that reveals 1) business requirements that are not covered by functional requirements, and 2) out-of-scope functional requirements that creeped into your project.

Too often, however, project managers see the steps in a project from the point of view of items that simply need to be checked off: Read more



Type A’s Needed!

November 26, 2012

We write frequently on this blog about our proven method to deliver IT architectures based on industry-standard tools and approaches like UML and IT Risk Management. We also write about the critical intangible skills that an architect needs to succeed, such as meeting facilitation, diplomacy and organization. One needs to be steeped in all these areas – as well as to form a strong “magic triangle” of technical/business/management skills to really succeed.
Read more



Pre-Requirement Estimation for IT Projects

September 24, 2012

Objectives and requirements – they are what makes the project world go ’round. Changing a business’ operations for the better requires one to decide what are the objectives of the change, and what are the requirements a change must meet to satisfy the objective.

Implementing the change usually starts with someone needing to know what the change is going to cost!

Read more



The Solution Architect’s Path to Success

April 11, 2012

Welcome to today’s blog. Sit back and relax. Close your eyes. Take some deep relaxing breaths. Envision a Utopian architecture project delivery:

  • Scope is clear and agreed upon,
  • Requirements are carefully crafted,
  • Read more


Next Page »