Master Data Management

Executive summary

Most large organizations hold the same customer, product or supplier in many systems, each with its own identifier, spelling and idea of which attributes matter. The consequences are familiar: duplicate mailings, inconsistent product descriptions across channels, regulatory reports that cannot be reconciled, and analytics teams matching entities instead of analyzing them. Master data management (MDM) is the discipline, supported by technology, that establishes a trusted, shared version of these core entities and keeps it consistent as business processes change the data.

The central design decision is the implementation style. A registry leaves data in the sources and maintains only identifiers and cross-references. Consolidation copies source data into a hub, matches and merges it, and serves the result to analytics without changing the sources. Coexistence publishes the golden record back to the sources so that operational systems converge. A centralized hub becomes the system of record where master data is authored. Each style trades intrusiveness and cost against the consistency it delivers, and most enterprises run different styles for different domains.

• Matching and survivorship rules are business decisions expressed as configuration; they need owners, thresholds, labeled test sets and staffed review queues.
• An over-merged record is a more serious defect than a duplicate: it mixes data between unrelated parties and is costly to unwind.
• Identifiers, cross-references and effective-dated hierarchies make the hub useful to operational systems and the analytics platform alike.
• A customer hub concentrates personal data; consent, data subject rights and retention must be designed into it from the start.

The paper recommends starting with one domain selected by value and feasibility, proving the operating model and integration pattern before expanding, and measuring progress with duplicate rates, steward queue age, time to onboard a source and downstream adoption. It closes with recurring pitfalls and a maturity path from fragmented records to governed, integrated master data.

Why master data management matters

Master data management exists because the same real-world entity is described differently in every system that touches it, and the business pays for the disagreement every day.

A customer opens an account in a branch, buys a product online and calls the contact center. Three systems record the person, each with its own identifier, address format and spelling of the name. None is wrong from its own point of view, yet the organization cannot say how many customers it has, what each one holds, or whether a complaint and a sales opportunity concern the same household. Products described differently in engineering, procurement and e-commerce systems, and suppliers recorded under several variants of their legal name, show the same fragmentation.

Several triggers turn this background cost into a funded program. Regulatory reporting requires exposures, holdings or sales to be aggregated per legal entity or customer, which is impossible without reliable identification across systems. Mergers and acquisitions bring overlapping customer and supplier bases that must be reconciled before synergies can be realized. Digital channels need a consistent product catalog and a recognizable customer across touchpoints. Analytics and artificial intelligence (AI) initiatives find that models trained on unmatched entities learn from duplicates and inconsistencies as if they were signal.

The value of MDM is best framed through the processes it changes rather than through generic efficiency claims. A reliable customer view shortens onboarding and removes duplicate correspondence; a consistent product master reduces order errors and speeds the introduction of new products; a consolidated supplier master exposes aggregate spend and sanctions exposure per legal entity. Each outcome can be baselined in the organization's own process metrics, which is a more credible basis for a business case than external benchmarks.

Definitions and scope

The term master data is often used loosely for any important data. A sharper definition distinguishes it from the two kinds of data it is most often confused with, reference data and transactional data, and the distinction determines how each is governed.

The golden record

A golden record is the best available representation of an entity, assembled from all the sources that know about it under agreed rules for which value wins when sources disagree. Three clarifications prevent misunderstandings. It is a managed outcome of matching and survivorship, not the discovery of a single true record that already exists. It does not replace the source records; it is linked to them through cross-references, and the sources remain the systems of record for the transactions they process. And it is only as trustworthy as the rules and stewardship behind it.

It is also useful to distinguish a system of record, where an attribute is authoritatively created and maintained, from a system of reference, which other systems consult for the agreed value. Depending on the implementation style, the hub may be the system of reference only, or the system of record for some or all master attributes. Recording this per attribute in a data ownership matrix resolves many later disputes about who may change what.

Master data domains

Master data is organized into domains, each a family of entities with a common structure, ownership and set of consuming processes. The party domain deserves attention: a party is any person or organization the enterprise deals with, and the same party may play several roles, such as customer, supplier or employee, that older systems treated as separate entity types.

