Understanding Master Data Management (MDM)

In Part 1 of this series ‘Understanding Master  Data Management (MDM)’ (http://underthehood.ironworks.com/2011/02/understanding-master-data-management-mdm.html ), we covered some basic concepts in MDM like its definition, benefits, what MDM is and is not, and steps in implementing MDM.

In this part, we will cover the following

-          MDM Implementation Styles

-          Things to keep in mind while implementing MDM

As always, we cordially invite your comments and inputs.

Thanks, and happy reading!

Deep Sogani

Practice Leader, BI & EIM, Ironworks

 

Understanding Master Data Management (MDM)

(Part 2 of 3)

MDM Implementation Styles

More often than not, MDM is implemented into existing information architecture. Therefore, depending upon the business requirements, existing enterprise architecture, and other considerations like budgets and organization culture, MDM can be implemented in many ways.

• Registry Style:

In this implementation style, a central MDM Hub is created as a registry that provides the master entities by pointing to the various source systems. There is no central data repository, and data continues to reside in the source systems.  Therefore, this registry provides a ‘virtual’ golden view of the master entity from the connected systems, by using data federation.  For implementing this, the various source systems publish their data and the MDM Hub stores only the source system IDs (as Foreign Keys), and other important data values needed for matching.

The Registry style is often used when it is not feasible to create a central data repository for reasons such as organization structure, disparate systems, regulatory requirements, etc.  In case of mergers and acquisitions also, organizations use this approach to quickly achieve MDM without making a significant investment in re-engineering, and without significantly disrupting the individual businesses

The Registry style of implementation is least disruptive – technically, politically and business-wise.  Source systems do not need to re-engineer themselves to any central common format, and the MDM hub just taps into existing data flows and processes.

 

In case an Enterprise Data Warehouse (EDW) initiative is undertaken, the EDW can subscribe to the MDM hub for all dimensional content. Hence EDW implementation is considerably simplified.

 

• Co-existence Style:

In this implementation style, a central MDM hub is created by physically consolidating relevant data from various source systems.  The spoke systems (data sources) create and store their own data, and the central gold copy in the MDM hub is updated based on events.  The master data in this case is usually not used for supporting the transactions in the source systems (as is the case with Transactional Style of MDM), but rather supports reporting, and referential needs.

 

This approach is a hybrid style between a Registry and a Transactional Style, and often is a transition stage in an organization’s MDM journey from a Registry to a full-fledged Transactional style.   It retains the single place to go to get centralized customer information, but also enables individual lines of businesses to retain ownership of their data and, as necessary, make sensitive data unavailable to the central hub.

In a more advanced version of this architectural style the master data stored in the central MDM hub is selectively published out to the subscribing spoke systems. Therefore the flow of data becomes bi-directional.

 

• Transactional Style:

In this implementation style, a central MDM hub is created by physically consolidating relevant data from multiple sources in the enterprise and storing them in one centralized hub to create a single, master version. The master data is arrived at by linking, cleansing, matching and enriching data from various sources.  The Hub is also responsible for enhancing and maintaining the master data and its attributes, over time.

The centralized hub presents the same consolidated view of data to all users, i.e. the single version of truth, and because of this, the data management requirements of individual Line of Business systems are reduced and the availability of enterprise-wide data for analytics is assured.  The hub, being the authoritative source of truth publishes the master data back to the spoke systems, and supports their transactions.

Close partnership between IT and business is crucial for the Transactional Style to be successful. This style also requires that all spoke systems and processes that consume master data get re-architected so that they request master information from the transaction hub in the same way; each system or business process interacting with a transactional hub must also model customer data in the same way, and work with that data in the same format.

 

Because of the above characteristics there are a number of benefits to a transactional hub style, such as the ability to enforce standards required to maintain enterprise-wide data quality, a centralized single place to correct and update data, and streamlined process for data availability throughout the enterprise.  One such advantage is depicted in the figure below:

 

 Figures 1 and 2: MDM is implemented in a Hub and Spoke style, thus providing a central access for master data as well as removing redundant interfaces between systems (Courtesy: http://TDWI.org )

 

Things to keep in mind while implementing MDM

MDM should not be ‘all things to all people’. Different organizations have different needs for implementing MDM. Some have an Operational issue to solve – for instance they may have multiple operational and Enterprise Resource Planning (ERP) systems, and need to synchronize data across them in order to arrive at a single, master list of products, customers or geographies. For other organizations, the purpose of the master list may not be so operational, but analytical, with the objective of managing their relationships with customers better, or doing better campaign management, up-selling and cross-selling to customers. 

 

Organizations must have a strong understanding of the current imperatives driving the MDM implementation and use that knowledge to determine the appropriate scope and methodology.  The different styles of MDM allow organizations to undertake their MDM journey at their own pace, and a timeline that matches with their strategic goals. For instance, if an organization wants to test the MDM waters and prove ROI before going deeper, the registry style can provide them with a minimally disruptive way. From there, a co-existence style hub can bridge the evolution towards an eventual transactional hub.

References:

• Three Guidelines for Implementing MDM, by Sreedhar Kajeepeta;  Information Week http://mobile.informationweek.com;
• Master Data Management Implementation Styles;  http://tdwi.org;
• Master Data Management Implementation Styles, by David Butler; Oracle Blogs http://blogs.oracle.com
• MDM:  Realizing the Same Benefits through Different Implementations, by  Dr. Scott Schumacher;  http://mdmbook.com;