Two of everything
Two mid-sized business services firms — one strong in facilities services, the other in workforce and administrative outsourcing — merged into a single group. On paper the fit was good: complementary client bases, adjacent services, little geographic overlap. In the IT estate, the merger meant what mergers always mean. Two CRM platforms. Two ERP systems. Two payroll engines, each wired deeply into its own country's statutory reporting. Two field service applications, two intranets, two identity platforms, and two IT departments, each fluent in its own stack and politely convinced the other's was the problem.
For the first year this was tolerable, because integration had rightly waited while the commercial merger settled. By the time we arrived, tolerable was ending. Every group-wide initiative — one client portal, consolidated financial reporting, a single onboarding experience for staff — ran into the doubled estate and slowed down. Licence and hosting costs for the duplicated systems were the visible irritant; the invisible one was that every new project began with an argument about which side's system to build on.
The group had chosen Sparx EA as its architecture tool, and we were engaged through our Sparx EA consulting practice to do something specific with it: put both estates into one repository, on one set of concepts, in a way that would let the leadership decide what to keep, what to retire and in what order — and to defend those decisions afterwards.
Why the integration programme stalled
An integration programme did exist, and it had produced paper: a systems inventory from each side, a consultancy's synergy estimate from the due diligence phase, and several slide decks proposing target states. It had not produced movement, and the reasons were instructive.
The first was that the two sides were arguing from anecdote. Each firm's people knew their own systems' strengths in daily-work detail and knew the other side's systems mostly through their worst incidents, retold. Meetings pitted one side's lived experience against the other's, and adjourned without a way to adjudicate.
The second was that the existing analyses compared systems head-to-head — this CRM versus that CRM — which quietly assumed the answer to a question nobody had asked: whether the group needed one CRM at all, or two doing different jobs, or a different boundary entirely. Product comparisons cannot see past the products that exist.
The third was vocabulary. The two firms did not merely run different systems; they used different words for the same activities and, worse, the same words for different ones. "Client management" on one side meant account relationship work; on the other it included contract administration. Until that was untangled, even agreement was unreliable — people could concur on a sentence and mean incompatible things by it.
One capability map before anything else
So we did not start with the applications. We started with a capability map: a neutral description of what the merged group does — manage client relationships, price and contract services, schedule and dispatch work, run payroll, bill and collect, report to authorities — deliberately free of any system name or either firm's internal jargon.
Building it took four workshops with people from both sides, and we enforced one rule that shaped everything after: no application names in the room. The moment someone says a system's name, the discussion snaps back to defending territory; kept at the level of the work itself, the two sides discovered they were describing the same business faster than they expected. Where vocabulary genuinely differed, the map became the arbitration record — one agreed term, with each firm's word for it noted in the element's documentation so nobody's language was simply erased.
Two of the workshops nearly failed, and it is worth saying why. Capability mapping feels, to busy operational people, like being asked to state the obvious slowly. What carried the sessions was keeping every abstraction tethered to a concrete decision it would soon inform: this box will decide which of two systems survives, and your name will be on the mapping that decides it. Abstraction with consequences attached holds attention; abstraction for its own sake does not.
The map settled at two levels: a dozen top-level capabilities and about fifty beneath them, each modelled as an ArchiMate capability element in a reference package that both sides reviewed and signed. We have written more generally about building capability maps that connect strategy to execution; here the map had one immediate job — to be the neutral ground the merger conversation had lacked. It was the first artefact in the programme that neither side could call the other side's document.
Loading both portfolios into one repository
With the map agreed, the applications came in. Both firms' inventories arrived as spreadsheets — one exported from a well-kept CMDB, one maintained by hand and optimistic in places — and we loaded both through a script against the Sparx EA automation API rather than by manual entry, keeping the load repeatable as the inventories were corrected. Around two hundred and forty applications came in between the two firms. Every element carries tagged values for its origin firm, lifecycle status, hosting, support owner, annual run cost where finance could supply it, and the source inventory's identifier, so later corrections could flow through rather than fork.
Then the mapping: realisation links from each application to the capabilities it supports, drawn in working sessions with people who actually use the systems, side by side from both firms. These sessions doubled as quiet diplomacy. Sitting a facilities scheduler next to a workforce planner to map their respective systems onto the same capability produced, repeatedly, the discovery that the other side's system was neither mysterious nor stupid — a small effect per session that compounded across the programme.
We resisted enriching the model further at this stage. Interface detail, data flows, deployment — all real, all eventually useful, none needed for the decision at hand. A consolidation decision needs to know what each system is for, what it costs, and what would have to absorb its work; every additional attribute delays the moment the model can start answering questions.
What the load revealed about the inventories
Putting two inventories through the same scripted load, against the same validation, is itself a diagnostic — and the findings were not distributed the way either side expected. The hand-maintained inventory was optimistic in the predicted ways: systems listed as live that had been switched off, cost fields copied forward from years past. But the well-kept CMDB had its own failure mode: it faithfully recorded infrastructure while missing a stratum of departmental applications that had never been through central IT at all — a spreadsheet-and-database layer of quoting tools and client trackers that the working sessions surfaced one embarrassed admission at a time.
We fed every discrepancy back to its owner rather than silently fixing it in the model, and re-ran the load after each correction cycle. Three cycles in, the two inventories were, for the first time, comparable artefacts — same fields, same lifecycle vocabulary, same definition of what counts as an application. It is a mundane deliverable to name in a case study, and it may have been the single most useful one: the merged group's first shared list of what it actually runs that both sides believed. About a dozen systems entered the estate picture this way that had appeared in neither firm's official inventory, several of them handling client data — which promoted a tidy-up that would otherwise have waited for an audit to force it.
The load scripts stayed in the repository afterwards, documented, because a reconciliation that runs once is an event; one that can be re-run is a control. The client's team now runs the same reconciliation quarterly against both source systems while those sources still exist, and the model's identifiers are the bridge between them.
Seeing the overlap honestly
Figure 1 shows the picture that the programme had been missing: the capability map with both portfolios laid onto it, colour-coded by origin. The Relationship Matrix view of the same content — capabilities down one axis, applications across the other — became the working tool, because it can be filtered, sorted and exported, but the diagram is what changed the meetings. Where two colours stack under one capability, the group may be paying twice; where one colour stands alone, one firm brought something the other never had.
The honest part mattered more than the visual part. Not every stacked pair was a real duplicate. The two payroll engines served different statutory regimes and were both staying for years, whatever the synergy deck had implied. One firm's "CRM" earned most of its keep as a contract administration system, so retiring it in favour of the other's relationship-focused CRM would have silently dropped a capability. The mapping surfaced these distinctions precisely because applications were linked to capabilities rather than compared to each other by label — the analysis the head-to-head comparisons could not produce. Of roughly forty stacked pairs, the working sessions classified about two thirds as genuine overlap and the rest as coexistence with a reason.
From overlap to options
For each genuine overlap, the question became a structured choice with four honest answers: converge on one side's system, converge on the other's, replace both with something new, or keep both deliberately with a defined boundary between them. Forcing "keep both, deliberately" into the option set was important — without it, every unresolved argument disguises itself as a pending decision, and the backlog of pending decisions is what had stalled the programme before.
The criteria were agreed before any individual case was argued: functional coverage of the capability as mapped, run cost, contract exit windows, integration weight (how many other systems would feel the change — counted from a one-off interface inventory we ran per shortlisted pair, rather than modelled estate-wide), statutory constraints, and the human factor of where the operating knowledge sits. Contract end dates did more sequencing work than any architectural property — a system whose licence renews in eight months creates a decision window that a diagram cannot.
Each overlap's assessment was held in the model against the affected elements, not in a separate document, so the option chosen and the evidence for it stayed attached to the applications it concerned.
Modelling the transition
The chosen options then had to become a sequence, and for this we used ArchiMate's implementation and migration concepts in Sparx EA directly: plateaus for the stable intermediate states, work packages for the moves between them, gaps where the analysis had found capability that would need rebuilding before the system providing it could retire. Figure 2 shows the structure: the day-one state with its doubled estate, two consolidation waves, and the target.
The waves were cut by dependency and contract windows rather than by ambition. Wave one took the retirements that unblocked the group initiatives — one CRM absorbed the other's relationship data, one intranet won, the identity platforms converged so that everything after could assume a single login. Wave two took the heavier moves that wave one made possible. The ERP consolidation, largest and riskiest, was deliberately parked at the wave-two/target boundary with its own decision gate, because pretending its date was knowable in month three would have cost the roadmap its credibility.
Every application element carries its disposition and wave as tagged values, so "the roadmap" is not a picture that can drift from the inventory — it is a query over the same elements the inventory is made of. When a date slips or a decision changes, the tagged values change, and the views and generated reports pick the change up at their next refresh or regeneration.
Decisions recorded where they bite
Merger integration is a parade of contestable decisions, and the people who contest them change as staff rotate. So each consolidation decision was recorded as an element in the model — the option chosen, the options rejected, the criteria scores, who decided and when — linked with traceability relationships to every application it affects. Two years later, when someone asks why the group runs the payroll engine it runs, the answer is one navigation away from the system itself, with the reasoning intact.
This is unglamorous modelling, and it is some of the highest-value content in the repository. It also changed behaviour in the steering meetings: knowing that the decision record would name the criteria and the scores made arguing by volume noticeably rarer. A claim that could not survive being written next to the evidence tended not to be made.
A merger roadmap that lives in slides is renegotiated in every meeting. A roadmap whose every claim traces to inventory, cost and contract evidence in the repository can still be challenged — but the challenge has to bring evidence of its own, and that discipline is what finally let this programme move.
A steering pack generated from the model
The integration board met monthly, and its pack was generated from the repository through Sparx EA's document templates: the capability overlap matrix, each wave's scope with status, the open decisions with their evidence, and the retirement count against plan. Generating rather than authoring the pack had two effects. The board stopped receiving numbers that disagreed with each other, because every figure came from the same elements; and preparing the meeting stopped consuming an architect's week, because the pack assembles in the time it takes the template to run.
The same content, scoped differently, went to the two IT departments — their systems, their waves, their open actions — which quietly ended the era of each side maintaining its own version of the plan.
One repository, two modelling cultures
A detail that mattered more than we expected: the two firms did not just bring two estates, they brought two habits of describing them. One side had a modelling past — old process diagrams, a retired tool, people comfortable with notation. The other documented in prose and spreadsheets and regarded diagrams with suspicion. Left alone, the repository would have filled with one firm's voice, and its neutrality — the property everything else depended on — would have quietly gone.
So the working conventions were written for the least notation-inclined person in the room. The portfolio views use a deliberately small ArchiMate vocabulary — capabilities, applications, realisation, and little else — and every convention in use fits on two pages. The Relationship Matrix and generated documents carried more of the communication load than diagrams did, precisely because a filtered table reads as evidence to people for whom a diagram reads as art. Package structure kept a clean separation between the shared reference content — the capability map, the merged portfolio — and each programme's working views, with package-level security matching: everyone reads everything, but the reference packages change only through the weekly review that both firms' architects attend.
That weekly model review, an hour with both sides present, became the programme's quiet institution. It existed to keep the repository consistent; what it actually did was give the merged architecture group a place where it practised being one group, on neutral material, every week.
What changed
The programme moved. Wave one completed close to its dates: the smaller CRM — the one doing genuinely duplicated relationship work — was retired with its history migrated, while the system that had worn the CRM label but earned its keep in contract administration stayed, reclassified as what it actually was, the intranets and identity platforms converged, and a first tranche of duplicated tooling around them went with them. The licence and hosting savings from wave one alone covered the modelling engagement several times over, which is worth saying plainly since architecture work is so often asked to justify itself in softer currency.
The less countable change was that the two IT departments started behaving like one. The shared repository gave them a common description of the estate; the capability map gave them a language that belonged to the group rather than to either legacy firm; and the decision records took the personal sting out of retirements — a system was retired by a criteria-scored decision, not by the other side winning. Two schedulers who had mapped their systems side by side in the early sessions ended up jointly designing the consolidated dispatch process, which no plan of ours had foreseen.
What we would do differently
We would chase the cost and contract data harder, earlier. The architectural mapping outran the financial attributes for months; several decisions waited not on analysis but on someone extracting contract end dates from filing cabinets, and the model's authority suffered wherever a cost cell was blank. In the next engagement of this shape, the inventory load and the commercial-data chase start the same week.
We would also name the limitation of capability mapping more loudly at the start: a capability map is deliberately coarse, and consolidation decided at capability level can hide product-level gaps until migration planning finds them. It did here, twice — modest gaps both times, absorbed in the wave that found them, but they were discovered later than they needed to be. The correction is not a finer map; it is scheduling the product-level fit assessment as the first task inside each wave, rather than treating the capability-level decision as the end of analysis. Sparx EA holds both levels comfortably; the discipline is knowing which level a given decision may rely on.
And we would put the second repository administrator in place from day one. The model became operationally important faster than expected, and for a stretch it depended on one person on one side of the merged organisation — exactly the single point of concentration the merger was trying to unwind elsewhere.
Where they are now
Wave two is under way, tracked in the same repository by the group's own architects; our involvement has narrowed to periodic review. The ERP decision gate was passed with the evidence assembled from the model, and that programme now maintains its own solution-level views alongside the portfolio content. The capability map has quietly become the group's planning language beyond IT — the operations directorate now expresses its annual objectives against it, which is more adoption than architecture usually gets to claim.
If your organisation is absorbing a merger — or simply running two of things it means to run one of — and the integration conversation has stalled on competing anecdotes, you can reach us through our contact page.
This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.