Blog post

A lay-up I can’t resist: Reference Data Management (RDM)

By Andrew White | December 02, 2010 | 2 Comments

Reference Data Management (RDM)Reference DataMDM

I note the increase in attention that MDM is getting in the press.  Seems like almost every day I get a PR piece from a website, marketing program or vendor that extols their own experiences of services related to MDM.  Hype seems to be on the uptick.

Today I spotted the following article:  How to Create Business Value from MDM published on Information Management.  The article itself is pretty good – I didn’t spot much at odds with our research; I didn’t spot much that was overly new or challenging.  It is a pretty good, solid even “foundational” perspective.  But I did spot something close to a current dialog I am having with users quite a lot.  I spotted this:

While MDM provides solutions around key business concepts such as customer, product, location and employee, reference data management provides solutions around data that is not mission critical across an enterprise. This might include a list of codes and descriptions for software used in an organization, a list of cost center codes and descriptions, etc.

This particular dialog happens to fit very closely with numerous inquiries I have had recently.  Numerous users are asking about “reference data” meaning, that data that is a) not transaction data, b) not master data, but c) is used in conjunction with mater data, often behaving like master data, but clearly not master data.  This data could be but is not limited to:

  • Units of Measure
  • Country Codes
  • Corporate Codes
  • Conversion Rates (currency, weight, temperature, etc.)
  • Calendar and calendar constraints

More generally, these data could be described as a set (i.e. table) of permissible values (observations) that are often referred to by other (master) data and transactions/analysis.  I suspect Mark Beyer, a colleague of mine at Gartner, would no doubt offer a more precise definition, but most business users get the idea. 

The questions we get end up at this point: “If I am making progress with mastering of master data, can I not use that MDM program to govern reference data?”

Firstly users have to accept that there is a specific data realm called reference data.  And that it is different but related to master data.  Often such data is widely re-used, widely referenced, does not change overly much in terms of definition; and gains in value when it is consistent across uses.  But, this data is not master data since it fails the business sniff-test: this data does not describe that the business does; the business users do not spend their day worrying about units of measure.  They spend their day worrying about customers, citizens, services, and the business performance related to same.

The article therefore nicely highlights a self evident truth: yes, re-use the parts of your MDM program to govern other important data like reference data.  Just don’t re-define MDM since we will all get mightily confused over what is in – and out – of scope of MDM.  In your implementation, try defining “reference data” as a form of “master data” but remember to keep tracks on its real definition.  In truth the governance of reference data will not be as onerous as it is for master data; and the technology used to support MDM will be more than enough to master reference data.

Comments are closed

2 Comments

  • Jeff Gentry says:

    Some of the data you’ve listed as reference data looks like master data to me. It’s as if the definition of master data is morphing before my eyes.

    If a list of country codes is not master data, then I confess to not knowing what master data according to the 2010 marketing and think tank spin. In most cases, the ISO 3166 country codes are the best basis for this country master data, but it still requires adjustment and augmentation. I may wish to add US APOs as country subdivisions for certain purposes, like defining valid CUSTOMER postal addresses. I also may need to add a country short name and adjust some names based on public relations needs, such as the choice to call that large island of the southeast coast of Asia “Taiwan, Province of China” or “Taiwan.” That decision, especially when the data is public-facing, may impact profitability, represent a choice between business risks, and should be consistent across the enterprise.

    My sniff test includes questions like:

    Does it need to be uniform across the enterprise?
    Does the enterprise benefit from managing a single source of record used across the enterprise?

    I find that idea that experts in our field don’t think of country and conversion reference data as master data shocking and I doubt that is the case out in the trenches. If so, I’d love to hear that from people in the field dealing with the practical implications of master data management.

    In summary, reference data is “real” master data.

  • Andrew White says:

    Hi Jeff, thanks for the post. I must admit I was a little shocked myself at being the cause of such a flutter. I had not expected that. But thankfully I don’t think this is a major issue. I think it is a) both a measure of granularity, or scope, and b) a minor error on my part. First the error. Yes, in some cases, “master data” such as “customer” cannot be defined without the relevant “country code”. From that perspective, country code is part of the master data definition. Not all organizations that model “customer” need country code, but I accept that many do, so it would qualify. Likewise with product, as Steve Strout from Black Watch Data reminded me a few weeks ago, it’s pretty hard defining “product” without reference to unit of measure. So as such, unit of measure is part of the master data definition. However, even he used the term “reference data” when it came to unit of measure.

    Now the scope thing: There are clearly some corporate codes that are sometimes part of mater data (above example) but there are other corporate codes that are not. Perhaps currency conversion would be a good example. So I would qualify my original point as this: there are other data in organizations, that often behave like master data (widely re-used; value increases with consistency) but often are not of the traditionally accepted uses – such as “customer”, or “product”. Country code is not quite at the same level as “customer” even though it might comprise the definition of customer. Customer would be inclusive of various pieces of data, including (in some cases), reference data. Reference data is therefore sometimes a subset of master data; other times it is not. So I suspect that my original comment, thus qualified, would be “acceptable” to many implementations. And yet may need more qualification in others.

    I am not quite as keen to go with “reference data is real master data” since I think (in some cases) one is a subset of the other. But in other cases, reference data can clearly be non-master data. So perhaps a better way is to say that they intersect?

    Lastly, there are in fact some industries that use the term “reference data” to mean “master data”! Financial services companies rarely use the term “master” at all . Many “correct” me and use their own term, “reference data” to mean counter party and other “referenced” sources. But they too admit (in dialog) that various corporate codes and look up tables containing same sometimes are not “reference data”. Perhaps its more “horses for courses?

    Good point to call out – thanks for sharing it.

    Andrew