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. Its 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 others 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 companys 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. Its 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. Its 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, its not practical to have every system implement the FAAs shipper requirements. Its 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. Its 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 dont 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 isnt specially designed or coded within an application. This also means that master data propagation and provisioning wont require specialized development or support from the system of origin. All applications know that they dont 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. Its one thing to define customer but another to reflect accepted business rule changes to the customers master record. MDM level 5 removes the final barrier of master data: theres 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 companys business goals. Ensuring your MDM program is delivering business value is not only crucial, it is without question a best practice.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access