TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

MDM: Keep Your Eyes on the Business Problem

The impetus for MDM should come from within and be shared by all of the lines of business. There must be a consensus that there's a business problem and that MDM is the solution.

• By Steve Swoyer
• May 5, 2016

You don't just go out and buy master data management (MDM). To be sure, you can buy any number of MDM technology solutions. You can also buy services expertise to help you develop and implement a technology-centered MDM program.

You can even "buy" buy-in from business executives and other critical stakeholders. Software vendors and services providers will happily sell you MDM-themed products, and MDM is something executives can easily get behind.

The impetus for MDM should come from within. It must also be shared by all of the lines of business. There must be a consensus: first, that there's a problem and that MDM is the solution; second, that the problem in question is primarily a business problem and not a technological one; third, that any MDM program must be treated and managed as a business solution.

"In a lot of [engagements], customers will start off by saying to us, 'We have an MDM problem,' but then they'll talk about it in technical terms. When you ask them questions about it, there's no real sense of the business problem," said Matt Dahlman, vice president of North American operations with MDM specialist Semarchy. "The business focus gets lost as you have the discussion until someone gets the idea that 'We need MDM technology.' They're right, but not for the right reasons."

Keeping the focus on MDM as a business problem is also critical because of a phenomenon that might be called MDM Mission Creep. Simply put, because MDM is so hard and, more precisely, so hard to see through, there's a tendency for MDM programs to go off track.

Even though MDM begins with consensus, it must in most cases be carried out by fiat: changing processes, changing perquisites, and changing IT systems means changing the routines and conventions to which people are accustomed. These are routines and conventions that are bound up with power, prestige, and identity.

This is a situation that's intuitively familiar to anyone who's ever been caught in a melee between two business units duking it out over the master definition of "customer." Pushing and advocating for change of this kind can be hard, dispiriting work.

That's why the promise of easy, plausible fixes or escapes -- e.g., MDM technologies that permit individual business units to retain their favored canonical terms or multi-domain MDM technologies that support product, customer, finance, and other kinds of MDM initiatives -- can seem so tempting.

It isn't that these technologies are "wrong" or unsuitable. They might, in fact, be just the ticket. As Semarchy's Dahlman puts it, they're the right solutions, they're just selected for the wrong reasons.

In a sense, to reframe MDM as a technology problem is to take one's foot off the gas pedal. It's to declare "Mission Accomplished!" even though the hard work of nation-rebuilding remains to be done. Put another way, it's to tell yourself you aren't moving the goalposts -- i.e., changing the victory conditions -- even as, at some level, you know that's precisely what you're doing.

MDM from the Bottom Up and Inside Out

Part of the problem has to do with the dominant MDM paradigms, almost all of which attempt to impose a formal, top-down structure on a dynamic, living, and, above all, open system: the business itself. The business will change. The formal top-down structure that's imposed on it won't be able to change (organically, temporally, or spatially) with the business.

Certainly, key definitions -- customer, supplier, product, revenue, sale, shipment, etc. -- won't change, but the contexts -- the systems, processes, and local practices in which these definitions are embedded -- will change. Over time, the grid of the MDM overlay will correspond less with the underlying -- living, stochastic -- business reality.

This isn't an indictment of MDM as a whole. It's rather a rallying cry against top-down, totalitarian superimpositions. Almost all MDM products and services take the form of top-down superimpositions.

On the other hand, vendors such as Semarchy champion an agile approach that works inward from the periphery. This is somewhat like bottom-up, in that this approach aims to identify high-value use cases and then tries to target them tactically. In other words, this approach starts with projects (customer data in this business process) and attempts to build on that.

Whether we realize it or not, we're moving to a pragmatic model in which the "completeness" or "cleanliness" of data is determined by the purposes to which it will be put, not on the basis of formal abstractions, such as "100 percent clean" or "100 percent consistent."

What does 100 percent clean actually mean? Why does it matter? Does it have any significance outside of the use to which the data is put? No. Is this carte blanche to tolerate data quality issues that compromise (or sabotage) the efficacy of business operations? No. It's permission to recognize that for many business operations, data of inconsistent quality is actually okay.

Think of a large research university with half a million living alumni. Take a look at its data model -- at the attributes of the entity it defines as "alumnus." Imagine that the resulting data set is of poor quality: on average, the university might have 60-70 percent of the required attributes; in some cases, it might have only 30 percent. Does this matter? It depends on the purpose.

If you need to put together a phone list for students to badger alumni for donations over the January intermission, probably not. You're calling alumni and asking them for money. To do this, your students need a name and a telephone number. Alternately, if you're trying to come up with a model that scores an alumna's propensity to contribute after graduation, you don't need anything close to100 percent clean or 100 percent accurate data.

For these and other purposes, only a few key attributes matter. This use case also illustrates how a bottom-up, tactical approach to MDM might work, too: in placing calls to alumni, students discover that certain telephone numbers no longer work, or that a number does work but that an alumna has changed her address, that an alumnus is deceased, that an alumnus changed his name because he got married, and so on.

In short, your bottom-up student callers discover that you have data quality problems. It isn't and shouldn't be incumbent on them to fix this problem; on the other hand, this is a great, and also anticipatable, opportunity to identify and collect information that can be used to resolve data quality problems.

The simplicity of this example also shows how MDM can be framed as a business issue, not a technology problem. Getting consensus across the enterprise for a bottom-up approach to MDM focused on business problems may not be easy, but your final master data management program will be more effective over the long term as a result.