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
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
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” 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
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