6.2 MDM Repository Architectures

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

---

Selecting the Right MDM Architecture

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

1. 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.
2. 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.
3. 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).
4. 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

1. 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).
2. 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.
3. 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.