This is a backup version from an older Twitter-Thread of mine.
Do we need “software architecture?” Some thoughts that might help you in our busy software development world.
A software system has to be extended and maintained, especially when it is successful. Simon Wardley has an excellent term for this: “evolution.” He further says, “Everything evolves through supply and demand competition.” But what does that mean?

Components (like software systems) start as a vague idea. Then, when there is a demand in a market AND we can fulfill those needs, the component evolves. There are different stages with different characteristics:

Especially for software systems, there is a critical part: When many users – with all their individual needs – want to use the software system, software developers must fulfill all those needs to keep the software in business.
This situation leads to plenty of work. Most companies answer with more developers and create more teams to implement all those needed features to move forward.
But this often leads to new problems. More teams mean more coordination efforts between the teams and within the team (the later because of the onboarding of new team members). The software system evolved into a more complicated, socio-technical system with many working parts.
At this point, software architecture gets more attention. Team members become lead engineers who care about architectural issues but quickly become bottlenecks. Other ways of organizing architectural work are needed to meet demands and stay competitive.

But more than just introducing new roles is required. With success arises the need for more quality. Aspects like system performance or security become more important, leading to even more work that needs to be coordinated and prioritized.

Especially in the critical phase of evolution, it gets tricky: More and more qualities come into play that are not directly visible to the end users or product managers. It’s getting harder and harder for developers to justify investments in those qualities.
The second rise of software architecture occurs. Feature development and architectural work have to be balanced. If you miss this phase, you get burned by product management because you missed making the needs for those qualities visible. You get drowned in feature development.
Thus, architectural work must create a counterweight, especially a connection between business goals and architectural solutions are required. Creating a shared vision and clarifying the “rules of the game” (e.g. principles and risk appetite) between all participants is needed.
When do you see that more “software architecture” is needed? There are many indicators, e.g., different views of the evolution of your software system. In this case, speak up, make the different perceptions visible and act accordingly. Be a software architect!
Do we need “software architecture?”

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.