How to Build a Single Source of Truth Without Building an Empire

"Single source of truth" is a phrase that has been used to justify some very expensive projects. It gets interpreted as one system holding all our data, which leads to consolidation programmes that run for years, cost a great deal and frequently end with a new system alongside the old ones rather than instead of them.

The useful version is narrower and much more achievable: for each important fact, one place is authoritative, and everyone knows which place that is.

That reframing changes the work from a migration project into a series of decisions.

Authority, not location

Copies are not the problem. Data is copied constantly and legitimately — into reports, caches, integrations, exports. The problem is ambiguity about which copy wins when two disagree.

So instead of asking "where should all our data live?", ask a list of much smaller questions:

• Which system is authoritative for a customer's contact details?
• For the price agreed on a specific job?
• For whether an invoice has been paid?
• For a job's current status?
• For what stock we hold?
• For an employee's current role and rate?

Each has one right answer, and writing them down takes an afternoon. Most of the confusion in a business dissolves the moment these are settled and published, before any technical work occurs at all.

Rules that make it hold

One writer per fact. The authoritative system is the only place a fact is edited. Everywhere else, it is read-only and clearly marked as a copy. When someone needs to change an address, there should be exactly one place they can do it.

Copies flow one way. Data moves from the authoritative system outward. Two-way sync between systems that can both edit the same field is where most integration disasters begin — conflicting edits have no correct resolution, and the systems will silently pick one.

Copies are visibly dated. A number displayed in a secondary system should indicate when it was refreshed. Undated copies are trusted as if they were live, and eventually one of them will be a day old at an important moment.

The authoritative system is the convenient one. If the official place is slower or harder to reach than the alternative, people will use the alternative and the authority is theoretical. This is worth real investment — reducing the friction of the correct path does more than any policy.

Identity is shared. Every system referring to the same customer should be able to agree which customer it is. A common identifier — even one written into a reference field — is what makes the whole arrangement work. Without it, reconciliation is by name, and names are not unique or stable.

Doing it incrementally

1. List the facts that matter. Twenty or thirty, not thousands. The ones that cause problems when they are wrong.

2. For each, name the current authority. Sometimes the answer is genuinely "nowhere" or "two places". Those are your problems, and the list is now a work queue ordered by pain.

3. Publish the list. A single page, accessible, kept current. This costs almost nothing and delivers a surprising share of the benefit.

4. Fix the worst ambiguity first. Usually customer contact details or job status. Pick one, make one system authoritative, make the others read from it, and remove the ability to edit elsewhere.

5. Deal with the shadow copies. For each unofficial spreadsheet, either it becomes a read-only view of the authoritative system, or the authoritative system gains the field that made the spreadsheet necessary. Both are small pieces of work; neither is a programme.

6. Repeat for the next fact. Each cycle is weeks, not quarters, and each delivers value on its own.

What to avoid

Choosing a system because of its category. The authoritative source for job status is whichever system the people doing the jobs actually use, not the one labelled "system of record" on an architecture diagram. Authority follows behaviour; if you assign it against behaviour, the assignment loses.

Building a central store nobody writes to directly. A warehouse that aggregates from several systems is useful for reporting and is not a source of truth. It is a copy of copies. Do not let a reporting layer be mistaken for authority.

Trying to include everything. Some information genuinely lives in email and always will. Decide which facts matter enough to have an authority and accept that the rest is unmanaged. A short list that is real beats a long one that is aspirational.

Solving it with a policy document. Data governance policies that describe desired behaviour without changing what the software permits do not survive a busy month. Where possible, make the wrong path impossible rather than discouraged.

Doing it as one project. The failure mode of large consolidations is that they take long enough for the business to change underneath them, and during the transition there are two systems of record — which is worse than where you started.

The businesses that get this right rarely have fewer systems than everyone else. They have the same number of systems and no ambiguity about which one is right, which turns out to be the part that actually mattered.