Mastering Data Management

More in Business Process Management

• Improving Business Processes with MDM
• Mobility: Inventing the New Division of Labor
• Take Charge of your Data Environment: IBM Performance Management Solutions
• Top 5 InfoSphere Demos at IOD

More in MDM

• Top Books for your MDM Library
• Recent Reads: MDM & Data Governance
• Big Data Governance: A Framework
• Predictive Data Governance for Business Transformation

More from Lawrence Dubov

• MDM Vs Data Governance: History and 8 Predictions
• What’s Harder: Starting or Sustaining MDM?
• Conclusion: Quantifying Assets
• 3 Essential Questions for Data Quality: Benchmarks, Penalties & Latency

Share this Post

Recent Comments

• Lorraine Fernandes on Response: A Universal Identifier Isn’t a Silver Bullet
• Henrik Liliendahl Sørensen on Response: A Universal Identifier Isn’t a Silver Bullet
• Response: A Universal Identifier Isn’t a Silver Bullet | Mastering Data Management on 3 Best Practices in Identity Management

Initiate's Larry Dubov explores the 3 keys of data for MDM success

As we continue on our MDM roadmap journey, it’s time to consider some of the most important facets of data: data domains, entities and high-level data models. To succeed with MDM, you must grasp how the three work together, especially as you explore more complex architectures.

While early MDM implementations were primarily focused on a single MDM domain, such as Customer or Product, the current trend is shifting to multidomain MDM solutions. Thus, the majority of recent and current MDM implementations have a multidomain perspective even though the initial phase often concentrates on a single domain. (My colleague Marty Moseley recently wrote a series on the basics of multidomain MDM.)

An MDM team that approaches MDM with a multidomain perspective must make sure that the MDM product they select can actually handle multiple domains. An efficient way of doing this is to select an MDM product with a data model and services that are domain-agnostic.

Standardization of systems’ on-boarding procedures will help here, too. This standardization approach will help constrain the costs of future phases as new data domains are included in the MDM scope. This can make investments in integrating new data domains lower than the costs of the first MDM data domain.

When evaluating the complexity and potential cost of the implementation itself, you must also understand the intricacies of the key data domains. A master data model can greatly help you understand the level of MDM complexity.

Even when an MDM solution is being implemented for just a single domain (such as customer), the overall party model can be fairly complex and consist of 20-30 entities in the 3NF representation.

As you introduce multiple entity definitions (customer, client, partner, etc) that must coexist, the model’s complexity grows. More specifically, it is not unusual for an enterprise to have 10-15 definitions of a customer that depend on the context, department or function. Each definition has its own value and purpose within the organization.

For instance the term “customer” can apply to an individual, household (that can be defined in multiple ways), trust, fund or a commercial institution. For shipments, the intersection of a customer and location can represent a definition of a customer. Marketing, billing and compliance departments can have very different definitions of a customer.

By combining these varied customer views, the result is a complex party model. A master model that is readily available and reasonably complete can help reduce uncertainties in planning and cost estimations.

Still, the change in scope between a single entity with twenty attributes that later unexpectedly evolves into a relatively complex data model with 20-30 entities and many hundreds of attributes can impact the accuracy of planning, resources, and the cost estimates. The size and maturity of the MDM data model are important for planning an effective MDM solution.

Next week, we’ll move on to two more important domains: Relationships & Hierarchies and Third-Party Data Sources.

This is part of a series, Building an MDM Roadmap. For other posts and a complete index, view the Table of Contents.