All playbooks
Playbook · Change · 7 steps
Integrating after a merger
Combine two companies' systems without stalling both businesses.
“Multiple models are inevitable, yet when code based on distinct models is combined, software becomes buggy, unreliable, and difficult to understand.”
- 1Operating Model (Standardisation and Integration)What operating model is the combined business aiming for, and how much integration does it really need?Decide how standardised your business processes must be and how tightly units must share data; the architecture follows from that choice.Open
- 2Capability MappingMap both companies' capabilities side by side. Where do they overlap, and where do they complement each other?Describe what the business does, independent of how, by whom, or with which system.Open
- 3Bounded ContextWhere does the same word mean different things in each company?A model is only valid inside an explicit boundary; the same word can mean different things in different contexts.Open
- 4Anti-Corruption LayerWhere must systems talk before they are consolidated, and how do we keep each model intact?Protect your domain model by translating at the boundary with systems whose models you don't control.Open
- 5TIME Portfolio TriageFor each pair of duplicate systems, which one do we invest in and which do we retire?Sort each application by business value and technical quality into Tolerate, Invest, Migrate or Eliminate, and fund it accordingly.Open
- 6Conway's LawWhich teams will own the combined systems, and does that structure match the target design?Organisations design systems that mirror their own communication structures.Open
- 7Power–Interest GridWho on each side can block or champion the integration?Map stakeholders by how much power they have over the outcome and how much they care, and engage each group differently.Open