ExamFinch.com My Study

Study guide

6.2 MDM Repository Architectures

Practice this exam

DAMA Certified Data Management Professional CDMP

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview & DMBoK Framework

1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles

2 Chapter 2: Data Governance (Part A)

2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures

3 Chapter 2: Data Governance (Part B)

2.4 Data Stewardship 2.5 Governance Metrics & Implementation

4 Chapter 3: Data Modeling and Design (Part A)

Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization

5 Chapter 3: Data Modeling and Design (Part B)

3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices

6 Chapter 4: Data Quality (Part A)

Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle

7 Chapter 4: Data Quality (Part B)

4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting

8 Chapter 5: Metadata Management (Part A)

5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures

9 Chapter 5: Metadata Management (Part B)

5.4 Standards and Semantics 5.5 Metadata Governance & Integration

10 Chapter 6: Master and Reference Data Management

6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards

11 Chapter 7: Data Warehousing and Business Intelligence

7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses

12 Chapter 8: Data Architecture

8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards

13 Chapter 9: Document and Content Management

9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies

14 Chapter 10: Data Integration and Interoperability

Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards

15 Chapter 11: Data Security

Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards

16 Chapter 12: Data Storage and Operations

Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations

17 Chapter 13: Big Data and Data Science

13.1 Big Data V's & Technologies

18 Chapter 14: Data Ethics

14.1 DMBoK Data Ethics Framework

19 Chapter 15: Data Management Process and Maturity

15.1 Maturity Assessment Frameworks

6.2 MDM Repository Architectures

Key Takeaways Explain This Topic AI

The Registry architecture stores only pointers (keys) and cross-reference mappings, assembling the BVT on-demand, which reduces storage but increases latency.

The Consolidation architecture creates a persistent golden record store for reporting, but data flows one-way, leaving source systems duplicate-ridden.

The Coexistence architecture uses bi-directional synchronization to feed cleansed golden records back to source systems, improving data quality at the cost of high complexity.

The Transactional (Centralized) architecture provides absolute control by making the hub the sole system of entry and system of record for master data.

Last updated: July 2026

Master Data Management Repository Architectures

Master Data Management ( MDM ) requires a central system, often referred to as the MDM Hub , to manage, cleanse, and distribute master records. The DAMA DMBoK2 identifies four primary architectural patterns for MDM hubs: Registry , Consolidation , Coexistence , and Transactional (Centralized) . The choice of architecture dictates how data flows between source systems and the hub, where data is authored, and how the Golden Record (also known as the Best Version of Truth or BVT ) is stored and maintained.

  • Detailed Analysis of the Four Hub Patterns
  • 1. Registry Architecture

The Registry Pattern is a lightweight approach. The central hub does not store the master data attributes (such as customer names or phone numbers). Instead, it stores only the unique identifiers (keys) and the cross-reference (XREF) mappings between the different source systems.

Mechanics : When a consuming application requests a master record, the hub uses its registry index to query the relevant source systems in real-time, compiles the master attributes on-the-fly, and presents the assembled record.

Strengths : Fast and inexpensive to implement; minimal storage overhead; zero risk of replication conflicts; low impact on source system operations.

Weaknesses : High read latency due to real-time federated queries; heavily dependent on the availability and performance of source systems; lacks a persistent store to house enriched master attributes that do not exist in the source systems.

2. Consolidation Architecture

The Consolidation Pattern is a downstream, read-only approach. Data from various source systems is regularly extracted, transformed, matched, and consolidated into the MDM hub to create a persistent store of golden records.

Mechanics : Source systems continue to operate independently. Any creation or modification of master data happens in the source systems, and these changes are periodically (batch) or in near-real-time (event-driven) replicated to the hub. Consuming applications query the hub for read purposes (e.g., for business intelligence or reporting).

Strengths : Excellent read performance since the golden records are pre-assembled and persisted; provides a centralized source for enterprise analytics; low impact on source system transactional workflows.

