Model governance

Data Model Registry vs MDM Platform

By Dzmitryi Kharlanau · Published · 23 min read

A company has a data problem.

Contents

Reviewed: 14 July 2026

A company has a data problem.

Customer definitions differ between countries. SAP migration mappings are inconsistent. Important decisions are buried in tickets. Nobody can show which source fields support the target model. Every field change triggers another round of meetings.

The programme begins looking for an MDM platform.

Vendors demonstrate golden records, matching, consolidation, stewardship workflows, data quality, multidomain views and distribution.

These are substantial capabilities.

They may also be solving a different problem.

The company did not begin with duplicate customer records or the absence of an operational master-data hub. It began with an inability to control its model specification, mappings, evidence and implementation decisions.

An MDM platform can become part of the eventual solution. It does not automatically repair the fragmented delivery knowledge surrounding the programme.

This is where the distinction between a data model registry and an MDM platform matters.

An MDM platform governs important business records.

A data model registry governs the structured specification explaining what those records mean, how they are represented, where their values come from and how the model may change.

The difference can be expressed simply:

MDM platform:
Manages trusted master-data records.

Data model registry:
Manages trusted knowledge about the model.

The two categories can overlap in terminology. Both work with domains, attributes, relationships, rules and ownership.

Their operational responsibilities are different.

The procurement mistake

The mistake is not buying an MDM platform.

The mistake is assuming that every master-data problem is an MDM-platform problem.

An organisation may actually be struggling with one or more narrower problems:

These problems are real and expensive.

They do not always require an operational hub for creating, matching, approving and distributing master records.

Buying a full MDM platform before clarifying the problem can produce an awkward result:

The MDM technology may be functioning correctly.

The surrounding delivery model remains weak.

What an MDM platform is designed to do

MDM is an established enterprise discipline rather than one specific product architecture.

SAP currently defines MDM around creating a trusted master reference and identifies consolidation, governance and data-quality management as central pillars. SAP MDG adds governed models, matching, consolidation, steward workflows, validated values, quality monitoring, mass changes and auditable operational processes.

IBM similarly describes MDM as an enterprise approach using tools, processes and workflows to consolidate critical data, reduce fragmentation and provide unified records across applications. Informatica presents MDM around integrating source data, maintaining high-quality records, match-and-merge, multidomain views and 360-degree applications.

Although products vary, an operational MDM platform commonly addresses capabilities such as:

The central object is usually the master-data record.

Examples include:

The platform answers questions such as:

These are operational governance questions.

What we mean by a data model registry

“Data model registry” is not yet as standardised a software category as MDM.

We use the term deliberately to describe a narrower control layer.

A data model registry maintains identifiable, versioned and validated objects representing the model and its implementation context.

Typical objects include:

The central object is not the operational customer or supplier record.

It is an element of the model specification.

For example:

Business attribute:
Supplier Risk Classification

Source endpoints:
LEGACY_A.VENDOR_RISK
LEGACY_B.SUPPLIER_GRADE

Target endpoint:
SAP supplier-risk field

Value list:
LOW, MEDIUM, HIGH, UNDER_REVIEW

Related rule:
HIGH requires compliance approval

Related decision:
UNDER_REVIEW may not be used as a permanent default

The registry answers different questions:

These are model-engineering and implementation-governance questions.

The same word “model” refers to different things

Confusion begins because both categories contain models.

An MDM platform needs a model to operate.

It must understand:

A data model registry also stores entities, attributes and relationships.

The distinction is not that one has a model and the other does not.

The distinction is the role the model plays.

In an MDM platform

The model is part of an operational system that creates, validates, consolidates or distributes master data.

In a data model registry

The model is an independent specification used to understand, validate and change implementations across several systems and project artefacts.

The registry may describe:

It sits across implementation boundaries.

Record truth and model truth

A useful way to distinguish the categories is through two forms of truth.

Record truth

Record truth answers:

This belongs to the MDM platform.

Model truth

Model truth answers:

This belongs to the data model registry.

An organisation may need both.

A trusted customer record does not explain why one migration source was selected over another.

A validated model specification does not create or distribute a trusted customer record.

A practical capability comparison

