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: learnwardleymapping.com/landscape/
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.
https://architectelevator.com/architecture/organizing-architecture/
https://architectelevator.com/architecture/organizing-architecture/
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.
https://www.innoq.com/en/blog/quality-value-chain-evolution/
https://www.innoq.com/en/blog/quality-value-chain-evolution/
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?”