Multidomain MDM manages several domains on one platform and, more importantly, the relationships between them: a customer buys a product at a location from an employee. The questions that justify MDM are frequently cross-domain, such as revenue per customer per product line, which makes relationship management a first-class requirement. Multidomain platforms share stewardship workflow and distribution across domains, but they do not remove the need to prioritize domains and implement them one at a time.

Implementation styles

The implementation style determines where the golden record lives, how data flows between the hub and the sources, how quickly a change becomes visible elsewhere, and how much the program intrudes on existing applications. Industry practice distinguishes four styles: registry, consolidation, coexistence and centralized. They are best understood as points on a spectrum of increasing consistency and intrusiveness rather than as mutually exclusive products.

Registry

A registry hub stores identifiers, a minimal set of matching attributes and cross-references to the source records. It matches records to establish which entries describe the same entity but does not build a persistent merged record; a consolidated view is assembled on request by reading the sources through the cross-reference. It is the least intrusive style. Its weaknesses are read latency, dependence on source availability, and the fact that it improves nothing in the sources. It fits where regulation or organizational boundaries prevent data movement, or as a first step to size the duplication problem.

Consolidation

In the consolidation style, source data is copied into the hub, in batch or near real time, where it is standardized, matched, merged and stored as a persistent golden record. The golden record serves downstream consumers, most often the data warehouse, reporting, analytics and marketing, while the operational sources continue unchanged. Consolidation delivers a reliable analytical view quickly and with limited organizational friction. Its limitation is that operational processes still work with inconsistent data, and steward corrections in the hub do not reach the systems where defects originate unless a separate remediation process exists.

Coexistence

Coexistence extends consolidation by publishing the golden record, or selected attributes of it, back to the sources and to other operational consumers. Master data may still be created in the sources, but the hub harmonizes it and distributes the agreed version, so that systems converge over time. This delivers operational benefits, such as a consistent customer view in the contact center, while leaving capture processes in place. It is more intrusive because sources must accept inbound updates, resolve conflicts between local edits and hub updates, and participate in change control. Clear rules on which attributes the hub may overwrite in each source are essential.

Centralized or transactional

In the centralized style, also called a transactional hub, the platform becomes the system of record where master data is authored and validated before distribution to subscribing applications. New customers or products are created in the hub, and the former sources become consumers. This gives the strongest consistency and the shortest delay between creation and availability, and it suits product information management where many products are introduced, or a newly designed onboarding process. It is also the most intrusive and expensive style: applications must be changed to call the hub, the hub becomes a critical operational dependency, and the governance of authoring must be mature before go-live.

Choosing a style

The choice is made per domain and often changes over time. Four questions drive it:

• Operational need. How much consistency do operational processes need, as opposed to analytical ones?
• Source tolerance. How much change can the source systems absorb, given their age, ownership and vendor constraints?
• Data location. Does a regulatory or contractual reason require data to remain where it is?
• Governance maturity. How mature are ownership and stewardship? The more authority the hub asserts, the more decision rights it needs behind it.

A common path is consolidation first, to establish the golden record and prove the match rules, then coexistence for the attributes where operational inconsistency hurts most, with centralized authoring reserved for domains willing to redesign the creation process.

Architecture components

Whatever the style, an MDM platform is a set of cooperating components around a hub. Understanding them individually helps in evaluating products, in deciding which capabilities can be shared with the wider data platform, and in planning the work. The figure below shows the components, and the table after it summarizes the purpose of each and the design decisions it forces.

The hub data model

The hub data model is the canonical definition of each domain: the entities, attributes, relationships and allowed values the organization agrees to share. It is deliberately narrower than the union of all source schemas; attributes that only one application uses belong in that application. Good hub models keep the source records alongside the golden record so that stewards can see what each source said, and they store provenance for every surviving value: which source it came from, when, and under which rule. Flexible attribute models suit product data, where attribution varies by category, but they must still be governed through the metadata catalog and the business glossary, so that every attribute has an agreed meaning and an owner.

Stewardship user interface

The stewardship user interface is where people make match decisions, corrections and hierarchy changes, and it is the component most often underestimated. Stewards need fast search across source and golden records, side-by-side comparison of candidates with the evidence behind the score, one-step merge and unmerge, bulk actions for systematic issues, and a view of their queue by age and priority. Task routing should follow domain ownership, and every action must be auditable with user, timestamp and reason.

