Microservices: Revisiting Conway's Law

Conway’s Law applies to modular software systems and states that:

"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure".

Conway’s Law was brought to my attention a few years ago whilst in dialogue with a major Swiss Investment Bank, who were referencing this as a limitation on their ability to build software products. Intuitively, I could see that this might not be such a good thing, but Melvin Conway came up with this in the 60’s right and it wasn't like this could be all that bad, could it? So with a certain curiosity I engaged in a conversation to better understand these concerns. What I discovered was that it's more like “a software system whose structure closely matches its organization’s communication structure works better (defined broadly) than a system whose structure differs from its organization’s communication structure”. “Better” in this context means higher productivity for the people developing and maintaining the system, through more efficient communication and coordination, and higher quality. All of a sudden what previously seemed intuitively to make sense was now clearly making sense - productivity and quality being both tangible and desirable.

Fast forward to today, the adoption of Microservices provides us with further reason to suggest that Conway’s Law is even more relevant. Microservices, a pragmatic implementation of Services Oriented Architecture (SOA) based on loosely coupled API’s is well suited to the implementation of small teams working on autonomous components. Martin Fowler and James Lewis article goes into more depth on the subject, highlighting the fact that these architectures allow organizations much more flexibility in aligning the architecture of their systems to the structure of their teams in order to ensure that Conway’s law works for us.

That naturally leads us to reflect on the implications if we can't make Conway's Law work for us? Under what circumstances might that be the case? Let’s consider an instance where an organizations structure and software are not in alignment. Typically, this arises where a distributed team are put to work on a monolithic codebase. The communications channel that Conway refers to are not aligned. Generally, this leads to frustration and tension within the implementation teams, resulting in a loss of efficiency and diminished quality.

The alternative to this would be a modular codebase (enabled by Microservices) that can be worked on by small distributed teams, located anywhere. Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system.

Microservices embraces Conway's Law to leverage the power of distributed teams, making distributed teams the norm irrespective of whether they are located onshore, offshore or nearshore. Enterprises that are unable to engage a distributed team due to monolithic products or codebases, are likely to be at a competitive disadvantage or at worst case markedly increasing their technical debt.