The persistent belief that strategic clarity emerges from centralising everything often manifests as the Enterprise Data Warehouse: a single, lowest-grain repository intended to serve all needs, the Single Source Of Truth.
The enterprise data warehouse is rarely born of bad thinking. It usually begins with a sincere and reasonable aspiration: to create a single, trusted view of the organisation; to drive definitive, empirical reports and to support decisions that can be made with confidence rather than intuition. A place where cross system semantic and representational differences and are resolved by approved transformations. In complex businesses, data is fragmented across systems built at different times, for different purposes, using different definitions. The warehouse promises to bring order to this fragmentation — to reduce duplication, reconcile inconsistencies, and make information broadly accessible without requiring every question to become a bespoke IT project. For executives under pressure to justify decisions, manage risk, and demonstrate control, the idea of a shared, neutral foundation of facts is deeply appealing. The warehouse offers the hope that, once the data is finally “in one place,” the organisation can move faster, argue less, and govern more effectively.
Why it fails:
- Cross-domain semantics – An enterprise model that can hold all domains creates semantics that are, at least in part, familiar to everyone, but truly understood only by the data team. Well-understood domain language acquires new, expanded meanings that obscure original intent
- Loss of integrity control – Conformance is either lossy (discarding nuance) or “gainy” (introducing inferred meaning that never existed), in this it takes integrity control away from the business
- The BI trap – “Business users” interrogating lowest-grain data amplifies misinterpretation while governance shifts to after-the-fact damage control
- No well defined purpose – Warehouse projects and programs are high on aspiration, but rarely have well defined exact purpose (in violation of Principle #4)
- Escalating Maintenance Costs – Without clear and documented purpose, and with users from all across the enterprise ensuring full backwards compatibility for every change, or running full impact analysis and business change programmes for impacted users and connected systems becomes increasingly expensive
The warehouse promises to create a context-free semantic layer over all data in pursuit of a Single Source of Truth. In reality there is no such thing, there are only Context-Appropriate Adequate Sources of Adequate Values.
Once this is accepted, things don’t actually look so bad for the warehouse, and several useful opportunities present themselves.
- Warehouse As Architecture
Using consistent processes and technology to deliver context-driven enterprise data still offers economies and efficiencies and simplifies governance and talent management. The same technology used for modern warehouses / data-lakes can support Context-Appropriate Sources too - Separated Context Sources
Separating and segregating the warehouse contexts enables federated delivery, ownership and accountability - Strong Definition Of Purpose
Each separated Context-Appropriate Source can have a strongly defined purpose, e.g. a source to supply quoted, bound and unused capacity for reserving, or source to supply financial expectations and bank reconciliations to support AR/AP processes. - Improved Prioritisation and Resource Scaling
With clearly defined purpose, business aligned and driven prioritisation becomes possible, and with segregated delivery using common processes and technology, scaling out without bottle-necks or conflict becomes significantly easier
For instance: instead of one enterprise-wide “Customer” entity trying to serve billing, marketing, underwriting, and claims simultaneously, you might have:
– A Customer-for-Underwriting source (risk assessment context)
– A Customer-for-Billing source (payment and collection context)
– A Customer-for-Marketing source (segmentation and campaign context)
Each purpose-built, each sourced from the core Customer domain, by now enriched and owned by the domain that uses it, fit for that purpose, each governable within its context, with accountability lineage.
These Context-Appropriate Sources are a form of Data Product – purpose-built, domain-owned, and fit for their specific use. This isn’t abandoning the warehouse. It’s acknowledging that a single semantic layer cannot serve all contexts equally well – and building accordingly. The fallacy isn’t centralisation. It’s believing that one model can be simultaneously appropriate for everyone.
This is Transformation Architecture in practice: designing how data flows through governance and accountability structures, not just where it’s stored.