This is a Flickr badge showing public photos and videos from Chief Architect. Make your own badge here.

Search ...

Powered by Squarespace
« "Correct" is a contextual thing... | Main | Business architecture organization models »

Architecture as diagrams is an anti-pattern!

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.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.
  • Response
    Response: Blog Carnival #8
    Unit testing Udi Dahan wrote a post about unit testing - Unit Testing for Developers and Managers Architecture

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 !!

October 5, 2008 | Unregistered CommenterKevin Brady

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,


October 22, 2008 | Unregistered CommenterTom Rose

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>