Exception Union

Nine departmental systems implement the same capability. The business case says one system will replace nine. Eighteen months later the replacement is late, and the reason is not the engineering - it is that the target quietly became "one system implementing everything all nine do".

Each source system encodes local exceptions: a department that approves in a different order, a region with an extra mandatory field, a legacy contract with a bespoke rule. None of them is in a requirements document. All of them are in production, and each has someone who depends on it and will escalate.

Why it matters

Complexity is additive across the sources and the benefit is not. The replacement inherits the sum of nine exception sets, so it is strictly more complex than any of the nine, costs more to build than the sum of what it replaces, and is harder to change afterwards - which destroys the agility that justified the programme.

The timing makes it worse. This risk arrives during requirements, before any code, and it compounds for the rest of the programme. By contrast, the risks teams size carefully - combined load, data migration - arrive later and have known playbooks. The combined load of nine departmental systems is nearly always trivial.

There is also a political mechanism: each exception has an advocate and no single exception is unreasonable. Without a named person empowered to refuse a department, every exception is accepted, one reasonable conversation at a time.

Implementation patterns

• Count the exceptions in week two. Grep the nine codebases for conditionals on department, region, product or customer type. That count is the programme's real size estimate and it is available before any design.
• Write the exception policy before the design, with an executive owner: which exceptions migrate, which are dropped, who is allowed to say no, and what the appeal route is.
• Retire before you consolidate. Every system switched off before the build is one whose exceptions never enter the target. Sequence the easiest retirements first; it shrinks scope and demonstrates progress.
• One governed escape hatch. A configurable rule table so genuine exceptions become data rather than code branches, plus a rule for what may enter it and who approves.
• Set an explicit exception budget - for example, no more than 20 configured variations at go-live, with each one costing roughly 5 days of build and test - so the constraint is visible in every conversation rather than discovered at the end.
• Time-box the survivors. Exceptions that migrate carry a review date, or they become permanent by default.

Industry example

This is the best-documented failure pattern in enterprise consolidation and ERP programmes generally: the published post-mortems of large public-sector and enterprise system replacements repeatedly identify requirements growth from accommodating existing local practice, rather than technology, as the cause of overrun. The pattern is visible in production estates long before it appears in a report - the tell is a requirements document that grows monotonically after the budget is fixed.

The same shape appears in software at smaller scale whenever three teams' internal libraries are merged into one shared library, and the result serves none of them well.

Failure scenarios

• Feature parity as the acceptance criterion. "Parity with nine systems" is the union, stated as if it were a floor.
• Discovery by escalation. Exceptions surface when a department's work breaks in user acceptance testing, which is the most expensive moment to find them.
• The long tail migrates last and never finishes, so the old systems stay on - and the programme delivers a tenth system rather than replacing nine.
• The escape hatch becomes the system. A rule engine with 400 rules nobody can reason about, which is the same complexity in a different file format.
• Post-launch paralysis. Every future change must be checked against every inherited exception, so change cost rises rather than falls.

Trade-offs

Refusing exceptions is not free. Some of them encode genuine regulatory or contractual obligations, and a programme that refuses indiscriminately produces a system that cannot be used, which is a worse outcome than one that is complex. The work is triage, not refusal: separate obligations from habits, and be willing to change a business process rather than the software.

Accepting exceptions as configuration is a middle path with its own bill - configuration is untested code, and a rule table is only better than branches while someone governs what enters it.

When not to use it

The concept applies wherever systems are merged. The prior question is whether to consolidate at all. Similar capability is not the same capability: nine systems serving nine businesses with different regulators and different customers may be correctly separate, and a consolidation justified purely on the observation that nine teams all do "user management" will produce a platform that serves none of them.

Where the nine genuinely differ in process rather than in parameters, keep them separate and consolidate the platform underneath instead - shared identity, shared deployment, shared data model - which captures most of the saving without the requirements union.

Interview question

Q: You are asked to consolidate four regional order-management systems into one. In your first two weeks, before any design, what do you do and what would make you recommend against the programme entirely?

What a strong answer covers: counting conditionals on region, customer type and product across the four codebases as the real size estimate · getting the exception policy and a named decision-maker agreed before design starts · looking for systems that can be retired outright first · the recommendation against, with its conditions: different regulators, different customers, or an exception count so large that the union is more complex than the four · and the alternative of consolidating the platform beneath rather than the application above.

Quick check

Quiz: Why does the exception union beat data migration as the dominant risk in a consolidation? Because it arrives during requirements rather than during build, it is a scope risk rather than a schedule risk, and it compounds for the rest of the programme - while data migration has a known playbook of profile, map, reconcile and parallel-run.

Flashcard: What is the cheapest early estimate of a consolidation's real size? — The count of conditionals on department, region, product or customer type across the source codebases. Available in week two, before any design.