Designing Software Architecture: What’s Changed and What’s Next

Five years ago I wrote the article Designing Microservice Architectures for People. Today I want to reflect on the content and see how it has aged. In the previous article, I put the emphasis on microservices. I also presented three ideas that would bring the focus to aligning your architecture with your organisation structure: The Single Responsibility Principle, Bounded Contexts and Conway’s Law. Let’s reflect on the ideas I presented.

The Focus on Microservices

In the previous article, I stated that microservice architectures were everywhere at the time. I don’t think that has changed, but we’ve stopped talking about them so much. Cloud platforms and serverless offerings seem to have detracted from the term microservices, even though the systems built using these technologies are often still microservices architectures, just implemented with different tools.

Recently, we’ve also seen talk from prominent companies about them migrating from distributed systems back to monoliths. As a result, monoliths are getting a little bit of a buzz again. I’m sure we’re not going to move to an era when everything is a monolith by default, but I do think we’re entering an era where the stigma of monoliths has gone, and they will more commonly be considered a viable option for parts of the systems we build.

In the previous article, I focussed on microservices because I was trying to address a problem which I was finding widespread — teams building “microservices” because of the hype, but ending up creating tightly-coupled architectures; or what we affectionately call distributed monoliths. However, everything I covered still applies in these other types of systems; in fact, most of the thinking around the ideas I presented pre-exists microservices altogether. From this perspective, I think that what I presented would still serve well with the term microservices wholly removed.

The Three Ideas

The three ideas I discussed—The Single Responsibility Principle, Bounded Contexts, and Conway’s Law—remain fundamental to designing robust software systems. These principles should be applied regardless of whether the architecture is monolithic, cloud-based, or microservices-based.

‍

1. The Single Responsibility Principle

This principle emphasises that a class or module should have only one reason to change. This concept remains crucial for ensuring that software is modular, maintainable, and adaptable.

‍

2. Bounded Contexts

Bounded Contexts help manage complexity by defining clear boundaries within a system. This concept continues to be essential for ensuring that different parts of a system can evolve independently while maintaining coherence.

‍

3. Conway’s Law

Conway’s Law highlights the relationship between an organisation’s structure and its software architecture. It underscores the importance of aligning team structures with system design to foster better communication and collaboration.

‍

Team Topologies

 In 2019, Matthew Skelton and Manuel Pais published their book Team Topologies. Like my original article, Team Topologies emphasises a team-first approach to software architecture. This idea is not new; for example, Michael Nygard’s book Release It! was published in 2007 and says “Team assignments are the first draft of the architecture.” — Matthew and Manuel reference this quote in their book.

“Your early decisions make the biggest impact on the eventual shape of your system. The earliest decisions you make can be the hardest ones to reverse later. These early decisions about the system boundary and decomposition into subsystems get crystallized into the team structure, funding allocation, program management structure, and even time-sheet codes. Team assignments are the first draft of the architecture. (See ​Conway’s Law​.) ”

— Release It! by Michael Nygard (2007)

However, Team Topologies explicitly calls out Fast Flow as the output you want from your optimised team and software architectures. The book is based on the four team types it presents (stream-aligned, platform, enabling and complicated subsystem). It suggests Conway's Law as one of the driving forces in designing teams, as does my original article and Michael’s book from back in 2007.

This set of four team types (and the interaction modes that go with them) is an incredibly useful tool for designing people-centric software. Team Topologies is a must-have when designing software architectures for people. However, the most interesting piece for me was that it brought the idea of Cognitive Load into the equation.

The Team Topologies book shows how we don’t want to just line software boundaries up with teams, but also we want to ensure that teams are designed and sized so that the cognitive load required to do work is comfortable. By managing the cognitive load in the team, not only does work flow through the value stream query, and individuals and the team also enter flow states more easily. Woody Zuill refers to the combination of these three types of flow as Flow++.

The rise of “Socio-technical”

This idea that building software is less dominated by the technical and heavily informed by the social is becoming more widespread. As a result, the term Socio-technical is becoming more prevalent.

“Socio-technical theory has at its core the idea that the design and performance of any organisational system can only be understood and improved if both ‘social’ and ‘technical’ aspects are brought together and treated as interdependent parts of a complex system. ”

— https://business.leeds.ac.uk/research-stc/doc/socio-technical-systems-theory

The term is not new; it was coined in the World War II era, but it has only recently become more commonplace when discussing software. If we see the software architecture and the social constructs in the organisation as two parts of the same system, then work will flow more naturally.

As this thinking evolves, some exciting ideas are being developed; for example, Nick Tune has published some socio-technical architecture patterns and an upcoming book on the topic.

Conclusion

The evolution of software architecture continues, with tools, patterns, and methodologies advancing rapidly. However, core principles like Conway’s Law, The Single Responsibility Principle, and Bounded Contexts remain timeless. As technology evolves—potentially with significant impacts from Artificial Intelligence—the interplay between humans and technology will continue to be crucial.

At Armakuni, we are dedicated to helping organisations navigate these evolving architectural trends. Our expertise in applying core principles and emerging practices ensures that your software architecture aligns with both technological advancements and organisational needs. Whether you're adapting to new technologies or refining existing systems, Armakuni’s offerings support you in achieving optimal software design and performance.