How to choose a master data management platform

Choosing a master data management platform is less a feature comparison than a fit assessment. The right platform is the one that can enforce the ownership model your organisation will actually operate, hold the kinds of data you actually share, and deliver the agreed version to the systems that actually consume it.

Most selection processes go wrong the same way: a long feature matrix, scored by a team that has not yet agreed who owns the data. The matrix then measures things that do not decide the outcome. These are the ten questions worth answering before the matrix.

1. Who will own the data, and can the platform enforce it?

Master data programmes fail on ownership far more often than on capability. Before evaluating any platform, decide who is accountable for each domain, who does the daily stewardship, and who resolves a dispute between two business units.

What a good answer looks like. Permissions expressed by role rather than by individual, and applied at the level of the dataset, the table, the record and the individual field, so a regional steward can maintain a local description while a global identifier stays read-only to them.

How to test it. Ask the vendor to show a change proposed by a business user, rejected by a steward, and the audit trail that records both.

2. How many kinds of data must one model hold?

Master data is one of four things organisations usually need to govern together. The others are reference data, the permitted values records may take; hierarchies, the structures reporting rolls up through; and metadata, the meaning and lineage of the data itself.

What a good answer looks like. Be honest about which of the four you need now and which within three years. If you only ever need one, a narrower tool may serve you better and cost less.

How to test it. Ask whether the four are one model or separate products with separate licences, separate administration and separate upgrade cycles.

3. What will your AI systems actually be reading?

This is the question that has changed most in the last two years, and the one most selection processes still skip.

A model or an agent does not read your intentions. It reads rows. If the same customer exists four times, it inherits four customers. If a field called status means something different in two systems, it averages the difference. If nothing records who approved a value, it cannot tell a governed figure from a guess. Retrieval makes this worse rather than better: a system that pulls the nearest-matching text will happily pull the wrong version of a record, confidently.

What a good answer looks like. Ask what travels with the data when a machine reads it:

• Resolved entities, so one customer is one customer, not four near-duplicates.
• Meaning, so a field carries its definition rather than relying on its column name.
• Relationships and hierarchies, so the system knows which entity belongs to which, not just that two rows exist.
• Permissions that travel with the record, so an agent answering a question cannot surface what the person asking is not entitled to see.
• Provenance and currency: which version this is, when it was approved and by whom, so an answer can be traced rather than trusted blindly.

How to test it. Ask the vendor to show exactly what an external system retrieves for a single entity. If the answer is rows and nothing else, the context has to be rebuilt somewhere, by someone, every time.

The honest caveat. Governed master data improves what an AI system is reading. It does not make a model correct, and no MDM platform should claim it does.

4. You already have a cloud data platform. What does MDM add?

Most organisations evaluating master data management already run a lakehouse or a cloud data warehouse, and the reasonable first question is whether that is enough.

It usually is not, and the reason is specific rather than competitive. Analytical platforms are very good at storing and querying data at scale. They are not where an organisation decides what is true. That decision needs four things an analytical environment is not designed to provide:

• A place to adjudicate. When two records may or may not be the same entity, a business steward has to decide. That is an interface and a workflow, not a notebook or a SQL job.
• Governance of change, not of access. Warehouse permissions answer who may read a table. Master data governance answers who may change what a value means, and records the decision.
• Write-back. Analytics is the end of the line. A correction to a customer record has to reach the operational systems that caused the problem, not only the reports that revealed it.
• Structures that survive restatement. Reproducing last year’s roll-up needs the hierarchy that was in force then, versioned deliberately, not reconstructed from history tables.

The relationship is complementary, not competitive. Master data management decides the agreed version; the analytical platform is one of its most important consumers. Governed master data makes everything downstream cheaper, because reconciliation stops being a modelling exercise repeated in every pipeline.

How to test it. Ask how the platform publishes to your analytical environment, whether it can share rather than duplicate, and the revealing one: how a correction made by a steward reaches both the warehouse and the operational system it came from.

5. What happens when two systems disagree?

Every MDM programme eventually hits two records that may or may not be the same entity, where the rules cannot decide. What happens next is the single most revealing thing about a platform.

What a good answer looks like. A steward can see why the system scored a match the way it did, override it, and have that decision recorded and reusable. Matching that is a black box produces decisions nobody can defend in an audit.

How to test it. Bring your own messy sample data to the evaluation, not the vendor’s.

6. Can you reproduce last quarter’s numbers?

Structures change. Cost centres move, entities merge, classifications are revised. If the platform overwrites, prior-period reporting cannot be reproduced against the structure that was in force at the time.

