02:27 PM

Three Guidelines For Implementing MDM

Let business drivers, data volatility and project scope determine your approach and deployment style for master data management.

When we look for common features across IT "killer apps" over the decades, there has been a consistent level of apathy toward data management. As a result, the quest for a single source of truth has been getting progressively more complicated.

The emergence of master data management (MDM) solutions represents the pendulum swinging in the other direction, bringing much-needed balance by focusing on the data problem. MDM is not for every enterprise, but for a broad spectrum of financial services, manufacturers, health care providers, retailers, government agencies and other organizations, it is an essential next step to driving growth, improving operational efficiency, and easing regulatory compliance.

Implementing MDM is easier said than done. Should it be collaborative, operational or analytic MDM? And should it be a registry-, coexistence- or transactional-style deployment?

This article presents three guidelines that will help you determine appropriate MDM methods of use, implementation styles and domain scope.

Data Goes Uncontrolled

Excluding the brief attention data management received from Object-Oriented Programming "data hiding" principles and from Services-Oriented Architecture (SOA) data services, data has largely been allowed to grow uncontrolled.

Mainframes had flat files, VSAMs, and many flavors of hierarchical/relational databases. The days of client/server computing were even more flexible and indulgent. They brought in 4GLs that made it easier to have surrogate line-of-business (LOB) databases and corporate distributed databases that weren’t always synchronized. Enterprise Resource Planning (ERP) packages placed even greater emphasis on process logic that was ready-made with built-in, and often vendor-controlled, data models. The best-of-breed approach of building process-rich systems with multiple ERP packages was a great recipe to let data conflicts grow between data models of different vendors and those belonging to custom, mission-critical transactional systems.

The current virtualization (server consolidation) and cloud computing trends make it easier to manage storage proliferation; but they also come with limitations of scope and additional complexities. These efforts don’t go beyond the issues of physical storage to look inside the complex world of data. In addition, they introduce the management challenges of synchronizing data across public and private clouds.

Apathy Towards Centralized Data
(click image for larger view)
Apathy Toward Centralized Data
The bottom line is that it has long been more convenient to have master data replicated across the enterprise, allowing it to reside with multiple business applications, than to design and implement centralized data hubs.

As shown in the timeline at right, our decades-long apathy toward centralized data and focus on infrastructure, process/business logic, and presentation layers has been hurting us whenever we try to get a hold of the fragmented view of business-critical master data. We keep finding that there is no easy way to get a unified view of the business when we try to promote growth through cross-selling and up-selling and when we try to extract business efficiencies from current operations. The adverse effects are felt the most in the customer and product data domains, but businesses have been feeling the same pinch in other critical areas, including partners/suppliers, contracts, locations/shipping and so on.

Enter MDM

MDM has been around for a while now, earnestly so for the last five or six years. The recent spate of consolidation in MDM, with IBM acquiring Initiate and Informatica acquiring Siperian, confirms market growth and also indicates a trend toward MDM as a multi-domain discipline. Early master data initiatives had a limited focus on customers (often called CDI, for Customer Data Integration) or products/services (often called PMI, for Product Management Information).

Given the pervasive nature of the data management problem that MDM tries to address, it would seem natural that most enterprises would automatically have an interest in applying MDM solutions. But MDM isn't really for everyone. First, MDM's appeal all depends on the complexity of the landscape of applications and how master data is strewn among them. Second, not every business can make a legitimate business case for using MDM to drive growth, operational efficiency, and ease of regulatory compliance.

Qualifying enterprises cross the spectrum of vertical industries, including financial services, chemicals, energy and natural resources, healthcare, automotive/manufacturing, retail and the public sector. Requirements revolve around customers/citizens/patients, suppliers, locations, products, pricing, contracts, assets and so on. In these and other verticals, companies that could benefit the most from MDM have a combination of the following requirements:

• Greater compliance and privacy obligations such as Sarbanes-Oxley (SOX), Basel II, Basel III and meaningful use
• Portfolios of broad, retail-oriented offerings that can benefit from cross/up sell.
• A complex supplier network that can benefit from a consolidated view of transactions
• Multiple data-entry and data-transfer channels that require a centralized data-quality and governance process, including activities related to data cleansing and authorization/validation
• A federated business services strategy based on SOA that demands a complementing data-services strategy using MDM.

An Enterprise MDM Approach

To align the approach, architecture, and design of MDM solutions to your business requirements, apply these three guidelines:

