MDM Implementation Patterns
Do not let you multi-domain MDM evolve without a comprehensive enterprise strategy or plan. The building blocks of an effective MDM program are Scope, People, Governance, Process, Technology and Pattern. In this post we are going to discuss the various MDM patterns or otherwise known as implementation styles.
Analytical (a.k.a Consolidated)
As with anything it is always good to start simple and limit your scope to gain early success. One way to begin is to start MDM as a data warehouse implementation, leveraging existing data integration capabilities but adding some formal data quality capabilities to cleanse, standardize, consolidate, and augment existing information. This model is best described as your analytical MDM also known as the consolidated pattern, with its primary purpose to improve analytics, reports, and business intelligence. Improved analytics will certainly help with improved business decisions resulting in cost savings or additional revenue.
However, the analytical MDM model has only limited benefits and cannot be considered an enterprise solution. Operational systems rarely access data contained within an analytical system. From the analytical systems perspective, operational systems are upstream, read-only environments. Therefore, operational systems do not automatically benefit from data improvements or from the entity resolution in the analytical environment. Therefore, data quality improvements have to be duplicated in multiple sources, so they become scattered and inconsistent.
Registry
In the registry pattern, the MDM hub maintains the link keys and identity information. All other data to a given entity is kept at their respective sources and it’s not duplicate in the MDM hub. This is a system of reference pattern. The MDM Data Hub is a reference database pointing to all source systems but does not contain actual data for a given domain except for identifying attributes.
Centralized
In a centralized pattern, the MDM hub physically stores all attributes of an entity. The hub becomes a centralized single source of truth, and it is used to publish critical data elements and master data attributes to other application systems. This pattern requires an initial load of the hub with domain data from multiple sources. After initial load, data is created and maintained directly in the hub and consumed by other applications. This pattern consists of a highly integrated architecture, which is a significant effort since it requires changes to existing applications in order to access data from the MDM hub instead of data maintained locally.
Coexistence
The coexistence pattern of MDM is a hybrid style. In this pattern, the attributes are created and maintained both in the hub and source systems. The hub is not the only source of master attributes since data creation and maintenance continue to also happen at the original sources, and replicated in the hub. The MDM hub acts as a system of reference, integrating other sources, applying entity resolution and other data quality functions to master data, and makes available a single version of the truth to subscribing systems.
Before choosing a particular pattern for your MDM implementation, it is important to consider the level of data maturity, data quality, data governance structure, IT infrastructure that is required for implementation. As always start simple depending on your current state maturity and layout a roadmap for both the initial and final state MDM style implementation.