CapabilityData model registryMDM platform
Define structured model objectsPrimaryRequired for operation
Version an independent specificationPrimaryProduct-dependent
Represent source and target endpointsPrimaryOften integration-specific
Maintain migration mappingsPrimary use caseNot usually central
Compare datasets with model expectationsPrimary use caseData-quality capabilities may overlap
Detect missing model referencesPrimaryProduct-dependent
Trace implementation decisionsPrimaryUsually surrounding documentation
Analyse impact of a model changePrimaryOften configuration- or domain-specific
Create and maintain master recordsNoPrimary
Match and merge recordsNoPrimary
Manage survivorshipNoPrimary
Execute stewardship workflowsNoPrimary
Create golden recordsNoPrimary
Distribute operational master dataNoPrimary
Audit master-record changesNoPrimary
Review model patch proposalsPrimaryNot the main operational purpose

The table is intentionally asymmetric.

A registry is not a reduced MDM feature set.

It is a different control surface.

Why an MDM platform does not automatically become the registry

A sophisticated MDM platform may store many of the objects listed above.

It may contain:

The question is not whether it can technically store them.

The question is whether it should become the independent source for all implementation knowledge.

Several constraints appear.

The platform model represents its own implementation

An MDM platform naturally describes the model as implemented in that platform.

The programme may also need to describe:

These may extend beyond the operational platform’s responsibility.

The platform arrives after some decisions have already been made

Before an MDM platform is configured, the organisation needs to understand:

The independent model can begin earlier.

The organisation may replace the platform

A model specification tied completely to one vendor’s configuration becomes harder to reuse during:

Different platforms may govern different domains

An enterprise may have:

A registry can describe relationships across these boundaries without becoming the operational owner of every domain.

Why a registry should not become an MDM platform

The reverse boundary is equally important.

A registry may begin adding features because users want to see and edit data.

The progression can look tempting:

  1. Display example records.
  2. Allow record editing.
  3. Add approvals.
  4. Add matching.
  5. Add distribution.
  6. Add audit history.
  7. Add tenant administration.
  8. Add real-time operational requirements.

At that point, the registry is becoming an MDM platform.

This would require a very different product:

That is not a small product extension.

It is a category change.

For Martenweave, this would be overbuilding and strategic drift.

The product should remain focused on model truth rather than operational record truth.

The user groups are different

An MDM platform primarily serves operational and governance roles such as:

A data model registry primarily serves delivery and change roles such as:

There is overlap.

A data steward may review an attribute definition or value list in the registry.

An architect may inspect operational behaviour in the MDM platform.

But the primary jobs differ.

The lifecycle is different

An MDM platform operates continuously around master-data records.

Create
→ validate
→ review
→ approve
→ activate
→ distribute
→ maintain

A model registry operates around model knowledge.

Discover
→ structure
→ validate
→ compare
→ propose
→ review
→ approve
→ implement elsewhere
→ preserve evidence

The distinction is especially important for AI.

An AI system working with an MDM platform may help classify, match or enrich records.

An AI system working with a registry may help propose:

In both cases, governance is necessary.

The approval boundaries are not identical.

Example: adding a supplier risk attribute

Suppose the business wants a new supplier-risk classification.

An MDM platform may need to:

A model registry should capture the surrounding design:

The MDM platform operates the classification.

The registry explains and controls how that classification fits into the wider implementation.

Example: correcting a migrated customer value

A customer record in SAP contains the wrong group.

The MDM or MDG platform supports correcting the record through the governed operational process.

The registry helps answer:

The MDM platform corrects record truth.

The registry helps correct model truth and prevent recurrence.

Example: changing a mandatory rule

The business asks to make a tax field mandatory.

The MDM platform or SAP MDG can enforce the rule after approval.

The registry helps establish whether the rule should be approved:

The MDM platform enforces the decision.

The registry improves the decision.

When a company needs an MDM platform

An organisation likely needs an MDM platform when it must operationally control master data across systems.

Signals include:

These are significant enterprise capabilities.

A registry should not be proposed as a cheaper substitute.

SAP, IBM and Informatica all describe MDM around consolidating, governing and maintaining trusted enterprise records rather than merely documenting their structure.

When a company needs a data model registry

A registry becomes useful when the primary problem is controlling knowledge about models and their implementation.

Signals include:

The organisation may not need to replace or add an MDM platform.

It may need a better control layer around the work it already performs.

When both are needed

This is likely the most relevant scenario for large SAP and MDM programmes.

The operating model can be:

Data model registry
Defines and validates implementation model truth
                ↓
MDM platform
Executes operational master-data governance
                ↓
Business applications
Consume governed records

The feedback loop then returns operational evidence:

Operational defects and change requests
                ↓
