Producer Retirement Gate

A retirement programme switches off System D in March after its 90 users have moved. The disposition record says "no downstream consumers", and it was not careless: the integration catalogue listed D's outbound interfaces and there were none.

Week 2, a nightly pricing job starts producing output identical to the previous day - every value plausible, nothing erroring. Week 7, a quarterly regulatory extract comes out 4% off. Month 5, somebody traces it to a currency-rounding reference table that a batch job inside D refreshed each night and four other systems read out of a shared schema.

The dependency was on data and the evidence used to approve the retirement was about interfaces. No interface existed because none was built: producer and consumers shared a database, so the coupling left no trace in any model of connections between systems. A Producer Retirement Gate asks the other question - what stops being maintained when this goes away?

Why it matters

Retirement is the only portfolio action that actually removes cost, and the one organisations are most reluctant to approve. Every silent failure traced back to a decommissioning slows the next twenty retirements, so the cost of one undetected producer loss is measured in programme velocity rather than in the incident.

The failure class is worse than an outage, which is fast, loud and attributed to the change that caused it. A system producing plausible output from data nobody maintains compounds for months, and by the time anyone asks, the wrong values are in the warehouse, in approved reports and possibly in an external filing.

Implementation patterns

• Derive write dependencies from the estate, not from interviews. Grants, scheduled-job inventories and query logs say who writes which table. The departing owner frequently does not know who reads their tables, so a survey returns a recollection where a query returns a list.
• Record a producing system for every reference data set in the portfolio model, and make "producer retired with no named successor" a hard block on disposition. One attribute, and it is the structural fix.
• Assert freshness where staleness is silent: a last_refreshed column with a job that fails on an exceeded interval, plus an alert on output identical to the previous run. This catches the failure in week 2 rather than month 5 and costs less than everything else here.
• Hold the disposition open for one full business cycle, since a quarterly process is untested until a quarter has passed.
• Gate selectively: run the derivation only where the candidate owns a schema or runs a scheduled job. Those two conditions select nearly all of the risk.

Industry example

The pattern recurs wherever an estate grew by acquisition and several systems share a database. Its loud cousin is well documented: in April 2022 a maintenance script at Atlassian used the wrong identifiers and deleted roughly 775 customers' sites, with restoration running up to two weeks.

The producer-side failure has no equivalent public postmortems, and that is the lesson worth teaching: silent data staleness does not generate incident reports, so it is under-represented in the literature relative to how often it happens. The organisations that have it do not know yet.

Failure scenarios

• Interface inventory used as the dependency model, so a shared-schema producer is invisible and "no consumers" is both true and dangerously incomplete.
• A stale read indistinguishable from a correct read, because no consumer asserts freshness.
• Equality to the previous run treated as a quiet day rather than as the alarm it is.
• A successor named but never built, because the gate was satisfied by a plan. Require the successor to be producing before switch-off.
• Contaminated downstream copies, making remediation a back-fill with a business owner rather than a code fix.

Trade-offs

Running the derivation costs half a day to two days per candidate depending on instrumentation - a few weeks a year for a programme retiring 23 systems, and selective gating removes most of that.

What it buys is speed of approval. The gate's real product is confidence: a programme that has never caused a silent data failure gets its dispositions signed in days rather than argued for quarters.

The cost that is easy to miss is that the gate will block retirements. A system whose producer role has no successor cannot be switched off, so the forecast slips while somebody builds one - correct and unpopular, which is why the block must be a published rule rather than a reviewer's judgement.

When not to use it

For a front-end over somebody else's data. No schema of its own and no scheduled jobs means it writes nothing, and deriving a write-dependency graph for it taxes the programme.

When the estate already has data-product contracts with named owners and freshness objectives, since the successor question is then answered by the contract register. Check whether it covers reference and static data, which is usually where coverage stops.

For a greenfield estate with no shared schemas, where the interface inventory genuinely is the dependency model.

Interview question

Q: You are about to switch off 23 of 140 applications this year. Design the disposition gate: what evidence you require before approving a switch-off, how you obtain it without relying on the owner's memory, and what you do where the evidence says the retirement is unsafe.

What a strong answer covers: separating the interface graph from the data graph and knowing the second is the risk · deriving write dependencies from grants, job schedules and query logs rather than by survey · the two qualifying conditions that keep the gate proportionate · freshness assertions as the detection control · and the uncomfortable part, that the gate will block some retirements, so it must be a published rule and not a reviewer's call.

Quick check

Quiz: Why does an integration catalogue approve an unsafe retirement? — It models connections between systems, and a producer writing into a shared schema has no connection to model, so "no downstream consumers" is true and incomplete.

Flashcard: What is the cheapest control that catches a lost reference-data producer? — An alert when a job's output is identical to its previous run, plus a freshness check that fails on an exceeded interval. It turns five months of archaeology into a week-2 page.