Five Platform Shifts in Eighteen Years — What Repeats

I have a personal test for whether I am being sold something.

When a new enterprise platform arrives, the pitch always contains a version of the sentence “this changes everything.” I have now heard that sentence about the data warehouse, about business intelligence, about in-memory computing, about cloud, and about agentic AI. Five times, spread across twenty-six calendar years and eighteen of doing this professionally at the level where I am accountable for whether it works.

The useful thing about having been present for all five is not scepticism. Scepticism is cheap and it makes you bad at your job — I know people who dismissed HANA in 2012 on the grounds that they had seen fast databases before, and they spent the next decade catching up. The useful thing is pattern recognition about how these things fail, which turns out to be remarkably stable even when the technology is not.

The five, briefly

The data warehouse era. The problem was that the data was in fourteen places. I spent the early 2000s at Silicon Laboratories, then on content development at SAP Labs, then running a data warehouse and data quality programme at Boeing. The promise was a single version of the truth. What we mostly built was a fourteenth place.

Business intelligence. The problem became making the data legible to people who did not write SQL. BW, BusinessObjects, and at Accenture a team of eleven turning a client’s legacy reporting into something logistics, procurement and finance could act on. The promise was self-service. What we mostly got was a report backlog with a nicer front end, plus — occasionally — something genuinely transformative, like the distributor-spend work that freed up to a fifth of a client’s distributor capital because it finally answered a question nobody had been able to ask.

In-memory. HANA arrived and query time stopped being a design constraint. This one was real, and it was underestimated, because the second-order effect was not speed — it was that when answers are instant, people ask different and better questions. At IBM I was architecting for this while winning implementations at Honda, VSP and Abbott.

Cloud and S/4. The problem stopped being capability and became migration. This is the era where I learned the most, because migration is where architecture meets organisational reality. At SAP I led analytics delivery for utilities clients under MaxAttention through their S/4 journeys, drove mass on-premise-to-cloud migrations on HANA, and eventually moved HANA services off Neo onto HANA Cloud across a portfolio.

Agentic. Which is now, and which I will come back to.

The four things that go wrong every time

Here is the pattern. I could have written this list in 2006 and only had to change the nouns.

One: the capability lands before the ownership does.

In every cycle, the technology is available months or years before anybody has decided who is accountable for the thing it produces. A warehouse with no data owner. A report with no definition owner. A cloud landscape with no cost owner. Now an agent with no decision owner. The technology is never the bottleneck; the org chart is, and the org chart moves on a slower clock than the release cycle.

Two: the new thing is used to reproduce the old thing.

Every cycle, the first wave of projects takes the previous era’s artifact and rebuilds it on the new platform. We put paper reports into the warehouse. We put warehouse reports into BI tools. We lifted on-premise architectures into the cloud unchanged and were surprised by the bill. And right now, a lot of agentic pilots are a chatbot wrapped around a report that already existed — which works, demos well, and changes nothing, because the underlying process was never the constraint.

Three: the foundation gets skipped, then billed later with interest.

Nobody has ever been promoted for data quality work. So it gets deferred, every cycle, and every cycle the platform above it inherits the deferral. The difference now is the failure mode: a bad warehouse gave you a number a controller could see was wrong. A badly grounded agent gives you a fluent paragraph that reads like diligence.

Four: the benefit is asserted rather than instrumented.

In all five eras, the majority of business cases I have reviewed were built on estimated time savings with a self-reported baseline, and the majority could not be defended twelve months later. This is the most boring recurring failure and the one that most reliably kills renewals.

If you are running an agentic programme right now, those four are your risk register. They were mine in 2009 and they will be somebody’s in 2033 about whatever comes next.

What is actually different this time

Now the harder question, because pattern recognition has a failure mode of its own. If you have seen five cycles, it is very tempting to conclude that everything is a cycle, and that conclusion would have made me wrong about HANA. So I want to be careful about what I claim is new.

Most of what is marketed as unprecedented about agentic AI is, in my experience, a difference in degree. Faster. More accessible. Better at unstructured input. Real, valuable, not categorically new.

But one thing is different in kind, and it is not the thing on the slides.

In every previous era, the system produced information and a human produced the action. The warehouse gave you a number and a planner made a call. HANA gave you the number faster and the planner made the call faster. The accountability boundary sat in exactly the same place for twenty-two years: the machine informs, the person decides, the person is accountable.

Agentic systems move that boundary. When an agent closes a loop — reconciles the exception, adjusts the order, releases the item — the action has been taken by something that cannot be accountable for it. Accountability does not disappear; it relocates, to whoever configured the scope, set the threshold, and approved the deployment. That is genuinely new, and it is why the governance conversation in this cycle is not the usual security-review theatre. It is the actual substance of the work.

Which also explains why the four recurring failures bite harder now. Unclear ownership used to produce a report nobody trusted. Now it produces actions nobody authorised. A skipped foundation used to produce a wrong number. Now it produces a confident wrong action, at volume, with an audit trail that explains what happened but not why anyone thought it was acceptable.

Same failure modes. Higher stakes. That combination is what makes this the most interesting stretch of work I have had.

What I would tell someone entering this cycle

Read the last cycle’s post-mortems, not the current cycle’s marketing. The vocabulary will be unfamiliar and the failures will be identical.

Then do the four unfashionable things. Name an owner for every decision the agent participates in. Refuse to rebuild an existing artifact as your first use case — find a process that is genuinely bad and frequent. Fix the specific slice of foundation that use case needs, properly. And instrument the benefit before you change the process, while the baseline still exists.

None of that is novel advice. That is rather the point. Eighteen years in, the most valuable thing I carry is not a view about which platform wins. It is a fairly precise sense of which corner the programme dies in — and it has been the same corner every time.