Security

Master data concentrates the attributes most worth protecting: identity data, bank details, pricing and supplier terms. Security in the hub therefore operates at attribute level rather than table level, with entitlements derived from role and domain, masking or tokenization for attributes such as national identifiers, and encryption at rest and in transit. Because the hub distributes data, each subscriber receives only the attributes it is entitled to, enforced by the distribution layer rather than by the consumer, and reads as well as writes of personal data are audited.

Matching, merging and survivorship

Matching decides which records describe the same entity; survivorship decides what the entity's record should say. Both are business decisions expressed in configuration, and both need owners.

Deterministic and probabilistic matching

Deterministic matching declares two records the same when a defined set of attributes agrees exactly or after standardization: the same national identifier, the same normalized email address, or the same name, date of birth and postal code. It is transparent, fast and easy to explain, and it is the right choice wherever a reliable shared identifier exists. Its limitation is brittleness: a transposed digit or a former surname defeats it, and the rules multiply as exceptions are discovered.

Probabilistic matching, grounded in the record linkage theory of Ivan Fellegi and Alan Sunter, compares pairs of records attribute by attribute, weights each agreement or disagreement by how discriminating the attribute is, and sums the weights into a score. Disagreement on date of birth is penalized more than disagreement on a middle initial, and implementations that also weight by value frequency give agreement on a rare surname more weight than agreement on a common one. The score is compared with thresholds to decide match, non-match or review. Probabilistic matching tolerates noise and missing values and finds more true matches, at the cost of explainability and recurring tuning. Most production hubs combine the two: deterministic rules for identifiers, probabilistic scoring for the rest.

Two preparatory steps determine most of the result. Standardization brings attributes into comparable form: parsing names into components, normalizing addresses against postal references, formatting telephone numbers and dates consistently, and resolving nicknames and transliterations. Blocking restricts comparison to pairs that share a key, such as a postal code or a phonetic encoding of the surname, because comparing every record with every other is infeasible at enterprise volumes. Keys that are too narrow miss matches and keys that are too broad make the run too slow, so several overlapping blocking passes are typical.

Thresholds and the two kinds of error

A probabilistic engine yields three bands, as the figure below shows: above the upper threshold, records are merged automatically; below the lower threshold, they are kept apart; between the two, they are queued for human review. Where the thresholds sit is a business decision about the relative cost of two errors. A false positive, or over-merge, combines two different entities into one record: two customers share a statement, or a supplier payment goes to the wrong account. A false negative, or missed match, leaves a duplicate in place. In almost every domain the over-merge is more damaging and more expensive to repair, so thresholds favor precision and the review band absorbs the uncertainty.

Thresholds cannot be set by intuition. The practical method is to draw a stratified sample of candidate pairs across the score range, have stewards label them, and compute precision (the share of declared matches that are true) and recall (the share of true matches that are found) at each candidate threshold. The labeled set becomes a permanent asset: it is rerun whenever rules, standardization or the source mix change, and it grows with every disputed decision. Rules, thresholds and the labeled set are versioned together and changed under production change control, with the data owner approving any change that moves the automatic-merge threshold.

Survivorship rules

Once records are matched, survivorship determines the value of each attribute in the golden record. Rules operate at attribute level, because trust differs by attribute: the best source for a postal address is rarely the best source for an email address or a credit limit. Three criteria are combined in a documented order of precedence. Source trust ranks systems per attribute by how the value is captured and validated there; a verified billing address outranks a free-text web form entry. Recency prefers the value with the most recent update, subject to trust, since an old value from a trusted source may be stale. Completeness prefers populated, well-formed values over blanks and fragments. Multi-valued attributes such as telephone numbers are usually all kept, each with its source and type.

Survivorship must also honor steward overrides: a value a steward has verified should not be overwritten by the next batch from a less trusted source. The hub therefore records, for every golden attribute, the winning source, the selecting rule, the timestamp and any steward lock. This provenance lets a consumer ask why the golden record says what it says, and it is the evidence needed when a data subject requests a correction.

Review queues, merge and unmerge

