System Architecture Diagrams
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:
- Formal standards or even recommendations don’t exist, leading to ad-hoc diagrams with a limited level of consistency at the team level, and no consistency at the enterprise level
- Diagram formats range from boxes and lines to flaming walls, miniature workstations, and an unlimited set of Microsoft Visio icons
- Most diagrams are overloaded with whatever information can fit, and then a bit more
- Multiple vendors engage in projects, bringing their own diagram formats, or even more likely, multiple individuals from assorted vendors, each bringing their own diagramming preferences
Systems Flow has been a long-time advocate of the UML for diagramming system architectures. All our consultants are trained in the basics of the notation – and in our unique stylistic and formal extensions. We believe that a rigorous but simple approach to diagramming is the most critical ingredient to formal communications in a mixed business/IT environment.
Here are a few examples of our approach, together with a bit of explanation:
Logical Deployment Diagram
- Notation: UML Deployment Diagram
- Conventions: Models logical systems as nodes, include architecturally significant components, show interface providers with “lollipops” and interface consumers with a connecting line. See Investigative Architecture – Logical Diagram for more details.
- Audience: For technical audiences primarily
Data Context Diagram
- Notation: UML Communication Diagram
- Conventions: Show real time and batch feeds between systems, as well as the nature of the data being transferred. See Investigative Architecture – Data Context Diagram for more details.
- Audience: Good for business and technical stakeholders
Conceptual Overview Diagram
- Notation: Non-standard
- Conventions: Trade accuracy and completeness for simplicity and marketability. Use limited set of recognizable icons. See Investigative Architecture – Conceptual Diagram for more info.
- Audience: Primarily for business stakeholders, but also a good overall “roadmap” diagram for an entire system
Learn more about diagramming and UML for Enterprise and Solution Architecture here on our blog, or check out some of our publications; Leveraging UML as a Standard Notation for Enterprise Architecture is a good place to start as it presents a slightly more detailed overview of this topic.
We invite you to join us in championing the value of a clear set of diagramming standards for your organization! Please contact us, we’d be happy to help.
Latest posts by Ben Sommer (see all)
- Cost, Time, & Architecture – The Zen of Options Analysis - September 9, 2013
- Type A’s Needed! - November 26, 2012
- Pre-Requirement Estimation for IT Projects - September 24, 2012