SIGNIFICANCE OF CONWAY’S LAW IN API INTEGRATION
In 1967, Mel Conway came up with his famous law, which was a reflection on how large companies operate and achieve results. The following is the “official version” (as released by Mel Conway himself):
“The communication pathways in an organisation determine the structure of the system it creates,” or, even more simply, “the structure of an organisation determines the structure of the system it designs,” is a more informal way of saying it.
In any case, Conway’s law states that because creating complex systems is a difficult effort, it is unavoidable that the manner they are created (as a collaborative task) will dictate the design that is generated.
Although considerable work has been done to test this concept in the wild, there is currently no “scientific proof” that this law holds. Many others, however, believe it has some merit. Without explicit proof, everyone must determine for themselves if they believe the low holds. At the absolute least, it can act as motivation and prompt us to consider the interconnections between design processes and design outputs.
What Conway’s Law means for APIs
Conway’s law refers to complex design processes in general, and it appears that applying it to the API space is pretty simple. API landscapes can be thought of as the item that is being designed, and organisations on their API journeys as the designers. As a result, we get a picture of a sophisticated (and organised) organisation acting as the system designer, and the API landscape acting as the planned system.
We obtained monoliths with many internal dependencies in a more traditional environment of huge and heavily entangled teams, and these monoliths match the structure of the IT mindset and organisation that produced them.
There were many “shared elements” (such as everyone directly accessing databases) instead of clearly and cleanly delineating design components and developing them as encapsulated products, and as a result, the monolithic codebase would often have many and very intricate dependencies, making it difficult to change isolated parts without potentially affecting many others.
The monolith storey has a direct application in the API space. Complex dependencies and lacking abstractions were sometimes directly translated into APIs, resulting in “System APIs” that were just general database access APIs, closely binding implementation details on one side (the database schema) to consumers having to know all of them.
In the API area, it’s usually best to consider why database access is required (“we need access to customer data”), what sort of access is required (“here are the things we want to do with customer data”), and then design an API around that (“here’s an API that allows you to do what you want”).
Now that we have more loosely connected components, we can alter and improve customer management without harming API consumers, and API consumers can work with meaningful abstractions.
If the way you organise yourself influences the outcomes, then having these not-so-great APIs is an unavoidable effect of traditionally formed organisations. As a result, if you rearrange structurally, what you’re designing today should start to look different as a result of the new organisational structure. This method of thinking leads to the second application of Conway’s law.
The “Reverse Conway Maneuver”
The “Reverse Conway Maneuver” gets its name from the fact that instead of observing the outcome of a design process, you try to alter it by altering the organisational structure. It should be emphasised, however, that this is still just an application of Conway’s law, i.e., it is not reversed, and Mel Conway has stated that he is against that exact designation.
Many firms are taking this path now, adopting agile practises and reorganising themselves into smaller, more autonomous domain-focused teams. To some extent, one could argue that many of these organisations are pursuing Conway’s law: they desire a system that is more modularized, allowing them to change it more readily and fast.
In general, it appears that this strategy succeeds more often than not. APIs play a critical part in this since, in a perfect world, teams would use them as their primary means of cooperation, implying that the teams’ communication pathways are now identical to the structure of the designed system.
But this also means that the organization’s structure is crucial to get right, since if it isn’t, it will transfer into a system that isn’t.
Methods like Business Capability Mapping (BCM) are now even more significant than they were previously. It was easy to “hack” things in the previous world since there were no restrictions inside the monolithic system. When capabilities are not modelled according to business needs in the new world, business demands cannot be easily serviced by using a capability’s API.
This demonstrates how Conway’s law can be quite effective, because organisational modifications can “hack” your chances of achieving a well-structured design. However, this demonstrates how crucial it is to make these organisational changes properly.
CONCLUSION
The second lesson is that if you do reorganise into a more modular structure to get a better outcome, it’s crucial to make sure that the organisational structure matches with the system’s objective structure.
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 contact info@keleno.com
