We've Seen This Movie Before: Thirty Years of Bolting On Instead of Rebuilding

I've now watched this happen six times. Not read about it. Not studied it in a case-study deck. Watched it — from inside enterprise IT, across three decades of technology waves that each arrived promising to change how business gets done.

And each time, with almost mechanical predictability, the enterprise response was similar:

Bolt the new thing onto what already exists. Demonstrate adoption. Let engineering absorb the architectural compromise for years afterward.

I want to walk through all six waves because the pattern becomes difficult to ignore once you see the full sweep of it.

Earlier this week, I wrote about what can happen when AI changes the operating model itself: capacity can grow without requiring human capacity to grow at the same rate.

But that raises a harder question:

If the economics can be fundamentally different, why is genuine operating-model transformation still so difficult?

The answer may be hiding in the last thirty years of enterprise technology adoption.

And there is an important reason to revisit that history now.

The sixth wave — agentic and generative AI — is different.

Bolting AI onto yesterday's architecture doesn't merely constrain the benefit.

It can undermine the autonomy we are trying to create.

Wave one: RISC gives way to Intel, but the architecture largely follows

There was a period when RISC-based systems were the platforms large enterprises trusted for serious workloads.

As Intel-based servers became increasingly viable, they created more than a lower-cost hardware alternative. They opened the possibility of distributing applications across larger numbers of smaller systems rather than continuing to concentrate computing inside increasingly powerful centralized machines.

Distributed computing environments offered an architectural path toward that model.

But across much of the enterprise market, the dominant path was adaptation rather than architectural reinvention.

Existing applications were ported or recompiled onto Intel-based Unix and other x86 environments while retaining many of the centralized design assumptions under which they had originally been built.

Even the hardware evolved partly in response to that expectation. Rather than the market moving entirely toward fleets of smaller distributed systems, increasingly capable multiprocessor Intel servers emerged to address workloads historically associated with larger RISC platforms.

The new economics had arrived.

The architecture often followed much more slowly.

Adaptation largely won over reinvention.

Wave two: client-server repeats the pattern

The transition from centralized computing toward client-server architecture offered another opportunity to rethink application design.

In principle, client-server meant more than moving an interface onto a PC.

It enabled separation of presentation, application logic and data, with computing responsibilities distributed across systems designed for different purposes.

In practice, many enterprise implementations carried forward substantial portions of the centralized architecture they were supposed to replace.

The ecosystem eventually matured.

Distributed computing technologies improved. Wide-area networking and routing became more capable. Operating systems such as Windows NT made distributed enterprise workloads increasingly practical.

Over time, enterprises moved closer to what client-server had promised.

But again, technology adoption frequently preceded architectural transformation.

The new platform arrived first.

The operating and application architecture caught up later.

Wave three: the internet gets HTML-ized

Then came the internet.

The browser changed the way people expected to interact with applications. "Anywhere, anytime" access became a strategic requirement.

But once again, the fastest enterprise response was often not to redesign applications around internet-native principles.

It was to wrap what already existed.

Large enterprise applications gained browser interfaces while much of the underlying application logic, state management and transaction architecture remained rooted in an earlier era.

The browser made the application look internet-enabled.

That did not necessarily make the application internet-native.

The architectural gap eventually helped drive another generation of change: service-oriented architecture, web services, APIs and increasingly modular approaches to exposing application capability.

Once again:

Adoption arrived before nativity.

And another architectural wave was required to address some of what the previous one had left behind.

Wave four: virtualization and containers inherit the physical-server mindset

Virtualization should have fundamentally changed infrastructure operations.

A virtual machine was no longer a physical asset tied permanently to a specific piece of hardware.

But physical-to-virtual migrations often preserved many of the operating assumptions of the physical world.

I saw managed-services environments where the operational distinction between a physical server and a VM was surprisingly small.

They were monitored similarly. Managed similarly. Patched similarly. Capacity-planned similarly.

The infrastructure had become virtual.

The operating model had not.

Then containers arrived and exposed the same pattern even more clearly.

A container can have a lifespan measured in minutes.

