ConwaysLaw

Pretty much all the practitioners I favor in Software Architecture are deeply
suspicious of any kind of general law in the field. Good software architecture
is very context-specific, analyzing trade-offs that resolve differently across a wide range
of environments. But if there is one thing they all agree on, it’s the importance
and power of Conway’s Law. Important enough to affect every system I’ve
come across, and powerful enough that you’re doomed to defeat if you try to
fight it.

The law is probably best stated, by its author, as:

Any organization that designs a system (defined broadly) will produce a
design whose structure is a copy of the organization’s communication
structure.

— Melvin Conway

Conway’s Law is essentially the observation that the architectures of
software systems look remarkably similar to the organization of the
development team that built it. It was originally described to me by saying
that if a single team writes a compiler, it will be a one-pass compiler, but
if the team is divided into two, then it will be a two-pass compiler. Although
we usually discuss it with respect to software, the observation applies broadly
to systems in general.

As my colleague Chris Ford said to me: “Conway understood that software
coupling is enabled and encouraged by human communication.” If I can talk
easily to the author of some code, then it is easier for me to build up a rich
understanding of that code. This makes it easier for my code to interact, and
thus be coupled, to that code. Not just in terms of explicit function calls,
but also in the implicit shared assumptions and way of thinking about the
problem domain.

We often see how inattention to the law can twist system architectures. If
an architecture is designed at odds with the development organization’s
structure, then tensions appear in the software structure. Module interactions
that were designed to be straightforward become complicated, because the teams
responsible for them don’t work together well. Beneficial design alternatives
aren’t even considered because the necessary development groups aren’t talking
to each other.

A dozen or two people can have deep and informal communications, so Conways Law
indicates they will create a monolith. That’s fine – so Conway’s Law doesn’t
impact our thinking for smaller teams. It’s when the humans need organizing
that Conway’s Law should affect decision making.

The first step in dealing with Conway’s Law is know not to fight it. I
still remember one sharp technical leader, who was just made the architect of a large
new project that consisted of six teams in different
cities all over the world. “I made my first architectural decision” he told
me. “There are going to be six major subsystems. I have no idea what they are
going to be, but there are going to be six of them.”

This example recognized the big impact location has on human communication.
Putting teams on separate floors of the same building is enough to
significantly reduce communication. Putting teams in separate cities, and time
zones, further gets in the way of regular conversation. The architect
recognized this, and realized that he needed take this into account in his
technical design from the beginning. Components developed in different
time-zones needed to have a well-defined and limited interaction because their
creators would not be able to talk easily.

A common mismatch with Conways Law is where an ActivityOriented
team organization works at cross-purposes to feature development. Teams
organized by software layer (eg front-end, back-end, and database) lead to
dominant PresentationDomainDataLayering structures, which is
problematic because each feature needs close collaboration between the layers.
Similarly dividing people along the lines of life-cycle activity (analysis,
design, coding, testing) means lots of hand-offs to get a feature from idea
to production.

Accepting Conway’s Law is superior to ignoring it, and in the last decade,
we’ve seen a third way to respond to this law. Here we deliberately alter the
development team’s organization structure to encourage the desired software
architecture, an approach referred to as the Inverse
Conway Maneuver . This approach is .often talked
about in the world of microservices, where advocates
advise building small, long-lived BusinessCapabilityCentric teams
that contain all the skills needed to deliver customer value. By organizing
autonomous teams this way, we employ Conway’s Law to encourage similarly
autonomous services that can be enhanced and deployed independently of each
other. This, indeed, is why I describe microservices as primarily a tool to
structure a development organization.

Domain-Driven Design can play a role here to help define organization
structures, since a key part of DDD is to identify BoundedContexts.
A key characteristic of a Bounded Context is that it has its own
UbiquitousLanguage, defined and understood by the group of people
working in that context. Such contexts form ways to group people around a
subject matter that can then align with the flow of value.

The key thing to remember about Conways Law is that the
modular decomposition of a system and the decomposition of the development
organization must be done together. This isn’t just at the beginning,
evolution of the architecture and reorganizing the human organization must go
hand-in-hand throughout the life of an enterprise.

Acknowledgements

Bill Codding, Birgitta Boeckeler, Camilla Crispim, Chris Ford, Gabriel
Sadaka, Matteo Vaccari, Michael Chaffee, and Unmesh Joshi

reviewed drafts of this article and suggested improvements