In this article I would like to give a few examples how the organization of software development teams and the system architecture influence each other.
Developing Software systems is just an example of systems design in a more general sense, so we find the well known “Conway’s Law” which, according to this wikipedia article is cited as:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
– M. Conway How do Committees invent?
I was joining a small team working on an ecommerce marketplace platform. Because they also wanted some marketing pages to go with this, they have integrated a CMS module inside their marketplace. This has lead to a tight coupling of the CMS and the marketplace, which worked for a team of 2-3 people. Conway’s law in its most basic manifestation.
As the organization grew, this was creating problems, because the CMS was now tightly integrated and a lot of the assumptions of the marketplace system were reflected in the CMS module.
A better approach would have been to run this as two separate systems.
If we had two different teams responsible for the separate concerns of market place and public marketing frontend, then the separation of systems would have come naturally.
Of course this is not the only way to get to the desired system design, but it shows that the organization you set up has an influence on the system design you build.
What follows out of it
As a consequence, you need to think organization and system design together. While the organization structure is a constraint for the system design (Conway’s law) it can also be used to purposefully set a constraint to influence the system design, or to make a certain system design easier to follow.
The Inverse Conway’s Law
This gets us to the topic of this article: How can we use organization design to drive system design?
When designing organizations which design systems you > should align the organization structure with the desired communication structure of these systems.
– Tobias Abarbanell
How to apply it
Understand which parts of your system you want to be tightly or loosely coupled.
- Keep together what belongs together
- Keep separate what should know each other only as a “black box”
If you want to build a multipurpose API for multiple clients (Web, mobile, etc.) then it the API and its clients are good candidates to separate. This way you can make sure that the client only uses the documented interface of the API, and not any implementation assumptions it happens to know.
Also, you do not want some client developers negotiating implementation details of the API internals “over a coffee” with the backend developers. This could easily break the re-usability of the API for other clients.
If you build a multipurpose API for Mobile, Web, and other clients it may be actually helpful to separate the client developers from your API developers in different teams, which should communicate mainly over the published API functionality. This way any “whitebox” knowledge for the API users can be eliminated and the “multipurpose” property of the API is easier to achieve.
I just wanted to show that Conway’s law is not a one-way street, and while it cannot be ignored without bad consequences, it can actually sometimes be used to your advantage.
Looking for something else?
Enjoy some of my cat videos.
Think cat videos are bullshit?
Then try this: Cowshit is the new Bullshit.