Buyer’s Guide: Choosing and understanding MDM software

Master data management (MDM) projects can be large, complicated and expensive, which makes choosing the right MDM software imperative for deployment success. This guide provides an overview of MDM concepts and technology as well as expert advice on choosing MDM software that meets an organization’s IT and business requirements. Readers will also learn how to sell the benefits of MDM to corporate executives and get tips on evaluating MDM vendors and avoiding the “drama” of complex MDM initiatives.

In this portion of the MDM Buyer's Guide, consultant David Loshin explains master data management concepts and provides tips for starting your MDM software selection process.

MDM Buyer's Guide Table of Contents:
Choosing MDM software and understanding master data management
Focus on business benefits to sell MDM to executives
Evaluating and selecting an MDM vendor
As MDM project deployments grow more complex, ‘drama’ could follow
MDM building blocks from Gartner – governance, metrics key to success 

Choosing MDM software and understanding master data management
By David Loshin, SearchDataManagement.com contributor

What we refer to as the “enterprise” is often composed of many applications referring to multiple, sometimes disparate sets of data that are intended to represent the same, or similar, business concepts. And although in many organizations the administrative control of data is still aligned with operational business applications, there is a growing desire to consolidate common data concepts, subject that data to analysis and ultimately turn it into actionable knowledge to benefit the common good. 

In order to exploit that information for both operational and analytical processes, an organization must be able to clearly define those business concepts, identify the different ways that data sets represent those concepts, integrate that data and then make it available across the organization. That need has introduced an opportunity for organizational information integration, management and sharing, thereby creating a truly integrated enterprise. And this is the challenge of what is known as master data management (MDM): integrating tools, people and practices to organize an enterprise view of the organization’s key business information objects, and to govern their quality, use and synchronization and use that unified view of the information to achieve the organization’s business objectives.

Understanding master data and master data management
If (either deliberate or inadvertent) replication of these “key business information objects” impedes the achievement of organizational business objectives, then creating a unified view of “master data” will reduce barriers to success. We can define master data as the key business information objects used in the different applications across the organization, along with their associated metadata, attributes, definitions, roles, connections and taxonomies. Typical examples of master data include Customers, Suppliers, Parts, Products, Employees and Locations. 

In turn, MDM uses business applications, information management methods and data management tools to implement the policies, procedures and infrastructure that support capturing, integrating and sharing the use of accurate, timely, consistent and complete master data. 

In essence, MDM should give users the ability to uniquely identify representations about each master data entity across the infrastructure.

MDM technical capabilities
Launching a comprehensive MDM project or program, by virtue of its position as an enterprise application, requires coordination and planning in addition to technology acquisition. When your organization is at the point where critical stakeholders are aligned and prepared to commit to implementing MDM, it is valuable to know what goes into an MDM project in order to assess organizational business needs and appropriately evaluate vendor offerings.

To create a unified view of master data, the MDM platform must have an index or database of each unique entity to be managed. There are several deployment methods. On one side of the spectrum is the “registry,” which is a very thin index that only contains enough information to differentiate between unique entities while maintaining links to all managed data instances of each unique identity. The other side of the spectrum is the “transaction hub,” which is a single consolidated database containing all attributes associated with each entity. Variation in the degree of attribution managed within the implementation of a master data environment along that spectrum is determined by the organization’s business application operational and analytical business application requirements and corresponding need for synchronization.

Layered on top of the core repository, no matter how it is implemented, are additional components and services. We can group MDM technical capabilities into seven general infrastructure and service areas, as shown in Figure 1:

1. Core master data hub
2. Data integration and consolidation
3. Master data services
4. Integration and delivery
5. Access control
6. Synchronization
7. Operations and data governance

Different organizations’ scenarios for using master data may reflect different underlying requirements, which may or may not be met by a single MDM vendor.

Core master data hub
The master data hub combines the infrastructure supporting the unified data models, metadata management, reference data management and business rules management. The MDM architecture enables the instantiation of the selected implementation model (e.g., registry vs. transaction hub) upon which the models for each master data concept will be deployed. Some vendor products come packaged with data models that can be extended; other vendors expect the implementers to integrate their own models within the architecture.

Because of the variant syntax (structure and semantics associated with the distributed source data sets), a critical component is metadata management, including data element catalogs with business definitions, data structure and type specifications, as well as a catalog of master reference data concepts and corresponding enumerated value domains, such as country or currency codes. In addition, data hierarchies (such as regions, organization structures, cost centers and product categories) are managed as master data for both transactional and analytical applications. Likewise, business rules that are applied in different applications not only govern the consistency and completeness of master data, the rules themselves are potentially replicated and therefore are subject to mastering.

