Mastering Data Management

More in MDM

• Best Practices in Test Data Management: Discovering and Subsetting
• TDWI Chicago Preview: Data Warehousing, Analytics & More
• Who’s Afraid of the Big Bad Data?
• MDM for Chief Privacy Officers: A healthcare provider example

Share this Post

Recent Comments

• ICMCC News Page » Where East Meets West: ehealth in China and the US on Where East Meets West: ehealth in China and the US
• Kim’s Training Podcast on Training as a Safety Net: Kim May
• TDWI Chicago Preview: Data Warehousing, Analytics & More | Mastering Data Management on New ebook: Understanding Big Data

MDM is a journey, not a destination. Brian explains the most common routes.

I often get asked, “Where do I start with MDM and where is the ‘end’?” My answer is that MDM is not a destination, but a journey.

MDM journeys usually begin with solving one business problem and then extend to additional challenges. For instance, an organization trying to improve customer loyalty would like customer service representatives to have a complete view of the customer when they engage in conversations with customers.

After solving this challenge, many of our customers pivot to business problem number two. This may be complementary, such as trying to improve cross-selling opportunities, or a brand new challenge, such as reducing costs and time to market.

MDM journeys often begin with a small amount of data and grow. Many customers begin with a subset of all planned data for an initial phase. This may consist of a handful of source or consuming systems.  Over time, additional sources and consuming systems are added. IBM has several clients that have grown to over 100 total systems interacting with their MDM hub.

Another MDM journey centers on organizational ownership. I have several customers that have started with a regional hub for phase one (for example, North America), and have extended in future phases to other geographies or enterprise wide.

Yet another MDM journey revolves around data domain. Often, customers will start with one domain (e.g. customer) and extend to other domains (e.g organization, product, etc). We have seen an increasing trend of customers mastering data across more than one domain.

One last journey that I would like to mention is changing who owns the MDM data. This is often called implementation styles. This is less frequent than the other journeys, but I am often asked, “How do I move from one style to another?”  Typically this means moving from sources owning the data (registry style) to the hub owning the data (transactional style). There are many legitimate business reasons for changing data ownership. Interestingly enough, for a majority of customers, the best next step is to extend their current style.

Business Value and ROI of the MDM Journey

Here are our best practices:

End state: Often, the ideal end state is to have both virtual and physical style side-by-side. This is best suited for two use cases.

Co-existence: We have a number of customers that are trying to master the individual domain. They have prospects with sparse data (often not a lot of data filled in) and customer data with many required fields. In this example, a co-existence style with prospects in a virtual style and a physical style with customer data would be ideal.

Hub-of-Hubs: Many customers have separate divisions with different data policies. They would like to keep these hubs separate and include a new enterprise-wide hub that can consolidate information from each division. We call this a hub-of-hubs. The most deployed style for hub-of-hubs is virtual, where the divisional hubs can be either virtual or physical.

Sunset: In some cases it is best to move entirely from virtual to physical.

In any of these use cases, there are significant savings starting with a small phase one and moving to phase two. There are significant leveraging (savings) in most delivery phases with various IBM tools and best practices.

These are several of our best practices. We would love to hear your feedback below.

My colleagues are publishing several blog posts to give you more details on some of the features and use cases for InfoSphere MDM v10. See the list of posts and topics.