Yet I have seen environments attempting to monitor, patch and manage ephemeral infrastructure using concepts inherited from physical machines designed to remain in a rack for years.

The architecture had changed completely.

The operating mindset had barely moved.

Wave five: cloud becomes infrastructure modernization

Cloud should have been another opportunity to break the pattern.

And in some organizations, it was.

Cloud-native applications were designed around elasticity, distributed services, APIs, managed platforms, automation and increasingly ephemeral infrastructure.

But for large portions of the enterprise estate, cloud migration became infrastructure modernization rather than application rearchitecture.

The destination changed.

The application often did not.

A virtual machine moved from an enterprise data center into a hyperscaler environment.

The procurement model changed. The consumption model changed. The logo on the architecture diagram changed.

But many of the fundamental application and operating assumptions remained.

That is why so many enterprises eventually discovered that moving workloads to cloud did not automatically produce the economics or agility originally promised.

The same tendency appeared in software-defined networking, software-defined storage and SD-WAN.

New capability. Familiar operating assumptions.

The board-question problem

Across these waves, I don't believe the primary problem was a lack of technical understanding.

There is a more structural explanation.

"We've adopted it" answers an executive question much faster than "we've rebuilt for it."

Adoption can be represented on a roadmap.

Applications migrated. Cloud consumption increased. Virtualization percentage increased. Containers deployed. AI copilots enabled. Agents launched.

Those are visible milestones.

Rearchitecture is harder.

It crosses organizational boundaries. It changes processes. It challenges existing operating models. It requires investment before the full economic benefit becomes visible.

And inevitably someone asks:

Where is the ROI?

That question is entirely reasonable.

But it creates an incentive to demonstrate technology adoption before the organization has done the more difficult work required to capture the technology's native economics.

That is why I think the more useful executive question isn't:

Have we adopted the technology?

It is:

Did the operating model underneath actually change?

Because if it didn't, the technology may be new while the economics remain remarkably familiar.

Where I've lived this personally

This pattern isn't abstract for me.

I've watched it happen with capability I helped build.

Roughly a decade ago, I worked on an anomaly-detection-based incident-avoidance capability.

The idea was straightforward but represented a very different operating model.

Take metric streams from monitoring systems. Correlate signals across infrastructure. Identify emerging anomalies. Determine likely root causes. Intervene before the condition becomes a Severity-1 incident.

The objective wasn't to detect incidents faster.

It was to prevent some incidents from existing at all.

We demonstrated the approach across environments involving many of the major monitoring and AIOps technologies of that era — including Dynatrace, AppDynamics, CA, HP, ELK and Moogsoft.

The capability worked.

I later co-authored an article with a CIO describing the thinking behind this approach.

But moving from successful demonstrations to scaled production operations exposed the real challenge.

The technology wasn't the difficult part.

To prevent business-impacting incidents reliably, you needed to understand the business process itself.

What applications supported it? What infrastructure did those applications depend upon? Which signals represented genuine degradation of the business service? Which conditions were symptoms and which were causes? What action could safely be taken before a user ever experienced the failure?

That requires more than another monitoring tool.

It requires business-service context and operating-model change.

And many environments ultimately reverted toward familiar alert-based, reactive monitoring.

Not necessarily because the technology couldn't work.

Because buying and deploying another monitoring capability was easier than redesigning operations around incident avoidance.

The tool answered the adoption question.

The operating-model transformation was considerably harder.

Wave six: agentic and generative AI

Now we are doing it again.

Frontier and open-weight LLMs have put extraordinary capability within reach of virtually every enterprise.

Generative AI can interpret. Reason. Generate. Classify. Summarize. Write code. Interact with systems.

And increasingly, agents can combine reasoning with execution.

This should force us to reconsider how enterprise systems and operations are designed.

Instead, much of the early enterprise response looks remarkably familiar:

Put AI on top of the existing estate.

Copilot on the application. Agent on the workflow. LLM on the knowledge base. RAG on the documentation. Agentic execution on the existing process.

Then measure adoption.

Users enabled. Prompts submitted. Tokens consumed. Agents deployed.

But there is a fundamental question underneath all of this:

