In part 1 of this article (March 2008 DM Review), we discussed how master data management (MDM) has transcended IT infrastructure and has been embraced by executives as a bona fide business solution. This has driven the need for an MDM taxonomy via which both business and technical stakeholders can compare their companies’ current capabilities and evaluate their own functional requirements. Part 2 continues the description of the more complex levels of the MDM taxonomy, beginning with level 3.
MDM Level 3: Centralized Hub Processing
Centralized processing implies a common, purpose-built platform for MDM. This is where most companies discover that MDM challenges their incumbent IT architecture: they have lots of standalone platforms processing master data.
MDM level 2 centralizes data access and control across the various applications and systems that use data. This dramatically reduces the complexity of application data access, significantly simplifies the management and administration of data-oriented rules, and enables many more functions and features than in a decentralized environment.
The challenge with enterprise master data is its consistency. Data exists in different places, its meanings are different and the rules about the data vary from system to system. Centralized MDM processing - via a common platform known as a hub - indicates an awareness that the integration of subject area data from multiple systems means centralizing and standardizing the methods to convert heterogeneous operational data, regardless of its system of origin, and to integrate it. At MDM level 3, companies are centralizing the management of subject area content. This implies that the applications that “consume” or use master data have an awareness that the data is a reflection of subject area content outside of the bounds of their individual application. MDM level 3 supports the existence of distributed master reference data.
One of the keys to MDM is ensuring that all systems understand the single accepted method for data representation. It’s a bit like language translation: English has become a global language through which other languages are translated. At MDM level 3, a company can make any two systems share data and speak each other’s language.
MDM level 3 also removes the complexity of peer-to-peer connectivity. The consuming application no longer needs to support system location and navigation logic. Any distributed details associated with the systems originating the data will be handled centrally by the MDM hub.
Automating data standards at MDM level 3 means establishing the target data value representation and taking the data through the necessary steps to deliver an accurate master value. For the first time in the taxonomy, MDM level 3 supports a consistent enterprise view of data. Data quality rules come into play here to establish data cleansing and error correction.
Level 4: Business Rule and Policy Support
Once data is integrated from multiple sources and the view of the subject area transcends an individual application and reflects an enterprise view, you have achieved a single version of the truth. When a single version of the truth has been delivered, the inevitable response from business managers and executives is often, “Prove it!” MDM level 4 ensures that the master data reflects the company’s business rules and processes to substantiate accuracy.
MDM level 4 introduces the ability for master data to support rules and integrity checking from both the MDM hub and other external systems. Given the relative complexity of most companies, the rules and policies affecting the access and manipulation of business data proliferate. It’s impractical to assume that any single system can contain and manage the varied type of rules associated with master reference data. Consequently, support of workflow and process integration is necessary if an MDM hub is truly going to deliver enterprise-wide data accuracy.
For instance, within an HMO, multiple applications are required to support the care of a patient. A single visit might include hospital admissions, room and bed assignment, monitoring equipment, lab work, a physical examination and other procedures. Once the patient is ready to leave the hospital, the discharge process ensures that all activities and resources related to the patient are resolved. MDM technology has proven highly effective at bringing together a multitude of application systems to ensure that patient identification is handled correctly.
While patient identification is critical, integration with business rules is equally important. The clinical system relies upon a series of business process and data rules that identify all outstanding patient details. This includes returning all room-based resources (monitoring equipment, beds, etc.) to available inventory and resolving all fees to the appropriate patient when the individual is discharged. MDM ensures that when John Smith is discharged, the correct room and equipment is released back into inventory for that John Smith - not the other John Smith currently on another floor undergoing physical therapy.
MDM systems must not only support rules-based integration but also be able to integrate with external workflow. These rules might include the hub interacting with the clinical system or awaiting approval from another system or a human being who can authorize the change. With an MDM hub, rule definitions may not be limited to logic - they may be dependent on input from another system.
Indeed, reconciling and auditing data means being able to loop back to other systems (or business processes) to ensure that data changes undergo rigorous approval so that errors can be detected and transactions can even be rolled back if necessary. MDM level 4 introduces support for rule and policy extensibility. It’s important that the hub support any business-oriented rule set in a flexible and sustainable manner.
For example, if a store manager updates a product price, the hub system should be able to confer with a trusted system (e.g., the merchandise management system) to validate the rule. The detailed rules that support the change may in fact reside on another system - the hub needs to understand the authoritative system or the method with which to process and approve the change. These rules might involve complexity or privacy constraints that prohibit them from residing directly on the hub.
At MDM level 4, an enterprise can support a set of steps or tasks that must be followed before a particular create, read, update and delete task is allowed. Workflow automation is often used to support the authorization of events or activities that occur on the hub. But change management is bigger than just workflow: it can include logic-based processing and people-based decisions. Change management exists to support the dynamics of the business to allow change.
For instance, before 9/11, anyone could ship freight on a domestic U.S. airline. There was no requirement other than a form of identification and a method of payment. Post-9/11, Federal Aviation Association (FAA) guidelines established a more comprehensive set of requirements that dictated whether an individual was allowed to ship freight. In this particular example, it’s not practical to have every system implement the FAA’s shipper requirements. It’s easier (and more practical) to implement a rules management system that centralizes shipper approval rules for all systems (including the MDM hub).
Centralized data definition and standardization introduced at MDM level 2 is less complex than centralized rules management at MDM level 4. The more complex and numerous the business processes, the greater the need for the hub to support cross-functional and heterogeneous rules against common data. It’s important to note that MDM level 4 supports centralized rules management, but the rules themselves and the associated processing can be distributed. Put another way, the MDM hub will ensure the rules are applied centrally even though they may reside outside of the hub.
Level 5: Enterprise Data Convergence
At MDM level 5, the hub and its associated master data are integrated into the individual application systems. There is no noticeable separation between master data and application data. They are one and the same. When the master record details are modified, all applications associated with the individual data element are updated. This means that both the consuming applications and the system of origin have access to the same instance of data. This is essentially closed-loop MDM: all the application systems are integrated via the unified management of master data.
At this level, all systems see the same single version of the truth. The operational systems are synchronized with the MDM content, so when a change occurs, the operational system is updated. For those familiar with MDM architectural styles (see pages 46-52 in Customer Data Integration: Reaching a Single Version of the Truth), in the persistent hub architecture, when the hub is updated all operational systems will reflect the change, resulting in an immediate operational view of the change. In a registry environment, when the data is updated the hub applies transactional updates via Web services to the linked systems. Thus, MDM level 5 offers an integrated, synchronized architecture so that when one authoritative system updates a data value, all the systems in the company reflect that change. Systems invested in changing data values don’t have to worry about data changes from elsewhere being propagated to them: MDM makes this transparent.
The move from MDM level 4 to MDM level 5 means MDM functionality isn’t specially designed or coded within an application. This also means that master data propagation and provisioning won’t require specialized development or support from the system of origin. All applications know that they don’t own or control master data; they are simply using the data to support their native functions and processes. All applications have access to master reference data thanks to the MDM hub and supportive IT infrastructure.
A company that has achieved MDM level 5 has aligned all of its application systems - both operational and analytic - so access to master data is transparent. Enterprise data convergence means that changes are propagated across platforms and applications. For instance, when a customer changes her opt-in status - regardless of the system that registers the change - that data change is propagated (and thus consistent) across all application platforms. MDM level 5 is the realization of the concept of data as a service.
MDM level 5 guarantees a consistent enterprise image of the master data subject area. It’s one thing to define “customer” but another to reflect accepted business rule changes to the customer’s master record. MDM level 5 removes the final barrier of master data: there’s universal adoption not only of data definitions, but also of authorized usage and change propagation.
Before launching any MDM initiative, understanding the current state of your environment is key. Be honest about your existing capabilities and how straightforward or difficult it is to standardize, reconcile and propagate reliable master data. In truth, you might not need to go to MDM level 5 to benefit from MDM. As with all strategic technology initiatives, MDM programs are best designed and extended when they are delivering specific capabilities to support a company’s business goals. Ensuring your MDM program is delivering business value is not only crucial, it is without question a best practice.
Evan Levy is a partner and co-founder of Baseline Consulting Group, a multivendor systems integration and consulting firm. As the partner in charge of Baseline’s largest practice, Levy leads both executives and practitioners in delivering technology solutions that help business users make better decisions. He has led strategic technology implementations at commercial and public sector organizations and advises vendors on their product development and delivery strategies. Levy has been published in a wide array of industry magazines and has lectured on a range of technology delivery experiences at leading conferences and vendor events. He has been a featured speaker at the Marcus Evans Analytical CRM symposium, DCI’s Data Warehousing conference, the CRM Association, DAMA International, the AMA and the Data Warehousing Institute. His current work involves delivering and lecturing extensively on the topic of data integration. You can contact him at firstname.lastname@example.org.
For more information on related topics, visit the following channels:
Jill Dyche is a partner and co-founder of Baseline Consulting (www.baseline-consulting.com), a data integration and business analytics delivery firm. Her first book, e-Data (Addison Wesley, 2000) introduced managers to the concept of enterprise data integration. Her second book, The CRM Handbook (Addison Wesley, 2002) is the CRM best-seller. You can reach her at email@example.com.