Registry impact analysis
                ↓
Approved model change
                ↓
MDM configuration and release

The two systems remain aligned without sharing the same authority.

When neither is needed

A small organisation may not need either category.

A disciplined workbook and clear process may be enough when:

A registry should not be introduced merely because mappings exist.

An MDM platform should not be introduced merely because data quality is imperfect.

The architecture should match the cost of the problem.

Registry first does not mean MDM later

A model-registry pilot can help clarify whether an MDM platform is needed.

It can reveal:

The result may strengthen the case for MDM.

It may also show that the problem can be resolved through:

The registry is not necessarily the first stage of a vendor upsell.

It should improve the decision about what comes next.

MDM first does not remove the registry problem

An organisation may already have an MDM platform and still need a registry.

Common symptoms include:

The operational platform may be working well.

The missing capability remains model-delivery governance.

Data model registry vs metadata catalogue

The distinction also matters because a registry may be confused with a data catalogue.

A catalogue typically helps users discover and understand data assets across an organisation.

It may cover:

A data model registry is narrower and more delivery-oriented.

It focuses on the approved model specification and its changes:

A large catalogue may contain some of these capabilities.

The registry does not need to become a full enterprise discovery platform.

This distinction will be explored separately, but it reinforces the main point: tool categories should be selected based on the job, not on overlapping terminology.

The cost profile is different

An MDM platform is an operational enterprise system.

Its cost may include:

A data model registry should have a lighter operational footprint.

Its cost should be justified through reduced delivery friction:

A registry has failed economically if it requires a large platform programme merely to document the platform programme.

A decision framework

Before selecting a product category, ask what object needs to be governed.

Question 1

Do we need to govern operational customer, supplier, product or material records?

If yes, an MDM platform may be required.

Question 2

Do we need matching, merging and survivorship?

If yes, this points strongly toward MDM.

Question 3

Do we need approval workflows for master-record creation and change?

If yes, this is an MDM or MDG capability.

Question 4

Do we mainly need to control definitions, mappings, rules and implementation decisions?

If yes, this points toward a registry.

Question 5

Do we need to compare actual migration datasets with the approved model?

This is a strong registry use case.

Question 6

Do we need to distribute trusted master records across applications?

This is an MDM or master-data-integration responsibility.

Question 7

Do we need to analyse the impact of changing an attribute across mappings, rules and tests?

This is a registry use case.

Question 8

Do we need both operational governance and implementation traceability?

Use both, with explicit boundaries.

A product-selection anti-pattern

A programme creates an RFP containing every desirable data capability:

Every vendor appears to cover much of the list.

The programme cannot distinguish core capabilities from adjacent ones.

This produces evaluation based on feature quantity rather than architectural responsibility.

A better RFP begins with:

The answer may include several products.

That is acceptable when the boundaries are intentional.

Where Martenweave fits

Martenweave’s current public description defines it as a practical model-control layer for knowledge scattered across spreadsheets, datasets, tickets, validation reports, decisions, SAP context and project history. It connects fields, attributes, rules, owners, issues and decisions; validates references; detects gaps; traces impact; and routes AI suggestions through reviewable proposals.

The current core includes:

This places Martenweave on the registry side of the boundary.

Its core object is the model specification.

Its main value is controlling relationships between:

What Martenweave is not

The product’s current documented boundaries are important.

Martenweave is not:

These are not temporary omissions to hide.

They define the product.

Martenweave should not:

Its value disappears if it tries to become a smaller version of every adjacent platform.

A Martenweave operating model

Spreadsheets, datasets, tickets and SAP context
                        ↓
             Martenweave model registry
                        ↓
      Validation, gaps, lineage and impact
                        ↓
              Reviewable proposal
                        ↓
                 Human approval
                        ↓
   SAP MDG, MDM or another platform implements change

The implementation platform owns operational behaviour.

Martenweave preserves the approved specification and evidence.

Example: using Martenweave beside SAP MDG

Suppose SAP MDG governs Business Partner.

SAP MDG owns:

Martenweave owns the independent implementation model:

A tax rule change may begin in Martenweave as a model proposal.

The proposal identifies:

After approval, the SAP team implements the rule through normal MDG and release controls.

Martenweave records the new baseline and evidence.

Example: using Martenweave before MDM selection

An organisation has customer data across five systems.

It is considering an MDM platform.

Before procurement, Martenweave can help structure:

This will not create a customer golden record.

It gives the organisation a clearer basis for determining:

