THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

CDI and MDM are Broken, Part 1

Published: October 1, 2007

This article examines the current state of solutions for the rapidly growing area of CDI and MDM. He sets the stage for a different way of looking at the problem with emerging technologies that hold the promise of reducing complexity and implementation co

Some of the brightest, most forward-thinking minds in the data management industry, along with several of its largest and well-known vendors, converged at the Spring 2007 CDI/MDM Summit in San Francisco in late March. I attended with high hopes of finding some clues to the future of this important data administration subject area.

I discovered that the customer data integration/master data management discipline as it stands now is broken.

Well, I should restate that. The discipline itself isn’t broken; the approaches of the major vendors are predominantly dead on arrival. This is particularly troublesome because customer data integration (CDI) and master data management MDM are relatively young specialties and therefore run the risk of being branded as too expensive and complex to implement.

In my opinion, it doesn’t have to be this way.

The CDI/MDM discipline is alive and well, and extremely necessary in this age of acquisitions and expansion. A tremendous amount of shareholder value can be gained in the proper integration of base information in an enterprise, especially customer data. Likewise, as the mergers and expansion of the 1990s have not been digested completely by the surviving corporations, another opportunity for efficiency gains exists. What’s more, governments eager to protect their populations from terrorist attack in our post-9/11 world can use CDI/MDM techniques effectively.

There might never have been a greater need for skilled practitioners and strong tools in this area.

The major database and business intelligence vendors are not blind to this need. In fact, several of the largest have developed and marketed complete suites to address the issue, such as Oracle’s Customer Data Hub, IBM’s Information Server, and Business Objects’ Enterprise Information Management suite. Unfortunately, the offerings they have developed suffer from several fundamental flaws:

• In many ways, they are “just another system,” with the attendant expense in both procurement and implementation.
  
  
• The products (naturally) work best in a homogenous environment, ignoring the reality of heterogeneous computing environments in most organizations.
  
  
• The vendors’ case studies and “customer success stories” present a false picture of the effectiveness of the products since the scope of the projects described is so small as to be insignificant compared to the size of the CDI or MDM solution space in most organizations.

These flaws, among others, should make even the most adventurous CIO apprehensive to implement one of these solutions, especially in this era of generally tight operating budgets for business support functions.

One More System

I sat through several product demonstrations, including sessions from some of the largest enterprise application vendors such as Oracle, Business Objects, and SAP. Each had a compelling business case regarding theory and methodology for solving the CDI/MDM problem that many organizations face.

Put simply, several systems house base business data such as customers, products and orders; and, as a consequence, these data are disjointed and inefficient to retrieve as a coherent whole. Often it is not practical to select only one of these systems to perform standardization across the enterprise due to political and/or logistical issues. So, a centralized database system often is seen as the best answer to manage master data in the enterprise. That’s how these vendors approach the issue.

These systems share some common characteristics:

• High expense. The server infrastructure and license fees for these solutions are quite large, often totaling millions of dollars, with tens of thousands of dollars in yearly maintenance fees.
  
  
• Complexity. To their credit, these systems use many of the new technologies that are revolutionizing the IT industry, such as web services and service-oriented architectures(SOAs). This results in a tremendously complex system, adding to the existing complexity in many organizations.
  
  
• Staffing difficulty. The new technologies virtually guarantee that an organization’s existing staff will not have the skills required to implement and maintain the system. This means increased expense for consulting resources, which makes the solution even less attractive from a budgetary standpoint. (Note: Yes, I am a consultant, but I believe that if you save money for your clients, they’re more likely to give you return business.)

Perhaps it’s a personal bias, but I believe that PowerPoint slides shown at vendor demonstrations are directly proportional to the complexity of the solution. Here is an example of the PowerPoint presentation to illustrate the point, from Oracle:

Figure 1: Example (from Oracle Master Data Management Overview, Copyright © 2007, Oracle Corporation)

 

As you can see, the complexity of this solution is daunting. The shrewd CIO likely would not introduce this type of complexity into an environment without a large, highly talented technical workforce in place. If I were a CIO at a sales meeting for this solution, I would reassess the difficulty of naming one of my current applications as the master data repository.

Homogenous Solutions

This should come as no surprise, but the major vendors selling solutions for CDI/MDM have a great affinity for their other products. Their solutions have native connectors to their CRM, supply chain, human resources, and financials products that operate in a “plug-and-play” fashion. (Well, not really. If you’ve made customizations, you’ll have to account for those – but this is not the place to burst that particular bubble.) Therefore, as the pitch continues, if a customer wants to save money and time in implementation, the customer must standardize on the vendor’s other solutions.

Few organizations are in this position, from both the application and customization standpoints. Again, no surprise. Aside from the extremely well funded startup, most organizations operate a mishmash of platforms, architectures and toolsets. No singular cause can be blamed for this mixture of solutions. Politics, organizational structure, budgetary patterns, and the ever-changing technology landscape each play a role.

Given this reality, advocating a homogenous approach to such a large issue would seem to be self-defeating. A better solution would be to acknowledge this reality and work in support of it.

Case Studies

Vendor websites usually have customer success stories that demonstrate the effectiveness of the vendor’s solution set. These testimonials generally are high level, with standard buzzwords such as “integrated,” “standardized,” and “single source of truth.”

However, if you pull the covers back a little bit, you’ll usually find that the scope of the solution has been pared back to a small subset of the overall universe to ensure a successful outcome.

This is not terribly surprising from the vendor or customer perspective ­ no one wants to report difficulty, complexity or dissatisfaction. However, the usefulness of such success stories is questionable to someone evaluating the tool for applicability to a given problem scope, and ultimately counterproductive to the vendor because it breeds distrust and frustration on the part of subsequent customers.

It Doesn’t Have to Be This Way

For those of you who made it this far, thanks for being patient with me. I don’t enjoy being negative, especially in regard to established, successful companies staffed with dedicated, brilliant people. However, I think a better way exists to address this particular situation.

I have spent the better part of my career in consulting and implementation, convincing clients to adapt their business processes to a given technology solution. I’m becoming more and more convinced that this approach will not be effective in the CDI/MDM space. Far too many data input sources of different formats exist to keep track of. Any system built to accept specific inputs is unlikely to be flexible enough to assimilate data in new formats effectively.

What is needed is a system for passively cataloging and organizing a company’s information assets that is as flexible as possible but also robust enough to provide value to the constituent systems and end users.

Fortunately, technology is emerging that may provide a method for doing just that, using such terms as “semantics,” “ontologies,” and “taxonomies.” David Hay has done a great job in the pages of TDAN of describing the technical details of how a semantic system operates. I won’t repeat that here, but I will suggest that this technology holds great promise in solving the issues presented earlier:

• The system likely would not have a high expense, either in infrastructure or support. It can be housed in a series of text files at a minimum, or in several leading database products.
  
  
• The system would be vendor-agnostic since it would not require a host of supporting systems to attain maximum functionality.
  
  
• The system would be maintained easily by technical resources with object-oriented skills. There would be less of a requirement for specific skills such as Java or Microsoft.Net.

There is one problem, however. (Isn’t there always?) To my knowledge, such a system does not yet exist. In our next installment, we’ll discuss the design considerations for such a system.