Why should you draw Software Architectures?

Photo by KOBU Agency on Unsplash

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, Infrastructure all in a single view while others are often selective about what is captured - Some will focus on direction of arrows, strength(thickness) of lines, colour of lines while others might doodle away - Choosing the amount of detail presented is a choice that is individual too unless stronger standards exists

All of them are Correct and there’s always more that a single diagram can communicate. But why are diagrams so effective in describing architectures ? The answers 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 the personal experience

  • Use colors 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.

Did you find this article valuable?

Support CafeIO by becoming a sponsor. Any amount is appreciated!