The design of the system reflects the communication structure of the organization that produced it.
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations — Melvin E. Conway
In other words, the software architecture will always reflect the communication structure of the organization. If you intended architecture does not match it, it will never be implemented as intended.
This happens because humans design systems by decomposition. The system is split into subsystems, and the designing group is split into smaller groups accordingly (each group owning one or more subsystems). This continues recursively until subsystem is small enough for a single team to handle all the details.
Subsystem dependencies reflect the communication structure of organization because whenever there is a collaboration between two subsystems, the interface must be designed and agreed upon. Therefore, the corresponding groups must communicate. Vice versa, if there is no connection between two subsystems, the corresponding groups will not communicate—they have no reason to.
Evidence in support of Conway’s law has been published by a team of Massachusetts Institute of Technology (MIT) and Harvard Business School researchers who, using “the mirroring hypothesis” as an equivalent term for Conway’s law, found “strong evidence to support the mirroring hypothesis”, and that the “product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization”. The authors highlight the impact of “organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop”. — Conway’s law - Wikipedia
- There are no boundaries in software development
- § Software Architecture
- Make sure the organization is compatible with the product architecture
- Architecture/management duality
- § Software Design
- § Architect role
- Organizational context as architectural constraint
- Just Enough Software Architecture: A Risk-Driven Approach