Drawing a line…

Early in my career, I was in a meeting where we were talking about a project. The lead architect drew a picture consisting of blobs and lines. The diagram was presented with certainty throughout and positioned the speaker as a key expert. Each blob and line was explained clearly except one…

I pointed at a part of the diagram and asked, “I think missed the explanation of one of the relationships, what does this line mean?” There was a disapproving glare and a sharp answer “there is a relationship!” The tone made it clear to me that the real answer was, “I was glossing over the fact that I don’t know and now you have embarrassed me!”

Perhaps I could have asked the question in a less challenging way. However, that aside, presenting certainty when there is none can cause serious issues as a project progresses and create and build on unacknowledged assumptions.

Sometimes, however experienced you are as an architect and however “strategic” you are in your work, sometimes it pays to get right back to basics. The issue often is how effective is our communication? In the communication of ideas through pictures and words are we being clear? If not then we fail, so it is right, sometimes, to go back and ask yourself whether you are getting the basics of communication right.

I read a book called “101 Things I Learned at Architecture School” by Matthew Frederick.  It is about the basics of “traditional” architecture rather than enterprise architecture but I was surprised how much I could get of the book and find relevant to what we do.

The first of the 101 “Things” is “How to draw a line”.  Just as in traditional architecture, pictures at various levels of formality are critical for communication.

You need to buy the book to get the specific advice however this page prompts a number of questions:

  • what does each line on your diagram mean?
  • do the differences between lines – thick, thin, colours, dashes, dots, arrowheads, etc. all have clear unambiguous meanings?
  • is the labelling meaningful and informative?
  • are you routing lines so they are easy to follow?
  • are they crossing?
  • are there too many blobs and lines?
  • do they take the audience from the “beginning” of the diagram to the “end”?
  • does the diagram tell a story?
  • when you sketch on a whiteboard, are your lines strong and bold showing certainty in your ideas?
  • are the lines weak indicating your lack of clarity?
  • do your diagrams leaving people nodding in confusion?
  • could your audience use your diagram and explain it to someone else accurately?

The most fundamental tool for an enterprise architect is the simple line. Are you using it right?

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 artifacts.

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!