System of Record

For each business entity — customer, product, order, employee, price — exactly one system should be authoritative. Everything else holds a copy derived from it, and knows that it holds a copy.

When this is unclear, several systems each believe they are authoritative for the same entity. They diverge, reconciliation becomes permanent work, and the question "what is this customer's actual address" has no answer — only several candidate answers with no basis for choosing between them.

Why it is the dominant enterprise problem

Integration effort in large estates is overwhelmingly spent reconciling copies of the same entity rather than moving data. The same customer is modelled differently in each application, and the differences are not merely structural — one system's "active" is not another's.

No integration pattern fixes this. Point-to-point, hub-based and event-driven architectures all move data faithfully between systems that disagree about what is true.

Implementation patterns

• Ownership declared per entity, published, and enforced — one system may write, everyone else reads.
• A published contract rather than table access. Consumers depend on an interface or an event stream the owner maintains, so the owner can change internals without breaking anyone. Direct table access makes the schema a public API nobody agreed to publish.
• Change events published by the owner, so copies stay current without polling and without the owner knowing its consumers.
• Copies marked as copies, with their freshness visible, so a consumer can reason about staleness rather than assuming currency.
• Reconciliation with alerting, because in any asynchronous copy arrangement drift is a certainty and the only question is whether you detect it or a customer does.
• Classification and residency attached at the source, propagating through derived datasets — the prerequisite for every privacy and regulatory answer.

Industry example

An enterprise architecture practice strong in technology and weak in data architecture will produce good designs and an estate whose complexity grows anyway, because the entity ownership question is never settled. The symptom is that every new integration project begins by discovering which of four systems holds the current customer record, and the answer differs by field.

The rebalancing that pays is to establish ownership per entity before anything else — it is the foundation that makes capability consolidation, regulatory answers and integration simplification possible, and none of them is achievable while it is unresolved.

The same problem appears within a single product at scale, where several services each maintain their own copy of a shared concept because no service was designated the owner, and the reconciliation logic quietly becomes the most complex code in the system.

Failure scenarios

• Ownership assumed but never declared, so each team believes a different system is authoritative.
• Multiple writers to one entity, which is the same defect at data scale as shared mutable state is in code.
• Consumers reading base tables, making the schema an unpublished public API that can never be changed.
• A master data programme with no ownership decision, which builds reconciliation infrastructure instead of removing the need for it.
• Ownership assigned to a system that cannot serve the load, so consumers cache and diverge anyway.

Trade-offs

Establishing a system of record constrains teams that currently write freely, and the designated owner inherits an availability obligation to everyone who now depends on it — which may require investment before it can carry that role.

There is also a legitimate exception: some entities genuinely have different authoritative sources in different contexts — a customer's marketing profile and their billing record may reasonably be owned separately. The discipline is to make that split explicit at the field level rather than to leave ownership ambiguous.

Interview question

"Four systems hold a customer address and they disagree. Walk me through how you would resolve it — and tell me what you would change so it does not recur with the next entity."