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.