"Single source of truth" is a marketing phrase that has done more damage to mid-market data infrastructure than any other concept in the past decade. The premise is that one system should hold the authoritative version of every data element. The problem is that no real business operates this way — and forcing the architecture to mirror the marketing causes more breakage than it prevents.
Two reasons "single source of truth" fails as an architecture.
Reason one — different systems are authoritative for different elements. The CRM is authoritative for opportunity stage. The ERP is authoritative for invoice amount. The eCommerce platform is authoritative for cart abandonment. Forcing one system to "own" all of these means either replicating data from the actual source (introducing latency and divergence) or denying that the authoritative source is the operational system the team actually uses.
Reason two — the architecture that emerges from trying to build one master system collapses under its own integration weight. Every other system has to feed into the master. The master has to deduplicate, reconcile, and version. The team building the master spends two to three years and produces a system that lags reality by hours or days — which is exactly the problem the original architecture was supposed to solve.
The pattern that actually scales is domain-owned data products with documented contracts between them. Finance owns the financial data product, served from the ERP with a documented schema and refresh cadence. Sales owns the pipeline data product. Operations owns the operational metrics data product. Each domain product exposes a well-defined interface to other domains; consumers query the interface, not the underlying system.
This is a lighter-weight version of the data mesh pattern that emerged in enterprise data engineering. For mid-market, the full mesh is overkill — but the underlying principle (domain ownership, contracts between products) is the right architecture.
Across the data integration engagements I have led, the systems that produced reliable executive reporting were the ones organized around domain data products, not the ones chasing a single master. The single-master attempts all hit the same wall in year two: the integration debt accumulated faster than the reconciliation work could resolve.
If your team is building toward "one system that holds all the data," the architecture is going to disappoint at exactly the moment the business needs to trust it.
Filed under