Was the enterprise underneath ever designed for intelligence and autonomous execution?

Usually, it wasn't.

Its data architecture assumes human interpretation. Its permission models assume human pacing. Its workflows assume human checkpoints. Its exception handling assumes someone will eventually look at the queue. Its observability architecture frequently assumes something has already failed before action begins. Its applications expose interfaces designed primarily for humans rather than autonomous actors.

Putting an agent on top doesn't make that architecture AI-native.

It makes AI responsible for navigating architecture built for a different operating assumption.

Why this wave is different

Previous generations of bolt-on adoption certainly created cost, complexity and technical debt.

But they had one enormous advantage.

Humans remained embedded throughout the execution model.

When systems didn't integrate cleanly, a person reconciled them. When workflows broke, someone investigated. When context was missing, someone interpreted it. When an exception appeared, somebody eventually noticed.

Human intervention acted as the architectural shock absorber.

Agentic AI changes the equation because its objective is progressively to remove human intervention from execution loops.

That is precisely where much of its economic value comes from.

But it also means we cannot assume that architecture designed around human-paced review will behave the same way when autonomous systems begin operating inside it.

An agent can execute faster than a human. It can also repeat an incorrect action faster. Multiple agents can interact. Actions can create new state that becomes context for subsequent reasoning. Errors — and advantages — can propagate at machine speed.

Architecture that was tolerable because a human would eventually catch the problem may not remain tolerable when the goal is for the human not to be there.

That is why AI-native architecture isn't simply about getting better model performance.

It is about redesigning the environment in which intelligence operates.

AI-native does not mean AI everywhere

There is another trap worth avoiding.

Becoming AI-native does not mean inserting AI into every workflow.

In fact, sometimes the most AI-native decision is to eliminate the workflow entirely.

Before asking which agent should perform an activity, ask:

Should this activity exist?

Before predicting an incident, ask whether its underlying cause can be eliminated. Before automating a service request, ask whether the user should need to request the service at all. Before creating an agent to navigate six systems, ask whether those six handoffs represent an architectural problem that should be removed.

The sequence matters:

• Eliminate what should not exist.
• Prevent what should not happen.
• Enable self-service where users can act directly.
• Automate deterministic work where intelligence adds no value.
• Use agents where reasoning and autonomous execution create value.
• Use humans where judgment, accountability or expertise genuinely requires them.

That is a very different proposition from attaching AI to every process currently visible in the enterprise.

The question I'd ask every CIO

Look at the enterprise estate accumulated across previous technology waves.

There are applications whose architectural assumptions originated several generations ago. There are systems migrated repeatedly without being fundamentally redesigned. There are virtualized workloads still operated with physical-server thinking. Containers managed using concepts inherited from persistent infrastructure. Cloud estates carrying application assumptions formed long before cloud existed.

None of this means every legacy system should be rewritten.

That would be economically unrealistic and, in many cases, unnecessary.

But it does mean the accumulated estate should serve as a warning.

Technology migration and architectural transformation are not the same thing.

And we should be careful not to build another generation of technical debt by treating AI adoption as proof of AI transformation.

The question for CIOs, CTOs and business leaders therefore isn't simply:

Where can we deploy AI?

It is:

If intelligence and autonomous execution had been available when we designed this process, application or operating model, would we have built it this way at all?

That question produces very different answers.

And potentially very different economics.

Rebuild the operating model, not just the technology stack

The alternative isn't another multi-year technology program whose objective is simply to replace everything that came before it.

It is to start with the operating model we actually want.

Then work backward.

What work should disappear? What conditions should be predicted or prevented? What should users be empowered to do directly? What can execute deterministically? Where does agentic reasoning belong? Where should humans remain? What data, permissions, observability and governance would autonomous execution require?

Only then should we decide what architecture supports that model.

That reverses the pattern of the previous five waves.

Instead of:

we can move toward:

That is the difference between AI adoption and AI nativity.

AI-native isn't about adding AI to the enterprise we already built.

It is about asking what enterprise we would build if intelligence and autonomous execution had been available from the beginning.

We have seen the other movie five times.

This is the sixth wave. It doesn't have to be the sixth repeat.