The Myth of a Single System of Record in Modern Enterprises

Modern enterprises do not need every fact in one platform. They need governed authority, shared meaning and traceable context across many systems.

Emergent Africa Executive Perspective | September 2026

Every large data programme eventually seems to make the same promise: a single source of truth.

It is one of the most reassuring phrases in enterprise technology—and one of the most misleading.

The phrase suggests that if an organisation can move enough data into one enterprise resource planning system, data warehouse, lakehouse or cloud platform, disagreement will disappear. Customer, supplier, product, asset, employee and financial information will become consistent. Reports will reconcile. Decisions will accelerate. Artificial intelligence will finally have the clean foundation it needs.

But a modern enterprise does not have one kind of truth.

It has operational truth: what transaction occurred, where and when. It has mastered truth: which customer, supplier, product or asset the transaction relates to. It has analytical truth: how performance should be measured over time. It has contextual truth: why a decision was made, which exception was approved and what changed afterwards.

These truths have different owners, time horizons, controls and uses. Trying to force all of them into one physical system can replace fragmentation with a different problem: a central bottleneck that is expensive to change, strips away context and is never as complete as its sponsors expect.

The goal should not be one system containing everything. It should be one governed, explainable answer for each material business question.

That is a very different ambition.

The enterprise is becoming more distributed, not less

The idea of a single enterprise-wide system of record was more plausible when the technology estate was smaller and the operating model more stable. Today, even a moderately complex organisation may rely on an ERP platform, customer relationship management system, human-capital platform, procurement suite, operational technology, e-commerce channels, industry applications, partner platforms, spreadsheets, documents and multiple analytics environments.

Acquisitions add more systems. Divestments require separation. Cloud software allows functions to adopt capabilities quickly. Regional operations face different commercial and regulatory requirements. Connected assets create streaming data. Generative and agentic AI increasingly depend on unstructured information—policies, contracts, emails, maintenance notes, presentations and expert judgement—that traditional systems of record were never designed to capture.

The result is not merely technical clutter. It is an enterprise-management problem.

IBM’s 2025 study of 2,000 CEOs found that 68% regarded an integrated enterprise-wide data architecture as critical to cross-functional collaboration, while 50% said rapid investment had left their organisations with disconnected, piecemeal technology. Only 25% of AI initiatives had delivered expected returns and just 16% had scaled across the enterprise.[1]

Accenture’s 2026 research across 2,000 companies found a similar disconnect. Although 64% of respondents said their businesses had moved beyond isolated AI pilots, only 7% had achieved the data readiness required to scale advanced AI. Seventy-two per cent did not have trusted, suitably governed data of the required quality, and only 6% had a unified logical data view across systems and ecosystems.[2]

PwC’s 2026 Global CEO Survey reinforces the value at stake. Only 12% of CEOs reported that AI had delivered both cost and revenue benefits, while 56% reported no significant financial benefit. Organisations with strong AI foundations—including technology environments that support enterprise-wide integration—were three times more likely to report meaningful financial returns.[3]

McKinsey’s 2026 global AI survey found that 37% of respondents attributed at least some EBIT impact to AI, but only 6% met its definition of an AI high performer. Those leaders were distinguished not only by technology adoption, but by workflow redesign, leadership commitment and operational discipline.[8]

The answer, however, is not necessarily more physical consolidation. As Accenture puts it: “It is more pragmatic to aim for a single logical view of data that remains federated.”[2]

That sentence captures the shift executives need to make.

The important distinction: one truth is not the same as one database

A customer illustrates the problem.

The CRM system may contain the commercial relationship and sales pipeline. The billing platform holds the contractual account. The service platform records interactions and complaints. The e-commerce platform identifies users and behaviour. Finance sees a debtor and payment history. Compliance may need verified legal identities, consent and risk classifications. A loyalty programme may organise people into households. None of these views is necessarily wrong. Each reflects a legitimate business context.

The enterprise still needs to know that these records relate to the same customer. It may also need an agreed name, identity number, address, segment or group relationship. But that does not mean every operational attribute should be copied into one application and managed there.

The same applies to products, suppliers, employees and assets. A product can simultaneously be a commercial offer, a manufactured item, a stock-keeping unit, a regulated specification and a component in a maintenance hierarchy. A supplier can be a legal entity, payment beneficiary, operational site, risk exposure and member of a broader corporate group.

The useful executive question is therefore not: “Where is the single source of truth?”

It is: “Which source is authoritative for this fact, for this purpose, at this point in time?”

That question separates five capabilities that are often blurred together:

Microsoft describes master data management as creating deduplicated master records—a golden standard against which important assets can be checked. Its current architecture guidance envisages MDM solutions connecting to source systems, unifying and standardising relevant data, and publishing “golden records that represent the authoritative version of master data assets.”[4]

That is not a claim that the MDM platform must replace every source application. It is a way of creating enterprise identity and control across them.

Why monolithic truth programmes disappoint

1. They begin with technology rather than decisions

Many programmes start by selecting a platform and asking how much data can be moved into it. The better starting point is to identify the decisions being weakened by inconsistent information.

