For many organizations, breaking up a monolith is treated as a rite of passage. It signals maturity, scale, and architectural enlightenment. Teams are reorganized around products or domains, services are extracted, and autonomy increases.
And then—quietly, predictably—the remains of the monolith begin to decay.
This post is about that failure mode. Not the dramatic kind involving outages or rewrites, but the slow, organizational neglect that sets in when everything desirable has an owner and everything else does not.
Imagine a team of roughly 80 developers working on a large monolith. Over time, the system is decomposed. Product- or capability-driven (PCD) teams are formed, and services are extracted to align with their domains.
From the outside, this looks like progress:
But what remains inside the monolith is not a clean, shrinking core. It’s a mix of:
And crucially: none of it maps cleanly to a PCD team’s mission.
The remaining monolith becomes a shared dependency. It’s still critical, still deployed, still running production traffic—but it no longer has a natural home.
PCD teams are incentivized to:
The leftover system offers none of that upside. It mostly generates toil, risk, and maintenance work. So it falls between the cracks—not because teams are careless, but because they are behaving rationally within the incentives they’re given.
This is the moment when architectural fragmentation turns into organizational entropy.
Yes—but not in the way the term is usually used.
The issue isn’t simply “too many services.” It’s fragmentation without governance.
Over-fragmentation manifests as:
What’s often missed is that the remnants of the monolith are effectively an internal platform:
But unlike intentional platforms, these systems have:
Platform work done implicitly—by whoever happens to trip over it—inevitably rots.
Successful organizations name the problem instead of letting it float:
They staff it, give it OKRs, and treat it as a first-class product. Without this, neglect is guaranteed.
Every service—no matter how small—has:
If a service has no roadmap, that’s still a roadmap decision.
If teams are measured only on:
They will sacrifice shared reliability and long-term maintainability.
Healthy organizations include system health metrics, shared reliability goals, and explicit “tax” capacity for cross-cutting work.
Many mature organizations:
Fragmentation is a tool—not a moral good.
Breaking up a monolith doesn’t eliminate complexity—it redistributes it.
The quiet failure of over-fragmentation isn’t technical.
It’s organizational—and it’s preventable.
Contact us and we'll get back to you within 24 hours.
Swords, Co. Dublin, Ireland
+353 86 3118747
rachel@rchtech.ie