Get better APIs with Conway’s Law

Mel Conway formulated his famous law in 1967 and it was a reflection on how large organizations work and produce results. The “official version” (as published by Mel Conway himself) is as follows:

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

A more informal way of putting this may be to say that “the communication paths in an organization determine the structure of the system it designs,” or even further simplifying this that “the structure of an organization determines the structure of the system it designs.”

Either way, Conway’s law tells us that because designing complex systems is a complex task, it is inescapable that the way they are designed (looking at the design process as a collaborative task) determines the design that is being produced.

There has been some work on testing this hypothesis in the wild, but currently, there is no “scientific proof” that this law holds. However, many believe it to have some merit. Lacking formal proof, it is up to everybody to decide for themselves whether they think that the low holds. But at the very least it can serve as an inspiration and allow us to think about the interdependencies between design processes and design outcomes.

What Conway’s Law means for APIs

Conway’s law generally talks about complex design processes, and it seems relatively straightforward to apply it to the API space. We can look at API landscapes as the thing that is being designed, and organizations on their API journeys as the ones doing the design. Which then directly gives us the picture of a complex (and structured) organization as the system designer and the API landscape as the designed system.

In a more classical landscape of large and highly entangled teams, what we got, as a result, were monoliths with many internal dependencies, and these monoliths do resemble the structure of the IT mindset and organization that produced them.

Instead of clearly and cleanly delineating design components and developing them as encapsulated products, there were a lot of “shared elements” (such as everybody directly accessing databases) and as a result, oftentimes, the monolithic codebase would have many and very intricate dependencies, which made it hard to change isolated parts without potentially affecting many others.

The monolith story directly translates into the API space. The intricate dependencies and missing abstractions sometimes were directly translated into APIs, resulting in “System APIs” that simply were generic database access APIs, thereby tightly coupling implementation details on one side (the database schema) to consumers having to know all details of it.

In the API space, what’s typically the better approach is to think about why database access may be needed (“we need access to customer data”), to think about what kind of access is needed (“here are the things we want to do with customer data”), and to then design an API around this (“here’s an API that allows you to do what you want to do”).

Now we have more loosely coupled components, customer management can be changed and improved without affecting API consumers, and the API consumers get meaningful abstractions that they can easily work with.

If organizing yourself in a certain way predetermines the results, then getting these not-so-great APIs is an inescapable consequence of traditionally structured organizations. An interesting consequence of this then is that if you reorganize structurally, that should mean that what you’re designing now is starting to look different because of this changed organizational structure. This way of thinking brings us to the second way of how Conway’s law can be used.

The “Reverse Conway Maneuver”

The “Reverse Conway Maneuver” is named after the fact that instead of observing the result of a design process, you’re trying to change the expected result by changing the organizational structure. However, it should be noted that this still is simply an application of Conway’s law, i.e. it is not reversed, and in fact, Mel Conway has stated that he is not in favor of that specific label.

Many organizations today are following this route by embracing agile methods and reorganizing themselves into smaller and domain-focused teams with more autonomy. And to some extent, one could argue that what many of these organizations are after is exactly Conway’s law: They want a system that’s better modularized so that it can be changed more easily and more quickly.

Generally speaking, it seems that this maneuver works more often than not. And APIs play a crucial role in this because ideally, teams use those as their main collaboration mechanism, meaning that the communication paths of the teams now are identical with the structure of the designed system.

But this also means that the organization’s structure becomes absolutely critical to get right, because if it is not structured well, then this translated into a system that also is not structured well.

Methods such as Business Capability Mapping (BCM) now become even more important than before. In the old world, it was easier to “hack” things because the monolithic system meant that there were no barriers inside it. In the new world, when capabilities are not modeled according to business needs, then business needs also cannot be addressed easily by using a capability’s API.

What this shows is that using Conway’s law can be very powerful, because your chances of getting a well-structured design can be “hacked” through organizational changes. But this also shows that it’s critical to get these organizational changes right.

Conclusions

Putting it all together, Conway’s law teaches us two important lessons: The first lesson is that no matter how hard you try, you cannot design a complex system that exhibits a certain structure unless you align your organization accordingly.

The second lesson is that if you do reorganize into a more modular structure to produce a better result, it becomes critically important to make sure that the organizational structure aligns with the goal structure of the system that you’re building.

If you’re interested in more details about Conway’s law and how it creates a direct relationship between organizational structure and a structured design, please check out the following video.