Cutting Through the Confusion About Master Data Management

Last month, I wrote a blog post on Tips for Succeeding with MDM or Data Quality Initiatives. Cliff Longman - I assume it's the same Cliff Longman who is the CTO for master data management (MDM) solution provider Kalido - wrote a response noting that it might help readers to understand there are actually two types of MDM, operational and analytical MDM. He thought much of the information in the post applied to operational MDM.

Actually, I have no idea if the information I referenced applies to analytical or operational MDM. That's because this type of distinction is seldom made when vendors, analyst or trade journalist write about MDM.

Assuming I'm not the only one confused by this, I decided to do a little digging into these two types of MDM. What I found is that it's pretty hard to distinguish the marketing terms from useful descriptions. Shocking, I know.

Longman explained the difference thusly:

"Operational MDM seeks to straighten out the data in the operational systems for operational reasons. That's why it is big, risky, invasive, and expensive. Analytic MDM seeks to leave the operational world alone (phew!) and simply concentrate on compiling a view of data that can be used for analytic purposes. Much quicker, cheaper and less risky!"

Therefore, Longman suggested companies opt for analytical MDM.

As with all things IT, not everyone agrees. And there are a few other issues to consider.

"Operational MDM (O-MDM) is focused on the distribution, synchronization or exchange of master data to ensure consistency in transactional operations. Analytic MDM (A-MDM) is concerned with the management of the master data items and associated hierarchies required for aggregation and analysis."

Or, put another way, operational MDM synchronizes master data, including product or customer information, across the company's transactional applications, while analytical MDM reconciles data "drawn from a variety of sources to deliver integrated, consistent business intelligence across the entire business."

As I read it, this means operational MDM is making sure all the sources stay on the same page - pushing the information to the individual sources - while analytical MDM is sorting it all out in a hub to create one view - pulling it together from the various sources and then analyzing it in the hub. Typically, analytical MDM is seen with business intelligence tools.

To complicate things, there are also two different flavors of MDM products - one evolving from customer data integration (CDI) and one evolving from product information management (PIM). As the name suggests, one is designed for for customer data, the other for product data. (I should also note that IBM introduced a third flavor in 2007 - its multi-form MDM solution, which promised to let you use the solution for either customer or product data.)

The Intelligent Enterprise piece explains that both fall under the category of operational MDM. It also explains which vendors specialize in which approach. It's good for a general overview, but the information is from 2006 and no doubt dated by now. (As I said, people tend not to separate the two, so I haven't found a more recent survey - stay tuned.)

You might also want to check out this more recent piece, a sample chapter from "Enterprise Master Data Management: An SOA Approach to Managing Core Information," published by IBM Press. It explains why companies need MDM and the types of MDM solutions, including a discussion on industry-specific MDM offerings. It also explains a third usage for MDM -collaborative authoring, sometimes called collaborative MDM.

Wolter explained that the data for the two styles actually looks the same, though there are a few exceptions:

"Transactional MDM might have a few more attributes associated with a given entity because there are things the operational system cares about that that aren't required for analysis. An Analytical MDM hub will probably store more hierarchies than a transactional hub because there are generally hierarchies that are interesting in analysis and reporting that the operational system may not care about."

He noted that the two styles also load and publish data differently. In either case, he argued these differences are incompatible, so you could probably just use the same MDM hub for both, assuming you ensure the solution will support both:

"My take on it would be to look for an MDM solution that can support both transactional and analytical styles I think in most cases the logical progression would be to start with analytical MDM to master the data models, rules, technology and stewardship required to manage your master data in a less mission-critical environment. Once you have achieved some successes in analytical MDM, you can use the same data, models and processes to manage the master data for your transactional systems by just adding the publishing logic to push the master data into the operational systems."

I'm sure that some vendor will ping me to tell me what I miss - as they should. This isn't meant to be a definitive list of MDM categories. Rather, I'm just trying to make sense of it and wanted to share what I've learned thus far.

At this point, here's the one thing I can tell you: The MDM market is confusing and CIOs are going to have to be on their toes. Not all products will address all MDM needs, so you'll need to think long-term to ensure the solution will do what you need when you expand your master data program down the road. Otherwise, you may have to invest in a new MDM solution and, if you're not careful, you could just wind up with MDM silos.