• The primary business drivers determine the methods of use
• The data volatility determines the implementation styles
• The scope determines the number of domains.


Collaborative MDM (CMDM) is aligned with the business process layer. It is used to manage entities whose attributes are owned and maintained by a diverse, yet interlinked, group of users. Although often associated with the product domain alone and deployed to track the evolution of products, from definition through engineering and market launch, CMDM can and should be used to manage the master data of other entities, such as customers, for the appropriate life cycle activities such as prospecting, acquisition, delivery, and support, etc.

Architecturally, CMDM needs the support of enabling technologies such as Business Process Management (BPM), workflow, role-based security, etc. It is through CMDM that new records of master data get created.

Operational MDM (OMDM) is more closely aligned with the services layer and works closely with the SOA stack. OMDM needs to be built to support core business systems as they handle transactions with customers, suppliers, etc. These transactions could be generated from any customer-facing business channel, such as interactive voice response (IVR), phones, Web, ATMs, RFID, and wired/unwired devices. OMDM supports access to master data for the purposes of validation, and incidental updates to master data attributes as necessary.

Analytical MDM (AMDM) works on the side, with business intelligence (BI) applications to push out changes related to master data integrity. It also receives summary level metrics from BI applications and to make them persistent in master data, as needed, to make certain key statistics available centrally. Entity (or Identity) analytics is a specialized area with AMDM that deals with customer/citizen background checks and name services.


The Registry Style is a rudimentary implementation style that is more concerned with managing the master data records, as opposed to managing a comprehensive set of all the related attributes. It provides read-only access to master data for the purposes of restoring uniqueness and validation.

There are two other styles where master data is more of a database with full support for all the attributes and differing approaches to data synchronization with the application systems. In a relatively non-volatile environment, the Coexistence Style (or Convergent consistency) will suffice to keep the master data refreshed periodically. In a real-time environment however, the Transaction Style (or Absolute consistency) is used. Needless to say, Transaction Style requires robust support for SOA, messaging, and transactional monitoring to ensure that the master data is always in sync with transactional systems.


MDM solutions have been steadily expanding beyond the traditional turf of customers and products. As the scope grows to include multiple domains, as listed earlier, the architecture needs to incorporate additional services such as identity analytics, event management, etc. and products which specialize in newer domains and niche verticals (support for 'patients' could be very different from support for generic 'customers,' for example).

Reference Architecture and Vendors

Although the influencing criteria listed above might appear like options to pick and choose among, realize that these represent a set of mutually inclusive technical requirements that need to be considered as a sum in determining the overall conceptual architecture for an MDM system.

MDM Meets Enterprise Architecture
(click image for larger view)
MDM Meets Enterprise Architecture
For example, operational MDM needed by the manufacturing division may be an immediate priority for an automotive OEM. But the solution may soon be required to support collaborative needs if the engineering division also jumps on the bandwagon. Likewise, a registry style of MDM might be a good place to start for a hospital that is interested in building a patient-master for operational needs; but it would have to move up to coexistence/transaction-style MDM to support compliance for regulations such as Meaningful Use.

MDM Vendors
(click image for larger view)
MDM Vendors
Click on the "Reference Architecture," above right, to see a holistic view that shows how MDM fits in with the key components of enterprise architecture. The table at left lists leading MDM vendors and details on their products and technologies.

The Future of MDM

Business expansion, the drive for efficiencies and compliance demands will continue to drive MDM growth. Multi-domain MDMs is definitely drawing interest from product and service providers.

By its very nature, MDM is a services-heavy deployment, and the projects tend to be multi-year, requiring a combination of upfront consulting (on data governance strategy) and architecture and downstream development services (involving data quality and integration services).

The optimization efforts that, for many years, have been slanted toward infrastructure, process logic, and user interfaces, have to be realigned. Renewed focus on data will restore much-needed balance. It's time to deliver on the promises of industrialized IT and to live up to the service-level agreements of IT as a Service. Not the least of these promises is access to a single source of truth. The road to get there goes through MDM.

Sreedhar Kajeepeta is Global VP & CTO of Technology Consulting Practices for the Global Business Solutions & Services division of CSC. He previously worked for Convansys (now merged with CSC), Cambridge Technology Partners, and Tata Consultancy Services. Write him at [email protected]

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Email This  | 
Print  | 
More Insights
Copyright © 2021 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service