Master data management (MDM) provides methods for unifying data about important entities (such as “customer” or “product”) that are managed within independent systems. In most cases, there is some kind of customer data integration requirement for downstream reporting, and analysis for some specific business objective – such as customer profiling for product cross-sell marketing.
I've worked with many customers who were struggling to complete the development (and consequently production) of their master data repositories. Based on this experience, I've started to see an implementation artifact that exposes some of the key issues with the most common approaches to MDM deployment. In many environments, the deployment model effectively sweeps data from operational environments on a periodic basis, applies the identity resolution and matching algorithms, and links records representing unique entities together. These records are subjected to some kind of “survivorship” process that plucks assorted values to create the master record.
One issue I see with this approach is that the resolution of the master record is not only performed outside of any business context, it is also arbitrarily timed with no relation to the status of any business process. This may be good enough if the master record is only going to be used for periodic reporting and analysis. However, this asynchronous record cannot provide an accurate view of the master record for real-time operational and transaction processing.
For example, consider the difference between an individual creating an online customer account and subsequently applying for special credit terms. Before the credit application, a record is created in some kind of identity management application’s database that allows the website to recognize the individual and link his activity to a specific customer profile. But later, when the individual applies for special credit, his data is added to the database for the credit application's process. At that point there are two records for the same individual.
Until this person's credit application data is reviewed and a determination is made, the record is essentially a work in progress. If the master data management resolution process happens when the record is still in flux, it's a different story. In that case, the individual’s master record will not reflect the result of the credit process, and the record will remain out of sync with the other systems until the next resolution cycle takes place.
This is a simple example that only involves two interacting systems. But you can already see the dilemma: If the individual is granted the special terms, at what point do those terms become effective? If the eCommerce site queries the credit application, then it is effective immediately. But if the eCommerce site queries the master record, that record’s data will lag behind the actual process – and the customer will have to wait until it is synchronized again.
Get the TDWI checklist: Seven Tips for Unified Master Data Management