The review queue is where the matching design meets the operating model. Tasks arrive from the review band, from consumer-reported issues and from re-match runs after rule changes. Queue design should classify tasks by domain, type and business priority, show the evidence behind each candidate, and let stewards decide, defer with a reason or escalate. Service levels are set per task type, and queue age is a leading indicator of stewardship health: a queue that grows faster than it is cleared signals thresholds set too cautiously or insufficient steward capacity, and the resolution is a governance decision rather than a tooling one.

Unmerge splits a golden record that combined two entities, restoring each source record to its own golden record and reassigning transactions, relationships and identifiers correctly. It is demanding because downstream systems may already have acted on the merged record, and because edits made after the merge must be attributed to the right entity. A hub that cannot unmerge cleanly forces stewards into a caution that makes the queue unmanageable. Unmerge events must be distributed as reliably as merge events, and consumers must be designed to handle them.

Machine-learning-assisted entity resolution

Machine learning can improve matching in several ways: learned similarity functions that handle multilingual names and messy addresses, classifiers trained on steward decisions that predict whether a candidate pair is a match, active learning that selects the most informative pairs for stewards to label, and clustering that resolves groups of records rather than pairs. Used well, these techniques raise recall without sacrificing precision and reduce the labeling effort that tuning requires. The gains are largest where data is noisy and identifiers are weak, such as consumer records from many channels or supplier names across languages.

The governance obligations grow accordingly. A learned model is a match rule whose logic is not directly readable, so the program must compensate with explanations that show which attributes drove a decision, a labeled test set run before every model change, monitoring for drift as sources and populations change, and a policy that permits automatic merges only above a confidence threshold while routing the rest to stewards. Sensitive domains such as patient or citizen records may justify a rule that no merge is automatic, with the model used only to rank candidates. Model versions, training data and evaluation results are recorded as for any production model, and uneven match quality across populations is tested rather than assumed away.

A match rule is a policy about identity. It deserves an owner, a test and a change record, whether it is written by a person or learned from data.

Identifiers, hierarchies and integration

A golden record is useful only if other systems can find it, aggregate it and keep up with its changes. Identifiers, hierarchies and integration patterns are what make the hub part of the enterprise rather than another copy of the data.

Enterprise identifiers and cross-references

The most durable product of an MDM program is often the enterprise identifier: a stable, meaningless key issued by the hub for each golden record and used by consuming systems to refer to the entity. Meaningless keys are preferred because a key that encodes country or segment breaks when the attribute changes. Identifiers are never reused after a merge or retirement, and the identifier of a record merged away continues to resolve to the survivor. External identifiers such as the Legal Entity Identifier (LEI, defined in ISO 17442) or the GS1 Global Trade Item Number (GTIN) are stored as attributes and used in matching, but not relied on as the enterprise key, because their coverage is never complete.

The cross-reference maps every source system key to its enterprise identifier, with status and effective dates. It turns the hub into an index of the enterprise: given a customer number in the billing system, a consumer can find the golden record and from it the identifiers in every other system. It records merge and split history, so that a lookup against a merged key returns the current survivor, and it supports the registry style directly. The data warehouse, integration teams and privacy processes all ask for it first, so it should be exposed as a service and as a published data set from the earliest phase.

Hierarchies and effective dating

Hierarchies express how entities aggregate: legal entities into corporate groups, customer accounts into households or key accounts, products into categories and brands, locations into regions, cost centers into organizational units. Several hierarchies of the same entities usually coexist, because finance, sales and risk legitimately aggregate differently, so the hub should support multiple named hierarchies rather than forcing agreement on one. Legal ownership hierarchies matter especially in financial services and procurement, where exposure and spend are aggregated to the ultimate parent, and they change through corporate events that must be captured with their effective dates.

Effective dating records when a value or relationship became true and when it ceased to be true, independent of when the hub learned about it. It allows reporting as-is and as-was: a sales report restated under the current territory hierarchy, and the same report as it stood at quarter end. It applies to attributes, relationships and hierarchy memberships, and it must be designed into the data model from the start, because retrofitting history onto a hub that overwrote values is rarely possible. Keeping the date on which the hub recorded each change alongside the effective dates (a bitemporal design) also shows auditors what the hub believed at any point. Future-dated changes, such as a reorganization that takes effect at the start of the next fiscal year, are a common use.

