Heuristic
Minimize the number of teams that must change together
Cross-boundary coordination is a cost of architecture.
When it fits
- When small product changes require synchronized work across many groups.
When to avoid it
- Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner.
Why it matters
Map which teams must agree, build, test and release together for a normal change. Redesign boundaries or contracts where one change creates unnecessary multi-team coupling.
An example
A field-label change should not require integration, platform and reporting releases if the contract can preserve semantic identity.
Check your result
Typical changes require fewer simultaneous owners without bypassing controls.
Keep this limit in mind
- Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner.
Connected ideas
Use beforeMake dependencies directional where possible
Evidence and sources
Provides context
Simon described complex systems as often hierarchical and near-decomposable, motivating analysis of relatively strong within-subsystem interactions and weaker cross-subsystem interactions.
Near decomposability is a conceptual property, not evidence that any chosen boundary is correct.
The Architecture of Complexity · Near-decomposability discussion