Organizations that have done serious integration inventory work—who have mapped their services, catalogued their contracts, and organized their estate into domains—often discover they've solved the wrong problem. The portfolio is complete. The architecture is understood. And the program is still stuck. Not because of what they don't know. Because of what they haven't committed to.
There is a gap between knowing what you have and knowing how to move it. Most integration programs live in that gap permanently. They produce architecture documents, domain catalogues, and strategic roadmaps—and then spend the next two years revising them. The deliverable keeps becoming more complete. The program keeps not delivering.
A roadmap tells you where you're going. A work package tells you who is doing what, by when, at what cost, and what it depends on. Only one of these creates accountability. Only one of these is a commitment.
The discipline that closes this gap is decomposition: taking domain-level architecture knowledge and breaking it down into discrete, governable units of delivery. Not milestones. Not phases. Work packages—scoped, estimated, sequenced, and owned.
Why roadmaps fail at delivery
A roadmap is a sequencing of intentions. It communicates direction and priority, but it abstracts away the two things that actually determine whether delivery happens: effort and dependencies. When a roadmap says "migrate payments domain in Q3," it has said nothing about whether that is a three-month program for two teams or a twelve-month program for eight. It has said nothing about which migrations must complete first, which external teams need to be coordinated, which platform capabilities need to exist before the first service can move.
The roadmap looks like a plan. It functions as a hope. The moment delivery pressure arrives—when a regulatory deadline tightens, when headcount changes, when a dependency surfaces that wasn't accounted for—the roadmap cannot absorb the change. There is no granularity to adjust. You either slip the phase or you don't.
Work packages change this. A domain broken into twelve work packages, each with an effort estimate, a defined deliverable, a priority level, and explicit upstream dependencies, can be re-sequenced in response to reality. When a P1 item takes longer than expected, the P2 and P3 items slip—visibly, on record, with a clear decision about whether to add capacity or accept the schedule change. That transparency is not comfortable. It is how organizations actually govern delivery.
What the decomposition reveals
The act of decomposing a domain into work packages forces three conversations that architecture documents cannot force.
The first is effort honesty. When you have to estimate each piece of work—not as a percentage of a phase but as a discrete unit that a team will be held accountable for—the optimism that attaches to high-level planning disappears. A domain that looked like a three-month migration at roadmap level often turns out to require six months of parallel work across multiple teams when the work packages are written out. This is not failure. This is discovery at the right time.
The second is dependency exposure. Integration domains are not independent. A payments migration depends on a shared identity service being available in the new platform before the first service can move. A compliance automation depends on a database schema migration that requires DBA coordination. A corporate banking service depends on a vendor API that requires a new contract. None of these dependencies show up on a roadmap. They all show up when work packages force you to state what each unit of work requires before it can start.
The third is ownership assignment. A roadmap can be owned by an architecture team and tracked in a presentation. Work packages cannot. Each package names a team, a lead, a set of deliverables. The moment ownership is assigned, the question of capacity becomes concrete: does this team have the bandwidth to absorb this work in the proposed window? If not, which package gets deferred, and who decides?
Domain plans as a governance layer
Work packages gain their full power when they are organized within a domain plan that structures delivery across phases. A four-phase structure—discovery, rationalization, migration, modernization—does something important: it creates phase gates that governance can use. You don't migrate a domain until rationalization is complete. You don't modernize until migration is stable. Each gate is a decision point where leadership can review what was delivered, what was learned, and whether the next phase should proceed on the current scope and timeline.
This structure also makes cross-domain sequencing visible. When every domain has a plan with the same phase structure, you can see at a glance which domains are ready to move, which are still in discovery, and which have dependencies on other domains that need to resolve before they can progress. The integration program becomes a portfolio of domain-level programs—individually governable, collectively visible, and capable of absorbing the inevitable changes that arrive when delivery meets reality.
What I've found doing this across a complex integration estate
Writing work packages for a large integration estate is not intellectually glamorous. It is the kind of methodical, detail-intensive work that architecture teams often defer in favor of more interesting design problems. But the organizations that do it are the ones whose programs actually deliver, because they have converted strategic intent into accountable commitments.
The value doesn't appear at the start. It appears when a dependency surfaces mid-migration and the team can immediately identify which work packages are blocked, who owns the blocker, and what the schedule impact is—rather than spending three weeks in workshops trying to reconstruct what was supposed to happen. It appears when a new executive asks for a status report and can read a domain tracker that shows, for every domain, exactly where delivery stands. It appears when a delivery team is onboarding to a new domain and finds a work package breakdown that tells them the scope, the priorities, and the dependencies before they've attended their first meeting.
Architecture describes the destination. Work packages describe how to get there. Both are necessary. Only one creates accountability. And accountability is what programs are actually missing when they stall between strategy and delivery.