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
This may seem like an odd blog coming from a company that is so deliverable focused, but it isn’t. A design document is not just a document, but a powerful tool for figuring out an architecture. However, it is easy to get caught up in the “task” of completing the design document and lose focus on deeply understanding the architecture.
For practically every profession under the sun there are tools that make the job easier. From bakers to builders, everyone has their choice of implements to ply their trade. Naturally these tools will range from entry level, toy tools to expensive gadgets with more features and sophistication. Enterprise architecture is certainly no exception.
One of our primary tools for designing architecture, of course, is a modeling tool. Modeling tools help us visualize our design into standard, in our case UML, models. There are a variety of these tools in the marketplace, ranging from basic “drawing style” tools to far more advanced suites with “model awareness”, version control, team collaboration capabilities, etc.
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
Investigative Architecture is our “bread and butter.” We facilitate meetings with stakeholders, understand what they have or what they want, and use diagrams to rapidly drive to a clear consensus regarding what is there (“as is”) or what should be there (“to be”). We have refined our approach over many years into a clear, well defined, proven methodology. We write articles on our approach, we mentor clients, and we sell training.
So why am I stuck? Read more
We have made clear, and will continue to do so – in assorted blogs, tweets, and diatribes – the importance of consistent notations for diagrams. This was a significant driver behind our adoption of UML as our diagramming standard.
None-the-less, there do come times when we are forced to work “freestyle.” 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
Make sure that your designs are accurate. 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 few years back we presented for the first time at the Open Group Architecture Practitioners Conference in Miami, FL. I spoke about a topic about which we are passionate: UML as an Enterprise Architecture diagramming notation. Read more