At a couple of consulting engagements, I observed how Conway’s law is still relevant and used it to design better integration between software components.
This blog post maps how organisation of software development teams in organisations doing API development can lead to a smoother/faster-to-market product and how this relates to a well know observation made by Melvin Conway.
API development teams and modules
The observation was the API modules were divided into 3 “modules” – service providers, service consumers and the API gateway providers aka the “new middleware guys”.
Side Note: This pattern can also be seen in Enterprise Application Integration projects where backend applications rely on a middleware to send/receive data in a canonical format with each other and a portal …
The impact of have a 3 team organisation was observed during the software development lifecycle and maintenance.
During the development process, there were 3 modules created – the core service, the gateway component and the consumer component (Mobile apps, Web UI etc). This led to fragmented testing, duplicated tests across teams, general confusion regarding service availability monitoring and support responsibility in non-prod environments. Often core service developer would refuse to communicate with end users, relying on the middleware/gateway team to be the first-point-of-contact.
Similarly operational support was fragmented – the gateway enabling team had to monitor the core services, alert the backend teams and relay information across multiple teams leading to bottleneck.
The business impact were therefore delayed projects, frustrated testers and higher resolution times for incidents.
We use the concept of Software Cohesion to understand why having multiple teams, and different modules of software, have such an impact on the SDLC and operation of an API.
Cohesion is nothing but how closely components of a software are related to each other, a formal definition is as follows:
“cohesion measures the strength of relationship between pieces of functionality within a given module” 
In an API development context, the 3 components – core service, gateway and consumer code need to be analysed for cohesiveness.
The simplest argument would be to have a single module, one team building everything and be done with it! However this presents a new challenge since there may be more than one client (Mobile, Web, 3rd party – B2B) consuming the core service.
We believe that there should be at-the-most two modules – Service and Consumer. The service team would therefore own the gateway component, own the end-to-end testing of the API and be the first point of contact during development and support (You build it, you own it!)
It is important to therefore understand and determine which components of a software are related – there is cohesion vs which are not. Doing so can help decouple systems while maintaining integrity within related components.
So what’s the fix?
Recognise which components are closely related and which components can be decoupled. Decoupling systems that are closely related – by direct action or by accident can lead to communication issues, maintenance issues and chaos in a project.
In an API development lifecycle, we found the best practise is to allow service providers to own and provision the API gateway components (instead of a separate team of middleware specialists)
This empowers the API developers and allows them to communicate/test with the consumers directly while giving them ownership and responsibility of the overall solution.
We observed certain pain-points emerged during API development process due to ownership of software components and traced the root to organisation of teams per Conway’s law.
A study of the systems and their dependencies showed that getting core service teams to own the entire API stack (from the gateway down) helped significantly reduce friction during the SDLC and improve operational support.