Master Data Management (MDM) is widely considered critical to business; consider, for example, the opinions that the success of the Internet of Things (IoT) depends on MDM, and that, whatever the future of the data warehouse, MDM remains critical.

Nonetheless, many companies still struggle to establish MDM processes and systems, and/or to get value out of their MDM implementations. Why? In my experience, it’s because one size doesn’t fit all. A master data management system needs to be very different for customer data, product data, and other reference data.

Customer Data MDM

Large companies often have departmental or divisional customer databases, creating expensive barriers to such things as cross-selling, anti-money-laundering (AML), and tax law conformance. All of the traditional styles of MDM advise companies to add one more system—the MDM system—to their collection of customer masters, in order to harmonize customer data. This rarely works well, for a number of reasons.

You’ve probably had the experience of moving and having to contact multiple vendors to update your address; this is especially annoying when you have to advise one company of your new address multiple times, once per product line. An MDM implementation that preserves multiple copies of that one address does nothing to reduce customer pain.

A central customer MDM system does little or nothing to solve these data quality and customer service problems. What is truly needed is a single customer master that is capable of serving the customers of all product lines. This is not a trivial thing to do, but it’s the only way to increase customer data quality and reduce operational expense.

These problems can only be solved by creating a single customer master that replaces other customer masters. The one central database must be able to track the identity of a customer while supporting multiple personas of that customer. This is a very different task for corporate customers versus individual customers but, interestingly, in most cases a business deals with an individual even when the customer is an organization. Examples:

• A lawyer might place orders for her private practice, her law firm, as a professor of law, and on behalf of herself personally. She might have different addresses, names, and titles associated with each role; for example, some women use their maiden names professionally but their married names personally.
• A buyer at a large company might place orders with several different lines of business at your company, on behalf of several different lines of business at his company.

In addition to supporting unique attributes for each individual customer’s personas, a central customer master must support unique attributes for each line of business. For example, a business-to-business interaction requires different attributes than a business-to-consumer interaction.

If you’re starting with multiple customer masters and want to get to one uber-master, here are a couple of strategies that I’ve seen successfully done.

• Review all your existing customer master systems. If one of them has the multiple persona features you need, has good operational support, and performs reasonably well at a reasonable cost, elect it to become the single master. Create projects to replace your other customer masters with the chosen one, one at a time—because small projects are more likely to succeed than big projects. Part of each replacement project must include decommissioning the replaced system. This takes discipline and commitment but is critically important, because if you don’t replace the old system you’ve made matters worse, not better.
• If you can’t leverage a system you already have, build a new one, but part of the project’s success criteria must be to replace two of the existing customer masters. If you replace one, you’ve made a change without making an improvement, and if you replace none, you’ve made matters worse. Then proceed as above to replace the other customer masters, one at a time.

A great approach to system replacement is this process:

1. Define a new set of user interfaces and programmatic interfaces that can be supported by both the existing system and the new system.
2. Implement the new interfaces on top of the existing system.
3. Give users and other systems a time window to adapt to the new interfaces, then shut off the old interfaces.
4. Stand up the new system, and implement the new interfaces on top of it. This can be done in parallel with steps 2 and 3 if there are sufficient resources to do so.
5. Before cutover, copy data from the old system to the new system, and make sure that it is properly handled by the new system.
6. At cutover time, switch all users and systems from the new interfaces on the old system to the new interfaces on the new system.

This gives users and implementers a soft cutover window, provides ample opportunity for regression testing, and allows easy fallback if things don’t work at cutover time.

But before you start, keep these things in mind:

• The data matters more than the features. The reason to consolidate to a single customer master is to serve customers and the business better. That won’t happen unless the customer data is managed better by the new system. For this reason, the customer master data must be carefully modeled, and the business must truly understand—at a business level—what customer data is being managed, why, and how.
• The project’s benefits must be business benefits primarily, not just technology benefits. It’s fun and cool to build new systems, but the point is to delight customers, minimize costs, operate more speedily, etc.

Product Data MDM

Product data is less troublesome because most product definitions are generated internally, so there are fewer cases of the same data being managed in multiple places. The main challenge with product data is to enable a single product to be sold by separate divisions. The key success factor here is to have product identifiers that work in every division, and that enable each division to present the same product in unique ways. There doesn’t need to be a single product data MDM system; just a consistent product identification system. The ID system might depend on an internal identifier such as a UUID that a customer never sees. Each division would associate its own customer-visible product ID to the internal product ID, and everything works.

Externally Sourced Master Data

Some master data must originate from outside a company; examples include code sets such as country codes, postal codes, financial instrument “ticker symbols”, etc.

When there’s exactly one set of data coming in from outside, sourcing the data is quite straightforward. However, this is rarely the case. Country codes are surprisingly complicated. There are three sets of them (2-letter, 3-letter, 3-digit) and they change over time; furthermore, the International Organization for Standardization (ISO) and the United Nations (UN) maintain slightly different code sets. An MDM system for such data must be able to maintain the history of revisions and align differing code sets.

When there are multiple rich sources of potentially overlapping/conflicting data, such as financial instrument data or corporation data, a few principles should be followed:

1. Preserve each source’s data intact: There are sometimes business reasons why an internal data consumer will need the data coming from just one source. Make sure your MDM system can faithfully deliver exactly that data.
2. Support multiple blended versions: When supposedly the same data is supplied by multiple sources, build an MDM system that can maintain different blends of attributes from the various sources according to different rules, because you’ll have internal customers needing different blends.

Additional Thoughts

Don’t centralize all MDM. It should be apparent from the above that different types of master data require different management styles. There is therefore little advantage in managing all master data at a single point. Instead, there should be an MDM system for each style of data management needed.

Preserve history at the source. In the olden days, the job of maintaining master data history was delegated to the data warehouse, either because master data systems forgot to include history in their requirements, or because they couldn’t handle the performance requirements of maintaining both current and past data. The performance problem is gone. The history of any data is best maintained along with the current data. Then, the whole world, not just the warehouse, has access to historical data.

Have a data distribution strategy. It’s one thing to have a great MDM system; it’s another to make that data available to the systems that need it. Don’t tie yourself to a single data distribution mechanism (which, oddly, is usually chosen as the most fashionable API of the moment and is decidedly old-fashioned five years later). Instead, have an architecture that fully supports everything from REST to pub/sub to ODBC/JDBC to batch file.

Vendors? Vendors are a mixed blessing. Remember that they always have a great value proposition—for themselves. Before you make the build/buy decision or choose a vendor, make sure you have a highly skilled data architect on staff who can identify, document, and get agreement on requirements and the data model, and who can then ensure that the implementation, whether in-sourced or out-sourced, delivers the anticipated business value.