Inverse Conway Maneuver law: Transform your Organisation
Let’s see first what is Conway Law:
In April-1968 Melvin Conway said in his paper “How do Committees Invent?”:
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
- This basically means that the style of code (or services you built ) should reflect the way the people and teams in your company communicate or produce software architectures matching their current structure, which can lead to outdated and lower quality products. So basically this is outdated in the era of DevOps, tech ops and Agile.
- If to follow this law this might cause the creation of monolithic services or Codebase and create more dependencies and might cause more problems. If you’ve ever programmed in a less-than-perfect collaborative environment, you’ve probably noticed that your code ends up more closely meshed with the teammates you talk to the most.
- In the time of less dependent service (or separation of concern) techies came up with Inverse Converse Law’s
“Technology change is driving changing customer preferences and behavior, which in turn are driving organizational change across increasingly software-driven enterprises. The causality question behind Conway’s Law, therefore, is less about how changing software organizations can lead to better software, but rather how companies can best leverage changing technology in order to transform their organizations,” says Bloomberg.
“organizations which radically change their system design should expect changes in communication structure” Roy van Rijn
- Reverse Logic is structuring your system into independent, self-contained services so that teams can work independently.
- Microservices architectures aim to increase velocity, so they apply Conway’s law in reverse to structure the system to achieve this noble goal
- Reverse Logic follows to create fewer dependencies and can grow faster as compared to Conway Law.
- Teams only focus on what they building and how they communicate with other pieces of code or microservices.
That’s It
Happy Learning.