[Article series]

light My Insights: Architecture is not just about technical design (or dictating top-down a design for teams to build), it is much more. As an industry we need to embrace it and make it clear so that we can benefit from the power it brings to our developments: set clear direction for our developments, make sure our teams are equipped and are capable of owning the envisioned architecture and be enabled to improve their product(s) continuously. If we don’t do that, we are losing a great opportunity of bringing clarity and alignment to our developments.

Analysis & Summary

Simon Brown is undoubtedly one of the major contributors to modernize and “democratize” how we approach Software Architecture. He has been a major inspiration for me for 10+ years and this article series is a good “gist” of the core dimensions of Simon Brown views Software Architecture.

The series starts with “Software Architecture isn’t about big upfront design”, where Simon dissects the basic elements to look for when approaching software architecture. This is the “bare minimum” to set us on a good path, and from there iteratively address new elements as you learn more things (with this we can make more informed decisions).

Then he goes to a point very dear to me: “Every software team needs technical leadership”, i.e: teams need to have technical leadership in order to continuously stay aligned, look for and address the important decisions (= architecture), mitigate risks and consistently grow the technical vision of their product(s). This can be owned by a single person or by the whole team, but must be explicitly set.

In the third article Simon touches on the fact that “Software Architecture role is about coding, coaching and collaboration”, i.e.: make sure to not focus just in one of these dimensions. This is one of the most classic mistake of first time Software Architects - continue over-focusing on the code and forget about the coaching and collaboration dimensions.

The fourth article focuses on the fact that Architecture documentation does not necessarily mean UML and complex documentation. Here Simon shares his C4 Model, and how we can use it to document architecture by addressing different perspectives, which represent different levels of detail (like a map, and zooming into a map). This approach enables a pragmatic and simple approach where the people relevant for the discussion can be easily involved.

The last article titled: “A good software architecture enables agility” is in my view one of the major realizations that a lot of people in the industry need to develop: architecture is not a blocker for agility, i.e.: do not panic if you need to spend some hours or days investing on understanding and creating a clear alignment and strategy on how to proceed on building your product. That is in fact a crucial exercise to enable your agility and move forward at high-velocity (clear direction and high speed).