Lesson 8 — MDM/RDM Activities, Requirements, and Roadmap
Chapter 10 does not recommend buying a platform first and deciding what to master later. Both MDM and RDM begin with business requirements and source understanding, then move through architecture, modeling, stewardship/maintenance, and governance.
The shared six-stage skeleton
A useful exam sequence is:
Requirements → Sources → Architecture → Model → Steward/Maintain → Governance
The details differ between MDM and RDM, but the planning logic is parallel.
MDM activity route
1. Identify business drivers and requirements
Ask what problem the organization is solving and which entities/attributes matter.
A good assessment asks: - Which repeated core entities matter? - Where are they created? - Where are they stored? - How do they change? - Who accesses/uses them? - What quality/reliability problems exist? - What authority, sharing, and integration expectations apply?
2. Evaluate and assess data sources
Inspect semantics, identifiers, quality, authority, update behavior, lineage, and existing duplication.
3. Define the architectural approach
Choose Registry, Transaction Hub, Consolidated, or another fit-for-purpose pattern based on authority, latency, consumers, governance, and source constraints.
4. Model Master Data
Create enterprise entity/attribute semantics and relationships rather than inheriting source-system “system speak.”
5. Define stewardship and maintenance
Establish matching, identifiers, survivorship, exception handling, DQ, publication, and ongoing maintenance.
6. Establish governance policies enforcing enterprise use
Define source authority, ownership, conditions of use, approvals, monitoring, and consumer expectations.
RDM activity route
1. Define drivers/requirements and authoritative sets
Determine which shared domains need control and why.
2. Assess sources
Know whether values are internal or external, how updates arrive, who publishes them, and who consumes them.
3. Define RDM architecture/acquisition
Consider update frequency, volatility, vendor delivery, history, consumption patterns, manual stewardship, approvals, notifications, and mappings.
RDM does not need the same entity-resolution machinery as MDM.
4. Model Reference Data
Define code sets, descriptions, mappings, hierarchies, taxonomies/ontologies, Metadata, and effective versions.
5. Define stewardship/maintenance
Manage scheduled/ad hoc changes, approvals, impact, versions, history, and communication.
6. Establish governance policies for enterprise reuse
A central repository only creates value if consuming applications actually use the governed values.
Incremental roadmap
Chapter 10 recommends practical incremental implementation under an enterprise architecture. A new program that proposes mastering Customer, Product, Location, Account, and hundreds of attributes at once can magnify unresolved semantics, ownership, and Data Quality problems.
A stronger start is often: - one high-value domain; - a manageable set of attributes; - clear authority and stewardship; - measurable consumers/use cases; - expansion based on demonstrated value and learning.
Incremental does not mean random local projects. The work should align to a roadmap and enterprise architecture.
Tool families
MDM can use specialized applications, integration/remediation tools, databases/operational stores, workflow/stewardship capabilities, and data-sharing hubs. The exam point is not vendor recognition: technology supports the discipline; it does not equal the discipline.
Stop and check
Stem: “The matching product is selected; now define requirements.” Weak order. Requirements, sources, and architecture should drive implementation choices.
Source anchor: pp. 340–341, 351–356.