Integration with operational systems

Two integration patterns dominate, and most programs use both. Synchronous services expose the hub to applications in real time: search before create, so that a contact center agent finds an existing customer rather than creating a duplicate; validate and standardize an address at the point of entry; retrieve the golden record and its cross-references by any known key; and, in the centralized style, create or update master data through the hub. These services make the hub a runtime dependency, so availability, response time and backward-compatible interface versioning become architectural requirements, and the hub must be sized for operational query loads.

Event distribution publishes changes to golden records, cross-references and hierarchies as events on a messaging platform to which consumers subscribe. It decouples consumers from the availability of the hub, supports the coexistence style naturally and scales to many subscribers. Events must carry enough context to be processed independently, consumers must be idempotent because events may be redelivered, ordering per entity must be preserved, and merge and unmerge events must be distinct types that consumers handle explicitly. A replay capability lets a new subscriber rebuild its view from history. Batch extracts remain appropriate for initial loads, reconciliation and consumers that cannot process events.

MDM and the analytics platform

In the data warehouse and the lakehouse, master data appears as conformed dimensions: customer, product and location dimensions keyed by the enterprise identifier, with history preserved through slowly changing dimension techniques that align with the effective dating in the hub. The cross-reference allows fact tables from any source system to be joined to the conformed dimension without bespoke matching in every pipeline. In a lakehouse with curated layers, golden records and hierarchies are published as governed tables in the most trusted layer, where they also serve feature engineering.

The relationship goes wrong in two ways. Analytics teams under pressure build their own entity resolution in the pipeline, producing a second and divergent set of identifiers; the remedy is to make the cross-reference and the match services easy to consume and fast to extend to new sources. Conversely, programs sometimes try to make the warehouse serve as the hub; it can hold a consolidated view, but it lacks stewardship workflow, operational services and the ability to publish back, so it rarely gets beyond the consolidation style. The hub owns identity and the golden record; the analytics platform owns aggregation and history at scale.

Governance, stewardship and privacy

An MDM program needs specific roles and decisions from the enterprise data governance framework, and a customer hub carries privacy obligations that distinguish it from every other domain. Neither can be added after the platform is live.

Technology creates the golden record once; governance keeps it golden.

Ownership and definition authority

Each domain needs a named data owner, a senior business role accountable for the definitions, quality expectations and access rules of that domain's master data. The owner's first and hardest task is definition authority: deciding what counts as a customer, when a prospect becomes one, whether a legal entity and its branches are one supplier or several, and which attributes are mastered centrally. These decisions are recorded in the business glossary and the hub data model, and the owner arbitrates when sources or consumers disagree. Without an owner, disputes are settled by whichever team configures the hub, which is governance by accident.

Quality service levels and steward capacity

Quality expectations are expressed as measurable service levels per attribute: completeness of mandatory attributes, validity against reference data, the agreed maximum duplicate rate and the maximum age of a review task. They are measured in the hub and, where possible, at the source, because the hub can only mask source defects for so long. Steward capacity must be planned rather than assumed: the inflow of review tasks depends on source volumes, data quality and thresholds, and the clearance rate on the number and skill of stewards and the quality of the tooling. Most programs distinguish domain stewards, who own rules and difficult cases, from operational stewards in business units, who clear routine tasks within their existing role.

Exception handling

Not every conflict can be resolved by rules. Exceptions include disputes between sources about a legally significant attribute, requests to override survivorship for a particular record, and consumers that cannot accept a hierarchy change on the planned date. The program needs an exception register, an escalation path from steward to data owner to the governance council, and time limits for decisions. Recurring exceptions signal that a rule or a definition needs to change, and the council should review the register for that pattern.

Privacy implications of customer master data

A customer hub is, by design, the most complete collection of personal data in the organization, which makes it the focus of privacy obligations rather than an exception to them. Under the General Data Protection Regulation (GDPR) and comparable laws, every purpose for which the hub processes personal data needs a lawful basis, and each mastered attribute should be traceable to such a purpose; the data minimization principle argues against consolidating attributes simply because they are available. Consent and communication preferences are themselves candidates for mastering, because a preference expressed in one channel must be honored in all of them, but they must be modeled with scope, timestamp and source so that the hub can prove what was agreed.

