Conway's Law
Systems mirroring the communication structure of the organisation that builds them.
4 to work through
-
intermediate
Two teams own two deployables: a reader-facing API and a mobile backend-for-frontend that calls it. They are merged into one team of nine with one backlog and one standup. What happens to the interface between those two services over the next two quarters, and what would you do about it now?
3 min answer -
advanced
A B2B marketplace splits into supplier-onboarding, catalogue, pricing and fulfilment services. Eighteen months later every meaningful feature requires all four teams. What does Conway's Law say happened, and what are the two available fixes?
1 min answer -
advanced
What happens if an edge platform's configuration system is built by three teams - one owning the config language, one owning global propagation, one owning the edge runtime - and each team ships on its own schedule with its own API? Predict the architectural consequence.
2 min answer -
advanced
You design service boundaries along domain lines. They cut across three existing teams. What happens and what do you do?
2 min answer
3 terms in this topic
Coordination Cost
The delay and effort imposed on a change by the number of teams and services that must agree and release together - usually the dominant term in deli…
conceptCoordination Tax
The permanent, structural cost incurred when service boundaries are drawn on a different axis from the way work arrives - and the reason consolidatin…
practiceInverse Conway Manoeuvre
Deliberately reorganising teams so that the architecture you want becomes the architecture the organisation naturally produces.
Neighbouring topics
Architecture Fundamentals
General material on what solution architecture is and what an architect is accountable for.
Requirements to Constraints
Turning stated requirements into the constraints that actually bound a design.
Functional vs Non-Functional
Behaviour versus quality of behaviour, and why only the second constrains structure.
Architectural Drivers
The small subset of requirements whose change would force the structure to change.
Quality Attributes
Availability, latency, throughput, security, cost — expressed as testable scenarios.
Architecture Principles
Durable agreed rules that rule options out, stated with rationale and implications.
Coupling
How much one component must know about, or change alongside, another.
Cohesion
Whether the things inside a boundary belong together and change for the same reason.
Modularity
Composing a system from parts that can be understood and replaced independently.
Separation of Concerns
Organising so that a change to one concern touches one place.
Abstraction & Encapsulation
Hiding mechanism behind contract, and protecting invariants by owning state.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Evolutionary Architecture
Designing for guided incremental change rather than for correctness on day one.
Fitness Functions
Automated checks that an architectural characteristic still holds.
Architecture Documentation
What to write down, at what altitude, and what nobody will ever read.
Trade-off Fundamentals
Why every architecture is a set of purchases, and how to state what you gave up.
Technical Constraints
Existing estate, skills, licences and platforms as inputs rather than obstacles.
Architecture Roles
Solution, enterprise, domain and platform architecture, and where each is accountable.
Reference Models
Shared conceptual frames — layering, tiers, viewpoints — and their limits.