Thin clients became Chromebooks. Service-oriented architecture became microservices. The data warehouse became the data mesh. Mainframe centralisation became cloud centralisation. Every decade or so, the technology industry rediscovers a set of architectural trade-offs that were understood — and largely resolved, for that generation — by the practitioners who came before. New terminology is adopted. Vendor ecosystems form around the new framing. And the cycle begins again.
After fifty years, the pattern is not frustrating so much as clarifying. It suggests something important about the nature of the problems we are actually solving.
The Cycles Are Real
The pendulum between centralisation and distribution has swung, in enterprise technology, at roughly fifteen-year intervals across my working life. Centralised mainframe computing was challenged by client-server distribution in the eighties and nineties. Client-server was challenged by the web, then by service-oriented distribution. Now cloud centralisation — the concentration of computing into large shared infrastructure — is being challenged by edge computing and data sovereignty requirements that push processing back toward the source. The underlying tension between centralisation's efficiency and distribution's resilience and control has not changed. The technological context in which it plays out has.
A colleague who had joined the industry relatively recently described data mesh to me as a fundamentally new way of thinking about data architecture — domain ownership, distributed data products, federated governance. He was right about its novelty in one sense: the specific implementation patterns are new. But the underlying architectural debate — centralised data platform versus distributed domain ownership — is one I first had a meaningful version of in the mid-1990s. The answer was different then because the available technology was different. The question was the same.
The ideas do not come back because the industry failed to solve them. They come back because the technological context changes — new tools, new scale, new constraints — and the answer that was correct before is no longer correct now. The question, though, is often the same question.
What Changes and What Does Not
What changes, consistently, is the tooling and the scale. Each wave of new technology makes certain approaches more feasible, certain trade-offs more or less favourable, certain constraints more or less binding. Microservices are not the same as SOA: the container ecosystem, the CI/CD toolchain, and the operational monitoring capabilities that exist now were not available in the early 2000s, and they change the calculus of distributed service architecture substantially.
What does not change are the underlying tensions. Centralisation versus distribution. Flexibility versus consistency. Build versus buy. Make it work fast versus make it work well. These tensions were present at the beginning of my career. They will be present at the beginning of the next generation's career. They will be present at the beginning of the generation after that. The specific resolution — the right balance in a given context, with a given set of tools, for a given set of requirements — changes. The underlying tension does not.
What This Should Change About How We Work
The practical implication is that historical context — understanding what was tried before, what the conditions were that made it succeed or fail, what the specific resolution was at the time and why — is more valuable than the industry typically treats it. The tendency to treat each new architectural wave as a completely fresh start, without reference to what came before, is part of why the cycles feel surprising each time they arrive.
The practitioners who navigate these cycles best are not those who are most aggressively current. They are those who understand what is genuinely new — what the changed tooling actually makes possible — while also recognising what is the same problem wearing new clothes. That combination produces better architectural judgment than either pure novelty-seeking or pure historical conservatism.
The industry's relationship with its own history is, to put it charitably, imperfect. New ideas are presented as having no predecessors. Old solutions are dismissed as irrelevant by people who have not studied why they failed. Both habits are expensive.
After fifty years, the most useful single piece of advice I can offer to someone early in a technology career is this: learn the history. Not to be conservative — to be accurate. The problems you will spend your career solving have been approximately solved before. Understanding those solutions, and why they were later found insufficient, is the most efficient path to a sound opinion about what comes next.