Before you draw another box-and-arrow diagram, start with a harder question: where does your data actually live — and does it need to move at all?
For most of the last two decades, the default answer has been depressingly simple: move everything into one place and call it a platform. Gather it into a central repository, a data warehouse or a modern lakehouse, and reasoning about data becomes uniform. Governance is easier to apply. Analytics teams know where to look. It is a compelling logic — and consolidation still matters for certain analytical workloads, regulatory reporting, and cost control at scale. There are good reasons centralised warehouses became the norm.
But consolidation as a universal default has always been a mental shortcut dressed up as architectural wisdom. The distinction worth making early is this: a physical platform — a warehouse, a lake, a lakehouse — is an implementation choice. A logical platform is something different: a consistent set of contracts, controls, and semantics that governs how data is created, managed, and used, regardless of where it physically lives. Most organisations have been building the former while believing they were building the latter. The history of computing has a habit of correcting that confusion, and the current moment is doing so more forcefully than any previous wave.
When Gravity First Shifted
The first serious challenge came with IoT at scale — sensors, devices, and connected machinery proliferating across industries from around 2015 onwards. When you attach sensors to machinery, vehicles, buildings, or production lines, you quickly encounter a hard constraint: physics does not negotiate. Sending every event to a distant cloud region adds latency that makes real-time control unsafe or uneconomic. Bandwidth becomes a cost problem when thousands of devices generate continuous measurement streams. AI inference needs to happen close to where conditions are changing, not hundreds of milliseconds away.
Edge computing emerged because centralising data from a sensor network was often technically impossible, economically absurd, or both. The data had to be processed where it originated. The intelligence had to live near the thing being measured.
Central systems did not become irrelevant. A cloud-to-edge continuum emerged precisely because neither extreme sufficed — edge nodes carry real constraints, and complex analytical workloads still benefit from shared infrastructure. The lesson was subtler than “centralisation is dead.” It was that data gravity had spread. Intelligence had to exist at multiple points simultaneously, connected not by co-location but by shared contracts, controls, and semantics.
The Proliferation of Gravity Wells
A parallel dynamic unfolded in enterprise software. Large operational systems — in manufacturing, finance, healthcare, or logistics — increasingly arrived with their own data capabilities embedded. Modern ERP systems, CRM platforms, and industrial control environments are no longer passive record-keepers waiting for a nightly extraction job. They manage, expose, and often analyse their own data natively.
Faced with this reality, many organisations defaulted to what felt like good architecture: extract everything into the central platform. But when every operational system exposes its own analytics and APIs, nightly ETL pipelines start to look like architectural taxidermy — the act of making dead, moved data look as though it is still alive and operational. They are complex to maintain, latency-ridden, and out of date precisely when it matters most.
Centralisation is frequently sold as a cost-saving measure — consolidate storage, reduce duplication, simplify tooling. But it is technical debt at a competitive interest rate: you trade the ability to act in real time for a tidier infrastructure budget, and the interest compounds every time a decision waits on a pipeline.
The smarter question is not “how do we consolidate all data?” but “how do we align usage, contracts, controls, and semantics across the environments that already exist?” Central stores will remain the right home for some workloads — cross-system analysis, historical retention, batch processing — but they should be the deliberate end of a contract-driven design, not the default beginning.
The Third Wave: Intelligence at the Point of Action
AI agents are not analytical tools that sit at the end of a pipeline, waiting to be queried. They are operational actors — systems that observe conditions, reason about context, and take action within the workflows they inhabit. A procurement agent does not just report on supplier performance; it participates in supplier selection. A manufacturing agent does not just visualise machine health; it adjusts operational parameters. A customer service agent does not just surface historical case data; it shapes the conversation in real time.
Routing every agent decision back through a central warehouse makes your AI slow and brittle. Agents wait on batch-oriented infrastructure, operate on stale data, and fail whenever a pipeline does. An agent's decision has to be ready before the next event in the workflow — not after the next pipeline run.
An agent forced to reason on data that travelled through a thirty-minute ETL pipeline is not reasoning about the present — it is hallucinating based on the past.
There is a line from a practitioner, now over a decade old, that has only sharpened with time: up-to-date means before the next click. That bar has not lowered — it has become existential. If an AI agent has to wait for a ticket to be approved to access a database, you do not have an AI strategy — you have a digital paperweight. The business cannot be held back by the slowest data feed.
The uncomfortable corollary is worth naming: putting intelligence closer to the point of action also amplifies the impact of mistakes. A misconfigured agent or a poorly designed local data contract can mis-price, mis-route, or mis-treat customers at scale before anyone notices. This is why contracts, controls, and semantics must be embedded at the origin rather than applied downstream. Real-time monitoring and unified audit are not optional features in this world. They are the governance model.
The Platform as Principle, Not Place
The data platform was always a logical construction masquerading as a physical one. The warehouse, the lake, the lakehouse — these are implementation choices appropriate to certain contexts. They are not the definition of a platform.
A true platform is a consistent set of capabilities — store, compute, observe, govern — tied together by shared contracts, controls, and semantics, regardless of where data physically resides. Its primary value is not the technology underneath but the insulation it provides: domain teams should be able to work with data without knowing or caring whether the underlying infrastructure has changed, just as a city’s residents use electricity without knowing which power plant is running.
Think of it the way a city’s water infrastructure works. The water from your tap may originate from multiple sources, be treated in different facilities, and travel through different pipe networks. What makes it a unified system is not physical co-location but common standards: quality, pressure, safety, and the interfaces through which it is delivered. You do not need to own the reservoir to rely on the water.
Edge nodes, operational system environments, central repositories, and AI agent contexts can all participate in the same platform — not because they share infrastructure, but because they share what makes data trustworthy and interoperable wherever it lives. As SaaS vendors, edge providers, and AI tooling vendors continue shipping their own data layers, trying to collapse everything into one physical platform starts to look less like strategy and more like denial.
What This Demands Organisationally
The doctrine of the Single Source of Truth was a comforting simplification. What it actually described was a Multiple Source of Reality: data originating in many places, each source authoritative in its own operational context, connected by shared contracts. Those contracts mean three things: knowing what the data is and where it came from, trusting its schema and source, and knowing who is entitled to see it.
It is worth being precise about what shared semantics means here — it does not mean every domain must speak the same language. It means every domain must speak a translatable one. The platform is not the dictionary; it is the translation layer that lets manufacturing and finance maintain their own operational dialects while still being able to talk to each other.
This also reframes the governance argument entirely. Physical centralisation feels like a safeguard, but it is often a governance risk in disguise. When data is moved, it loses its original context — lineage, operational state, the conditions under which it was created. By the time it reaches the warehouse, it is a reconstructed version of the truth rather than the truth itself. The platform’s job is to export policy to the data, not import the data to the policy.
This means rethinking how teams are structured: distributing a central team into smaller versions of itself recreates the same bottlenecks at smaller scale. Real ownership means teams aligned to specific business outcomes, responsible for the full lifecycle of the data products they produce, empowered to move at the speed their business area requires.
This is not a licence for fragmentation. Naive federation — dozens of systems with incompatible schemas, ad-hoc permissions, and no shared contracts — is just centralisation's evil twin: slower, harder to govern, and even more fragile. Paradoxically, it often creates more coordination overhead than centralisation, with tight coupling but none of the clarity a central team once imposed. Teams end up in the data equivalent of synchronised swimming — unable to move independently despite having nominally distributed the work.
And there is a subtler danger: the smarter each domain becomes at optimising locally, the deeper the organisation's collective blindness grows.
Principled distribution is not a discount on governance; it is a premium on engineering. The central team’s job is no longer to be the bottleneck for data movement — it is to build the paved road of automated policy that local teams must drive on. The internal boundaries between domains need to be genuinely permeable: not just technically connected, but semantically transparent, so insights can flow without requiring an integration project each time someone asks a cross-functional question.
There is a predictable counter-pressure worth naming. Executives and regulators tend to prefer clear lines of accountability and visible system boundaries — often in the form of a single source-of-truth platform that can be audited and blamed. That preference will drive organisations to re-centralise in the name of control even when doing so quietly undermines speed and resilience. The uncomfortable truth is that in a distributed world, the only real control you have is the quality of your standards and enforcement — not the number of petabytes you have managed to herd into one region.
The Shape of What’s Coming
The next few years of AI deployment will be a real-time exam in architectural honesty. Agents embedded across operational systems will expose every hidden dependency on manual ETL, every brittle central pipeline, every missing contract. Diagram-driven architectures — the ones that look clean on slides but fall apart under live load — will be exposed first. The organisations that win will not be those with the biggest warehouse, but those where every system — from edge devices to operational platforms to agent runtimes — honours the same contracts at every boundary and can translate across domain boundaries without losing meaning
This is ultimately a mental model shift as much as an architectural one. The LegacyCo instinct is to control data by owning where it lives — to manage the estate. The emerging model is to govern data by enforcing how it behaves — to set the code of conduct and trust the network to follow it. That transition is harder than any technology choice, because it requires leaders to find confidence in standards they cannot see rather than infrastructure they can point to.
The question is no longer where the data lives. The question is whether the contracts that make data trustworthy are present wherever the data originates and wherever decisions are made.
The platform follows that principle. It always has. The only question is whether your architecture — and your org chart — are willing to admit it.
This essay reflects a point of view at a moment in time — shaped by observation, conversation, and the questions practitioners keep asking. The thinking will develop as AI reshapes the constraints and organisations push back with what they are actually experiencing.
If something here resonates — or something is missing — that friction is where the thinking develops.