𝗬𝗼𝘂 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗶𝘀 𝗮𝗹𝘄𝗮𝘆𝘀 𝗰𝗼𝗺𝗽𝗹𝗲𝘅 𝗮𝘀 𝘆𝗼𝘂𝗿 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻

This is Conway's Law. Melvin Conway wrote it down in 1967:

"Organizations who design systems are constrained to produce designs which are copies of the communication structures of these organizations."

This means that the structure of a software system is shaped by the structure and communication patterns of the team building it. The team's needs win over the system's needs, even when nobody means for that to happen.

The patterns fall straight out:

- 𝗦𝗺𝗮𝗹𝗹, 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝘁𝗲𝗮𝗺𝘀 produce modular service architectures.

- 𝗟𝗮𝗿𝗴𝗲, 𝗰𝗼𝗹𝗹𝗼𝗰𝗮𝘁𝗲𝗱 𝘁𝗲𝗮𝗺𝘀 produce monoliths.

A company split into 𝗳𝗿𝗼𝗻𝘁𝗲𝗻𝗱, 𝗯𝗮𝗰𝗸𝗲𝗻𝗱, 𝗮𝗻𝗱 𝗱𝗮𝘁𝗮𝗯𝗮𝘀𝗲 departments will ship a three-tier system with painful integration between the tiers. Each tier was optimized by a different team for a different goal.

In a broad sense we can even say that 𝗛𝗥 𝗱𝗲𝗳𝗶𝗻𝗲𝘀 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀.

Amazon learned this the hard way. In the early 2000s, the company was a monolithic organization shipping monolithic software. As they scaled, the system started to block innovation. Teams couldn't ship without coordinating across the entire codebase. The architecture mirrored the org chart, exactly as Conway predicted.

Bezos changed both at once. The monolith broke into hundreds of microservices, each owned by a "two-pizza team" of 5 to 10 engineers who owned the service end-to-end: design, deployment, on-call.

This is the 𝗜𝗻𝘃𝗲𝗿𝘀𝗲 𝗖𝗼𝗻𝘄𝗮𝘆 𝗠𝗮𝗻𝗲𝘂𝘃𝗲𝗿. Instead of letting the org shape the software by accident, you reshape the org to produce the software you want.

What is interesting is that the most organizations ignore Conway's Law. They treat org structure and software architecture as independent things. They draw clean architecture diagrams, then watch the system shape itself around their org chart anyway.

What are your experiences with Conway's Law?

Image: Manu Cornet (bonkersworld. net).