Master Data Management (MDM) is like Pepto-Bismol; it’s taken in repeated, fixed doses over time until the problem subsides.

Unlike Pepto-Bismol, however, MDM has no bismuth subsalicylate. This compound, when ingested and absorbed into the intestines, is metabolized into salicylic acid, which has the desired anti-inflammatory effect. Salicylic acid itself is a hydrolyzed derivative of aspirin (acetylsalicylic acid), which is derived from the bark of the willow tree.

Chemical engineers routinely assemble such compounds for an intended effect. They use metadata to describe the interaction of chemical elements. This metadata describes how molecular electron levels interact, what fits with what and what the result is.

You may be familiar with molecular model diagrams that show how different molecular structures interact. There are a finite number of these, and they describe the chemical compounds that often improve the quality of our lives. Chemists use a process to construct or deconstruct compounds based on patterns: the metadata, or reactive attributes of molecular structures, governs their thinking. But what do patterns of molecular interaction have to do with MDM?

Informal Networks and Relationships

A method of organizing data quality Web services as patterns was recently introduced.1 The data quality patterns method uses modular metadata descriptions of solutions to data quality problems. The form of that metadata consists of pattern name, problem description, context, solution and resulting context, at a minimum. Most of this information describes the solution itself. However, the solution itself is part of the pattern structure.

The reasoning behind this is that solutions to complex problems can be deconstructed into many solutions for smaller, constituent problems. The word “pattern” stems from the appearance of the resulting deconstruction – the metadata patterns form repeatable shapes and relationships that can form visual patterns (an idea that has its roots in architecture).

Another important consideration for this approach is that it helps people deal with complexity. Few things are as complex as managing large, disparate and heterogeneous data structures in midsized to large companies.

As discussed, most practitioners recommend that a MDM facility be built one step at a time. The reason for this is that bringing an external structure to a large mess of data is chiefly a political exercise, and it is difficult to manage many “political deals” at the same time.

Data administrators are primarily interested in maintaining their data stores. Their customers, internal or external, use databases to conduct business. This relationship of trust must be respected, because the business depends on informal organizations. An MDM initiative harbors the potential threat of changing the status quo of these relationships, which is a classic resistance-to-change problem.

A complaint that I often hear from mid-level and upper-level managers is about the repetitive work they have to do to compensate for poor data quality. Their staffers may have to spend a significant portion of their time manually sorting through data, such as mailing or customer lists, using desktop applications. Other complaints are about missing data that would allow them to improve their service to the paying customer or just plain improve efficiency. These complaints stem from current and past frustration – an inability to realize their vision. It is vital to understand that vision and get to the root causes of this kind of dissatisfaction.

At the same time, data administrators are providing a baseline service that runs the business, and they may or may not be aware of the dissatisfaction. They may have their hands full just managing what is running now, or they may be working as fast as they can - keeping all 10 of their fingers in the “operational dike.”

Resistance to change is significantly reduced when the participants in the change process are offered attractive and obviously beneficial alternatives to the status quo. Every negotiation to convert the use of an existing data structure to a revised MDM-based structure is built on making this benefit obvious - in return for accepting the change. This is political deal-making. How can MDM, a system that imposes rigor and discipline for the greater good, make itself more attractive than business as usual?

Patterns of Data Views

MDM systems tout the ability to provide a “single version of the truth.” This is an important step that must be performed in preparation for actually adding value. However, from a management viewpoint, merely pointing out the truth doesn’t pay the bills. Bringing to bear the operational consequences of accurate data does.

A pattern-based approach, implemented through a set of Web services, enables this transition. I call these “data view patterns.” MDM projects should have two broadly defined activity groups: one is the implementation of revised data structures – of which there are several forms - and the other is bringing the value created by this organization to bear on business processes. This can be done in the form of Web services patterns that allow managers to realize their visions.

Imagine a business operation that is able to identify small, modular information retrieval and process solutions, which can be assembled as needed to provide the information desired. This is a bit like a snap-together structure: the solution of the pattern is formed by Web services that return fixed or changing data views when invoked. Each pattern describes in detail what the service does, pre- and post-conditions of data, how often it can be used and any other relevant constraints. The actual structure of the underlying virtual machine is completely hidden. This is not unlike chemical engineering.

Patterns themselves do not enable accurate data, however. In fact, one of the major arguments of MDM vendors is that re-engineering the entire data structure of a large network is cost prohibitive in many ways. So the implementation of a referential data server must still be undertaken. The added benefit is that departments can now access information easily, in combinations that were not possible previously.

At the same time, accurate data does not immediately translate into improved business processes. This is done by providing the data views that the business needs. The good news is that the list of such needed views is not terribly long, and all the processes in a business share many of the same needs. This is a common attribute of patterns-based approaches to complex situations: simplification.

Repositioning the Repository

Data view patterns should be readily accessible, searchable, persistent and self explanatory. This can be delivered by registry/repository facilities that are offered by a variety of vendors. Universal Description, Discovery and Integration (UDDI) standards offer the ability to discover relevant Web services. And Web Services Description Language (WSDL) shows how Web services are used. However, business users will need additional descriptive data to make sure a particular data view meets their needs. For now, these interfaces are technical and are intended for use by developers, but progress is being made to make this more accessible for business users.

The very same platforms that deliver data view patterns to business users can deliver the necessary views to the MDM platform - whatever configuration is chosen. Data administrators love the idea of providing controlled, auditable and specific access to their data stores. Once the record/reference structure is determined, the process of deploying Web services that enable these specific transactions is straightforward, right along with their orchestration rules. This is a different, internal set of data view patterns. They are much more collaborative because different data administrators can see and understand how the whole fits together and what their rights and obligation in the scheme of things are.

Finally, embedded within patterns are facilities for use measurement and data quality. Data quality is not an add-on or some ad hoc, late night batch run that tries to clean up data. It is part and parcel of every access to data sources or the MDM hub itself. Measurement of not only quality but usage profiles of Web services is a boon to overall governance. System architects can now distinguish between patterns that are very popular and those that are not. 

Data view patterns make use of and enable the value created by MDM initiatives. Data view patterns expose record/reference structures in a UDDI compliant repository. In addition, they are associated with a variety of standardized textual metadata that enables the governance of reuse and modular assembly into hierarchical structures. They provide a method of creating value that can be seen as an attractive alternative to the status quo, enabling requisite organizational change. Lastly, data view patterns enable business managers to make use of the consolidated data reference structures created by an MDM hub.

So the next time you reach for the Pepto-Bismol while working on an MDM project, remember what makes it work: accessibility, simplicity and utility.

References:

1. Michael Overturf. “Patterns in Data Quality.” Group 1 Software Blog, July 7, 2008. http://blog.g1.com/Post/Patterns-in-Data-Quality.html

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access