Protocol
Test whether modularity actually localizes change
Modularity should be observable in change history.
When it fits
- When an architecture is called modular but there is no evidence that changes stay local.
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
Sample representative recent changes and count modules, teams and interfaces touched. Compare with the intended boundary rationale and redesign where change repeatedly leaks.
Steps
- Choose several representative changes.
- Count components and teams touched.
- Identify why each cross-boundary change was required.
- Update boundaries or contracts if leakage is systematic.
An example
Five policy changes all require edits in four services, showing that the supposed policy boundary is not localizing volatility.
Check your result
Change history supports or falsifies the modularity claim.
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
Useful withStop asking for one forecast under deep uncertainty
Evidence and sources
Supports
Parnas showed that modularization outcomes depend on decomposition criteria and argued for boundaries that hide changeable design decisions to improve flexibility and comprehensibility.
This is foundational software-design reasoning; organizational adaptations require separate validation.
On the Criteria To Be Used in Decomposing Systems into Modules · Abstract and design comparison