Architecture as diagrams is an anti-pattern!
Wednesday, October 1, 2008 at 06:36AM 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.
Alan Inglis
Reader Comments (2)
Alan is one of the best enterprise architects around and it great to see that Alan is putting much of his practical expereince and knowledge on the web. I could not agree more with this post and is similar to my programme managment post I wrote on my own blog called "Fools and Tools" http://www.claretyconsulting.com/it/comments/fools-their-tools/2006-07-05/. You don't always need the best tools to complete a job and sometimes tools are used to replace a lack of user professionaism and capabiltiy. Alan keep posting I certianly will be a regular reader !!
Alan I think you make an excellent point, it's easy to get caught up in the tool and pictures instead of creating an actionable enterprise architecture. I agree architects need to dig a bit deeper in expressing their architectural concepts, and validating those concepts. This really speaks to the more difficult aspect of enterprise architecture. Separating those that talk about enterprise architecture, and those that practice it everyday, bringing real value to everyone in the enterprise.
Although your approach is excellent to get architects' focal point adjusted, maintaining the vast amounts of information that are created is difficult without the appropriate tools. I don't believe it's a single tool, but a suite of tools for defining, cataloging, communicating, and collaborating throughout the enterprise.
I agree that architecture teams should not get bogged down in the tooling, and at the the same time need to define how to manage and effectively communicate their architectural guidance, regardless of the tools. Otherwise they become a team with 1000s of unmanageable, seemingly disjoint artifacts. Ultimately, those artifacts are abandoned, and cease to provide any value to the organization.
Best Regards,
Tom