Business-Cycle Observation Window

A replaced system is made read-only for thirty days. Nothing complains. It is switched off and its data archived. Three weeks later the annual regulatory extract fails, because it read straight from the retired database, and nobody knew it existed.

Every step of that was done carefully. The flaw is in the arithmetic of the evidence: a traffic-based observation can only prove the absence of consumers that would have run during the observation period. Thirty days is a number that feels thorough. It has no relationship to the system being retired.

The practice is to derive the window from the system itself: find the longest period on which anything touching this system runs, and observe for at least that long. For anything connected to finance, regulation or audit, that is thirteen months, not thirty days.

Why it matters

Consumers of an enterprise system are not uniformly distributed in frequency. There is a dense band of continuous, daily and weekly work, and then a long tail at monthly, quarterly, annual and on-request frequencies. The tail is small in count and large in consequence, because the annual and quarterly jobs are the regulatory, statutory and financial ones.

Detection latency compounds it. A decommissioning mistake is not discovered in minutes; it is discovered when the consumer next runs. Retire a system in February and break the annual close, and the outage is announced in the following January, long after the team has moved on and the environment is gone.

Implementation patterns

• Inventory from the calendar, not from traffic. Scheduler definitions, batch calendars and job dependency chains list jobs that have not run yet, which is the one thing a log cannot do.
• Add firewall rules, connection logs, service-account usage and BI extract definitions, each of which names consumers nobody remembers.
• Stage the shutdown so every stage emits a signal: read-only, then reject all connections with a logged and paged error, then stop the service, then delete. Rejecting is what converts a silent reader into an alert; read-only proves only that nothing is writing.
• Keep the hostname, port and credentials alive after the data has moved, answering with a loud error that names the archive and the owner, for at least one further cycle. This turns an unfindable failure into a support ticket with an answer in it.
• Publish the shutdown date against the business calendar — "after the year-end close completes" — rather than against a project milestone.
• Write down the window you chose and why. If the batch calendar is genuinely empty and there are no reporting consumers, thirty days is defensible; the decision is the artefact, not the number.

Industry example

Published postmortems of administrative actions that removed something still in use share one shape with this failure: an irreversible step taken on evidence that was not wrong so much as too short. The removal is executed correctly against an inventory that was complete for the period it observed, and the consumer it missed was simply not running during that period. In the decommissioning case the delay between action and discovery is longer, because it is set by the missed consumer's own period rather than by a request rate.

Organisations that do this well in production are recognisable by one habit: their decommissioning plans are dated relative to the finance calendar — "after the year-end close completes" — and their "no remaining consumers" claim cites the longest-period job they could find rather than a number of days. The difference costs a year of run cost on one system and removes an entire class of incident.

Failure scenarios

• The annual job. Found three weeks to eleven months after shutdown, usually by a regulator's deadline.
• The quarterly board pack built on an extract from the retired store, discovered at the worst possible moment in the reporting cycle.
• The read-only stage that proves nothing, because every reading consumer kept working silently through the entire watch.
• A consumer that is a person, not a job — the analyst who connects once a year to produce a comparison — which no scheduler lists.
• The environment is gone. By the time the failure appears, the servers are decommissioned, the credentials are rotated, and the recovery is a rebuild rather than a restart.

Trade-offs

A thirteen-month window costs a further year of licences, hosting, patching and on-call for a system nobody wants. On a mid-sized estate that is a real number, and the pressure to shorten it is constant and legitimate.

The counterweight is asymmetry: the saving from shortening the window is a fraction of one system's annual run cost, and the exposure is a missed regulatory filing or an unreproducible prior-year comparison. The pragmatic middle is to shorten the expensive part rather than the watch — move to archive storage and a minimal error-answering endpoint early, so what runs for thirteen months costs almost nothing while the evidence continues to accumulate.

When not to use it

For a system with no batch, no reporting and no regulatory extracts, thirteen months is theatre. An internal tool with only interactive users, whose entire consumer set is visible in a month of access logs, should be retired in weeks. Applying a full-cycle window there wastes a year of run cost to protect against a consumer class that does not exist.

The test is evidential rather than cultural: look at the batch calendar and the BI catalogue. If both are empty, record that finding and switch the system off. The practice is about deriving the window from the system, and sometimes the system answers "short".

Interview question

Q: You are retiring a system that has been read-only for 30 days with no complaints. Convince me it is safe to switch off — and tell me what evidence would change your mind, and what you would keep running afterwards even once it is off.

What a strong answer covers: that silence under read-only is weak evidence because readers succeed silently · the sampling argument that a 30-day watch cannot observe a monthly, quarterly or annual consumer · calendar and scheduler inventory as the source that lists jobs before they run · the staged shutdown where the reject stage is what produces signal · keeping the hostname answering with a loud named error for a further cycle · and the honest cost, plus the conditions under which 30 days is genuinely enough.

Quick check

Quiz: Why does a 30-day read-only soak fail to prove a system has no consumers? Because reading consumers succeed silently and the watch is shorter than the monthly, quarterly and annual cycles on which the highest-consequence jobs run.

Flashcard: How long should you watch a system before switching it off, and what stage actually produces evidence? — At least one full business cycle, which for anything touching finance or regulation means thirteen months; and the stage that produces evidence is rejecting connections with a logged error, not making the system read-only.