Modernizing with context: taking monoliths apart, twice

Two employers, one pattern: decompose the monolith behind stable service boundaries, and write down the existing system's rules before changing it.

Case study. The direction and standards were mine; the delivery belonged to many engineers, architects and leads.

The situation

I have led the decomposition of a legacy monolith twice. At Enclara Pharmacia, the monolith became service-based APIs. At Mansfield Energy, the work spans ERP, customer applications and integrations, moving to microservices.

What I did

Set the architecture and standards teams build to, starting with API-first integration.
Made decisions durable and visible: architecture decision records for consequential choices, infrastructure as code and CI/CD pipelines, and observability.
At Enclara, introduced continuous integration and delivery, and made code review and technical documentation standing practice.
At Mansfield, built the context that lets coding agents work in existing systems: tools, connectors and codebase knowledge.

What changed

At Enclara, service-oriented APIs became the standard for integration between enterprise applications. At Mansfield, the same pattern runs through the modernization roadmap I own, with decisions recorded and automation.

What I would carry forward

Modernize with the existing system, not against it. The rules that matter most are often the ones nobody wrote down, so write them down first: in decision records, in tests that pin current behavior, and in context a new engineer or an agent can read.