Another layer of confusion lies in conversations about how MDM relates to identity resolution (full disclosure: I'm with Infoglide Software and edit Identity Resolution Daily.) Industry analysts are trying to sort it out at this point, so more help may be on the way. I've tried to clear up some confusion in frequent posts on our blog (www.identityresolutiondaily.com), but it's an ongoing effort. Identity resolution (aka entity resolution and analysis) was first considered part of BI, yet lately it's been classified with data management products. To me it's a horizontal technology that enhances many types of solution areas including MDM (both CDI and PIM), but it also addresses a class of problems that are identity resolution pure plays.

If you cross check against any of the marketing and analyst reports going back to 2004 (5 years ago! my how time flies), you will see the origination of "operational / analytical and (yes!) collaborative MDM" simultaneously arrived in the marketing of IBM and Oracle as well as in our research reports of that period (we were the CDI Institute back then, now the MDM Institute). From reports/PPTs of that period, I offer up:

Although "Collaborative MDM" has received less attention as a term these days, most followers of MDM "grok" the distinction it provides as a fundamental use case difference from operational and analytical.

--Aaron ZORNES, chief research officer, The MDM Institute and conference chairman for the MDM SUMMIT series of conferences

I think that both Bob & Aaron, touch on what I see as a key difference between Operational and Analytical MDM, which is identity resolution.

Operational MDM is looking to do quick and efficient identity resolution, so that operational systems are in sync. This gives one the comfort that the same customer site / raw material / GL Code is referenced in various operational systems. The attributes needed in most cases are there to assist one in matching identifying codes. This is primarily identity resolution and plumbing that then pushes these mapping as efficiently as possible to each operational system. Due to this most analytic MDM solutions have been vertical (CDI, PIM) as one typically does not need to go beyond the immediate domain to perform the matching.

Analytic MDM on the other hand looks at that same base operational data from various different views. Firstly would be classifications of the base for different divisions of the organization (Finance vs. Operations vs Marketing). Each of these could look at the same bucket of products / customers etc. through the specific lens of their organization. Another key portion of Analytic MDM is that it is cross functional. The way one might want to classify products could be driven by Geography, competition or the Industry classification of customers. Analytic MDM marries to most analytic solutions which are cross functional & introduces data that does not typically reside in operational systems (My grouping of 2009 strategic customers). This kind of data usually requires a fair bit of collaboration from a human perspective, so these solutions tend to be more visual and interactive.

Both solutions are necessary in organization however due to the more extensive plumbing involved with operational MDM it is typically something that has a longer timeline prior to delivering on initial business benefit.

Registry (just manage references to data held elsewhere), Hub (Manage a central copy of the data), hybrid (mix of registry and Hub)

All combinations of the three dimensions are potentially valid. You could have an Operational Customer Registry for example, or an Analytic "All subject" Hub.

Everyone would like to do all combinations (i.e. manage all their data subjects, for operational and analytic purposes using the most appropriate technical architectures). But it is impractical to do all this in one go, so

The 64,000 dollar question people ask me is "what should we start with?"

To that question, I advise people to start with analytic (because in my opinion it is less risky and cheaper than operational), using very flexible technology that can grow to accommodate all data subject areas, with technology that can be deployed as registry or hub. Unless, of course, they know exactly what they want to do (in which case they probably would not have asked the question).

This way people can start small, think big, and incrementally evolve to accommodate their grand vision

The challenge: master data management is always deeply ingrained in the current business process, applications and infrastructure across the enterprise. Vendor and analyst labels often describe uses rather than management of master data.

First lets define managing master data. There is the entity in the real worldand then the information entityabout the entity in the real world. That information entity is the datawere talking about. The masterdata are the information entities about the domains most shared across the enterprise and critical to the business such as customer (or party) and product. Managing master datameans the business process, logic and database services to manage the information entity (object) through its lifecycle.

With product the enterprise ownsboth the entity in the real world and the information entity. There are also complex hierarchies that describe relationships between products that are part of the master data information entity. With party the enterprise has no control over the state of the entity in the real world. Parties have less complex relationships also expressed as hierarchies in the information entity. In both cases master data management comprises the business process, logic and workflow for the creation and lifecycle management of the master datainformation entity.

The current state has many simultaneous implementations. Different business process, different application logic, different database design - all many times over managing the same enterprise level domain like party and product. At the same time there are many business drivers, often functionally based, to resolve the problem and motivate substantial business benefits.

The labels for these solutions more closely describe the use of master data than the lifecycle management of the master data information entity itself.

For example, Ray Wangs recent post describes three architectural styles for building MDM but only transactional operational data storeformally manages the master data information entity. Hybrid harmonizedcomes close but the harmonizationis an after the fact implementation of a cross reference at the entity instance level without an explicit common business process and workflow. Cross referencedfocuses on managing accurate across sources key assignment so that an instance of the same master data information entity (and the entity in the real world) in one database is linked to another instance of the same entity in another database. Building a simple off-linecross reference registry itself is no simple task and many times what the business really needs. But it does not address the lifecycle management of the master data information entity.

As Aaron Zornes points out Collaborative MDMarrived at the same time as Operational and Analytical. Collaborative most strongly covers the concepts of managing the lifecycle of the information entity. Which is why is it often associated with the product domain where business owns Reply

Feb 10, 2009 9:11 AMRobert Rich
says:

both the information entity and the entity in the real world. Operational comes next with a focus on the implementation pattern but includes an actively managed repository (optionally with stewardship and workflow) at its heart. Analytical, in my humble opinion, steps over the line into using master data with no formal management of the information entity itself.

MultiformMDM implies full lifecycle management of master data domains as an enterprise platform architecture with a variety of implementation patterns.

Labels aside, the best MDM solution is the one that adds critical capabilities, leverages what you already have and can be used to implement a series of use cases each of which drives business value over time.

Good job! I like the way you have bought some clarity with few concise words.

The point I was making in the artical you quoted, was not that operational and analytic MDM are alternatives, but that they are alternative START POINTS.

Almost everyone I speak to wants "everything" (operational, analytic, collaborative, all data types, enterprise wide, etc). Their challenge is where to start, and the strategy for getting from where they are today to their end goal.

I prefer the risk reward ratio for STARTING with analytic MDM in the majority of companies I speak to because they get high business value from being able to analyse a single view of their data, and do not need to modify their operational systems to get it. For those companies who seek the (perhaps more significant) benefit of consistent data across their operational systems, they have to face the more significant risk of modifying those systems.

Not such a good play for the systems integrators of course as it means less well paid, lower risk, smaller projects. But then perhaps I am getting a little cynical in my old age

I believe there is one more dimension to this discussion which relates to the architecture style of MDM or rather different MDM Hubs i.e. registry, co-existence and transaction hub.
So if you are intending to use an operational MDM you would never go for registry or co-existence styles which means you would go only for a transaction hub architecture and vice versa.
So one of my predicaments is how should companies plan on moving from analytical to operational MDM if you initially have a registry hub and you plan on moving to Transaction Hub Reply

Please enable Javascript in your browser, before you post the comment! Now Javascript is disabled.

Post a comment

Your name/nickname

Your email

WebSite

Subject

(Maximum characters: 1200). You have 1200 characters left.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.