Why should you draw Software Architectures ?

Thoughts & Experiences for Drawing Software Architecture

Most Architects represent their thoughts in the form of diagrams. These are of varied types and formats.

• Some like to represent in the form of mixed formats representing Data flow, Applications, and Infrastructure all in a single view while others are often selective about what is captured
• Some will focus on the direction of arrows, strength(thickness) of lines, color of lines while others might doodle away
• Choosing the amount of detail presented is a choice that is individual too unless stronger standards exist

All of them are correct and there’s always more than a single diagram that can communicate. But why are diagrams so effective in describing architectures? The answer lies in a definition or more so understanding of the Term.

While there are many I love the definition by Mr. Martin Fowler, “the shared understanding that the expert developers have of the system design” ..! In a complex system with multiple services and varied tech stack this defination helps intutively understand why there is a need to draw.

Softwares evolve and are constantly under change. With this there is a natural need to understand the impact of a change on the overall system. This is critical to maintaining stability and continuity of the system. How many times has it happened that we find ourselves changing a piece scared to death about it causing a cascading impact in production, or blowing off a downstream system due to lack of awareness of the overall picture. This awareness is what Architecture diagram brings in.

So next time if you have a change ensure that the first activity within your sprint is to assess the architecture impact. Even if there is none it is important to capture a simple ADR (Architecture decision record) describing the requirement and capturing the conversation.

Best Practises out of personal experience

• Use colours to represent changing states
• Ensure that arrows follow a single convention (Data flow, Call Flow etc)
• Group multiple interfaces and move them to a different diagram basis the interoperability method (All external REST APIs are grouped under a single group)
• Different environments can have different diagrams with a graduation process guiding them
• Limit the details (Focus on requirements and eliminate the noise)

In the next post, I will try to a take a sample app draw it as I think might be good. Stay tuned.