EA Practice · 2026-07-23

You Can't Consolidate What You Can't Compare

Acquire five banks and you inherit five of everything — five payment platforms, five correspondent networks, duplicated party and account data — and no way to compare them, because every bank describes its systems differently. Map every institution onto one shared, MECE industry blueprint and three things that were invisible finally surface: Duplication, Gaps, and Misalignment. Drawn from The Open Group and BIAN's Archi Banking Group case study.

By Tom Ward, Enterprise Architect — Cloud & Infrastructure

Download the deep-dive PDF6 pages — the full model in detail, a checklist, and curated references. Free, no signup.

You Can't Consolidate What You Can't Compare — architecture infographic — How a shared reference model turns five acquired banks into one architecture

What a shared reference model exposes

You can't consolidate what you can't compare, and you can't compare without a shared reference model. What makes a model work is that it is MECE — Mutually Exclusive (no two capabilities overlap) and Collectively Exhaustive (together they cover the whole business). Map every institution that was acquired or merged onto a MECE model and the reveal is automatic: overlaps surface as Duplication, holes as Gaps. Without that discipline you go hunting for problems anecdotally; with it, the model surfaces them for you.

Duplication

“The same capability, built N times”

When every institution runs its own version of a function, capacity multiplies without adding value. Party data and current-account data are duplicated across the group; each bank operates its own correspondent network and negotiates from a weak position. Mapped onto one blueprint, the redundancy is obvious — and so is its cost: personnel and maintenance multiplied across the group, weak negotiating leverage from fragmented spend, and a cost/income ratio that quietly keeps climbing.

Gaps

“Capabilities nobody owns”

The mirror image of duplication: functions the group needs that no institution owns. International payments have no group-wide straight-through processing; open-banking readiness sits on no one's plate. Under short-term pressure, the service domains earmarked for centralization get built locally instead — so the shared capability never actually arrives. Three shapes surface: capabilities with no clear owner, compliance readiness that's everyone's problem and no one's job, and group-scale capabilities no single bank builds.

Misalignment

“The same thing, done incompatibly”

The subtlest of the three: the same capability exists in several institutions, but implemented so differently that it can't be shared, consolidated, or reported on. Each institution kept its own business organization and IT platform, so the information they produce lacks consistency, reliability, and completeness — and there is no reliable group-level view. Reuse and integration are blocked before they start, and every “simple” consolidation becomes a translation project.

Three standards, three jobs

The case study's real lesson is that no single standard does this alone. Three of The Open Group's assets combine — each answering a different question.

Standard 1
BIAN
the vocabulary
The Banking Industry Architecture Network's reference model — a “service landscape” of discrete, non-overlapping, mutually-exclusive and collectively-exhaustive service domains. It gives a mixed, multi-institution team a common language and a canvas to index artifacts and make like-for-like comparisons. Used well, it becomes an enterprise blueprint for plugging in new products, not just reference material.
Standard 2
ArchiMate
the notation
The modeling language that expresses BIAN in architecture viewpoints — one visual vocabulary spanning business, application, and technology, with motivation, strategy, and implementation elements. It turns the reference model into diagrams a board and a delivery team can both read.
Standard 3
TOGAF
the method
The Architecture Development Method drives the work through its phases and levels — enterprise, segment, and capability — iterating as an enterprise does. Architecture segmentation here is a governance instrument, not a fence: each project should travel through the levels, summarizing its conclusions back up into the enterprise architecture.

The Rationalization Readiness Test

Ten checks before you try to consolidate a group built by mergers and acquisitions. Score one point per “yes.” Below seven, you don't have a consolidation plan yet — you have five maps that don't line up.

Every institution is mapped onto one shared reference model (e.g., BIAN) — not five local models.
You can do a like-for-like comparison of the same capability across institutions, because the boundaries are defined the same way.
Someone owns an architecture capability at group level — not just “local heroes” in one institution.
Duplication is quantified: you know which capabilities are built more than once, and roughly what that costs.
Gaps are named: you know which needed capabilities no institution actually owns.
Misalignment is visible: you know where the same function is implemented incompatibly.
You've set explicit criteria for what gets integrated versus kept local — not decided case by case under pressure.
Customer- and market-facing identity is protected as local; everything else is a candidate for integration.
Assessments are documented at service-domain level with measures — target vs current, cost, coverage — not at slogan level.
Architecture segmentation is used as a governance instrument, not as fencing to protect local turf.

Going deeper

Sources worth your time, roughly in the order a team should read them.

More field notes ship as they're written.

Get the next note by email