In 1968 Melvin Conway published an observation that has since outlived most of the technology it was written about: organizations that design systems are constrained to produce designs that copy their own communication structures.
It sounds like a curiosity. It is closer to a law of physics.
Siloed departments produce siloed systems. Departmental budgets produce departmental technology choices. Teams measured locally produce locally optimized architectures. None of this requires anyone to make a bad decision — every actor can behave sensibly within their scope and the result is still fragmentation, because no one is accountable for the whole.
This leads to the uncomfortable conclusion for anyone who owns an architecture function: governance cannot win this fight indefinitely. You can publish principles, run review boards, and maintain a target-state model, and the organization will still quietly re-fragment your systems — faster than governance can integrate them — as long as reporting lines, incentives, funding models and decision rights point in different directions. Architecture divorced from organizational design is a cosmetic exercise.
The four levers that actually decide your architecture
Not the diagrams. These:
- Reporting lines — who a team answers to determines whose problems it optimizes for.
- Incentives — what gets measured locally gets optimized locally.
- Funding models — allocate budget per department and technology decisions will follow departmental boundaries. This is the quietest and most powerful of the four.
- Decision rights — the real architecture is whatever the people with authority to say yes actually approve.
Change any of these and the architecture moves, whether or not anyone updated the model.
The maneuver
If the force is unavoidable, use it. This is the inverse Conway maneuver: decide the architecture you want, then design the team structure, boundaries and funding to produce it. Team Topologies made this explicit; the Accelerate research supports it empirically.
The Corollary surprises people: more communication between teams is not automatically better. Many-to-many communication tends to produce tangled, tightly coupled systems — the organizational chatter becomes the integration pattern. What you want instead are boundaries good enough that teams do not need constant coordination: bounded contexts aligned to team boundaries, APIs on those same lines, test doubles and virtualization so a component can be verified in isolation. Decoupled teams and decoupled systems are the same achievement viewed from two angles.
The vendor-era complication
There is a modern twist Conway could not have anticipated. In a SaaS-heavy enterprise, complexity grows even when every individual platform is well designed — because the enterprise is no longer one system. It is an ecosystem of vendor-defined architectures, each importing its own design decisions, its own data model, its own assumptions about how work flows. You are no longer only mirroring your own communication structure; you are absorbing everyone else's.
That is a large part of why enterprise architecture exists as a discipline at all. Enterprises are systems of systems — technology, people, processes, data, governance, incentives, culture — where changes ripple with delayed and nonlinear effects. Local optimization, applied everywhere, fails at enterprise scale.
The question worth asking every quarter
Mel Conway himself suggested the diagnostic, and it belongs in every architecture review:
Is there a better design that is not available to us because of our organization?
If the answer is yes — and it usually is — you have just found the real work. And it probably isn't a diagram.
One practical rule
When launching any new capability, design the operating model and the architecture together, in the same conversation, with the same people. Do them separately and the org chart silently overrides your target architecture. It always wins on a long enough timeline, because it is the thing that persists after the programme ends.
Why it matters
For anyone passionate about enterprise architecture, this is the difference between practising the discipline and performing it.
- Governance has a ceiling. Principles, review boards and target-state models are necessary but insufficient. If the four levers — reporting lines, incentives, funding, decision rights — point in different directions, the organization re-fragments systems faster than governance can integrate them. Recognizing the ceiling is what moves an architect from producing artefacts to changing outcomes.
- Funding is an architectural decision in disguise. Per-department budget allocation quietly defeats any integration effort, no matter how good the target model. Anyone who wants coherent architecture has to care about how money is allocated — which is usually someone else's remit, and that is precisely the point.
- New capabilities are the rare open window. When a new function, platform or practice is being stood up, the operating model and the architecture can still be designed together. That window closes fast, and after it closes the org chart wins by default because it outlives the programme.
- The diagnostic belongs in every review. Mel Conway's own question — is there a better design that is not available to us because of our organization? — surfaces the constraint that architecture documents systematically hide.
- Vendor ecosystems raise the stakes. As more of the estate becomes SaaS, an architect is no longer only mirroring one communication structure but absorbing every vendor's design decisions too. The discipline gets harder, not easier, as build shifts to buy.
Sources
- The Art of Enterprise Architecture — Ashraf Elessawy
- Team Topologies — Matthew Skelton & Manuel Pais
- Accelerate — Nicole Forsgren, Jez Humble, Gene Kim
- Lean Enterprise — Jez Humble, Joanne Molesky, Barry O'Reilly
- The DevOps Handbook — Gene Kim et al.
- Data Mesh — Zhamak Dehghani
- Modern Software Engineering — Dave Farley
- Fundamentals of Software Architecture — Mark Richards & Neal Ford
Flashcards
Q1: What does Conway's Law state?
Organizations that design systems are constrained to produce designs that copy their own communication structures (Melvin Conway, 1968).
Q2: What is the inverse (reverse) Conway maneuver?
Deliberately structuring teams to match the architecture you want the system to have — letting the organizational force work for you instead of against you.
Q3: Why can't governance alone fix architectural fragmentation?
Because architecture cannot indefinitely compensate for misaligned incentives, per-department funding, and structural silos — the org re-fragments the systems faster than governance integrates them.
Q4: Is more inter-team communication good for architecture?
Not necessarily — many-to-many communication tends to produce monolithic, tightly coupled systems. Good boundaries reduce the need for coordination.
Q5: What diagnostic question does Mel Conway suggest asking continuously?
Is there a better design that is not available to us because of our organization?
Q6: Which four organizational-design elements drive system architecture (Elessawy)?
Reporting lines, incentives, funding models, and decision rights — together they shape systems more than any architecture document.
Q7: What happens to technology decisions when budgets are allocated per department?
Technology decisions follow departmental boundaries — each department optimizes locally, quietly re-fragmenting any integration effort.
Q8: What is "enterprise thinking" (the essence of EA per Elessawy)?
The ability to reason about the organization as a whole — across time, domains, and layers of abstraction — holding multiple perspectives simultaneously: business and technology, short-term and long-term, stability and change.
Q9: Why does enterprise complexity keep growing even when people are careful?
Because no one is accountable for the whole — each actor optimizes their local scope, and the interactions between local optimizations produce global complexity.
Q10: Why does Enterprise Architecture exist as a discipline?
Because enterprises are systems of systems (technology, people, processes, data, governance, incentives, culture) where changes ripple with delayed, nonlinear effects — and local optimization fails at enterprise scale.
Q11: Why does architectural complexity grow in a SaaS/vendor-heavy enterprise even with well-designed platforms?
Because the enterprise is no longer a single system — it becomes an ecosystem of vendor-defined architectures, each imposing its own design decisions.
Q12: Which architectural techniques let teams deliver without high-bandwidth inter-team communication?
Bounded contexts and APIs aligned to team boundaries to decouple domains; test doubles and virtualization to test components in isolation (Accelerate / Lean Enterprise).
Q13: When launching a new capability, what must be designed together — and why?
The operating model and the architecture, because team structure, decision rights, and funding will shape the resulting systems (Conway's Law) — designing them separately lets the org chart silently override the target architecture.
Comments
Post a Comment