Multiple ways to implement your MDM solution

There are several ways to handle and manage data when deploying a Master Data Management solution. Depending on the approach, we recognize the following styles that can be implemented:

REGISTRY Style

In this style, the various source systems publish their customer data and the subscribing hub stores only the source system IDs, the Foreign Keys (record IDs) and the key data values (needed for matching). The hub runs the cleansing & matching algorithms and assigns unique global identifiers to the matched records, but it does not send any data back to the source systems.

Master data distribution is performed downstream by federating the source data. The transformation and consolidation process for building the golden data is performed on demand.

This approach is completely non-intrusive and maintains data exclusively in the source applications. This style allows read-only access to the golden data via federated queries. Federating (assembling) golden data on the fly may raise performance issues and technology challenges, especially when large datasets or complex transformation/consolidation strategies come into play.

Critical data would be handled in a Registry style for regulatory compliance.

CONSOLIDATION Style

In this pattern, master data is copied from source applications, then matched and consolidated in the hub; The golden data physically created in the hub becomes available for distribution to downstream applications or for direct consumption by business users and data stewards.

This style is as non-intrusive, similar to the Registry hub style. Since golden data is stored in the hub, the performance concerns with complex transformation/consolidation strategies disappear, and stewardship processes can be executed and orchestrated in the hub.

Stewardship is a set of processes and policies that run on top of the hub. They include data entry (for fixing data into the hub), duplicates handling (for false matches or specific matching cases) and rejects management.

Product data would be managed in a Consolidation style (from the PLM and ERP applications), with some additional attributes and validation processes handled in a Centralized (#4) style.

CO-EXISTENCE Style

This pattern is similar to the Consolidation hub. It adds an integration loop back to the source applications for Golden Data.

This style is non-intrusive from the end-user perspective, but brings major organizational and technical challenges to approve and implement the integration loop.

Performing a loop not at the application data level, but at the application UI level alleviates these challenges. Such a UI-level loop could be implemented as portlets included in the end-user application to show the "similar customers in other systems" or the "golden customer record" corresponding to the source application record being viewed or edited.

Customer data would be managed in a Co-Existence style, aggregating data from the CRM, Website, etc., with a loop back to the CRM system.

CENTRALIZED/TRANSACTIONAL Style

In this pattern, master data is entirely migrated and cleansed in the MDM hub. The hub becomes the single provider for master data, and master data is exclusively authored in the hub through data entry workflows. All applications refer to the hub for their master data.

This pattern guarantees the highest level of quality for the master data, but is highly intrusive on existing business and technical processes, as it forces to rethink these processes around the MDM hub.
This style is applicable when you want to create golden and master data from scratch, when this data does not exist in a formal place at the operational level.

Financial data would be handled in a Transactional style to replace Excel spreadsheets and support authoring and validation workflows.