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

Search ...

Powered by Squarespace
« Finding Value In Enterprise Architecture | Main | Leo de Sousa »

Complex diagrams = bad architecture

A pet hate of mine is complex diagrams that I cannot read on my laptop without zooming in and out and scrolling around. They may be fine for posters that are put on a wall but they are not generally useful architectural artefacts.

I am going to state the obvious – most people look at documents and diagrams on screens or on printouts that they carry around. The size of these is pretty consistent at around A4 size. If you cannot read and understand a diagram that is that size then the diagram is a waste of effort. So, please have some consideration for your audience when creating diagrams – it is a simple and common courtesy.

But I said it is “bad architecture”, surely this is bad presentation. First, since communication is critical for architects, then poor communication is bad architecture. However, the point is deeper than this…

Good architecture is well modularised. It is separable logically. A large complex domain can be decomposed into multiple simpler domains with clean simple interfaces between them. This implies that a set of hierarchical diagrams can be created to represent the architecture each of which can be understood on their own and with sufficient contextual information. So, going back to the communication point. If the architecture is good then it can be presented simply. Is there any benefit in making simplicity appear complex?

What about the as-is? If the current architecture is a mess of spaghetti then how can this be represented simply. Well, this is a core part of the architecture skillset! Logical partitioning is a critical step towards resolving the mess. In short, you must partition it logically as you would a good to-be architecture and what you will be showing is that interfaces are not clean and the components are not well formed. This gives you a start point for refactoring. Showing a mess by producing complex diagrams highlights the problem but does not help solve it.

Please don’t produce complex diagrams, there is no need, ever! I do not want to waste my time trying to understand another diagram with 200 blobs and 500 lines on my laptop again. The person who produced this diagram had the knowledge and has singularly failed to transfer it effectively. That is bad architecture and failure for an architect!

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (4)

I enjoyed this post a great deal and actually found it very motivating. I also wondered what the cost of bad diagrams really is; something we'll never know but I still wonder how far-reaching the influence extends.

Certainly taking a little time to consider who will use the diagram, what it is trying to depict, and as you point out, what sort of device will be used to view the diagram, would go a long way towards improving what we experience today and going forward.

Thanks again for the post, it gave me cause to not only evaluate my diagrams but also ask myself what I can do to make a difference in my sphere of influence.


October 8, 2008 | Unregistered CommenterBIll

A student on a course of mine once raised a great point. A diagram should be understandable within 30 seconds of looking at it. If you are able to determine the general purpose and way that a diagram is attempting to show you a view on architecture within that time then I believe that the diagram has value. If you spend 5 minutes staring at a diagram and cannot understand what it is trying to communicate, then it has failed.
Take the London Underground Tube Map as an example. Although a big diagram it communicates its information very quickly. On the other hand complex system diagrams and their data relationships are generally very badly laid out take too long to understand how they work.
I generally believe that layout of a diagram is the key aim to make it intelligible and not the amount of information on the diagram. Balance and pragmatism are most important of course.
Often it is a good idea to find another way to categorise the information on the diagram further. For instance the tube map gives the lines colours to differentiate them and groupings of grey and white to show the zones. System diagrams could use the same techniques, for instance using colours to show the business criticality and grouping boxes to show the business functions supported. These techniques can go a long way to making a diagram more quickly understandable by the audience and also assist the author in understanding how to lay them out more clearly.
My top tip for diagrams would be to always take your completed diagram, find a third party that has not seen it and ask them if they understand the diagram in 30 seconds.

October 12, 2008 | Unregistered CommenterColin Wheeler

I fully support the Battle Against Complexity. But I believe that we can't win the battle unless we understand our enemy. This means understanding something about the mathematics of complexity and the principles that drive systems toward simplicity. We are caught in what I sometimes call the Paradox of Simplicity: It is simple to make systems complex; it is complex to make systems simple. As Einstein is often quoted, "We should make things as simple as possible, but no simpler." Mark Twain is attributed this quote in a letter to a friend: "I'm sorry to write you such a long letter. I didn't have time to write you a short one." Both of these quotes point back to the Paradox of Simplicity. In my view, it isn't enough to say we want simpler systems. We need to think of ourselves as practitioners of the Science of Simplicity. This, of course, implies three things. First, that there is a "science of simplicity". Second, that we understand that science. Third, that we are dedicated to following the principles implied by that science. I could go on forever on this particular topic, one for which I feel great passion. But if you are interested, I cover this topic in detail in my latest book, Simple Architectures for Complex Enterprises. It is nice to meet another traveler on the road to simplicity. Good luck!
- Roger

October 29, 2008 | Unregistered CommenterRoger Sessions

I agree with the content as well as the great comments..
Would like to talk about the flip side too. ie. What about diagrams that are "too simple" often making them too many and conveying not much if anything, but simply added because the template says so?
We say "a digram conveys 1000 words". I think by corollory, we should also put a condition that "a diagram should convey 1000 words" ie don't add a diagram if it is not conveying a reasonable number of words.

January 21, 2010 | Unregistered CommenterRaji Godbole

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>