Zombie Integration

A rationalisation programme retires an application. Users are migrated, the service is stopped, the project reports a completion. The 14 interfaces that fed it, or read from it, are still scheduled.

What happens next is determined by one property: whether each interface fails loudly or silently. A write to a queue nobody drains, or a file transfer to a directory nobody reads, produces no error at all. Where it does fail, the alert usually reaches a team that no longer knows what the target was, and the fastest resolution available under pressure is to disable the job or add an exception — a permanent decision made in ten minutes by someone without the context to make it.

Why it matters

The expensive consequence is not the broken job. It is the downstream systems that keep consuming the last data the retired system produced. A reference extract stops updating, every pipeline stays green, and some months later a number in a report is wrong. Stale data is harder to diagnose than missing data, because nothing in the monitoring distinguishes "correct and unchanged" from "frozen".

The second consequence is financial and it is why rationalisation programmes have their reputation. A programme identifies savings; the application is switched off; the licence, the database instance, the middleware route, the certificates and the monitoring all persist because something still references them. The application is off and the estate around it is not, so a large fraction of the identified saving is never booked.

The third is that the debris makes future change harder. In two years an engineer modernising an adjacent system finds connections to a system nobody recognises, cannot establish whether anything depends on them, and leaves them alone. That accumulation is a substantial part of what people mean when they say an estate is unchangeable.

Implementation patterns

• Define decommissioning at the interface level. The exit criterion is "zero remaining connections", evidenced by observed network flow, not by an application being stopped.
• Instrument before switching off. Run the system for a period with logging on every inbound and outbound connection, and treat that as the true inventory. The documented list is always shorter than the observed one.
• Retire in reverse order of data flow: cut producers first, then the system, then consumers, so that any break is loud and happens at a known time with the right people watching.
• Keep it reversible for a defined window. Stop the application but keep its data restorable for about 90 days, because whatever was missed usually surfaces within one reporting cycle.
• Book the saving against a named cost line with a renewal date. A saving credited to "the estate" is verified by nobody; an unclaimed licence is the evidence that the work is not finished.
• Revoke credentials and certificates as a tracked step, because a service account with production access to an unmaintained system is a standing security finding.

Industry example

This is a pattern documented more in audit findings and portfolio reviews than in engineering blogs, for the obvious reason that nobody publishes an account of savings they did not achieve. The adjacent and better-documented case is Atlassian's April 2022 incident, where a maintenance script run with the wrong identifiers deleted sites for 775 customers and restoration took until mid-April for the last of them: the lesson that transfers is that the lifecycle tooling around an estate is under-tested relative to the estate itself, and decommissioning is the least tested part of that lifecycle because it is performed rarely and by people who will not be there next time.

Failure scenarios

• Silent producers. Jobs that write to a dead destination and report success, so the loss is discovered by a reconciliation months later.
• Frozen reference data. Consumers using an extract that no longer updates, with every health check green.
• Disabled-by-an-engineer. A failing job switched off during an incident, where the switching off was correct and nobody ever established what else depended on it.
• Unbooked savings. Infrastructure retained because a reference exists, so the business case is quietly not delivered.
• Standing credentials. Service accounts and certificates that outlive their system, renewed automatically for years.
• Archaeology tax. A later project blocked because nobody can prove that 14 connections are dead, so they are left in place, permanently.

Trade-offs

Doing decommissioning properly costs real engineering at exactly the moment a programme wants to declare success, and it is unglamorous work with no user-visible output. That is why it is cut, and the cost of cutting it is deferred and diffuse rather than immediate.

The genuine trade-off is in the reversibility window. Keeping data restorable for 90 days costs storage and keeps a retention obligation alive; cutting it immediately is cheaper and removes the recovery option at the exact point where you are most likely to need it. Prefer the window unless the data itself is a liability, in which case the retention rule decides.

When not to use it

The full discipline is disproportionate for a system with two interfaces you can read in an afternoon. Switch it off, watch for a week, and clean up.

It is also wrong to block a retirement on completing the interface work first, in the case where the application is a genuine risk — an unpatched system with known vulnerabilities. There, stopping it is urgent and the debris is a follow-up. Just make it a funded follow-up with an owner and a date, because "we will clean it up later" without those three things is how the debris became permanent everywhere else.

Interview question

Q: A programme reports that 60 applications have been retired and £8M of annual savings identified. A year later finance can find £1.2M. Explain the gap, and tell me what you would have required in the programme's definition of done.

What a strong answer covers: the distinction between switching off an application and retiring the estate around it; unbooked licences, instances, routes and monitoring retained because a reference survives; the people cost that was counted and is not recoverable; stale-data failures downstream that surface a reporting cycle later; a definition of done expressed as zero observed connections plus a named cost line with a renewal date; instrumenting before switch-off because documented interface lists are always short; and reverse-order retirement so breakage is loud and timed.

Quick check

Quiz: Why is a silently failing interface worse than a loudly failing one after a decommissioning? — A loud failure is investigated at a known time; a silent one leaves downstream consumers using frozen data with every health check green, and the error surfaces as a wrong number months later.

Flashcard: What is the exit criterion for decommissioning, and what evidence counts? — Zero remaining connections, evidenced by observed network flow rather than by a documented interface list, which is always shorter than reality.