Reviving MDM Registry Implementation Style in the Data Mesh Context
In the context of digitization, Parsionate has set itself the task of offering a portfolio of solutions in the areas of master data management, data quality management and data governance. Practical experience shows that up to now MDM solutions have been designed almost exclusively in a centralized manner with the main features of master data consolidation. The Data Mesh paradigm shift to decentralized domain-specific ownership and areas of responsibility with higher-level data governance leads to the question of how traditional MDM solutions can accommodate this new concept.
The use of an MDM registry hub offers a pragmatic entry-level option because the domain-specific databases are only referenced - i.e. there is no need to invest efforts to centralize / consolidate large amounts of master data in a central repository - in addition further typical traditional disadvantages are eliminated by the Data Mesh Concept itself.
Can a specific business case for generating a company-wide (global) identification (customer, product ...) be solved with an MDM Registry Hub. Can these principles also be applied to the requirements outlined by Martin Treder (Boehringer Ingelheim / Webinar: “Seeking the Single Source of Truth in Business Party Master Data”)?
So, is the time ripe to successfully utilize the MDM Registry Implementation Style?

MDM and Corresponding Implementation Styles
Master Data Management (MDM) plays a key role in helping organizations to identify their critical data elements / data records and to manage them with a high level of quality. It ensures that these master data elements / data records are controlled for various applications, processes and data landscapes and that they guarantee maintenance, completeness and consistency across the company.
GARTNER defines Master Data Management as a technology-enabled discipline in which business and IT work together to ensure the uniformity, accuracy, stewardship, semantic consistency and accountability of the enterprise’s official, shared master data assets.
There are various ways to achieve the above requirements with different implementation solutions. This has led to different combinations of MDM implementation styles and usage requirements. However, the implementation style also depends on an agreed data strategy, such as the question of centralized or decentralized enterprise data management.
The pragmatic approach is to start with the simplest hub solution such as the registry hub if business requirements allow. Additional requirements can be met with alternative MDM hub solutions by migrating to the next style (e.g. migrating from Registry Hub to Consolidation Hub to persist master data in a repository). Some companies rely on a combination of different implementation styles.
Most Common Implementation Styles
4 important implementation styles have crystallized out, depending on where master data is persisted and managed – in the MDM Hub itself, or in the source systems, or in both.
Listing according to implementation effort
- Registry implementation style (simplest implementation style)
- Consolidation implementation style (mainly applied for analytics)
- Coexistence implementation style (most practical implementation style for operations and analytics)
- Transactional Hub implementation style (most complex implementation style / intensive change management)
As the styles progress from Registry implementation style to Transactional Hub implementation style, they provide increasing functionality but may require more implementation and governance effort.
Our Market Evaluation of MDM Implementation Styles
Registry Hub: Looking around the market, you will find a minimum (if any at all) Registry implementation styles due to the disadvantages as listed below. As the implementation styles can also change during runtime, it is difficult to evaluate the market share of all MDM implementations. Overall, it is repeatedly mentioned that the MDM Registry Style even is more of a concept than an implementation due to the lack of functional & organizational prerequisites.
Consolidation & Coexistence Hub: Most MDM implementations reflect both the Consolidation Hub for analytical MDM and the Coexistence Hub for operational MDM. Our estimate: Together, these two implementation styles may have >95% market share.
Central Hub: You will not find many Central Hub implementations, as the implementation effort for the required business process changes is disproportionately high and therefore (potentially) expensive. An exception is reference data management, where the reference data is generated and managed centrally and published to the source systems. This makes Reference Data Management a perfect candidate for the Centralized Style Hub.
Registry Hub Details
The Registry Hub can be useful to provide a read-only source of master data as a reference to downstream systems with a minimum of data redundancy. The MDM system holds the minimum amount of information required to uniquely identify a master data record (matching relevant data elements); it also provides cross-references to detailed information that is managed within other (source) systems and databases.
The Registry Hub is able to clean and match only this identifying information and assumes that the source systems can adequately manage the quality of their own data. The actual master data profiles remains distributed across various systems or data sources. The registry acts as a pointer or reference to the master data wherever it resides. This style is often preferred when the organization has a large number of disparate systems that need to maintain control over their own master data but still need a way to synchronize or reference that data across the enterprise.
Disadvantages:
- No explicit data quality management in the Hub
- Complex query structures
- Performance and data availability are determined by source systems
- Traditionally, there is no governance operating model between source systems and Registry Hub
Advantages:
- Entry-level implementation style – quick wins
- Access to the latest data records in the source systems
- Foundation for extension to the Consolidation Hub and others
Data Mesh - Decentralized MDM Approach With Federated MDM Model
The federated MDM model is a method of managing master data across different domains. On closer inspection, the MDM registry hub concept with a federated governance model is very closely interwoven with the data mesh concept - in fact, the principles of MDM registry and data mesh are identical.
A federated enterprise MDM model combines domain-specific models into an enterprise master data solution. This result is a coherent and networked MDM framework that spans different domains within the company.
The disadvantages of the traditional registry hub solution with all the criteria mentioned above are largely eliminated in the data mesh architecture. There is a paradigm shift in the data mesh architecture towards decentralized processing of domain master data and the introduction of data products.
Data Product / Product Thinking
A data product is owned by the functional domain team; the team is responsible for the operations of the data product during its entire lifecycle. The team needs to continuously monitor and ensure data quality, availability, and costs. Each domain has its own data ownership, governance and responsibilities.
- A data product is a logical unit that contains all the components for processing and storing domain data for analytical or data-intensive operational use cases.
- A data product includes not only the data, but also the associated metadata, code and infrastructure (e.g. contract)
- Data products serve data sets in one or many output ports (APIs).
- Data products connect to sources, such as operational systems or other data products and perform data transformations.
- Output ports are typically structured data sets, as defined by a data contract.
Source: „Data Mesh“ from Zhamak Dehghani
To treat data as a product means taking the consumer’s perspective and making data ready to generate value. Naturally, the concept of data products also applies to master data management- this means that master data records (e.g. golden data records with basic information) are treated as data products, and these can be expanded with additional data from other domains (composite data products)
The provisioning of a company-wide unique identifier created by MDM Registry Hub can also be defined as a data product (data as a product). Thus, the MDM Registry Hub collects the relevant identification attributes to generate a global identification inclusive cross references required for a Golden Master Data Record (cross domain queries) across functional domains, which ultimately improves the effectiveness, consistency and reliability of data management (current data, data-driven decision-making, accurate reporting, solving dedicated business challenges).
The actual data pre-processing, e.g. data cleansing, data transformations or enrichments, take place in the various functional domains themselves. The data product concept is the foundation for the collaboration between domains (business) and IT (data infrastructure as a platform / MDM Registry Hub) to work together in a value-driven mode.
According to GARTNER, the characteristics of a data product are as follows:
- Consumption ready (findable, trusted by consumers)
- Up-to-date through SLAs (data product contract)
- Approved for use (federated data governance)
- Scalable
- With quantifiable cost and measurable value
Decentralized Domains and Ownership
- Domains are business units or functional areas within an organization.
- Each domain has its own data ownership, local governance, and responsibility (responsibility of data is now shifted closer to the business value stream).
- Federated data and analytics governance is successful because it recognizes the existing work, value and data context within business functions (Data Mesh Domains).
- Domains can be classified by data characteristics and data product usage.
- Master data elements must be defined and managed by the domains themselves. This approach leads to Domain Master Data Management (DMDM).
- DMDM guarantees high data quality for matching (identification) attributes in the Registry Hub.
- Master data quality (in the source systems) is in the responsibility of a domain/business function (DMDM).
- Master data is provided as a "product” (master data element, master data record)
- The master data product is described by data contract.
Data Infrastructure as a Platform
- The MDM Registry Hub platform acts as a self-serve data infrastructure. It is a domain-agnostic, shared, infrastructure for processing and serving identity-level master data for matching and cleansing. If the data in the source domain is clean, the composite view served by the Registry Hub will also be clean.
- MDM Registry Hub requires strong governance practices because unilateral changes in a source could cause problems for MDM users or consuming systems (federated data governance model)
- At the central platform level, the critical matching-relevant master data elements, their definitions, dependencies, people, procedures and guidelines should be integrated into a federated governance model.
- A self-contained network is formed where enterprise master data can be correlated and expanded with domain-specific master data.
- The Registry Hub provides various services via APIs that can be consumed by applications and tailored to the specific requirements of different domains. In this way, MDM services become an integral part of data products generated by the respective domain data owners (e.g., supplementary attributes from other domains). These composite data products can be consumed within a domain or shared across multiple domains as required.