Data integration and consolidation
Two aspects of MDM are critical when it comes to the data managed inside the master data hub: getting the data into the hub and getting the data out of the hub. The first part requires data integration and data quality components, such as connectors to different source data systems, data transformation, data quality validation, parsing and standardization, data cleansing and loading. Some vendors bundle their MDM platforms with data integration and data quality/cleansing capabilities, while other vendors have partnership arrangements to provide these functions.

Master data services
The second part, getting the data out of the hub, relies on data delivery services. At the basic level, standard data object lifecycle services are implemented, such as “create a customer record” or “update product price.” For each modeled master object, basic master data services can be configured to create, read, update and delete—either the object itself or its associated attributes. MDM products may provide either a service library or the means for creating master data services as master object models are integrated or enhanced.

Integration and delivery
The delivery of information builds on the core master data services. The way we view it in Figure 1, delivery focuses on adding value to the business services, allowing you to reduce replication of common functions implemented multiple times across different applications (such as “create a new customer account” or “look up product”). In turn, these basic business services can provide more complex business services, implemented once and used multiple times. Creating a standardized interface will also help in transitioning existing applications to use the master data system by facilitating application interoperability.

Access control
While not typically seen as a value added component of an MDM product per se, access control is nonetheless necessary as the unified master data objects are exposed to a greater spectrum of applications (and corresponding users).

Synchronization
Across the implementation spectrum (from registry to transaction hub), there are different requirements for synchronizing data from the numerous source data systems. For reporting purposes, a daily synchronization may be sufficient, while certain operational activities may demand immediate coherence across all views of master data. Every MDM vendor should be able to describe how its product synchronizes data across the enterprise and show how to adjust the frequency and monitor the guarantees of consistency.

Operations and data governance
Not only must the quality of the data be continuously monitored to verify acceptability, there must be operational governance and stewardship services in place to support the inspection, root cause analysis, correction of data and propagation of corrections across the master data environment, as well as data quality and data governance reporting. Note that the inspection of data quality issues will be closely tied to the data quality capabilities of the data integration layers and to the business rules managed within the master data hub.

What to look for in a master data management platform
When evaluating and selecting MDM software, look for the following core functionalities:

1. Identity resolution: Since the objective is to provide a unified view of each master data concept, an MDM product must either provide identity resolution and matching as a built-in component or as an add-on from another vendor.
2. Core data models: Some standard similarities can be encapsulated into a template model that can be adjusted to meet customer needs. Same goes for other standard data concepts, like product, agreement, account (as in chart of accounts) and so on.
3. Data services: In relation to the core models, the product should suggest or provide a library of services used to create, modify and retire instances of master data objects.
4. Hub management functionality: If the MDM tool is used to collect and consolidate a single copy of master data objects, there must be a systemic capability to instantiate and manage that master database.
5. Data governance utilities: If issues are identified, usually because of a false positive merge or a false negative non-merge, there should be an interface to allow for manual remediation (either unlinking a merged record into its original constituents or linking two records that the tool may have missed).
6. Data federation: To support synchronization with application replicas or to capture and communicate updates, some data federation functionality (e.g., change data capture and message queues) should support observance of the specified expectation for coherence.
7. Data integration: The product should include tools with extract, transform and load capabilities
8. Standardization and enhancement: When merging records together, these capabilities, which are often part of a data quality suite, will help reduce variance and improve matching and linking.
9. Data profiling: While technically this is often a standalone component, its use for assessment of quality and for metadata discovery makes it indispensible, and some MDM tool vendors either bundle it or offer it as a separate product.

Summary
Transitioning to a master data management program is a strategic decision that’s intended to modernize and simplify the horizontal integration of enterprise business applications while providing data consistency and predictability. Organizations that want to succeed in building their master data environment must consider how their business processes intersect with their information needs and assess their information requirements before selecting a tool. Because of the complexity involved in transitioning to MDM, identifying key business drivers and their technical needs informs the technology selection process and enables a modern, staged implementation. As the MDM vendor market continues to mature, look for improvements in integration, development, deployment and especially governance capabilities for a successful implementation.

About the author: David Loshin is a recognized thought leader and expert consultant in the areas of data governance, data quality methods, tools, and techniques, master data management and business intelligence. David is a prolific author regarding BI best practices, via his BeyeNetwork expert channel and numerous books on BI and data quality. His book, Master Data Management, has been endorsed by data management industry leaders, and his MDM insights can be reviewed at www.mdmbook.com. David can be reached at [email protected], or 301-754-6350.

MDM Buyer's Guide Table of Contents:
Choosing MDM software and understanding master data management
Focus on business benefits to sell MDM to executives
Evaluating and selecting an MDM vendor
As MDM project deployments grow more complex, ‘drama’ could follow
MDM building blocks from Gartner – governance, metrics key to success