Data subject rights become tractable with a cross-reference. A request for access, rectification or erasure under Articles 15 to 17 of the GDPR, or a comparable request under the California Consumer Privacy Act (CCPA), must be fulfilled across every system that holds the person's data, and the hub is often the only place that knows where that is. Erasure raises a design question, since the hub must forget the person while retaining enough to prevent re-creation and to honor legal retention obligations in specific systems. Suppression records that hold only the minimum needed are a common answer; the UK Information Commissioner's Office, for example, generally prefers suppression to erasure when a person objects to direct marketing, keeping only enough information to respect the objection. The scope and lawful basis of any suppression record should be agreed with the privacy function.

Retention periods for the golden record are set by the data owner with the privacy function, documented in the records of processing activities and enforced by the hub. A data protection impact assessment (DPIA) is normally appropriate before a customer hub goes live. The DPIA guidelines endorsed by the European Data Protection Board list matching or combining data sets, and processing on a large scale, among the criteria for processing likely to result in a high risk, and in most cases processing that meets two of the criteria requires an assessment.

Program approach and metrics

Prioritizing domains

Programs that start with every domain at once deliver none of them. The first domain, and the sequence after it, should be chosen by business value and feasibility. Value is assessed by the processes and decisions that depend on the domain, the cost of its current inconsistency and the regulatory exposure. Feasibility is assessed by the number and condition of the sources, the existence of usable identifiers, the willingness of source-system owners to participate, and the availability of a sponsor and stewards. The matrix below makes the trade-off visible; it does not replace judgment.

Phased rollout

A phased plan with explicit exit criteria keeps the program honest. The phases below are typical for a first domain; later domains reuse the platform and the operating model and move faster.

1. Foundation. Confirm the data owner, define the domain scope and canonical model, profile the sources, and agree initial match and survivorship rules on a labeled sample. Exit: an approved model, rule book and steward roster.
2. Consolidate. Load the priority sources, run matching, build the golden record and the cross-reference, and open the review queue. Exit: duplicate rate and precision within tolerance on the labeled set.
3. Serve analytics. Publish conformed dimensions and the cross-reference to the warehouse or lakehouse and retire local matching in at least one pipeline. Exit: a named report or model consuming the enterprise identifier.
4. Publish and converge. Distribute identifiers and selected attributes to operational systems and add search-before-create to the highest-volume capture point. Exit: agreed attributes in coexistence under change control.
5. Expand. Onboard the remaining sources, add relationships to the next domain and, where justified, move authoring into the hub for specific processes. Exit: a documented time to onboard a source.

Business case and change management

The business case should be built from the organization's own baselines rather than external claims: the number of duplicate records and the cost of the processes they disrupt, the effort spent reconciling entities for reports, the time to onboard a new product or customer, the findings of regulatory examinations, and the exposure from unrecognized relationships between counterparties. Benefits are attributed to the processes that change, with their owners, and tracked after go-live. Costs should include stewardship time and source-system remediation, which are frequently omitted and then discovered.

Change management is as much a part of the program as the platform. Source-system teams must accept inbound updates and change their creation processes; business users must learn to search before creating; stewards take on new work, often alongside existing roles; and managers must accept restated figures when duplicates are removed. Communication should explain what changes in each role's daily work, training should use the real user interface, and early releases should make the benefit visible, for example by removing a reconciliation step people dislike.

Measuring the program

Metrics serve two purposes: steering the program and demonstrating value. Each measure in the table below should have a baseline from the profiling phase and a target direction agreed with the data owner.

Cloud and SaaS considerations

Many MDM platforms are offered as cloud services, which changes several design considerations. Data residency and transfer rules apply with force to a customer hub: the regions where the service stores and processes data, and the locations from which the provider can access it for support, must match the organization's obligations, including the rules on international transfers in Articles 44 to 49 of the GDPR. Latency between a cloud hub and on-premises sources affects synchronous patterns such as search-before-create, which may require private connectivity or caching. Multi-tenant services constrain customization of the data model and the matching, which is often healthy but should be tested against the hardest domain requirements before commitment. Pricing by record volume rewards early decisions about scope, and the ability to extract golden records, cross-references, history and rule configuration in usable form should be confirmed before go-live rather than at renewal.

