Master Data Management (MDM) Data Modeling

The Build once, Use Many (BOUM) principal provides clear value for organizations.  It’s one reason why we built data warehouses instead of just letting each individual reporting need build their own data mart.  And when the latter occurred, eventually synergy drove some efficiencies and the data marts got bigger and fewer.  However, unable to share that information in real-time with the operational environment proved limiting. 

The data integration side of master data management (MDM) provides real-time data sharing advantages over other mediums.  This means whatever gets into the MDM database is in its most leveragable position in the environment.  This puts serious data modeling and data quality responsibilities on the MDM team.  The data structures, and the data, will be spread throughout the organization.  Subscribing systems may not take the MDM model lock, stock and barrel.  They will, most likely, do some form of transformation.  However, the starting point – the MDM data model – will be used by all for sourcing the data.

Considering that proper attention is given to the modeling, MDM will save the organization significant and measurable time in building its other applications such as ERP systems, call center applications, sales force automation (SFA) systems, CRM systems, claims, reservations and all manner of operational systems.  Anyone who has built those systems knows that managing their data needs is upwards of half of the entire effort.  MDM is essentially taking that half of the effort off the table for those applications.

This is where many MDM implementations are achieving less than they could.  While building the database with a superset of corporate attributes, a cross-enterprise data model and business rules, eyes are not kept on the usability of the data to the subscribing applications. 

In addition to BOUM, MDM provides the mechanism for originating data within an organization through its data governance/workflow processes.  Often, processes must be added in order to have data that could reasonably be labeled as master data and distributed throughout the organization.

Also often, additional attributes need to be added to existing internal attributes to fill out a data model with enterprise aspirations.  Many of these attributes will be facilitated into the enterprise through the MDM data governance process.  After all, most data is entered by somebody, somewhere and increasingly organizations will be taking advantage of MDM governance processes to acquire that data. These new attributes also form the basis of new organizational capabilities.

Consider the requirements of the MDM data model:

1.  Superset of corporate attributes

In order to accommodate all corporate attributes about the subject area, MDM modelers will need to model the subject area to its lowest granularity.  CRM and SFA may be interested in different sets of attributes for Customer, but all of those customer attributes are modeled together in MDM for the enterprise.

2.  Cross-enterprise

Building the MDM data model with a view to the requirements of the initial subscribing systems is a good idea.  Building it such that you cannot extend the model beyond those initial requirements is not.  MDM will have subscribers over the course of years.  It will need to meet enterprise needs, known and unknown at the beginning.  Continually surveying those high interest groups for their upcoming, anticipated needs helps keep the MDM team informed and provides the runway that is needed to keep the MDM data model truly cross-enterprise.

3.  Easy to Use

While it is the responsibility of the subscribing system to learn as much as it can about the data it is subscribing to, it is the responsibility of the MDM team to make their data easy to use.  The term “APIs” comes to mind.  An API approach means that MDM is being modeled so that it is easy to understand, easy to use and easy to subscribe to.  While MDM teams cannot be expected to build “push button” data acquisition for MDM data, they certainly can be expected to build repeatable instructions and processes for acquiring the data.

4.  Support Governance

While you would normally think about only including attributes in the MDM data model that are useful to multiple other systems, when MDM plays the mature role of data origination through its data governance processes, it has unique opportunity to capture attributes.  You cannot separate the MDM data model from the attributes that are collected in the governance process.  The MDM data model will contain those attributes, even if only a single system is interested in them, that are collected in the governance process.

Another set of attributes that may be in the MDM data model are those that contain support data for the drop-down menus in the governance process.  These may or not be considered master data otherwise, but if they are being sourced into MDM, they will need to be modeled in MDM.

These comprise the major criteria, beyond general good data modeling practices, that are unique to MDM data modeling and allow MDM to step up to its roles in data integration, data origination and  new organizational capabilities.