Thinking about Software Architecture & Design : Part 7

The temptation to focus a lot of energy on the one killer diagram that captures the essence of your architecture is strong. How many hours have I spent in Visio/Powerpoint/draw.io on “the diagram”? More than I would like to admit to.

Typically, I see architectures that have the “main diagram” and then a series of detail diagrams hidden away, for use by implementation and design teams. The “main diagram” is the one likely to go into the stakeholder presentation deck.

This can works fine when there are not many stakeholders and organizational boundaries are not too hard to traverse. But as the number of stakeholders grows, the power of the single architectural view diminishes. Sometimes, in order to be applicable to all stakeholders, the diagram becomes so generic that it really says very little i.e. the classic three-tiered architecture or the classic hub-and-spoke or the peer-to-peer network. Such diagrams run the risk of not being memorable by any of the stakeholders, making it difficult for them to get invested in it.

Other times, the diagram focuses on one particular “view” perhaps by putting one particular stakeholder role in the center of the diagram, with the roles of the other stakeholders surrounding the one in the middle.

This approach can be problematic in my experience. Even if you take great pains to point out that there is no implied hierarchy of importance in the arrangement of the diagram, the role(s) in the middle of the diagram will be seen as more important. It is a sub-conscious assessment. We cannot help it. The only exception I know of is when flow-order is explicit in the diagram but even then whatever is in the middle of the diagram draws our attention.

In most architectures there are “asks” of the stakeholders. The best way to achieve  these “asks” in my experience is to ensure that each stakeholder gets their own architecture picture, that has their role in the center in the diagram, with all other roles surrounding their part in the big picture.

So, for N stakeholders there are N "main views" - not just one. All compatible ways of looking at the same thing. All designed to make it easier for each stakeholder to answer the “what does this mean for me?” question which is always there – even if it is not explicitly stated.

Yes, it is a pain to manage N diagrams but you probably have them anyway – in the appendices most likely, for the attention of the design and implementation phase. My suggestion is to take them out of the appendices and put them into the stakeholder slide deck.

I typically present two diagrams to each stakeholder group. Slide one is the diagram that applies to all stakeholders. Slide two is for the stakeholder group I am presenting to. As I move around the different stakeholder meetings, I swap out slide number two.