Many MDM initiatives struggle because the organisation begins with a platform decision before it has agreed what business problem is being solved.
Typical symptoms are familiar: too many domains are placed into the first release, ownership is unclear, matching rules are designed without business involvement, data quality is treated as a one-off cleansing task, and integrations are built before the organisation has defined how a trusted record should actually behave.
Attempting customer, product, supplier and reference data simultaneously creates complexity before reusable patterns exist.
"Create a single source of truth" is not enough. The programme needs business outcomes tied to real processes.
Without owners, stewards, decision rights and escalation paths, exceptions accumulate and trust falls.
Without proper pre-processing, attempting data migration risks inconsistent, duplicate, incomplete or inaccurate data entering the golden record.
Every implementation should begin with a clear statement of business impact. The problem might be duplicate customers affecting service, inconsistent product hierarchies disrupting ecommerce and analytics, fragmented supplier identities increasing procurement risk, or unreliable reference data breaking integrations.
That problem becomes the anchor for scope, architecture, governance, data quality and the first release. It also creates a baseline against which the programme can demonstrate value.
The first domain should combine meaningful business value with a scope that can be understood and delivered. A complex global customer domain may be strategically important, but a narrower supplier or reference-data use case can sometimes demonstrate the operating model faster.
Evaluate each candidate domain against business impact, data fragmentation, process pain, executive sponsorship, availability of representative data and the ability to measure improvement.
An MDM maturity assessment should look beyond data quality. It should establish how the domain is created, changed, consumed and governed today.
Sources, duplicates, completeness, standards, hierarchies, relationships and critical attributes.
Create/change workflows, approvals, exception handling, manual workarounds and lifecycle events.
Ownership, stewardship, policies, quality rules, decision rights and accountability.
Source systems, integration patterns, MDM capability, data platforms and downstream consumers.
Skills, stewardship capacity, business participation, operating model and adoption readiness.
Baseline KPIs, business pain, decision latency, operational cost and AI/analytics impact.
The conceptual model establishes the business entities and relationships that the organisation must understand consistently. The logical and physical models then translate that business structure into implementation detail.
For a customer domain, this might include organisations, individuals, accounts, addresses, locations, contacts and relationships. For product, it could include products, SKUs, categories, classifications, specifications and hierarchies.
The model should be driven by business use cases and consumption needs not by every attribute that happens to exist in a source system.
A golden record is not simply the “best row” from one source. It is the authoritative representation of an entity created through profiling, standardisation, matching, survivorship, enrichment and governance.
These decisions must be explainable. Business owners need to understand why records match, why one value survives and when a steward should intervene.
Governance becomes valuable when it is embedded into the master-data process. Policies and standards should become validation rules, ownership should become workflow routing, and decision rights should become approvals and escalation paths.
| Lifecycle stage | What happens | Typical control |
|---|---|---|
| Request | A new or changed master record is proposed. | Required fields, role-based access |
| Validate | Quality and policy rules are applied. | Format, completeness, reference-data checks |
| Match | Potential duplicates and related entities are identified. | Match thresholds, deterministic/probabilistic rules |
| Steward | Ambiguous cases are reviewed. | Queues, exceptions, escalation |
| Approve | Decision rights are applied. | Workflow approval and audit trail |
| Publish | The trusted record is made available to consumers. | Distribution policy, API/event/batch controls |
| Monitor | Quality and process health are measured continuously. | DQ KPIs, SLA, stewardship metrics |
There is no single architecture that fits every enterprise. Registry, consolidation, coexistence and centralised styles represent different levels of authority and operational control.
The right choice depends on where records are authored, the amount of control the business needs, integration latency, source-system constraints and the expected role of MDM in operational processes.
A focused demonstration is more valuable than months of abstract design. Use representative data and a real business scenario to prove that the proposed model, matching rules, survivorship, workflow and consumption pattern work together.
This is also where business users can challenge assumptions before they become expensive configuration or integration decisions.
The golden record creates value only when it reaches the processes that need it. Distribution therefore belongs in the solution design from the beginning.
Production readiness includes more than technical testing. Stewards must know how to handle exceptions, data owners must understand decision rights, support teams need operating procedures, and users need confidence in when the trusted record should be used.
After go-live, the programme should move from implementation metrics to value metrics: duplicate reduction, faster onboarding, higher completeness, fewer manual corrections, more reliable analytics and increased use of trusted master data.
Blue Altair’s 6D approach structures the implementation around six phases: Discover, Demonstrate, Develop, Distribute, Deploy and Drive. The phases create a progression from understanding the problem to proving value, industrialising the capability and sustaining outcomes.
Technical completion is not the same as business success. Measures should combine data, process, adoption and value.
It depends on scope, domain complexity, source systems and integration requirements. A focused first domain can demonstrate value much faster than an enterprise-wide rollout. The key is to separate proving the pattern from scaling every integration and domain.
Which MDM domain should we implement first?Choose the domain where data fragmentation creates measurable business impact and where sponsorship, representative data and a realistic first release are available. Customer, product, supplier, location and reference data are common starting points.
Do we need data governance before MDM?You need enough governance to make decisions about ownership, standards, quality, matching, survivorship and exceptions. Governance and MDM can mature together rather than waiting for a complete enterprise governance programme.
Should we select the MDM platform before designing the model?No. The business problem, domain scope, conceptual model, lifecycle and architecture requirements should inform platform selection and configuration not the other way around.
How does MDM support AI readiness?MDM reduces ambiguity in critical enterprise identities, attributes, hierarchies and relationships. That gives analytics and AI applications more consistent business context and a stronger foundation for trusted outcomes.
Blue Altair’s MDM Discovery Workshop and 6D Transformation approach help organisations prioritise the right domain, define the target capability and create a practical path from fragmented data to trusted, AI-ready intelligence.