Which customers are genuinely profitable? How much are we spending with a supplier group across all subsidiaries? Which assets create the greatest operational risk? Can finance reconcile revenue, margin and cash to the same product and customer hierarchies? Can sustainability measures be traced to reliable operational evidence? Can an AI agent determine which policy, price or approval rule applies?

Without a decision and value case, consolidation becomes an infrastructure programme with an expanding scope and an uncertain finish line.

2. They confuse standardisation with sameness

An enterprise needs common definitions where comparability matters. It does not need every domain to model all information in exactly the same way.

Finance may require a controlled legal-entity and account hierarchy. Sales may require a relationship view. Operations may need plant, site and equipment structures. Risk may group the same entities by exposure.

Standardising identifiers, critical attributes and exchange rules creates interoperability. Imposing one universal model can destroy useful distinctions.

3. They move accountability away from the source

Data defects usually originate in business processes: an incomplete supplier onboarding, an inconsistent product code, a free-text customer field, a poorly maintained asset hierarchy or an unrecorded exception.

A central data team can detect and sometimes repair the symptom. It cannot sustainably own the business meaning or correct the process that keeps recreating the defect.

That is why modern data operating models place accountability with the domains closest to the data, supported by enterprise standards and shared platforms.

McKinsey describes centralised, hybrid and decentralised data-architecture archetypes and notes that a hybrid model can combine central master data management with federated domain storage.[5] Deloitte similarly argues for breaking the data monolith into smaller, reusable data products with defined owners, consumers and quality standards.[6]

The original data-mesh model brings these ideas together through domain ownership, data as a product, self-service infrastructure and federated computational governance.[9]

4. They underestimate time and lineage

Two systems can both be correct and still show different numbers because they represent different times, cut-off rules or states of approval.

An operational dashboard may show today’s position. Finance may show the position at month-end after accruals and eliminations. A regulatory report may use a prescribed boundary and restated history. A machine-learning model may use features calculated from an earlier snapshot.

Trust requires more than a reconciled total. It requires lineage: where the data originated, how it changed, which rules were applied, when it was refreshed and who approved an exception.

5. They ignore the context AI needs

Systems of record are good at capturing the what: customers, transactions, products, assets and process states. They are far weaker at retaining the why and the how.

Advanced AI needs both.

An agent may know that a credit limit was changed, but not why an exception was granted. It may retrieve a maintenance instruction but miss the field experience that determines when it should not be followed literally. It may see a supplier’s legal name but not the commercial relationship across subsidiaries.

Accenture argues that AI-ready data needs semantic meaning, entity relationships, unstructured knowledge and real-time context—not structured records alone.[2]

This is why a credible AI foundation includes catalogues, glossaries, lineage, knowledge graphs, policies, documents and human oversight alongside operational databases.

What modern enterprises need instead

The alternative to a monolith is not an uncontrolled collection of silos. It is a governed federation.

Six design choices matter.

1. Define authority at data-element and domain level

Create an authority map for the critical facts in each domain. It should specify the business owner, system of entry, authoritative source, permitted consumers, update rules, quality threshold and required history.

“The ERP owns supplier data” is usually too broad.

The legal name may come from verified onboarding, payment details from a controlled finance process, performance measures from procurement and risk classifications from compliance. Authority needs to be precise enough to resolve disagreement.

2. Master the identities that connect the enterprise

Master data management should establish persistent enterprise identifiers and reliable golden records for the entities that recur across systems: customers, suppliers, products, employees, assets, locations and legal entities.

This requires matching, deduplication, hierarchy management, survivorship rules and stewardship. It should also preserve source references and legitimate local attributes.

The golden record is a governed bridge across systems, not a licence to erase context.

3. Create a shared language

An executive team cannot operate from common facts if revenue, customer, product, supplier, margin or active employee mean different things in different reports.

A business glossary and semantic layer should define critical concepts, calculations, hierarchies and relationships.

Technology can distribute and enforce these definitions, but executives must resolve the business trade-offs. The definition of a strategic customer or profitable product is not merely a technical decision.

4. Treat important data as a product

A data product has an owner, known consumers, documented meaning, quality measures, access controls and service expectations. It is designed to be reused, not recreated for each report or project.

This creates a practical balance between domain ownership and enterprise consistency.

Domains remain accountable for the data they understand. The enterprise provides common standards, platforms and controls so that products can interoperate.

5. Make lineage, quality and policy visible

Trust cannot depend on personal knowledge held by a few analysts. Critical data should carry evidence of origin, transformation, freshness, quality and permitted use.

For executive decisions, this may be expressed simply:

• Is the measure certified?
• How current is it?
• Which domain owns it?
• What is the confidence level?
• What changed since the previous period?

For AI, the same controls must increasingly operate at machine speed.

BCG argues that metadata and lineage are logical starting points because they improve discoverability, quality management and regulatory control while enabling further AI capabilities.[7]

6. Govern data as an operating discipline

Data governance often fails when it becomes a committee outside the flow of work. The effective model combines central standards with domain accountability:

