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


Documenting Design Decisions

December 16, 2013

We previously discussed Options Analysis – our method for evaluating multiple viable technical solutions.  We also facilitate numerous smaller design choices at all levels of the architecture.  We often need to document these as “design decisions,” and use a common approach and format to document at all levels of design (conceptual, logical, physical, component, etc.).
Read more


Prose: Great for Novels, Lousy for Solution Design

December 3, 2013

While we often find ourselves advocating for design documentation, we typically are referring to “some” design documentation vs. “more” design documentation.  When it comes to design documentation, more is actually not better.  We have encountered customers, and even other consulting firms, that deliver design documentation by the inch – measuring design quality horizontally across the binding.  We recommend not doing this!
Read more



Cost, Time, & Architecture – The Zen of Options Analysis

September 9, 2013

Solution architecture is typically designed within a project context. Although we focus on the right process for this design activity frequently in our blog, the intersection of that process with the process of delivering an actual production solution is very important. Constraints are a key reality in projects, and often they compete with achieving the “right” architecture. A process to guide a design through this gauntlet of project constraints is why we created our “Define Solution Options” process.

Read more



The System Context Diagram

April 4, 2013

We use a system context diagram in the early stages of our Investigative Architecture™ process. It provides a high level functional view of a system and, while it is very powerful for the early stages of functional design, it also ensures you have identified any functional needs that impact the non-functional, or architectural, aspects of the design. Read more



System Architecture Diagrams

August 13, 2012

Diagramming software systems is still a largely undisciplined activity, despite the many advancements in notation and methodology made over the last 10-15 years.

The typical “Systems Architecture Diagram” profile of a large organization goes something like this: Read more



Welcome to Our Investigative Architecture Training!

October 27, 2011

We are very busy right now, refining our Investigative Architecture Workshop scheduled for next month.

Investigative Architecture is the term we coined back in 2008 for our approach that facilitates the rapid assessment and documentation of ‘as-is’ and proposed IT architectures. Read more



Investigative Architecture: The Data Perspective

July 31, 2011

“Investigative Architecture” is a term we at Systems Flow coined a few years ago for a core, overarching discipline of ours. It describes – and prescribes – the sometimes tedious, but always challenging, process that a working architect employs to locate and absorb information about a problem space in order to create usable, professional visual work products that best communicate a solution. Read more



Investigative Architecture – Read the Tea Leaves of Your Enterprise

March 18, 2011

A foundational skill for an architect is the ability to rapidly assess and document “as is” and proposed solution architectures. The challenge lies in the typical state of enterprise knowledge regarding the systems – a myriad of internal and external information sources at all levels of quality and completeness. Rapidly converting this sea of information into usable knowledge requires a repeatable, structured approach for gathering information from internal stakeholders and documents, as well as performing focused research for publicly-available product and industry information. This is the Investigative Architecture approach. Read more