Changing software architecture by changing teams.
Many years after Melvin Conway published “How Do Committees Invent?”, he summarised his 45 paragraphs thesis into one sentence:
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
Conway’s Law suggested that the software architecture eventually copies the communication structure.
I’ve seen a common example of frontend and backend teams.
This is your desired architecture.
Then, you start to organize the teams based on expertise, frontend, and backend.
Eventually, the backend team works on the API and Back-office inside the same application code and deploys it as a single application.
It also proves the quote from Ruth Malan:
If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins. — Ruth Malan
However, does it apply to monorepos?
Conway’s Law and Software Modularity
We have a monolithic application. Many teams contribute to the monorepo. Does Conway’s Law apply?
In 2008, Alan D. MacCormack, John Rusnak, and Carliss Y. Baldwin conducted a test on a “mirroring” hypothesis:
Loosely-coupled organizations will tend to develop products with more modular architectures than tightly-coupled organizations.
In the research, they analyzed software that fulfill the same function but that have been built by two opposite modes of organizations, commercial (tightly coupled) and open-source (loosely coupled). They used a technique called Design Structure Matrices (DSMs) to visualize the architectures of different software and to calculate metrics to compare their levels of modularity.
Their results revealed significant differences in modularity.
In commercial organizations, the developer teams were colocated. They solved problems by face-to-face interaction and maximized the performance by taking advantage of the easy accessibility to other modules’ developers. Naturally, they produced tightly coupled (image on the left) software.
In open-source organizations, most developers rarely or never meet. With limited communications, the benefits of modularity are greater. The software needs to be modular (image on the right) for contributors to easily understand enough of a design to develop new features or fix defects, without the cost of affecting other parts of the system.
Conway’s Law and Team Design
When the organization is growing from one small, cross-functional team to many bigger, specialist teams, the teams are organized around the technology. You will have a couple of frontend teams (web and mobile) and a backend team.
On a daily basis, every team collaborates closely with each other to deliver features on all platforms. Your communication paths look like this:
Naturally, you produce the software architecture that mirrors the communication paths.
On the other hand, if you organize cross-functional teams and each of them works independently, you are producing a service-oriented or microservices architecture.
Does that mean designing software architecture is pointless? The short answer is no.
The ‘Inverse Conway Maneuver’ recommends evolving your team and organizational structure to promote your desired architecture. — Inverse Conway Maneuver
Software architecture is critical in building fast and safe software. Optimize your team structure to achieve the desired architecture and support the ability of the team to get the works done faster and safer.