📖 Business
Loosely Coupled Architecture
The Accelerate research found that the specific technology stack or architectural pattern (microservices, monolith, serverless) does not predict software delivery performance. What predicts performance is the degree of coupling — specifically, whether teams can deploy, change, and operate their services independently. A well-structured monolith with clear module boundaries can outperform poorly-designed microservices. Architecture matters not for its pattern name but for the deployment independence it enables.
2
Minutes
2
Concepts
+45
XP
1
How It Works
Three testable criteria for loose coupling:
- Independent deployability — A team can deploy their service to production without coordinating with other teams. No shared release trains, no deployment windows where everyone goes together, no "we need Team X to deploy their changes first."
- Independent changeability — A team can make large-scale changes to their service design without depending on changes to other services. Interfaces and contracts are stable enough that internal refactoring doesn't ripple outward.
- Independent operation — A team can complete their work without needing to communicate extensively with people outside the team. This doesn't mean zero communication — it means the architecture doesn't force constant cross-team synchronization for routine work.
Conway's Law in action: Organizations design systems that mirror their communication structures. If your architecture requires cross-team coordination to deploy, your delivery performance will suffer regardless of how elegant the technical design is. The implication cuts both ways — if you want a loosely coupled architecture, you need loosely coupled teams with clear ownership boundaries.
The anti-patterns are revealing: shared databases between services, distributed monoliths (microservices that must deploy together), and "platform teams" that become bottlenecks all destroy the independence that loose coupling is meant to provide.