Why Platforms Decay: The Operate Half of an Operational Platform

The build half of an operational platform is genuinely hard, and plenty of organisations do it well. Requirements get gathered, systems get connected, data gets migrated, people get trained, and one weekend the thing goes live and works. That is a real achievement and it usually gets the celebration it deserves.

It is also the last day the platform will match the operation exactly.

Not because anything was built badly. Because from that morning onward, every system it touches begins moving independently of it.

Decay Is Not Disrepair

"Decay" sounds like neglect, as though software corrodes when left alone. It doesn't. The platform sits precisely where you left it, doing precisely what it was built to do. What moves is everything around it.

Take the release cadence of one connected system. Salesforce delivers new features three times a year, in Spring, Summer and Winter, and that schedule is not a matter of preference. Asked directly whether an upgrade can be deferred, the documentation answers that it cannot, and that "automatic upgrades are mandatory as outlined in your Salesforce contract." The same page notes that when older API versions are retired, "implementations that continue to use older technology will stop working."

None of that is a criticism. Shipping on a predictable cadence and retiring old interfaces is what a well-run platform should do, and most major enterprise systems now work the same way. But it establishes something uncomfortable about the ground your integrations stand on: it moves several times a year, on a timetable you do not set, and there is no opting out.

Now multiply that by every system in the estate, and add the changes your own organisation makes.

Nothing on That List Is a Failure

Read the events again and notice what is absent: incompetence. A team adding a required field is doing their job. A vendor retiring an old API is maintaining their platform responsibly. Growing volumes are the business succeeding. An analyst taking a better role is a career.

Drift is not an accumulation of mistakes. It is an accumulation of reasonable decisions, made by people who were not coordinating with the integration layer, because coordinating with it was nobody's job.

That is why decay catches people off guard. They look for the error that caused it and cannot find one. The platform was correct at go-live, and it remains correct about a world that has since moved on.

What Unowned Drift Becomes

Left unabsorbed, those changes convert into technical debt, and there is credible evidence for both its scale and its direction. McKinsey's survey of CIOs found that tech debt amounts to 20 to 40 percent of the value of their entire technology estate before depreciation, and that 10 to 20 percent of the technology budget earmarked for new products is diverted to resolving it instead.

The direction matters more than the magnitude. In the same research, 60 percent of CIOs said their organisation's tech debt had risen perceptibly over the previous three years. Decay is not an unlucky outcome that befalls badly run estates. It is the default trajectory, and holding position against it takes deliberate, funded effort.

The Mechanism Nobody Budgets For

Two of the events in that timeline concern people rather than systems, and they are the two most often missing from a support arrangement.

Integration logic depends unusually heavily on the reasoning behind it. The mapping is visible in the implementation; why it was built that way frequently is not. When that reasoning walks out, the platform does not break. Something quieter happens: change stops, because nobody will alter a system they cannot explain.

And people do move, at a rate that is measured. The ABS reports that just over 1.0 million employed people, or 7.2 per cent, changed their employer or business in the year to February 2026, down from 7.7 per cent the year before. In Professional, Scientific and Technical Services, where many of the people who build integrations sit, the rate was 8.1 per cent. Across a two-year window, assuming the same individuals will still be there to explain the platform is not a safe bet.

Who Owns Each Surface

So the cause of decay is easy to state and awkward to act on. Change arrives continuously, and most organisations have no standing owner for most of the surfaces it arrives on. Support contracts cover the systems themselves. Very little covers the connective layer between them.

It is worth being concrete, because the list is shorter than people expect. There are roughly eight surfaces where drift actually lands.

The pattern is consistent across organisations. The loud surfaces get owners, because their failures are obvious and someone gets called. The quiet ones fail silently, which is exactly why they drift furthest before anyone looks. A stalled integration is the worst of them, because the reporting layer keeps presenting the last values it received as though they were current, which is the failure mode described in Visibility Is Not Reporting.

What the Operate Half Actually Is

It is not a support contract with a response-time commitment. Responding quickly to breakage has value, but it is a different discipline: it begins after something has already stopped. The operate half is the standing work of absorbing change before it turns into breakage.

• Inventory and change surveillance — every connection and the version it depends on, checked against vendor release notes each cycle.
• Schema and reference-data stewardship — one authoritative definition per entity and per list, maintained as new values appear rather than after they cause a discrepancy.
• Exception promotion — recurring manual workarounds converted into designed paths on a routine basis.
• Access and flow monitoring — credential expiry tracked ahead of time, and a stalled flow raising an alert rather than a question.
• Written reasoning — the why recorded outside anyone's memory, and updated as part of making changes rather than afterwards.

This is what "owning maintenance forever" involves in practice. The Build vs. Buy Decision names it as one of five factors that settle the build-or-buy question, and it is the easiest of the five to underrate while the platform is still theoretical.

The Path Forward

There is a specific trap at the end of unmanaged drift. After a few years the platform and the operation have diverged far enough that repair looks harder than replacement, so a business case gets written for something new. It is usually approved, because the incumbent demonstrably no longer fits. Then the same clock starts again on day one, against the same estate, with the same surfaces unowned.

Breaking that cycle does not take a programme. It takes naming an owner for each of those surfaces and treating the quiet ones as seriously as the loud ones. The connective layer is what carries work between your systems, which is why The Operational Last Mile argues it deserves deliberate design to begin with, and why letting it decay quietly returns you to The Integration Tax you were paying before you built it.

A platform is not something you finish. It is something you keep aligned with an operation that will not stop changing.

Want the operate half handled properly? Start the conversation — we'll review which drift surfaces have owners in your organisation today, and where the gaps are most likely to cost you first.

---

Sources

1. Salesforce. Salesforce upgrade release schedule FAQ. Salesforce Help, published 24 February 2026. help.salesforce.com — "Salesforce delivers new features three times a year. The seasonal releases occur in Spring (February), Summer (June), and Winter (October)"; "Can I delay the push upgrade to production? No, upgrades are scheduled according to the Salesforce release calendar"; "automatic upgrades are mandatory as outlined in your Salesforce contract"; and, on retired managed-package API versions, "Implementations that continue to use older technology will stop working."

2. McKinsey & Company. Tech Debt: Reclaiming Tech Equity. 2020. mckinsey.com — CIOs reported that 10 to 20 percent of the technology budget dedicated to new products is diverted to resolving issues related to tech debt; CIOs estimated tech debt amounts to 20 to 40 percent of the value of their entire technology estate before depreciation; 60 percent of the CIOs surveyed felt their organisation's tech debt had risen perceptibly over the past three years.

3. Australian Bureau of Statistics. Job mobility continues to decline into 2026. Media release, 31 July 2026. abs.gov.au — just over 1.0 million employed people (7.2 per cent) changed their employer or business in the year to February 2026, compared with 7.7 per cent over the previous year; job mobility in Professional, Scientific and Technical Services was 8.1 per cent.