Weaknesses : The MDM hub is downstream, meaning source systems remain "dirty" with duplicate and low-quality data. No data is pushed back to the sources.

3. Coexistence Architecture

The Coexistence Pattern builds upon the consolidation pattern by establishing a bi-directional data flow. The MDM hub consolidates master data from various source systems to create golden records, but then it publishes those cleansed and deduplicated golden records back to the source systems.

Mechanics : Master data can be updated in both the source systems and the hub. The hub reconciles these changes and synchronizes the updated BVT across all participating systems.

Strengths : Source systems benefit directly from the MDM cleansing and deduplication process; supports operational workflows with high-quality data; allows local systems to maintain autonomy while staying aligned.

Weaknesses : Highly complex to implement; requires robust conflict-resolution rules to handle data collisions (when the same record is updated simultaneously in a source system and the hub); heavy integration and synchronization overhead.

4. Transactional (Centralized) Architecture

The Transactional Pattern (also known as the Centralized Pattern ) is the most mature and invasive architecture. The MDM hub becomes the absolute system of entry and system of record for all master data.

Mechanics : Source systems no longer author master data. Instead, all master data is created, updated, and deleted directly within the MDM hub (typically through data stewardship portals or dedicated APIs). The hub then broadcasts the master records to the subscribing source systems.

Strengths : Maximum control over data quality and governance; absolute consistency across the enterprise; zero duplicate records; simplified data stewardship.

Weaknesses : Highest implementation cost and complexity; significant impact on legacy operational systems, which must be re-engineered to query or sync with the hub; the central hub represents a single point of failure.

Architectural Comparison Matrix

  • Architectural Pattern Implementation Cost Source System Impact Write Control Read Latency Sync Complexity
  • Registry Low Low Distributed (Sources) High (Real-time assembly) Low
  • Consolidation Medium Low Distributed (Sources) Low (Persisted hub) Medium (One-way)
  • Coexistence High Medium Co-managed (Sources & Hub) Low (Persisted hub) Very High (Bi-directional)
  • Transactional Very High High Centralized (Hub) Low (Persisted hub) High (Hub-to-spoke broadcast)
  • Selecting the Right MDM Architecture

Organizations must evaluate their specific needs and constraints when selecting an MDM architecture:

Organizational Maturity : Low-maturity organizations typically start with a Registry or Consolidation pattern to deliver quick business intelligence value. As governance processes mature, they transition toward Coexistence or Transactional architectures.

Legacy System Flexibility : If legacy ERP or CRM systems cannot easily ingest external updates or adapt to new API calls, a Coexistence or Transactional pattern is unfeasible, and Consolidation is the default choice.

Latency and Performance : High-volume, real-time operational environments cannot tolerate the latency of a Registry pattern, requiring persisted-hub models (Consolidation, Coexistence, or Transactional).

Integration Infrastructure : To support these architectures, organizations must implement Data Integration and Interoperability ( DII ) tools and patterns. For instance, event-driven architectures utilizing message queues or publish-subscribe systems are commonly used in Coexistence and Transactional patterns to broadcast master data changes instantly. Conversely, batch ETL (Extract, Transform, Load) pipelines are typically sufficient for Consolidation patterns where real-time synchronization is not a business priority.

DAMA Exam Traps and Study Tips

Consolidation vs. Coexistence : Remember the defining difference is the direction of data flow. Consolidation is strictly one-way (sources to hub). Coexistence is bi-directional (sources to hub and hub back to sources).

The Registry Hub Myth : Do not fall for exam questions suggesting that a registry hub contains the "master customer record." It only contains the indexes and pointers. The attributes remain in the source databases.

System of Record vs. System of Entry : In a Transactional hub, the hub is both the system of record and the system of entry for master data, whereas in Coexistence, the hub is the system of record but multiple source systems can be systems of entry.