Conway's Law & System Design
Today nobody wants to associate themselves with monolithic architecture.
But how would you feel if I tell you that it is just a reflection of the team communication and organisation style on systems design.
Conway's Law, named after computer scientist Melvin Conway, has had a profound impact on software development methodologies and practices over the years.
It states that the structure of a software system will mirror the communication structure of the organization that designs it.
Conway's law never talked about what type of system design we would need, but rather the channels of communication and interaction between teams will end up dictating the system’s architecture.
In other words, the architecture of a software system is a reflection of the social boundaries of the teams that develop it.
Lets look at the some of the well known org structure and system design produced and popular in these orgs.
Functional Structure (Manufacturing, Government)
An organizational structure in which employees are grouped by their specific functions or departments (e.g. marketing, finance, production).
System Design : May result in a monolithic software system that is difficult to maintain and scale, as changes to the system may require coordination and approval from multiple levels of management.
Divisional Structure (Coca-Cola, IBM)
An organizational structure in which employees are grouped by product, geography, or customer base. Each division operates as a separate entity with its own functional departments.
System Design : May lead to a software system that is modular (SOA) and easy to maintain, as each division may be responsible for a specific area of the system. However, there may be challenges in integrating different parts of the system across divisions.
Matrix Structure (Procter & Gamble, NASA)
A hybrid org structure that combines elements of functional and divisional structures. Employees are assigned to both functional departments and specific projects, allowing for flexibility and collaboration across teams.
System Design : May lead to a software system that is flexible and adaptable to changing project needs (Domain Driven Arch), as each project team is responsible for a specific aspect of the system. However, communication and coordination between teams may be challenging, and there may be duplication of effort between teams.
Flat Structure (Zappos, Buffer)
An organizational structure with few or no levels of management between top executives and front-line employees. This approach emphasizes collaboration and empowerment, and allows for more rapid decision-making.
System Design : May lead to a software system that is highly innovative and responsive to user needs (Lean Arch), as teams have a high degree of autonomy and are able to make decisions independently. However, there may be a lack of oversight and direction in the design of the system.
Cross-Functional Teams (Spotify, Amazon)
Teams comprised of individuals with diverse skills and backgrounds who work together on specific projects or products. This approach allows for greater collaboration, flexibility, and innovation.
System Design : May lead to a software system that is highly modular and scalable (MicroServices), as each team is responsible for a specific aspect of the system. However, there may be challenges in coordinating between different teams, and there may be duplication of effort between teams.
Micro Teams (Netflix, Google)
Small, autonomous teams responsible for a specific aspect of the business. Micro teams typically have a high degree of autonomy and are able to make decisions independently.
System Design : May lead to a software system that is highly focused and responsive to specific business needs (Microservices). However, there may be a lack of oversight and coordination between teams, and there may be challenges in integrating different parts of the system.
In the meantime, if you want to learn about Popular System Architectural Style, do read my previous post on the same.
As micro services is a de-facto selection in this age, we must plan to provide autonomy and flexibility to small teams so that they can develop, deploy and scale better.
It is common for a microservices team to include members with a variety of skills and expertise, such as QA, UI design, Devops etc but in reality micro services team pull expertise from QA, UI Design, Devops etc on need basis which sometimes do create communication delays situations.
But what if we plan the system design first and team after?
Reverse Conway's Law, also known as the Inverse Conway Maneuver, is the idea of intentionally designing an organization's structure to achieve the desired software architecture.
While Conway's Law suggests that software architecture will reflect the communication structure of the organization, the Inverse Conway Maneuver uses this principle to influence the software architecture by changing the organizational structure.