A Single View of MDM Concepts: Time To Fish or Cut Bait

The continuous reverberation of discussions about the definition of customer may ring in your ears, but the fact remains that when assembling a strategy for customer data integration and master data management (MDM), at some point you have got to fish or cut bait. Competing definitions are a stumbling block in the master data integration process, especially when seeking to refine a master model that can accommodate the various sources of data.

I’ll give you a quick minute to review what I said in the last sentence, and hopefully you will raise the objection that I often raise when attempting to resolve the “customer definition” issue, which is whether the objective of master data modeling is accommodating the data suppliers or the data consumers? I’ll suggest that perhaps the root cause of the “single definition of customer” problem derive from a misunderstanding of basic intent for managing master data.

Many people think that MDM is about providing a “single version of the truth” resulting from data consolidation. But from my purist perspective, that is a lofty and perhaps unattainable goal. Rather, we might consider MDM as a set of disciplines for providing a unified view of the information associated with a conceptual master data domain. The difference between the first perspective and mine is that with so many different definitions and presumptions associated with our data domains (such as “customer”) it is extremely difficult to differentiate what is really meant by “truth.” To paraphrase Colonel Jessep in “A Few Good Men,” most organizations and their systems can’t handle the truth! Instead, let’s focus on just providing visibility into (all) the data sources that can be linked to a single customer or product – that is hard enough.

Anyway, back to my earlier point: before when I said “fish or cut bait,” does that mean forcing a diverse community of creators and consumers of customer data to agree to a single definition? Not necessarily, and the justification reflects back on the difference between data visibility and “single version of the truth.”

Let’s look at it from a different point of view. When there are different definitions for what we might think would be the same concept, perhaps we are not really thinking about the same concept. Let’s use “customer” as the example. The individual who pays for your product might not be the one who actually uses the product, and in fact the person authorizing the payment might be yet another individual. The sales people talk to prospects who might become customers, while customer service might provide advice to individuals evaluating the product but who have not yet committed to buying it. Actually, is the customer the individual purchasing the product, or is it the organization for whom the individual works?

In retrospect, these are all slightly different concepts, and attempting to shoehorn all of them into a single model is bound to lead to inconsistencies between what is in the master repository and the original source systems. On the other hand, the cross-functional view that marshals the individual s(and their corresponding organizations) through the sales and support processes will use the same information, even as the contexts change. This suggests that in some cases when we say we want a unified view of the “customer” we really want a unified view of the “party” cast into the different roles that party will play across the end-to-end activity.

Using that as the starting point, we can change the rules for our customer definition debate. Instead of getting a single definition of customer, let’s differentiate two aspects:

1. Distinguish between the different “customer” roles that exist in the different business processes and figure out which attributes are shared and those that are not among those roles, and
2. Differentiate between the core entity (“party”) and the role that party plays during the process flow.

These distinctions represent the semantic differences that have plagued those carrying the “single view of the customer” flag. Once we have those distinctions, we are in a much better position to inform our modeling process. For example instead of having a customer as a core data domain, we need to catalog the different customer roles and institute those roles within the model. Core identifying attributes associated with the individual are retained by the “party” data concept – first name, last name, eye color – the stuff that is relatively static and is associated with the individual. (We can apply similar logic to corporate entities as well, I am just using the individual as a canonical example.) Attributes relevant to the individual acting in a particular role can be used as identifying attributes, but only in the contexts where that role is meaningful.

The upshot is this: don’t attempt to force a single definition of any master data concept – you will end up getting people angry, confused, and ultimately you are going to lose information along the way. Instead, embrace variation and embed it in the master model as a way of capturing the semantic differences and ensuring they don’t get in the way of supporting the cross-functional business processes that demand that unified view!