Designing Software Architectures For People in 2023

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

There is very little to say about the three ideas I presented. Their usefulness and importance today are no different from how it was five years ago. They should be applied when building software systems; whether monolithic, cloud-based or microservices.

That said, there has been some interesting additional thinking that has come out since my previous article…

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!
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.

Source: 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 ideas behind improving the ways that large organisations are building software are still evolving and improving. What I have taken away from this reflection, is that tools, patterns, architectures and methodologies come and go, but solid underlying principles persist. An idea Melvin Conway came up with in 1968 is more relevant now than it was then. How systems are implemented over the next decade will change (I’m sure Artificial Intelligence is going to have a huge impact), but the interplay between humans and technology will remain paramount. Ideas like Conway’s Law, The Single Responsibility Principle, Bounded Contexts, building stream-aligned teams, and optimising for flow and low cognitive load will outlive any technology or architectural pattern.