Pitfalls and the maturity path

The failure modes of MDM programs are remarkably consistent across industries and platforms. Most are organizational, and most are visible early to anyone who looks for them.

Avoiding these pitfalls is less a matter of insight than of structure. The pillars below summarize what a sustainable program needs, and each maps to a part of this paper.

A maturity path

Maturity in master data management is best described in stages and assessed per domain, because an organization is commonly mature in product data and immature in party data, or the reverse. The five stages below can be mapped to whichever general data management maturity model the organization uses, and they can set targets for each planning cycle.

At the fragmented stage, reconciliation is manual and repeated for every report and integration. A consolidated domain has a hub that builds a golden record for analytics, but its match rules exist without formal ownership or stewardship. The governed stage adds data owners, definitions, service levels and a staffed review queue, and the golden record becomes trusted for reporting and regulatory use. In the integrated stage, operational systems consume identifiers and attributes through services and events, and new duplicates fall because capture processes search before they create. The optimized stage manages source quality at the root, maintains cross-domain relationships, and improves matching continuously under measured governance.

Conclusion

Master data management gives the organization one answer to the question of who and what it deals with, and keeps that answer current as the business changes. The implementation style sets the architecture, the matching and survivorship rules set the quality, and the operating model determines whether either survives contact with daily operations. Practitioners who choose a style per domain, govern matching as the policy decision it is, treat identifiers and cross-references as products, design privacy in from the start, and fund stewardship and source remediation will find that the hub becomes the system of reference the rest of the enterprise builds on.

For a program that is starting out, five first moves follow from the argument of this paper:

1. Choose the first domain with the value and feasibility matrix, and confirm its data owner and definition authority before selecting a platform.
2. Decide the implementation style for that domain and record, per attribute, whether the hub will be the system of record or the system of reference.
3. Build a labeled sample of candidate pairs, and agree match thresholds and survivorship rules with the owner before loading production data.
4. Put steward capacity and source-system remediation into the plan and the budget from the start.
5. Agree the adoption measures, such as downstream systems using the enterprise identifier, that will show the hub is changing how the business works.

Glossary

Blocking

Restricting record comparison to pairs that share a key, such as a postal code or a phonetic encoding of the surname, so that matching is feasible at scale.

Conformed dimension

A dimension table in the analytics platform that is shared across fact tables and keyed by the enterprise identifier.

Cross-reference

The mapping between each source system key and the enterprise identifier of the golden record, including merge and split history.

Deterministic matching

Matching that declares records the same when defined attributes agree exactly or after standardization.

Effective dating

Recording the period during which a value or relationship was true, independent of when it was recorded in the system.

Enterprise identifier

A stable, meaningless key issued by the hub for each golden record and used by consuming systems to refer to the entity.

Entity resolution

The process of determining which records, within or across systems, refer to the same real-world entity.

Golden record

The best available representation of an entity, assembled from all contributing sources under agreed matching and survivorship rules.

Implementation style

The architectural pattern of an MDM solution (registry, consolidation, coexistence or centralized), defined by where the golden record lives and how data flows.

Master data

Data describing the core business entities, such as customers, products, suppliers and locations, that recur across processes and systems.

Over-merge

A false positive match that combines records describing two different entities into one golden record.

Probabilistic matching

Matching that weights attribute agreements and disagreements by their discriminating power and compares the total score with thresholds.

Reference data

Code sets and classification schemes, such as country or currency codes, used to categorize or qualify other data.

Review queue

The set of match, quality and hierarchy tasks awaiting a human decision, managed against service levels.

Suppression record

A minimal record kept after an erasure or objection so that a person's data is not re-created and their preference is honored.

Survivorship

The rules that select the value of each attribute in the golden record from the contributing source records.

System of record

The system in which an attribute is authoritatively created and maintained, as distinct from a system of reference that other systems consult.

Unmerge

Splitting a golden record that wrongly combined two entities and restoring each to its own record with its history and relationships.