25 Years Technology Paradigm Shifts | Enterprise Architect Learns

Every generation of technologists inherits a set of assumptions about how systems are built, how they behave, and what they are for. And every generation, without exception, has had those assumptions overturned.

The pace at which that happens has never been constant. But the direction has never reversed.

The mainframe era defined computing as centralised, monolithic, institutional. The system was immovable. You went to it. Architecture meant understanding a single, enormous, deeply interconnected platform — and the people who mastered it built careers on that mastery alone.

Then the web changed the model entirely. Three-tier architectures separated concerns for the first time — front end, middleware, back end. The computer came to the user. Systems became layered, and architecture became about designing the interfaces between those layers as much as the layers themselves.

Service-Oriented Architecture followed. Enterprises drowning in point-to-point integrations reached for a new model — reusable services, connected through an Enterprise Service Bus. SOA promised agility and delivered, in many cases, a different kind of complexity. But it left behind something important — the idea that architecture should be organised around business capabilities, not technical systems.

Mobile shifted the centre of gravity again. The interface moved into people’s pockets. Always on, always connected, always personal. Architecture had to follow the user wherever they went — which meant rethinking everything from session management to data synchronisation to the very definition of what an application was.

The digital and API economy dissolved the walls between organisations — and in many ways was a direct response to the weight and rigidity of what SOA had become. APIs replaced ESBs. Lightweight connectivity replaced centralised brokering. Systems stopped exchanging data through overnight batch files and started talking to each other in real time. Integration became a product. The boundary between institutions became permeable — and architecture had to account for ecosystems, not just systems.

Cloud made infrastructure disappear. Or more precisely, it made infrastructure someone else’s problem and turned it into software. And then containerisation changed the definition of a deployable application entirely — from a monolith, to a service, to a container that could run anywhere, scale independently, and fail without taking everything else down with it. The constraint shifted from what hardware you could afford to how well you had designed for change.

Data stopped being the byproduct of digital and became the point of it. The exhaust of every transaction, every interaction, every system event accumulated into something with its own architectural demands. How information flows, how it is governed, how it is made useful — these became first-class architectural concerns in their own right.

And now, AI.

Not a new tool to be added to the existing stack. Not another layer in the architecture. A fundamental shift in what systems can do, how decisions get made, and — for the first time — a genuine question about what the humans who design these systems are actually for.

Each of the shifts above changed the technology. AI has the potential to change the architect.

I have spent twenty-five years inside this progression. Not as an observer. As a practitioner navigating each shift as it arrived — sometimes ahead of it, sometimes inside it, rarely behind it.

Good fortune played some part. The variety of experience I accumulated was not the result of a master plan. It was the result of being in the right place at the right inflection point, more than once, and saying yes to what was in front of me.

My career started on the mainframe. A large-scale digital transformation project in the early 2000s — the kind that was building out three-tier architectures for the first time, separating front end, middleware, and back end. My world was the back end. The mainframe. I understood it deeply and nothing else.

What came next wasn’t a conscious pivot. It was proximity. The next role brought me into contact with Ab Initio — data integration on the mainframe. Then Informatica. Then data warehousing. The work kept evolving and I kept moving with it. Not because I had a plan, but because each new thing was an extension of the last.

The move toward architecture came gradually. Transformation strategies. Roadmaps. Exposure to MuleSoft and the world of API-led connectivity — process APIs, system APIs, the idea that integration could be a product rather than a problem. By this point the work had shifted from building systems to designing how systems talked to each other. The architect role was forming around me before I had fully named it.

Then two things happened simultaneously — and the collision of them produced the most concentrated period of learning and growth in my career. A conference introduced me to Domain-Driven Design. AWS was growing in prominence in the organisations I was working with. Cloud and DDD arrived together, and the combination demanded fluency in both simultaneously. There was no gradual ramp. The learning was compressed, intensive, and — looking back — the most formative period of the career.

What followed was a period of application and consolidation. Cloud migrations. Leading a platform architecture team. Managing the operational reality of the patterns I had spent years designing. And then, in recent years, a return to the domain-driven and event-driven work that has become the mainstay of my practice — including the organisational and foundational challenges of EDA that I wrote about in Edition 4 of this newsletter.

The practitioners who navigated each paradigm shift well weren’t necessarily the most technically gifted. They weren’t always the most experienced. What they shared was a consistent relationship with change itself — curiosity over comfort, engagement over defence, and an open mind focused on the work and what it required. Not always a conscious choice to move toward something new. More often simply a refusal to let what they already knew get in the way of what needed doing.

The practitioners who struggled shared a different pattern. They had mastered something real. A paradigm, a platform, a way of working that had taken years to understand deeply. And when the industry moved, they stayed inside what they knew. Not out of arrogance. Not out of laziness. But because deep mastery creates its own gravity. The longer you have operated at the centre of one way of thinking, the easier it is to stay there — through comfort, through inertia, or simply through not noticing that the ground has shifted until the gap has already opened.

My own journey reflects neither a strategy nor a struggle. When I moved to my first new role, the organisation was running Ab Initio on the mainframe. That proximity led me to embrace it alongside what I already knew. When more data integration programmes followed, the work pulled me further — into Informatica, into data warehousing, each step a natural extension of the last rather than a deliberate departure from it.

Operating in CTO space eventually put me in a position where I had to solve for a platform strategy. Looking for a solution led me to Domain-Driven Design and cloud — not as paradigms to master for their own sake, but as tools that answered a problem I was already holding. An open mind and a problem-solving focus did the rest.

And now we arrive at the shift that is different from all the others.

Every paradigm I have described gave practitioners time. Time to observe, to experiment, to accumulate exposure gradually before the shift became the mainstream. The mainframe experts had years before three-tier arrived. The SOA generation had a decade before APIs displaced the ESB. Even cloud, which felt fast at the time, allowed for a gradual ramp — early adopters, then fast followers, then the majority.

AI is not giving anyone that time.

For the first time in the history of this industry, every practitioner — experienced and inexperienced, senior and junior, specialist and generalist — is arriving at the same inflection point simultaneously. Nobody has accumulated years of quiet exposure. Nobody has the advantage of having been proximate to this before it became mainstream. The paradigm is arriving faster than the ramp that has always preceded it.

That leaves all of us — regardless of experience — standing in the same place. Uncertain. And uncertain in a way that no amount of prior experience in this industry has quite prepared anyone for.

The question is whether that uncertainty is something to embrace or something to fear.

That question does not have a clean answer. Not yet.

What is clear is that AI is not simply the next item on the list of paradigm shifts I have described. Each of the previous shifts changed how we built systems. AI has the potential to change who builds them and what building even means.

Every paradigm shift in this progression introduced more layers into the architecture — solving for different problems, introducing a few of their own. And now we have AI, which can solve a few problems for us, and which can also create a few problems for us. Just like every paradigm that came before it, the application and adoption of AI is uncertain at the start.

AI will be no different in that respect.

What is different is the pace. And what is also different is that AI sits inside the work the architect has always done. Those who approach it the way they have approached every shift before — with an open mind, focused on the work, looking to solve problems rather than preserve what they already know — will find their footing. As I explored in Edition 2 of this newsletter, those who learn to augment their architectural judgment with AI will outperform those who don’t — not because AI is better at architecture, but because the combination of human judgment and machine acceleration creates leverage that pure human effort can’t match.

We are still evolving. And this time, we are all evolving together