The MDM implementation then begins from a more controlled specification.

Example: using Martenweave without MDM

A company is migrating from legacy ERP systems to SAP S/4HANA.

It will use standard SAP processes and does not need a separate enterprise MDM hub.

It still needs to manage:

Martenweave can support this model-delivery problem without introducing operational MDM.

This is an important market position.

Not every migration needs another master-data platform.

Most complex migrations need better control of model knowledge.

A sensible pilot

A data model registry should prove value without requiring an enterprise rollout.

Select:

The pilot should demonstrate:

  1. Stable model-object identity.
  2. Deterministic reference validation.
  3. Source-to-target traceability.
  4. Dataset gap detection.
  5. Value-coverage analysis.
  6. Impact analysis for one change.
  7. A reviewable model proposal.
  8. A role-specific report or workbook.
  9. Preserved decision rationale.
  10. Clear handover value.

The pilot should not attempt:

Those would test the wrong product category.

How to measure registry value

Useful measures include:

These measures are modest and practical.

The registry does not need to claim that it transformed all enterprise data governance.

It needs to reduce the cost of model delivery and change.

Common misconceptions

“The registry is a lightweight MDM”

No. It does not govern operational master records.

“The MDM platform already has a data model, so the registry is redundant”

The MDM model describes the platform implementation. The registry may describe sources, targets, mappings, decisions and several platforms.

“A registry is only documentation”

Documentation is one output. The core value is structured objects, validation, lineage and controlled change.

“A registry should eventually write directly into MDM”

Not necessarily. A deliberate human and release boundary may be safer.

“MDM will solve our mapping-spreadsheet problem”

It may provide useful modelling and integration capabilities. Migration and implementation knowledge can remain external unless the programme governs it explicitly.

“We can use the registry instead of MDM to save money”

Only when the organisation does not need operational MDM capabilities.

“AI can generate the model, so we do not need either”

AI can propose a model. The organisation still needs authority, validation, ownership and operational execution.

AI behaves differently in each category

Within an MDM platform, AI may assist with:

In a registry, AI may assist with:

Informatica currently presents AI-assisted match tuning and recommendations as part of its operational MDM offering. That illustrates how AI can support mastered-record processes inside an MDM platform.

Martenweave’s principle is different:

AI proposes model changes.
Validators check structural consistency.
Humans approve.
Operational platforms implement.

This keeps AI outside direct authority over the approved model and production records.

Our conclusion

A data model registry and an MDM platform are not two versions of the same product.

An MDM platform manages operational master-data truth.

A data model registry manages implementation-model truth.

The MDM platform answers:

The registry answers:

A company may need one, both or neither.

The correct decision begins with the object that needs governance.

Our practical rule is:

Do not buy an MDM platform to solve a model-documentation problem. Do not use a model registry to solve an operational master-data problem.

When both problems exist, use both layers with explicit authority.

That separation makes the architecture easier to explain, the product scope easier to control and the implementation less likely to become another expensive platform built around the wrong problem.

About the authors

Martenweave is maintained by Dzmitryi Kharlanau.

We build practical model-governance infrastructure for SAP migration, MDG, MDM and AMS teams. Martenweave is designed to preserve and validate the model specification surrounding enterprise implementations—not to replace the platforms that govern operational master data.

Sources and notes

This article was reviewed on 14 July 2026.

SAP currently defines master data management around creating a trusted master reference and identifies consolidation, governance and data-quality management as key pillars. SAP Master Data Governance adds governed models, golden records, matching, consolidation, steward workflows, validation, monitoring, mass changes and auditable operational processes.

IBM describes MDM as an enterprise approach combining technology, processes and workflows to consolidate critical data into unified master-data services shared across applications.

Informatica describes MDM as consolidating and maintaining high-quality master records from multiple sources and currently markets match-and-merge, multidomain views and 360-degree applications as part of its MDM offering.

Martenweave’s current public documentation describes structured model objects, deterministic validation, generated indexes, dataset gap detection, trace and impact analysis, spreadsheet review flows and controlled PatchProposal and ChangeRequest lifecycles.

Martenweave’s documented boundaries state that it is not a full enterprise MDM replacement, workflow engine, generic data catalogue or replacement for SAP MDG and related enterprise systems.

Martenweave is an independent project and is not affiliated with or endorsed by SAP, IBM or Informatica. Product and company names mentioned in this article may be trademarks of their respective owners.

Primary sources

Related articles