DATA & ANALYTICS | POINT OF VIEW
For two decades, building the platform first was the right call. AI moved where the hard part lives, and the old order no longer makes sense.
Most enterprise data modernization is built in the wrong order. And hardly anyone stops to question it.
Here is how it usually goes. A program is funded, and a roadmap is drawn up carefully, layer by layer: land the sources, stand up the lake, build the pipelines, model the warehouse, wire in the governance, and then, at the very end, deliver something the business can actually use. Everyone signs off. And then everyone waits.
The wait runs 12 to 18 months. For most of it, the business is looking at infrastructure, not outcomes. The dashboards that were promised, the forecasts, the unified customer view, the thing that started the whole conversation—all of it sits at the far end of the plan, behind a foundation that has to be finished first.
I have spent enough years inside these programs to say it plainly. The engineering is rarely the problem. The order is.
The same pattern, every time
The teams running these programs are good. The engineering is sound. The problem is structural, and it shows up the same way in e
nterprise after enterprise.
The entire estate is scoped on day one, which is exactly the day you know the least. Requirements are guessed at when uncertainty is highest, and those early guesses get carried for the life of the program. Cost starts accruing from the first week, while value waits until the last. And because 18 months is a long time, the business moves underneath you: priorities shift, a reorg lands, the market changes, and the thing you set out to build in month one is not quite the thing anyone needs by the time it ships.
Platform first means value last. That is the design, even when no one says it out loud.
Why did the industry build it this way?
It would be easy to blame this on poor planning. I don’t think that is fair, and it misses the more interesting point.
For most of the last two decades, the foundation genuinely was the hard part. Standing up ingestion, storage, compute, and governance took real, specialized effort. Getting data modeled and trustworthy was slow work. In that world, building the platform first and layering outcomes on top was a rational sequence. You built the hard thing once, and everything downstream got easier. The order made sense because it matched where the difficulty actually lived.
So this is not a story about people doing it wrong. It is a story about the difficulty of moving, and the sequence not moving with it.
What changed: the distance collapsed
Two things happened at once, and together they broke the old logic.
First, data product thinking matured. Instead of treating modernization as one monolithic build, we began treating each business outcome as a discrete product: owned by someone, bound by a contract, shipped with an SLA, and put into production on its own. A customer view is a product. Trusted financials are a product. Each one operates independently, rather than waiting for the entire estate to be completed.
Second, and this represents a significant shift, AI has collapsed the entire build process. The work that used to define the timeline, generating pipelines, drafting the physical model, building the semantic layer, and converting legacy code, is precisely the work that now compresses the most. And there is good evidence for where the time actually goes. According to recent MIT research, roughly 80% of the pilot-to-production effort spent is on integration, not the model itself. That aspect of the process has always taken the longest time. That is the part AI now accelerates most.
Put those two together, and the conclusion is hard to avoid: you no longer have to finish the platform to deliver an outcome. The distance between raw data and a working result—the distance that once justified the entire program timeline—has collapsed.
This is why the old order now runs backward. It optimizes for a bottleneck that has largely moved.
Ship the outcome, let the foundation follow
So flip the sequence.
Instead of building the full foundation and hoping value shows up at the end, put a working outcome in the hands of the business first, in weeks, and let the foundation accrue beneath it. Scope is bounded to one product, not the whole estate, so you are making small, reversible decisions instead of betting the program on day-one guesses. The architecture expands only where adoption proves it belongs. Value begins at the first release and compounds from there, with each product helping to fund the next.
The part people miss is that the foundation still gets built. Governance, quality, lineage, a proper platform underneath—none of it is skipped. It simply accrues beneath outcomes that are already in production, instead of standing as a gate in front of them. You get the same rigor. You just stop waiting a year and a half to see any of it pay off.
This is what I mean by one foundation, every outcome. One trusted, governed foundation, built progressively, carrying every outcome the business needs, with the outcomes arriving first and the foundation deepening under them over time.
What a data product actually looks like
The product-first argument only holds if what you deliver in weeks is genuinely production-grade, not just a prototype. So, it’s important to be specific about what a data product is and how it is built.
Every data product follows the same logical spine. Raw data lands from sources through batch pipelines, streaming ingestion, or API feeds. A data contract validation step acts as the quality gate before anything moves further. Inside the product area, data flows through storage and distributed computing into a curated gold zone, which becomes the trusted, modeled core asset. From there, a semantic and knowledge layer adds consistent business definitions, an ontology, and a knowledge graph that grounds AI in your actual entities and relationships. This approach makes every product AI-ready by design, not by retrofit. Output ports then serve that governed data to any consumer: SQL endpoints, REST or GraphQL APIs, event streams, and an MCP server for agents. The same product that feeds a BI dashboard is the one an AI agent queries at runtime.
Cross-cutting governance, including data catalog and discoverability, data quality and observability, and identity and access, applies across every part of the pipeline, not bolted on at the end. This is what it means to build governance into, rather than onto, the product.
Fast is not the same as reckless
There is an obvious objection here, and it deserves a direct answer. If AI is generating pipelines and models and the timeline is measured in weeks, where is the control?
The honest version of this model is human-led and AI-accelerated, in that order. AI contributes to every phase, but people govern every decision. The architecture, domain definitions, metric logic, reconciliation, and final sign-off before any production data flows all remain with accountable individuals. AI drafts and executes; humans decide and approve.
That is the lifecycle view. The same principle becomes even clearer when you specify who owns what. AI handles the mechanical and repeatable work. People retain the decisions that require judgment and risk.
That distinction becomes even more important as the speed goes up. Speed without governance leads to more frequent mistakes, and nobody wants a wrong answer delivered quickly. This approach works not because AI is left to run on its own, but because AI removes the manual grind while people keep their hands firmly on the decisions that carry risk.
What this means if you are planning modernization
If you are about to fund a data program, the practical shift is straightforward.
Stop buying an 18-month platform build based on the promise of value at the end. Instead, ask a different question: what ships in the first few weeks? Request to see a working product, not a thicker roadmap. The thickness of the plan was never the point. What lands in production is.
And keep it engine-agnostic. A good outcome should never be hostage to a single platform bet. The same open foundation should carry Snowflake, Databricks, or Fabric, so the choice of engine serves the outcome rather than the other way around. When the foundation is open, you are free to pick the right tool for each job instead of forcing every job through the tool you happened to start with.
The order is the advantage
I have come to believe that the winners in the AI era will not be the organizations with the biggest platforms or the longest roadmaps. Instead, success will belong to those who put trusted data into the hands of the business the fastest, continuously building on that foundation.
The technology to achieve this already exists, and data product thinking is now mature. The only thing left to change is the order in which we work. For a long time, starting with the foundation was the right approach, but that’s no longer the case. Lead with the desired outcome, and let the foundation follow.
One Foundation. Every Outcome. In that order.
