Trap #16 Just the Architecture Diagram

Architecture Diagrams are a communication technique not an architecture development tool.

Enterprise architects at the top of their game develop architecture. An enterprise architecture is useful while it is being developed, and after the stakeholder approves it.

We use architecture diagrams. They are only part of the delivery of useful architecture. Often a small part.

Crash and burn stories

Low-functioning EA Teams. One anti-pattern after another.

If you see these practices, stop! Stop now!
Eject while you still can.

Enterprise Architecture Graveyard

Learn the failure patterns to avoid

Enteprise Architect's Guide

Download the Enterprise Architect's Guide. TOGAF Series Guide on developing useful enterprise architecture.

Be a better architect

Free 90-day Personal Enterprise Architect Kickstart to be a better architect.
Weekly recorded webinar, with downloads

Free EA Community Membership
Free training, guidance, tools and techniques from Conexiam Consulting

Start today

We have all seen a practitioner show up with a carefully drafted architecture diagram that showed how some elements of a system should relate in the future. We reverently look at the picture, appreciate the elegance. Then we go about creating a system that bares only superficial relations to the diagram.

Why? Everything that comprises a useful architecture was missing:

  • gaps that indicate what change is needed
  • controls that mitigate risks to the enterprise
  • specifications that constrain designers, implementers, operators and future architects
  • anything that highlights how the future ecosystem will deliver better value than what we have today

These carefully crafted diagrams typically represent a part of the complete ecosystem. Too often the diagram is a filled with arbitrary design choices made to support the practitioner’s biases.

Good architecture supports informed decision during the architecture development process and constrains design, implementation and operational choice. A diagram might do these things.

You can't govern from a box & line

Usually picture-based delivery short circuits the rich understanding in the minds of Stakeholders, decision makers and key contributors that evolve during development. This damage occurs because few diagrams can represent more than a single Concern. When we focus on these diagrams, we implicitly avoid complex trade-off and become fixated on a single optimization.

Diagrams masquerading as architecture are replete with unjustified specification and control. Unjustified because the rule only ‘stands alone.’ Standing free of context, the diagram specifies a service provider, software, or an operational location. Good architects see this and have to hold back the cry of why?

Best practice links a specification explicitly to a goal, objective, or other requirement and the design choice to the specification. Without this linkage, how can we assess the fitness of the design choice to the objective?

We’ve all heard the excuse, ‘but the diagram is just a View.’ In our EA Capability practice, our eyes are rolling. If it is an architecture view where is the repository that maintains the information that highlight concerns, requirements, preferences, relationships, and analysis. You guessed in the practitioner’s head where peer review and reuse are impossible.

Conexiam Navigate uses the Solution Development Notebook, or SDN, to address actively support the change & implementation teams and facilitate portfolio managers control change initiatives and measure value. In every SDN the architect needs to identify the essential guidance for the implementer, the owner, and the portfolio manager.

Join the Personal Enterprise Architecture Kickstart

Free 12-week program to be a better enterprise architect

Scroll to Top