Cloudy Skies ahead: MDM as a Service

Much like the rest of the IT industry, it's inevitable that MDM as a service will emerge. There are several practical applications of MDM as a service, for both analytical and operational purposes.

Operational
There are many practical times where master data is required to support certain activities on the web. Perfect example - when a user registers for an online publication, many times the company would like to capture the organization that employs the person. This is a standard requirement for any registration process, but oftentimes the existing state of firm-level data does not yield a tidy view of a single organization, given the varieties of aliases used to identify even the largest organization. GE = Gen Electric = General Electric. As a result, most often the individual user registers with a free-form representation of the company name, which produces a hit or miss to the actual firm on the backend of the customer master. This simply compounds the problem.

What if a data provider that is a trusted source of firmographic data exposes a web service which would allow websites to access their data at the time users registers? Much like the process of registering for Linkedin, expect the data is provided by an external source. Of course there would be a cost for this feature, but in return you get the quality firmographic data you need to tie the user to the organization, as well as lower software development, testing, and maintenance costs. There may be further mappings down the road, but you know that the range of assignments would be valid from the time of registration, allowing a company to identify their customer at a firm and contact level, which is a key objective of any CDI initiative.

Of course the data provider delivering this service could be an established industry leader such as Dun & Bradstreet, or Acxiom. But then again, it could be a leader in professional networking such as the aforementioned Linkedin. There is a tremendous amount of firmographic data in Linkedin that serves as a trusted source of firm-level data for millions of professionals across a wide array of industries. For those of us networking on Linkedin, I trust the contact and the organization data in Linkedin because frankly the reputations of us all are on display so we project the most complete and accurate view for the rest of our colleagues to see. Therefore Linkedin has tremendous credibility from a data perspective. Moreover, such a service extends Linkedin's revenue originating from this new CDI as a service offering.

Obviously this CDI as a service would not apply to account level or contract level MDM, but I think it is safe to say that getting that firm-level view established with appropriate linkage to underlying contacts is an enormous step on the path to advanced CDI capabilities.

Analytical
I personally know of projects where data providers offer reporting as a service, based on established industry standard data sets. At a high level, companies push their data sets to the service provider in a standard format, and the data is integrated, associated, and aggregated for sales and marketing analysis. Based on Web 2.0 technologies, the users can customize the reports, adding widgets as needed.

Beyond data providers with private cloud offerings, the large vendors are inching their way to more advanced analytics with offerings in public and private clouds. Teradata has outlined their move into the cloud, IBM is heading there as well.

Information Management Article

Another article I authored for Information Management Online addressing a completely different topic:

http://www.information-management.com/issues/2007_52/10002009-1.html

BI Journal Article on Data Quality

For TDWI members, check out an article I wrote on the elements of a successful Data Quality program.

http://www.tdwi.org/Publications/BIJournal/display.aspx?ID=9247

Here is the abstract:

Most organizations that have addressed application and data integration have also launched data quality campaigns to meet the challenges head-on. These campaigns can include any combination of four elements to achieve data quality improvements: processes, technology, overnance, and people.

In building and growing data quality programs, the first order of business is to establish a framework that promotes data quality from the top levels of the organization. It is important to administer this framework centrally because the four elements are integrated yet independent. The integration between the four elements ensures that a data quality safety net is cast across multiple projects, providing continuity as well as alignment with strategic business objectives. The independence promotes data improvements through ground-level activities within each element.

Establishing these four elements ensures a sturdy platform
that will support data quality initiatives throughout the enterprise. This article provides practical examples that illustrate how to independently grow these elements and integrate them into a complete data quality framework.

MDmM - Master Data micro-Management (Part 2 of 2)

Now that I have characterized Master Data Management on a small scale as Master Data micro-Management, and having placed some guidelines for attributes that are candidates for MDmM, let’s explore some real-world examples that should bring the discussion down to earth:

Example 1 – Account-holder Status

I was involved with a large MDM initiative, motivated by SOX-compliance, which was focused on account-holder information. The overall project was scoped to support <20 attributes across 6 systems, but one attribute was so significant that we had to define a mini-release to deliver a consistent view of the attribute across all systems to support new functionality for the web. This attribute, the account holder’s status, fits the criteria above. It is tightly-bound in that each system had 2-5 values when defining the status. These values could easily be derived from the domain values into the enterprise standard. The definition of each attribute was clear and unambiguous. Finally the account holder status was crucial to each operational status – from card-generation, to benefits management – every business process must be status-aware to function properly.

Example 2 – Product Description

I deliberately choose this attribute to generate discussion and debate – it also crosses into a different subject area (product). Product description is not as clear-cut as account-holder status. It is not tightly-bound (it’s free-form), which is actually part of the issue. Thus, finding a consistent product description across systems is a challenge. A product description may not always be well-defined. Is the description used for labeling, if so on a package or a shelf? However, the product description is a business-essential attribute – it is used in searches, sorting, user and customer display (in-store, web), which makes me ask the question could it be easily derived (i.e. having a “description-builder” that concatenates the product name, manufacturer, and product dimensions)? This is when the debate escalates – how can you have a derived description without standardizing the product names or manufacturer? Can you rely on product dimensions – are these the dimensions from the manufacturer or from the system?

Those who have implemented a PIM recognize these complexities. I believe that this derived product description could hold value to the business and could be easily derived and therefore is a candidate for MDmM. However, my confidence level is higher when it comes to account-holder status based on theory (since it meets all of the MDmM guidelines), and I have seen this in practice on a project. Alas I never saw the product description work in practice.

The concept of MDmM is deliberately limited to attributes that meet the criteria and would not be suited for more complex MDM domains, such as hierarchies. It also requires a pragmatic approach for choosing the enabling technologies during implementation. However, MDmM can deliver value to the business in less time then it takes to launch a full-blown MDM effort, and therefore helps to build a strong case for the investment required of larger-scale MDM initiatives.

MDmM - Master Data micro-Management (Part 1 of 2)

The tip of the MDM iceberg can intimidate the most experienced captain. One way to break the proverbial MDM ice is to start with a single attribute so that the business problem can be solved incrementally. Addressing a single attribute (or attribute group) through MDM principles and best practices can be thought of as Master Data micro-Management (MDmM).


A typical master data management initiative requires significant investment before an implementation that delivers business value is realized. A MDM initiative requires a serious commitment so that data standards can be defined and systematically enforced at an enterprise level for an entire subject area, such as customer or product. Although the scope of MDM is constrained by information shared by systems across the enterprise and therefore is a subset of the complete universe of attributes for customer, product, et al., the overall effort is increased by the number of participating systems and the complexity of the integration.


Facing the daunting aspects of full-scale MDM, you probably have implemented a MDmM solution and you know that a critical success factor to MDmM is determining what attribute is suited for a small-scale MDM implementation. To help guide the discussion, let’s start with establishing criteria for identifying MDmM attributes:

• The attribute must be tightly-bound. An attribute is tightly-bound when its domain values are limited (ideally <=5).
• The attribute must be easily-derived. An attribute is easily derived if it can be transformed with minimal complexity into a defined standard.
• The attribute must be well-defined. An attribute is well-defined when you can look at the column name and immediately recognize what the information represents. This is an exaggeration of course, but you shouldn’t have to dig for the dead-sea scrolls to determine the true meaning of the attribute.
• The attribute must be business-essential. Saving the best for last, an attribute is business-essential when the absence of the attribute within the scope of a process causes failures, unhandled events, or non-compliance.
  

Like all MDM standards, MDmM guidelines are open to amendment and interpretation, but in the next installation of this topic, we will explore two attributes (account-holder status and product description) that should illustrate the concept.