From the data warehouse wars of the nineties to the generative AI gold rush today — the pattern repeats. Technology promises transformation, executive FOMO follows, expensive programmes launch, and too many fail to deliver.
Here’s what the organisations that do succeed have in common.
1. They Treat Data as a Product, Not a Byproduct
Unsuccessful organisations treat data like industrial exhaust: a messy, accidental consequence of running operational applications. They build massive data lakes (which quickly become data swamps) and task an overworked, centralised data team with “cleaning it up.”
The winners flip this script entirely. They apply product thinking to their data assets.
Just like a commercial software product, a data product must have:
- A dedicated owner: Someone accountable for its quality, lifecycle, and value.
- An explicit target audience: Clear downstream users (analysts, data scientists, or LLM applications) whose specific problems the data solves.
- Guaranteed Quality (SLAs/SLOs): Contracts that guarantee data freshness, accuracy, and completeness.
When you treat data as a product, you stop funding aimless infrastructure projects (“Let’s migrate everything to the cloud!”) and start funding specific, high-value data assets that directly power business outcomes.
2. They Decentralise Ownership (But Centralise Standards)
The 1990s gave us the dream of the all-encompassing monolithic Data Warehouse. The 2010s promised that a centralised Data Lakehouse would solve everything. Both architectures failed for the same reason: scalability. A single central data team cannot possibly understand the business context of every department across a global enterprise. They become a chronic bottleneck.
Successful organisations embrace architectural patterns like Data Mesh. They shift data ownership to the domain teams—the people closest to the source who actually understand what the numbers mean. The marketing team owns marketing data; the finance team owns finance data.
However, they don’t allow this to devolve into fragmented silos. They provide a centralised, self-service platform that enforces federated governance. The central team builds the “highways” (infrastructure, identity management, compliance protocols), but the business domains build and drive the “cars” (the data products).
3. They Solve for Interoperability with Data Contracts
FOMO-driven organisations throw money at the newest AI models while their foundational plumbing is held together by digital duct tape. They change a column name in an upstream production database, and instantly break twenty downstream dashboards and three machine learning models.
The organisations that survive technological shifts build resiliency via Data Contracts.
A data contract is a formal, machine-readable agreement between a data provider and data consumers. It defines the schema, expected data quality thresholds, and service-level agreements. By shifting governance “left” into the software development lifecycle, any change that breaks the contract is caught before it ever hits production. This creates the stable, trusted foundation required to feed automated systems and LLMs without fear of silent data corruption.
4. They Prioritise “Time to Value” Over “Time to Architecture”
When a new technology wave hits, the instinct of many enterprise architects is to spend eighteen months designing the perfect, flawless future-state blueprint. By the time the blueprint is approved, the technology landscape has shifted, the budget is depleted, and the business stakeholders have lost patience.
Winners focus ruthlessly on the Minimum Viable Product (MVP). They pick a single, high-impact use case—such as automating a specific customer service workflow or optimising a high-churn marketing segment—and build the vertical slice of infrastructure needed to solve just that problem.
They prove value in weeks, win executive trust, and use the momentum (and revenue) to incrementally scale their infrastructure. They build their architecture iteratively, funded by realised value, rather than speculative up-front investment.
The Bottom Line
Whether you are deploying a Teradata server in 1996, a Hadoop cluster in 2012, or fine-tuning a LLM today, the technology is rarely the reason a programme fails.
Success doesn’t belong to the company with the biggest tech budget or the loudest AI hype. It belongs to the organisations that do the hard, unsexy work of establishing clear ownership, treating data as a first-class product, and designing their architectures around human accountability and business value. Everything else is just expensive noise.