Intellectual honesty requires, at some point, an accounting of what you got wrong. Not the small mistakes — the project that ran late, the estimation that proved optimistic, the approach that needed adjustment. The structural predictions: the ones about where the technology was going, made with confidence, that turned out to be substantially incorrect. I have made several. Here, for the record, is a selection.
Client-Server Would Kill the Mainframe
In the early nineties, the consensus was clear: distributed client-server architectures were going to make centralised mainframe computing obsolete. The economics were compelling, the direction seemed obvious, and the mainframe's days appeared numbered. I believed this, argued for it, and made architectural recommendations based on it.
The mainframe is still running. Not just surviving — in many financial institutions it is still running the most critical processing at the core of the business. It turned out that the very characteristics that seemed to make it obsolete — its centralisation, its operational model, its cost structure — were features in specific contexts rather than defects. The distributed computing revolution happened. The mainframe remained.
What I misread was the difference between a technology that was losing ground in new applications and a technology that was irreplaceable in established critical functions. Those are different things. I conflated them.
Service-Oriented Architecture Would Solve Integration
SOA arrived at a moment when the integration problem in large organisations was acute. Decades of point-to-point connections, undocumented interfaces, and systems that communicated in ways nobody fully understood anymore. SOA — services with defined contracts, discoverable, reusable — appeared to offer a principled solution. I was an advocate.
What happened was that SOA solved the conceptual problem while creating substantial new operational and governance problems. Service proliferation. The ESB becoming a new integration bottleneck. Governance overhead that slowed the pace of change. And the underlying integration complexity did not disappear — it migrated into the service layer and became, in many cases, harder to manage rather than easier.
Microservices came along a decade later and, looked at from a distance, addressed several of the same integration problems using many of the same ideas — with different operational trade-offs and different governance failures at scale. The problem turned out to be harder and more persistent than the solution made it appear.
Big Data Would Democratise Insight
The promise of big data was that the volume of data organisations held, properly analysed, would produce insights that had previously been invisible. The democratisation of data — making it available to the people who needed it — would transform decision-making. I believed this and designed programmes around it.
What happened, in most organisations, was that the volume of data grew dramatically, the cost and complexity of managing it grew alongside it, and the number of people making genuinely better decisions as a result of it grew more slowly than anyone had projected. The data quality problems that had always existed became more visible and more consequential. The governance problems that nobody had solved with small data were not solved by making the data larger.
The insight problem turned out not to be primarily a data volume problem. It was a data quality problem, a governance problem, and a culture problem. More data made all three harder, not easier.
Being wrong about these things was not comfortable. But the discomfort was productive. Each wrong prediction taught something that correct predictions did not: that the gap between a convincing solution narrative and a working solution in a real organisation is large, and that the gap is almost always larger than the people selling the narrative suggest.
The predictions I trust most now are the ones that account for implementation complexity, governance failure, and human resistance — the forces that determine whether a technically sound idea actually works in practice. Those forces are less interesting to write about. They are considerably more reliable to plan around.