A Pragmatic Approach to Service Decomposition
For many enterprises, the monolith is both a strength and a challenge. Over decades, organizations build robust platforms that support critical operations — but eventually, the weight of legacy coupling begins to hinder growth.
Successful modernization is less about "new tech" and more about managing the transition of complexity.
The real question is never "should we modernize?" — it is "how do we modernize without stopping the business that funds the modernization?"
A Tale of Two Modernizations: Lessons from the Field
I have lived through two very different modernization efforts — separated by roughly two decades, different companies, different scales, different outcomes. What they share is that the architecture of the transition mattered far more than the architecture of the target system.
Case 1: The Language Migration Trap (The "Big Bang" Failure)
Early in my career, I was part of a company that decided to rewrite its entire monolith into Java J2EE. This wasn't an incremental evolution — it was a full stop, full swap. Legacy maintenance was put on pause. The "New World" was everything.
Looking back now, the failure modes are clear.
The first was customer patience running out. While the team was absorbed in the rewrite, real business demands kept coming. Support tickets piled up. Feature requests went unanswered. The old system was frozen, and the new one wasn't ready. There is only so long a customer base will tolerate that gap before the relationship breaks.
The second was over-ambition in the architecture itself. The lead architect — talented, no question — went deep into building a universal framework that would auto-generate screens and business logic. The idea was impressive on paper. In practice, the generated code was slow and inflexible, and the framework became a bottleneck. Every change required fighting the abstraction rather than solving the business problem. Code reviews turned into painful rework cycles. Development slowed to a crawl.
Here is the hard lesson: they built it because they could, not because the business needed it. There was no real requirement driving the need to regenerate screens automatically. It was engineering ambition outrunning business reality.
The frustration compounded over time. Engineers lost momentum. Team morale eroded. About two years after I left, the company went bankrupt.
Not because of bad engineers. Because of an approach that put architectural purity ahead of continuous value delivery.
Case 2: The Microservices Evolution (The Balanced Win)
Years later, leading the web and API team at a UK insurance technology firm, I faced a different challenge. We had a large integration monolith — not a traditional business logic monolith, but a complex orchestration layer connecting our core insurance processing platform (handling policies, contacts, claims and more) with banking validation, payment processing, and a range of custom-built internal services. It was the nervous system of the operation.
The goal was to decompose this into microservices. The constraint was that we could never stop the business while doing it.
We allocated 15–20% of development capacity to the migration. The rest kept the platform running and delivering features. We applied the Strangler Fig pattern — gradually routing traffic away from the monolith and toward new, purpose-built services, while both coexisted in production for an extended period. There was no hard cutover. There were instead many intermediate states, each stable enough to operate in, each a step closer to the target architecture.
It worked. Not because we were faster or smarter than the team in Case 1 — but because we never stopped serving the business while we transformed it.
Engineers had room to learn new technologies — microservices patterns, event-driven architecture, modern API design — without being pulled entirely away from the systems that mattered today. That balance kept frustration low and momentum high.
The Strangler Fig in Practice
The Strangler Fig pattern deserves more than a passing mention, because it is the architectural mechanism that makes incremental decomposition possible.
The principle is straightforward: rather than replacing a system in one move, you grow new capability around it. New requests are routed to the new service. The monolith handles what hasn't been migrated yet. Over time, the monolith "strangles" — its surface area shrinks as each capability is extracted — until it can eventually be retired, or simply left running the small residual it still owns.
In our case, the monolith was an integration and transformation layer. Extracting from it meant two distinct types of work:
- Service extraction — identifying discrete integration flows (say, payment processing or banking validation) and pulling them out as standalone services with their own deployment lifecycle.
- Transformation layer rewriting — where the monolith was doing complex schema and API transformations between systems, we rewrote those translation responsibilities into a new architecture, giving us cleaner contracts and independent evolvability. Neither of these was a clean, surgical operation. Real systems aren't clean. The intermediate states — where both the old and new paths existed simultaneously — required careful routing logic, thorough testing at the boundary, and a tolerance for living with complexity during the transition. That tolerance is itself an architectural decision. You have to accept that the system will look messy for a while. The alternative is a Big Bang that looks clean on a diagram and fails in production.
The Strangler Fig trades short-term tidiness for long-term survivability. That is almost always the right trade.
The Boundary Problem: Strategic vs. Tactical
Both stories surface the same underlying challenge: where do you draw the line?
In software, we tend to think of this as a technical question — bounded contexts, API contracts, data ownership. But in practice, it operates at three levels simultaneously:
- Logical Boundaries (Domain-Driven Design): Ensuring that a change to payment processing doesn't cascade into claims, and that each service owns its own model cleanly.
- Implementation Boundaries (Anti-Corruption): When integrating with a third-party platform that has its own data model and terminology, you need a translation layer that protects your new services from absorbing legacy concepts. Your domain language should stay yours.
- Operational Boundaries (Capacity): This is the one most teams ignore. How much architectural change can your organisation absorb per sprint without compromising delivery? That is a real constraint, and it needs to be treated as one. Most failed modernizations violate all three simultaneously — trying to redesign the domain model, integrate legacy systems, and restructure the team all at once.
The Human Side of Transformation
This is the part that rarely makes it into architecture documents, but it determines outcomes as much as any technical decision.
In Case 1, the human cost was visible in hindsight. Engineers were asked to build an entirely new world while the old one decayed around them. The framework they were building didn't give them small wins — it was all or nothing. When the abstraction fought back, there was no relief valve. Frustration accumulated quietly until the team began to leave.
In Case 2, the 15–20% model created a different dynamic. Engineers were working on modern technology and shipping production value in the same sprint. Learning didn't come at the cost of delivery. People could see the migration moving forward in concrete steps — a service extracted, a transformation layer replaced — without feeling like the business was being held hostage to the architecture.
There is also a knowledge dimension that is easy to underestimate. A monolith built over many years carries encoded business logic that exists nowhere else — not in documentation, not in the heads of current team members, but in the behaviour of the running system. A Big Bang rewrite forces you to rediscover all of that logic under pressure, at the worst possible time. An incremental approach surfaces it gradually, giving the team time to understand it and encode it correctly in the new services.
The domain knowledge in legacy code is an asset. Treat it as such.
The 15–20% Capacity Model: Governance, Not Just a Number
The capacity allocation deserves its own framing, because it is often misread as a conservative compromise. It isn't. It is a governance model that answers a question most modernization programs never ask explicitly:
At what rate can this organisation absorb architectural change without compromising delivery?
The constraint is intentional. By capping the modernization investment, you force prioritization. Only the highest-value boundaries get addressed first. Engineers can't disappear into abstraction for quarters at a time. Stakeholders see continuous delivery alongside the transformation, which preserves the trust that long modernization programs tend to erode.
And it compounds. Early investments in shared infrastructure — service templates, deployment pipelines, observability tooling — reduce the cost of each subsequent extraction. The 20% buys you more over time, not less.
Modernization becomes a capability, not a project.
Strategic Principles for Success
- Avoid technology for technology's sake. If a framework doesn't solve a current business requirement, it is a liability, not an asset. Case 1 is the cautionary example.
- Modernize the path, not just the destination. The process of decomposing a monolith is as important as the target architecture. Design the transition, not just the end state.
- Apply the Strangler Fig deliberately. Accept intermediate states. Plan for them. Route carefully, test the boundaries, and retire the old paths only when the new ones are proven.
- Protect your domain model. When integrating with legacy systems or third-party platforms, use translation boundaries to keep your new services speaking your language, not theirs.
- Budget for evolution. A fixed capacity allocation turns transformation from a high-stakes project into a continuous architectural practice.
- Use observability as a compass. Instrument the system before you decompose it. Traces will show you where the real boundaries are — and validate that your extractions are actually working. (See Part 1 of this series for how to introduce observability non-invasively.)
Conclusion
Whether you are migrating into a new technology or decomposing an integration monolith into microservices, the path to success is the same: pragmatic incrementalism.
Modernization is not a single event. It is a strategic design choice to build the future without abandoning the present.
The strongest architectures are not those that are the most "pure" — they are those that are the most resilient to change. And resilience, in architecture as in engineering, is built through deliberate, sustained, small steps — not through a single leap of faith.
The monolith served the business for a reason. Your job is not to condemn it.
Your job is to evolve it — without breaking it.
This article is Part 2 of the Incremental Modernization Architecture series.
Part 1: Enabling Observability in Legacy Systems
