News Stay informed about the latest enterprise technology news and product updates.

Analytical MDM is just one piece of the data management puzzle

Data management expert Andy Hayler deciphers the complex relationships between analytical MDM, enterprise MDM, data governance and data warehousing.

Image goes here

Attempting to understand the relationships between enterprise master data management (MDM), analytical MDM, data warehousing and data governance can make even the smartest heads spin. At a high level, they all point to a common goal -- improving the quality of business information to enable better decision making. But in practice, it's not quite that simple. spoke recently with Andy Hayler, the founder of U.K.-based data management consultancy The Information Difference Ltd., in an effort to get a clear picture of how enterprise MDM, analytical MDM, data governance and data warehousing fit together. Hayler explained that analytical MDM is really just an easier-to-manage version of enterprise MDM that focuses on information stored in the data warehouse. He also talked about why large companies need MDM and data warehousing to help fill the gaps in communication that have existed between business and IT organizations.

Why is enterprise MDM particularly important to large organizations?

Andy Hayler: If you think about a large company or global company, you've always got the issue of certain types of data that are [important] to the business [being] scattered around the organization. For example, if you want to ask a question like: What is my most profitable customer? Or, What is my most profitable product? These are very easy questions to ask but they’re not very easy to answer if you're a big company, because there won't be one place with customer [information] and there won't be one place with product [information]. We did this survey three years ago and found that the average large company had six different systems generating competing customer data and nine different systems generating product data. If you've got these six systems [at least] five of those customer data systems are not right and possibly all six. So the issue for big companies is: How do you deal with that? You've got all these different competing systems but, there is really no way to answer these really quite basic questions.

You can't just run the query against operational systems because there isn't just one operational system. If there were just one operational system, you wouldn't have a problem.

Andy Hayler, founder, The Information Difference Ltd.

Is this where data warehousing comes into play?

One way to deal with [the aforementioned problem] is by building some sort of data warehouse. You can take the six different customer systems and nine different product systems and a whole bunch of other things and copy the data from all the operational systems and stuff them into one big place. [But] the quality of data in the operational systems may be an issue. That is one issue. And the second issue is that [if] the operational systems change in structure through a reorganization or something, then the warehouse is out of date again, and you have to sort of fix that.

Could you describe the relationship between the data warehouse and MDM?

Interestingly enough, they are different, but they are in some ways linked, and here's the link: A data warehouse has got two things in it, typically. [For one], it's got transactional data. Think of a retailer to make it easy. You go into a store to buy a can of Coke. That transaction happened in a point-of-sale system. But there is also stuff associated with that transaction which gives it business context. [There is the] fact that it was a Coke [and] that Coke may be classified as a fizzy, or a carbonated, drink. [Another] classification would be the store. All those bits of classification -- the product hierarchy and the store hierarchy -- those are examples of master data. [For] any business transaction there is going to be some kind of context. It's that context that people call master data.

Does the data warehouse capture the master data as well as the transactional data?

The data warehouse captures the transactions and it captures the context -- the master data. But [in the case of a data warehouse] it's always a copy of stuff taken out of the operational systems. There are lots of reasons for that. You can't just run the query against operational systems because there isn't just one operational system. If there were just one operational system, you wouldn't have a problem. The data warehouse therefore contains transactional data and it contains master data. [But while] the warehouse can cope with easy things, like adding stuff, if you want to change the structure of the warehouse, it's a big deal. That is why data warehouses don't entirely do the job just in the same way that [enterprise resource planning (ERP)] doesn't entirely do the job. It's too hard.

Are you saying that MDM is required to fix the problems that things like data warehouses and ERP systems cannot reasonably address?

MDM is complementary and it says: Instead of just copying the data, why don't we try and fix this data in then operational systems? Why don't we have a go at standardizing these six different customer systems? And [we're] not going to do it technically. We can't just [impose technology] because there are six regional managers with six different ways of classifying things. But what if we got all the six retail managers together and got them to agree on a new customer classification system and new product classification system that was completely standard? What if we could get them to agree that one of them is now owner of the product hierarchy, and that all the other guys have to change their different systems? They wouldn't be able to do it overnight, but in principle they could do it.

Is this why data governance is such an important part of the definition of MDM?

This is where this whole area of data governance comes in. Data governance is sort of the soft side of MDM, if you like, because it's about getting those guys to agree on stuff -- agreeing on conflict resolution, agreeing on who should own stuff, and agreeing on data quality standards, which is very tough. But that is sort of the lofty goal of MDM. In the ideal world, you'd go out and you would change all of the operational systems. In reality that is really hard. But that is one style of MDM. That is called a transaction style. In other words, you're going out and you're fixing the actual data in the transaction systems.

If that is transactional MDM, what is analytical MDM?

Analytical MDM is another style and it says, [Getting everyone to agree is] just really hard, guys. We're basically going to take the same approach but we're not going to go and try to change [the operational systems]. That's just too difficult. But what we can at least decide on is a new reporting standard for product data.

Is it just me, or does MDM sound like a fancy way to get people to talk to each other?

[In the past, IT workers and business units] wouldn't talk to each other and the poor sods in IT putting in the warehouse had to try and figure out which customer hierarchy to use and which product hierarchy to use. And because there was no linkage with the business, the business would just go off and change it anyway, and it would just break. There wasn't that next step of the business [units talking to each other and IT] and trying to keep things in line. The big reason why MDM at least promises to have some hope is that it's [giving] the business ownership of the data, and before, that didn't really happen very often.

Dig Deeper on MDM best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.