Stop exporting everything to CSV: question what you actually need
“Single source of truth” is one of those phrases that everyone agrees with and almost nobody implements. The agreement is easy. The implementation is a series of small, boring choices that the team has to make and then defend, every time someone suggests an exception.
The phrase, stripped of buzzword, just means this: for every fact your organisation cares about, exactly one system is responsible for storing it. Everything else displays a copy. The copy is read-only. If you want to change the fact, you change it where it lives. The displays update.
That is the whole idea. The hard part is doing it.
The failure mode
A property team we worked with stored the same tenant’s address in five places: the CRM, the lettings spreadsheet, the rent ledger, the contractor portal export, and an old Word-document template that nobody had retired. When the tenant moved, the address got updated in two of the five within a week. The other three drifted, quietly, for months.
Eventually someone noticed that a gas-safety reminder had been posted to the wrong flat. The investigation took an afternoon. The fix — updating the four places that were wrong — took ten minutes. The cause — not having decided which system was the home of the address — was never fixed, and it happened again the following spring with a different tenant.
This is the failure mode. Not the dramatic data loss. The quiet drift, between systems that all agreed they were the “source of truth” until somebody checked.
What “ownership” actually means
For a fact to have a home, three things have to be true about that home:
- It is the only place the fact can be edited. Other systems can read; they cannot write.
- Its version is the one that wins on a disagreement. No appeals. If the home says the tenant moved out on 14 March, the tenant moved out on 14 March. The spreadsheet on Susan’s laptop is incorrect by definition.
- Updates from the home propagate, automatically. Not “Susan emails everyone the new value on Friday”. The other systems pull from, or are pushed by, the home.
If you cannot say which system owns a given fact, you do not have a single source of truth for that fact — you have several sources of approximately-truth, with a person doing the reconciliation.
The ownership map
The single most useful artefact for a team that is serious about this is a one-page document listing the facts the organisation cares about and which system owns each. It is unglamorous and it changes everything.
An example, from a diocesan operations team:
| Fact | Owned by | Read by |
|---|---|---|
| Parish boundary | DMS | Maps, finance, website |
| Clergy contact details | DMS | Mailchimp, website, payroll |
| Property compliance dates | Property platform | DMS dashboards, board reports |
| DBS expiry | Safeguarding system | DMS, line manager dashboards |
| Bank balances | Accounting system | Board pack, finance dashboard |
Two things to notice. First, the home is not always the prettiest system or the one most people log into. The accounting system owns the bank balance, even if everyone reads it via the finance dashboard. Second, the “read by” column is the bit that prevents drift — every reader is an automatic copy, never a manual one.
The conversation this forces
The first time a team draws up this map, the argument is healthy. Two systems both claim to own the clergy address. One thinks it is the safeguarding system; the other thinks it is the DMS. The conversation that resolves it — which workflow actually changes the address, where is it most often correct, who is responsible if it is wrong — is the conversation that should have happened years before, and never did.
Without the map, the question never gets asked, because nobody can see the conflict. Each system feels self-consistent on its own.
The hard cases
Three patterns make this harder than it sounds.
The fact that nobody wants to own
“Project status” is a famous example. The project manager thinks the PM tool owns it. The finance team thinks the cost report owns it. The board thinks the slide deck owns it. None of them want the responsibility of keeping the status current.
The fix is to assign it anyway, name a person, and write the rule. “Project status is owned by the project tracker. The PM updates it weekly. Everyone else reads it.” The discomfort of assigning ownership is the point.
The fact that lives in two places for a good reason
Sometimes the duplication is structural. A finance system has its own customer record because that record carries VAT status; a CRM has its own customer record because that record carries sales-stage information. Both are correct.
The trick here is to identify the shared fields (name, address, account ID) and own those in one place, while letting each system own its system-specific fields locally. The ownership map shows shared fields as owned by one home, with the others marked “reads”.
The fact whose home is offline
Sometimes the system that should own a fact is a piece of legacy software that you can’t integrate with. The fact has to be re-keyed manually somewhere. This is a known weakness, not a permanent state. The ownership map should mark it explicitly: “Owned by legacy X, copied manually weekly into Y until Z is decommissioned.”
Writing the weakness down keeps it visible. Hidden manual steps are the ones that fail silently.
What changes when this is in place
The tangible difference is small and constant. Reports stop disagreeing with each other. Tenant addresses do not drift. The audit trail of who changed what, when, becomes meaningful because there is only one place to audit. New systems join the picture by saying which facts they read and which they own — not by silently creating their own parallel copies.
The intangible difference is bigger. The team stops apologising for the data. Nobody says “well, that number is from the spreadsheet, the system has a different number” in a board meeting. Decisions get made on numbers that are stable.
The work to get there is mostly conversation, not engineering. The technology to do it well has existed for thirty years. The decision to be disciplined about ownership is the part that organisations either make or don’t.
If you would like a hand drawing up the ownership map for your own systems, we are happy to spend a morning on it. It is the cheapest, highest-leverage piece of operational work most teams have not yet done.