Analytical MDM is the focus of delivering clean, conformed and consistent master data to data warehouses, cubes, and other business intelligence applications. The process is to extract data from the various operational source systems, and integrate that data into the MDM master entities that have been defined. As with any robust form of data integration, rules are applied to only allow valid data to enter the MDM environment.

Once in the MDM environment, users may interact with the master data via a suitable front-end. One of the key analytical maintenance tasks that users may be required to do is to supply additional entity attribute values for reporting purposes. It's quite likely that if, for example, Customer data has been sourced from the ERP system, then the master data entity that gets populated will contain Customer attributes such as names, address and telephone numbers. But what about a customer attribute such as 'Industry Classification'? In our example, senior management wish to see a report of customer sales that must include Customer Industry Classification, but as it happens there is no such customer attribute in the ERP.

Forgetting MDM for the moment, and depending on how mature the organization's Business Intelligence actually is, Excel may currently be involved to solve the above problem. It's not unheard of for someone to take a data feed from somewhere, and then manually adjust in Excel before delivering some sort of manual excel dashboard to the executive in question.

Another solution to this problem could be to create a new attribute in the ERP. This may be a good choice, but it could take time to implement and could be technically difficult, depending on which ERP product the organization has implemented.

MDM tools can offer a quicker and more robust solution, as they're highly specialized to deal with this kind of situation. As each new customer is detected by the MDM tool, a user can be alerted, and then prompted to fill in the Industry Classification for the new Customer. As you would expect, it's also possible to alter the new attribute value for existing Customers as well.

Due to the huge data volumes involved in some data warehouses and BI tools, the delivery of master data to these systems tends to happen in batch, for example, over-night.

Operational MDM is a little more complex than Analytical MDM. With Analytical MDM, the data travels one way, from the source, via MDM in the middle, into the data warehouse. Operational MDM is altogether different, as the members of the master data entities that are controlled and improved by the MDM process actually become the members that get used directly by the source systems.

By addressing the overall data quality in the operational systems via a central program, the issues outlined earlier in this chapter can be addressed. For example, a situation could occur whereby users of a marketing system need to send out a promotion to a group of existing customers. They take a feed of customer contacts from the Sales system, which to them seems sensible enough. However, the salespeople who frequently call a range of existing customer contacts have discovered that a few contacts have recently left. This means that the marketing users will be sending promotions to out-of-date contacts and is a waste.

With operational MDM in place, updates to a central repository of customers would ensure that the Marketing users in the example above can send their promotional advertising to a list of customers that will be more likely to respond.

Often, in order to prevent the kind of problems that can occur at the operational level, data needs to be made available to the operational systems in near real time. This is in stark contrast to the kind of latency that is often acceptable in a data warehouse. There are several architectural design patterns that can help address this situation, as we will see in the next section of this chapter.

A final point is that there is some debate on Operational versus Analytical MDM in the industry. This centers around the point that if an entity is to be managed by MDM, then all systems, whether they are analytical or operational, should be using the very same master data.

One thing is certain: the tasks involved getting the operational and analytical systems to participate in the MDM program are different. Operational MDM may need to operate in real time, in order to detect source system changes, deal with them, and then synchronize them back to get users using the correct data as soon as possible. The normally over-night batch loading of a data warehouse is easier to undertake, as no-one will be using the system, and the integration will likely happen into a set of de-normalized tables, which are easier to understand for a developer when compared to the entire normalized structure of an off-the-shelf ERP database, for example.