• The executive team prioritises the decisions and value pools that require trusted data.
• A central data function establishes policies, architecture, shared tooling and enterprise measures.
• Domain owners are accountable for meaning, quality and remediation at source.
• Stewards manage exceptions, hierarchies and unresolved matches.
• Technology teams automate controls, lineage and distribution.
• Risk, privacy and security functions define guardrails proportionate to use.

This is an operating model, not a once-off clean-up.

The South African executive agenda

For South African groups, the issue is especially practical.

Many operate across multiple legal entities, regions, currencies, channels and regulatory environments. They have accumulated systems through growth and acquisition, while constrained capital requires technology investment to show measurable value quickly.

Centralising every record before improving any decision is rarely affordable—or necessary.

A better approach is to begin with a small number of enterprise outcomes where fragmented data is already creating cost, risk or delay. Examples include:

• a trusted customer view that improves cross-sell, service and credit decisions;
• a supplier view that exposes group-wide spend, concentration, duplication and risk;
• a product and material hierarchy that connects revenue, margin, inventory and procurement;
• an asset view that links maintenance, reliability, capital expenditure and operational risk;
• a legal-entity and chart-of-accounts spine that accelerates close and management reporting;
• an auditable sustainability-data chain from operational evidence to external disclosure; and
• an AI use case whose value is currently constrained by identity, quality, access or context.

The programme should then improve the minimum set of data, controls and processes required to unlock that outcome.

This creates evidence, builds stewardship capability and avoids waiting years for an idealised future state.

A 90-day starting point

The executive team can establish momentum in one quarter.

1. Select one material decision journey. Choose a decision with visible economic or risk consequences and a senior owner.
2. Trace the data backwards. Identify the reports, models, data products, transformations, source systems and manual interventions on which the decision depends.
3. Expose disagreement. Document where definitions, identities, values, timing or ownership diverge—and quantify the consequences.
4. Establish authority. Agree the authoritative source and owner for each critical data element, including the rules for exceptions and history.
5. Build the minimum viable trusted view. Apply matching, master data, shared definitions, quality rules and lineage only to the scope required for the chosen outcome.
6. Measure value and reuse. Track decision speed, reconciliation effort, leakage, risk, forecast accuracy or another business measure. Then determine which components can be reused in the next domain.

The purpose of the first 90 days is not to complete enterprise data transformation. It is to prove that governed data can change a consequential business outcome—and establish the pattern for scaling.

Eight questions for the next C-suite discussion

• Which five decisions lose the most value because executives do not trust or cannot reconcile the underlying data?
• For each critical customer, supplier, product, asset and financial attribute, is the authoritative source explicit?
• Where are business units maintaining rival versions of the same master data or metric?
• Which data defects are repeatedly repaired downstream instead of prevented in the originating process?
• Can the organisation trace a board, regulatory or AI-generated conclusion back to source evidence and transformation rules?
• Does each priority data domain have an accountable business owner with the authority and capacity to improve it?
• Are technology investments building reusable data capabilities or creating another isolated store?
• What valuable decision could be improved within 90 days without waiting for a multi-year platform replacement?

Replace the slogan with a stronger objective

The single-system ambition persists because it expresses a legitimate executive need.

Leaders want numbers that reconcile, accountability that is clear, information that can be trusted and decisions that do not stall in arguments about whose spreadsheet is correct.

Those outcomes are essential. The architecture implied by the slogan is not.

A modern enterprise can have many operational systems and still have disciplined truth. It can distribute data ownership without surrendering standards. It can preserve local context while maintaining enterprise identities. It can allow multiple views while making every material figure traceable to an authoritative source.

The shift is from one place for all data to one accountable truth for each important decision.

That is a more realistic architecture, a stronger governance model and a far better foundation for AI.

About Emergent Africa

Emergent Africa helps leadership teams strengthen the connective tissue between strategy, data and execution.

Through Master Data Management as a Service and related governance, analytics and transformation capabilities, we help organisations establish trusted enterprise identities, clarify ownership, improve data quality and connect information to measurable business outcomes.

The objective is not another technology layer. It is reliable data for faster decisions, scalable AI and stronger execution.

Research sources and interpretation note

The research cited in this article uses different populations, definitions and time periods. The statistics should be read as complementary indicators of the enterprise data and AI challenge, not combined into a single benchmark.

1. IBM Institute for Business Value, 2025 CEO Study: CEOs Double Down on AI While Navigating Enterprise Hurdles—survey of 2,000 CEOs in 33 countries and 24 industries.
2. Accenture, AI-ready data: New rules of data for the advanced AI era—2026 research including a survey of executives at 2,000 companies in 15 countries and nine industries.
3. PwC, 29th Global CEO Survey—survey of 4,454 CEOs in 95 countries and territories.
4. Microsoft Learn, Master data management in Microsoft Purview.
5. McKinsey & Company, Revisiting data architecture for next-generation data products.
6. Deloitte, Treating data as a product in the era of GenAI.
7. Boston Consulting Group, The Future of Data Management with AI.
8. McKinsey & Company, The state of AI in 2026: On the road to ROI—global survey of 1,719 participants in 97 countries.
9. Zhamak Dehghani, Data Mesh Principles and Logical Architecture.