We have all seen a practitioner show up with a carefully drafted diagram that showed how some elements of a system should relate in the future. We reverently look at the picture, appreciate the elegance, then go about creating a system that only bare superficial relations to the diagram.
Why? Everything that comprises a useful architecture was missing:
These carefully crafted diagrams typically represent a part of the complete ecosystem. Too often the diagram is a filled with arbitrary design choices made in support of 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.
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 not only 'stands alone' it stands realized. 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 a 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.