What a good answer looks like. Versions held side by side rather than overwritten, and the ability to prepare and compare a proposed structure before it is published.

How to test it. Ask to see last year’s hierarchy and this year’s open at the same time.

7. How does the agreed version reach consuming systems?

A governed record that stays inside the MDM platform changes nothing. Distribution is not an afterthought, it is most of the value.

What a good answer looks like. Published APIs, documented and standards-based, plus the ability to push as well as be pulled, and a record of which systems received which version.

How to test it. Ask which of your consuming systems the vendor has connected before, and how.

8. Which implementation style does your landscape need?

There are four, and the right one depends on where authoring happens today:

• Centralized. Data is authored in the MDM platform and published to, or subscribed to by, other systems.
• Consolidation. Source systems feed the platform, which consolidates records into golden records.
• Coexistence. A blend of the two: data can be created in several systems, including the platform.
• Registry. Records stay in their sources; the platform aligns their identifiers through cross-references.

What a good answer looks like. Most organisations need more than one, in different domains, and change style over time. A platform locked to a single style constrains you later.

Where this points away from a heavier platform. If you genuinely only need registry-style identity resolution across a handful of systems, and expect that to stay true, a full MDM platform is more than the problem requires.

9. How will you measure the return?

MDM sits between systems, so no single system shows its benefit. The investment is made in one place and the return appears somewhere else, usually in a team that does not know the programme exists. A campaign that stops bouncing looks like a marketing result; a procurement team finding it bought the same component under four codes records a sourcing saving.

What a good answer looks like. A business case assembled jointly from the systems the data reaches, separating two mechanisms:

• Prevention, the bad record that never enters. This is the larger number and the harder one to evidence, because an avoided cost never appears in a ledger.
• Correction, the defect fixed once and propagated everywhere. This one is directly measurable: time to detect, time to correct, systems reached, manual effort removed.

How to test it. Ask the vendor which department signed the business case at a comparable customer, and which departments the savings actually landed in.

10. Where will it run, and who operates it?

Separate two questions that often get merged: who operates the platform, and who holds the data. They are not the same decision, and the right answer depends on your own constraints rather than on what is fashionable.

Some organisations want to run it themselves, for control over the upgrade cycle and over where data physically sits. Others want no operational footprint at all. Both are legitimate, and the trade-off is real: self-operated means you choose when to upgrade, and it also means you are the one upgrading.

What a good answer looks like. Clarity about who patches it, who holds the data, where it is stored, and what the exit looks like. EBX^® is deployed on premises, in a customer-managed cloud, or hybrid.

How to test it. Deployment options change, and the same vendor may offer more than one. Ask every vendor on your list directly, including us, rather than assuming from the category. Then ask the question most buyers forget: what does leaving look like, and who holds the data while you do it?

What this guide deliberately does not do

It does not score vendors or publish a comparison matrix. The weighting depends entirely on your landscape: an organisation with one authoring system and three consumers has a different problem from one with twelve of each. Any published matrix is really the author’s landscape, scored.

Common questions

Do we still need MDM if we have a lakehouse or cloud data warehouse?
Usually yes, and for a specific reason: an analytical platform stores and queries data, it does not decide what is true. Adjudicating a duplicate, governing who may change a meaning, and writing a correction back to the system that caused it are not analytical functions. The two are complementary. Master data management decides the agreed version, and the analytical platform is one of its most important consumers.

Will master data management make our AI accurate?
It will improve what the AI is reading, which is usually the larger problem, but no MDM platform makes a model correct. Governed master data gives an AI system resolved entities, definitions, relationships, permissions and provenance instead of unreconciled rows. The model is still a model.

How long should an MDM selection take?
Longer on the ownership question and shorter on the feature matrix than most teams plan for. Programmes that start with one domain, one clear owner and one consuming system show value early.

Should we run a proof of concept?
Yes, with your own data, including the records you know are bad. A proof of concept on vendor sample data tests nothing you need to know.

Do we need a separate data quality tool?
Sometimes. Validation and matching at the point of entry are MDM functions; large-scale profiling and cleansing of historical data may warrant a specialist tool alongside.

What is the difference between MDM and a data warehouse?
A warehouse consumes master data; it does not govern it. It assembles copies for analysis. MDM decides what the agreed version is and distributes it, including to the warehouse.

Who should lead the selection?
The business function accountable for the data, with IT assessing operability. Selections led entirely by IT tend to optimise for integration and under-weight stewardship, which is where programmes actually fail.