Why Single Source of Truth Fails — And What Fixes It

Sixty percent of enterprise AI projects are still stuck at proof-of-concept stage. When asked why, fifty-eight percent of data leaders point to the same root cause: data quality and access (Databricks, State of Data + AI 2024). Behind that statistic sits a more uncomfortable one — the one that shows up in nearly every management meeting in a mid-to-large enterprise. The finance team has a number. Supply chain has a different number. Marketing has a third. Each is technically correct. None of them agree.

The “Single Source of Truth” That Was Supposed to Be the Last One

Walk into a Monday morning revenue review at most established companies and the first ten minutes are a reconciliation exercise. Finance opens with the closing number from the ERP. Commercial pulls a different figure from the CRM. Supply chain reports shipped revenue from the order management system. Marketing has yet another version, sourced from the campaign attribution stack. Each team is looking at a real number. None of the numbers describe the same thing.

This is not a story about bad data. It is a story about a company that has built a single source of truth — and then built another, and another. Data warehouses were supposed to end this. Then enterprise data hubs were supposed to end this. Then customer data platforms. Then lakehouses. Each layer arrived as the final answer. Each became another silo with a different definition of customer, product, or transaction.

A multi-business retail group we have worked alongside spent eleven years and three platform migrations chasing one definition of “active customer.” Each project produced a working warehouse. None of them removed the older warehouses, because too many critical reports were already wired to them. By the third migration, the company was paying to maintain four overlapping platforms — each with a defensible claim to be the source of truth, none of them actually trusted.

This is the pattern that a unified data fabric is supposed to break. But before we get to the fix, the diagnosis has to be precise — because most data fabric projects fail for the same reason warehouse projects fail.

Why the Warehouse Approach Keeps Failing

The standard architecture answer: build a central data warehouse, force everyone to feed it, force everyone to consume from it. Make it the law.

The reason this fails is structural, not technical. Data is created where the work is done. The point-of-sale system creates transaction data. The campaign platform creates engagement data. The supply chain system creates inventory data. Each of those systems is owned by a domain team that understands the meaning of its own data better than any central team can. Centralising the storage of that data does not centralise the meaning. The central warehouse becomes a translation layer that loses fidelity at every step.

Zhamak Dehghani’s Data Mesh (O’Reilly) named this directly: centralised data teams become the bottleneck for every domain that wants to move. Gartner now estimates that by 2025, 25% of large organisations will have adopted data mesh principles — up from less than 5% in 2021 (Gartner, 2024). Data mesh inverts the model: data is treated as a product, owned by the domain that creates it, with federated governance for interoperability.

But the pendulum swing has its own failure mode. Pure decentralisation without a connective layer just produces the same fragmentation faster. Every domain has its own definition of customer. Every product line maintains its own master data. The reconciliation exercise on Monday morning gets longer, not shorter.

The companies that resolve this do not pick a side. They build a fabric.

Data Fabric Is a Connection Layer, Not a Storage Layer

The single most expensive misunderstanding in this category is treating “data fabric” as a synonym for “next-generation data warehouse.” It is not. A data fabric is the governance and metadata layer that connects the data products that already exist — wherever they exist — with consistent definitions, lineage, access policies, and AI-ready semantics.

In practical terms, a unified data fabric does four things at once:

1. Defines the entities once. Customer, product, transaction, store — defined at the business level, mastered once, referenced everywhere. This is where master data management stops being an IT initiative and becomes a business discipline.
2. Catalogues the data products that exist. Not by copying them. By describing them — owner, schema, freshness, quality, allowed use cases. Tools like Databricks Unity Catalog have made this layer enterprise-grade; Databricks’ own analysis shows organisations running unified data and AI platforms deploy AI to production three times faster than those using separated warehouse and ML infrastructure.
3. Federates governance. One policy framework — access, retention, privacy, lineage — applied consistently across data products owned by different domains. Domain teams keep ownership. Compliance gets one auditable surface instead of seven.
4. Makes the layer AI-ready. RAG-based agents grounded in governed enterprise data reduce hallucination rates by up to 40% versus foundation models without retrieval (Databricks Mosaic AI, 2024). The fabric is what makes that grounding possible at the enterprise security boundary.

The fabric is not where the data lives. It is what makes the data legible across the company.

Warehouse, Mesh, Fabric — Three Things That Are Not the Same

Three terms get used interchangeably in architecture decks and almost never describe the same object in the room they were drawn for.

The three are not competitors. A mature enterprise architecture tends to use all three: a fabric for the cross-business definitions, governance, and AI grounding; a mesh model for who owns what data product; warehouses or lakehouses where high-volume analytics actually run. The mistake we see most often is choosing one and expecting it to absorb the work of the other two.

What “Unified” Actually Looks Like in Practice

The shift from theory to practice is where most enterprise architecture diagrams stop being useful. Three concrete patterns describe what a working data fabric does for a business.

Demand planning across multiple data sources. A top-five global CPG company built a demand-sensing capability on top of historical POS data, external weather feeds, promotional calendars, and supply chain master data — each held in its own system, each governed through one fabric layer. Result: finished goods inventory reduced by €200M while service levels stayed above 98% (BCG, AI in Consumer Goods 2023/2024). The data was never centralised. The definitions and access were.

Financial reporting in a multi-business group. A holding company with five operating businesses spent years trying to consolidate financials by forcing each business onto one ERP. The project never completed. After switching strategy to a fabric approach, each business kept its own financial system and the fabric layer enforced one definition of revenue, one chart-of-accounts mapping, and one set of consolidation rules. Monday morning reconciliation went from ninety minutes of debate to a five-minute exception review.

Customer 360 without the rebuild. A retail bank attempted three customer data platform projects over six years. Each one stalled because business units refused to migrate live customer journeys. The fourth attempt did not migrate anything. It exposed customer entities through a fabric, with each domain — cards, loans, deposits, marketing — registering its data product into a shared catalog. Within nine months, the marketing team was running personalisation campaigns that pulled from real-time card transactions without owning, copying, or moving the data.

These three cases share one feature. None of them solved the problem by building one more warehouse.

How to Start

If your organisation is on the third or fourth attempt at a single source of truth, the next attempt is unlikely to succeed by being bigger. It needs to be different.

Three practical first steps before any platform decision:

1. Pick three cross-functional decisions and trace the data lineage backward. Pick decisions that matter to the P&L this quarter — pricing, promotion, replenishment, churn. Map every system the data passes through. The map will tell you whether your problem is storage, definitions, or governance. In most cases, it is the second and third.
2. Define entity ownership before infrastructure. Who is the business owner of “customer”? Of “product”? Of “transaction”? Not the IT owner — the person whose decision degrades if that entity is wrong. Until those names are written down, no fabric will hold.
3. Choose connection over consolidation as the default. Every time someone proposes copying data into a new central store, ask whether the same outcome can be achieved by exposing the data product where it already lives, governed through the fabric. Default to connection. Reserve consolidation for the cases where the math actually requires it.

The companies that move past the perpetual reconciliation exercise share one realisation: the truth was never going to live in one place. The job is not to build the final warehouse. It is to build the layer that makes truth consistent across the warehouses, lakehouses, applications, and AI systems that already exist — and the ones that will be added next year.

A useful diagnostic to leave the management meeting with: if a new data source were added to the business this quarter, how many weeks before any decision actually changed? If the answer is “more than four,” the problem is not the data. The problem is the fabric.