Domain-driven Master Data Management
a) Business Case: Get Customer Profile
Queries against the registry-style MDM system dynamically assemble the required information in two steps. First, the identifying information is looked up within the MDM system. Then, using that identity and the cross-reference information, relevant pieces of information is retrieved from other source systems in different domains.

The figure above shows a simple example (principle) where the MDM registry holds enough master data attributes to uniquely identify a customer (in this case name, birthdate, Social_Id information) and then provides cross-references to customer information stored in Domain1/System A and Domain2/ System B.
Process sequence:
1a,b = read matching attributes from application from relevant functional domains
2 = fuzzy / exact matching
3 = perform “getCustomerProfile” inquery using corresponding cross-references
4 = collect/assemble company-wide customer profile data based on cross-references information
b) Business Case: Create Global Customer_Id Cross Domains
Large organizations may deploy several autonomous MDM systems worldwide. Each MDM solution generates local golden record identifiers. Due to corporate reporting requirements, there is a need to generate a global golden record identification.
Queries against the registry-style MDM system dynamically assemble the required information using the global identification and the cross-reference information to retrieve relevant information from other source systems (local MDMs, CRMs)

The figure above shows a simple example (principle) where the MDM registry holds enough master data attributes to generate a unique “global“ Customer_Id (in this case name, birthdate, Social_Id). Both the Global_Id and the local Golden_Id must be referenced with the secondary repositories in the relevant domains.
On the marketplace local golden records can be retrieved within one domain – using the global Identification a cross-domain retrieval from different domains/systems generates a holistic view of the customer.
Process Sequence:
1a,b = read matching attributes from relevant functional domains
2 = fuzzy / exact matching
3a,b = return, synchronize Global_Ids to domain systems (secondary MDM repositories)
4 = perform “getCustomerProfile” inquery using Global_Id and corresponding cross-references (Golden_Id1; Golden_Id2)
5 = collect/assemble company-wide golden record based on cross-references information
Summary: Advantages of the MDM Registry Style in the Data Mesh Context
Prerequisite: Identifying enterprise-wide unique data and/or assigning “global” master identifiers (Global_Ids) can only be done centrally, not locally within domain systems.
- Keep domain-specific secondary repositories (such as MDM Applications) – they can hold additional data elements.
- Secondary repositories and their processes in the domains remain unchanged (exception: data model extension for “Global_Ids” in secondary repositories necessary).
- Primary MDM repository (Registry Hub) treated as a “black box” with no business user interface.
- No direct data maintenance on the primary MDM repository, but only on domain specific secondary systems. (processes remain unchanged)
- Data quality and data availability of domains are guaranteed by product orientation and agreed data contracts.
- Matching criteria are determined jointly between domains and data infrastructure platform (federated data governance).
- Data quality rules are defined jointly between domains and infrastructure platform (federated data governance).
- Only a few key data elements for duplicate identification need to be collected from the different systems for the primary MDM repository (data infrastructure as a platform), resulting in a reduced data volume.
- You will receive the most current information at the time of inquiry.
- The implementation effort for the primary MDM repository is relatively low, as the responsibility for the master data management and master data quality lies with domain master data management.
- All search activities can be improved using both semantic layers (data virtualization, data democratization) and AI-powered marketplace.
What do you think - can Registry Hub gain a new significance in the context of Data Mesh?
