The vendor hype machine is up and running, and master data management (MDM) will be in your favorite software salesperson’s messaging and in their quotas by the time you read this. That hype drives business for a while, but soon MDM will have to prove its mettle.

So should you listen or care? Is MDM a fad, as some believe, or is it here to stay? I believe information management architectures are ripe for innovation as the transition continues to more operational forms of business intelligence (BI), moving it back to its most effective place alongside business operations. MDM fits right onto that path, offering key supporting data for operational BI.

Most data warehouses only address mastering data on the periphery. Think back to the origin of your data warehouse. Like many, its creation was probably due to operational system limitations to querying the data (at the same time as it was running the business). The immediate knee-jerk reaction to this was to copy the data (from the one system giving you the problems) to another one, which refreshingly did not have operational obligations. Let’s call that the data warehouse release. It can expand to other systems (and hopefully integrated and cleansed data).

The major challenges to the data warehouse strategy lie in the sourcing of the vast amounts of transactional data. Master data (i.e., dimensional data) gets the second billing in this scenario because there are only so many problems that can be dealt with at once.

Those who addressed their data warehouse with some top-down planning and vision, and averted the continual re-evaluation of their core approach, have already accomplished some of the goals of MDM - namely data integration, data modeling and data quality. Experienced information management professionals will already understand the innate value of these items, which constitute most of the rationale for MDM today. However, whether they get addressed in the data warehouse or in a new, separate data hub seems to be an act of fate or bias. That’s the reality. The data flow should be MDM hub first for master data integration, modeling and data quality, which can then feed the data warehouse.

However, even if you have a best-practice data warehouse, you may still be in need of some of the value proposition for MDM. Specifically, MDM hubs are placed in operations (logically and often physically) for brokering master data operationally.

Few have solved the problem of making the “clean” data warehouse available to the operational environment - in other words, making the data warehouse part of a closed-loop system with operations. Several challenges, mainly operational and span of control in nature, have seen to it that data warehouses provide post-operational analytic functions only. The MDM hub is built with this in mind. It’s very operational in nature, providing (and sourcing) clean master data to operational and data warehouse systems.

So far, I have spoken architecturally of MDM. I will now say the same thing about the value of MDM as I have said about data warehousing and data quality - there is none on the surface. You cannot build an MDM hub and sell it on the market to gain revenue (at least I don’t think you can). It needs to assist other revenue- and expense-targeting applications.

You have two broad ways of getting value from MDM. The first is the way you want to go if possible because it is exponentially easier to justify. This is a total cost of ownership (TCO) approach. Regardless of whether you have a separate, culled budget for something called MDM, you are actually already doing MDM. You are mastering data for the operation of various systems. You just may not be doing it in the most efficient manner. If you have a veritable army of analysts running around compiling master data in a throwaway manner for numerous queries per week, you have MDM the hard way, and you have a TCO problem. That running around can be automated with an MDM approach. You can pit the investment in automation and the ensuing reduced cost stream against the current cost stream and voilá, justification.

Even if you justify it that way, I highly encourage the MDM effort to adopt best practices, provide new functionality and do some things right that weren’t done before. Though justification and development are different activities, they should be correlated and aligned.

If there’s hardly any process in place to automate/replace or it’s impossible to put bounds around it to capture some costs, you have to look to the improved efficacy of the applications that MDM supports (or the new ones it adds). Though there will be many applications eventually, decide on a finite one or set initially. For example, a consumer medical device manufacturer needed to manage compliance preferences across the parties it serves, something it was not even considering as part of its core business before MDM. The MDM hub enabled the activity and the millions of dollars in cost reductions.

It is for these reasons that I can, and productively do, include an MDM hub in the information architectures in my purview.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access