Businesses often talk about creating a “single source of truth” as though that means putting everything into one database. In practice, most operating environments need several systems. Finance, CRM, service, commerce and HR platforms may each be legitimate owners of different parts of the same business entity.
The architectural problem starts when ownership is implicit. One application changes a customer address, another changes it back during a sync, a spreadsheet contains a third version, and reporting teams spend time deciding which record to believe.
IBM's guidance on master data management describes the purpose of MDM as creating consistent enterprise master data across applications while reducing fragmentation, duplication and inaccuracies. The point is not necessarily one physical database; it is governed ownership, reconciliation and stewardship.
A system of record is an ownership decision before it is a technology decision.
Choose authority at field level when necessary
“The CRM is the system of record for customers” can still be too vague. The CRM may own contact details and sales status while the finance platform owns credit status, invoicing identifiers and tax information. A support platform may own service entitlements. The useful design question is: which system has the right to create or change this attribute?
For each important data domain, define the authoritative source, which systems may update it, which systems may only consume it, and what happens when records conflict.
Use four tests
- Process proximity: where is the fact created or verified as part of real work?
- Control strength: which system has the strongest validation, permissions and auditability for that fact?
- Lifecycle ownership: which team is accountable for keeping it correct over time?
- Integration practicality: can downstream systems consume the authoritative value reliably without creating circular updates?
The most familiar interface is not automatically the right master. Neither is the newest system. Authority should follow the business process that legitimately creates and governs the information.
Avoid bidirectional ambiguity
Bidirectional integration can be useful, but it also increases the need for explicit ownership. Microsoft's current Dataverse integration guidance describes tightly coupled bidirectional patterns between business applications. Technically, both sides may be able to write. Architecturally, that does not remove the need to define which changes are valid, how mappings behave and how conflicts are handled.
Without those rules, integration can distribute inconsistency faster. A synchronisation job that works perfectly can still be wrong if it copies an unauthoritative value into every connected system.
Separate system of record from reporting layer
The place where management consumes data does not have to be the place where operational data is mastered. A warehouse or analytics layer may combine information from many sources for reporting while the underlying operational systems retain authoritative ownership of their domains.
This distinction matters because trying to turn a dashboard or data lake into an operational master without appropriate controls can create another shadow system. Reporting should know where each metric comes from and which source owns the underlying facts.
What better looks like
A mature data architecture has a short, explicit answer for each critical data domain: who owns it, where it is mastered, which systems can change it, how it is distributed, how duplicates are resolved, and who investigates exceptions. Those answers are documented alongside integration mappings rather than living in one engineer's memory.
If teams regularly ask which customer record, product code or revenue number is “the real one”, the organisation has already reached the point where system-of-record decisions need to be formalised.