Every now and again I rediscover what I think of as Enterprise Architecture ways of working anti-patterns. These are not typical technical anti-patterns but ways of working that seemingly add value but in practice store up problems for the future. I highlighted one in previous blog on complex diagrams. There is another related anti-pattern that I find particularly annoying because it voids a significant amount of effort.
It is the misguided belief that the creation of diagrams is architecture. They are a representation of architecture. For architecture to be useful it must be actionable. A diagram is not actionable, it is a visualization. The specification relating to the blob on the diagram is actionable - you can build it, deploy it, assess it, review it. A colored blob on a diagram is next to useless.
What makes it actionable? It is understanding and attributes.
Understanding comes from using the correct representation of the information in a particular context. Sometimes this will be a hierarchical set of diagrams that gradually take the viewer into detail in focused areas. Other times it will be vast maps for those who know the landscape to rapidly move one part to another. Sometimes you needs lists and tables, other times you need raw data for comparison and aggregation. You need a detailed set of attributes. This is the key, architectures must be captured as data so that it can be re-presented in multiple forms and analyzed.
There is often an excuse - "we don't have the tools". Some architects appear to hold the view that a high-end enterprise architecture tool or nothing is the choice. There are low price or no price modeling tools that will do a good job of modeling and capturing attributes. A spreadsheet will enable you to do the analysis. They give you an 80% solution. A high-end tool will give you another 10-15%, but the reality is that you will spend 3 months configuring it to do what you want. It will take you less time to get going using an 80% approach and it will be much cheaper.
Sometimes architects are very focused on the ideas and the creative part of the role - this is good and positive. They are sometimes less interested in the mundane data capture and specification of attributes and the detailed validation of the ideas. Ultimately, design and implementation will be required. These require that you record your idea in its entirety with no implicit assumption that thought transference over time will take place. If you do not then the idea will be misinterpreted, may be rejected, it will be changed and the conceptual integrity of the architecture will be lost. It is not the implementation team that screwed up, it is the architecture team that failed to communicate.