A common definition of Master Data Management (MDM) is “a single version of the truth” or “a single view of X”. While it is true that the objective of any MDM initiative is to create one reference of shared data for the enterprise, I always find this definition a bit restrictive.
Actually, what makes master data complex is not only its level of duplication, but also its life cycle. Or we could say life cycles, because there are many different dimensions to consider.
The various dimensions of the master data life cycle make data governance highly complex for an organization. Unlike simple database products, an MDM solution provides powerful life cycle management capabilities that address this complexity.
Versions are the first dimension to consider. A single version of the truth is a slight misnomer since you need to manage present, past and future versions. Present defines your current master data. Past keeps track of master data value – snapshots of your master data back in time. Future is a bit more complex because it defines all the versions that may potentially occur in the future. Organizational hierarchy offers a good example of this. With reorganizations and future updates, you most likely need to work on many future versions. The difficulty here is to work concurrently on future versions and be able to compare and merge them overtime. In real time, this is even more complex since all versions are updated in parallel. The changes made in both future and present versions must be compared with potential conflicts.
Master data can have a long and complex life cycle and needs to have a clear status overtime. Consider the life cycle of a product: it is created by Research & Development, then marketed by Sales & Marketing, accounted for by Finance, and delivered by Supply Chain. Across all stages, the product’s specific status will be updated by various users and systems through workflows. The status is a parallel dimension to versions.
Again, the idea of “a single version of truth” is too simplistic in a complex organization. Variations, an often forgotten dimension of the master data life cycle, mean that master data will be adapted to many contexts. The same product we discussed earlier can not only be defined globally, but adapted locally for specific markets, geographies or distribution channels. In this case, the master data doesn’t need to be duplicated, but adapted. Inheritance is a significant feature that an MDM solution must offer to address mass adaption. This capability allows the definition of “child instances” of master data that inherit from its parent and can be adapted locally.
While version control provides snapshots of MDM in the past, history provides a fine-grained view of all transactions and values across time. This adds yet another dimension and fulfills the requirement for a detailed MDM audit trail which is needed primarily for reporting and regulatory compliance reasons. Generally performed at the record level, this audit trail is the footprint of all users and systems that consume or produce master data.
The ability to manage each dimension of the master data life cycle isn’t an easy task. Most MDM solutions – particularly former CDI products – were built on relational schemas for party-related data and cannot handle the “multi-dimensional” nature of complex master data.
Orchestra Networks EBX5 offers superior capabilities in this area. Designed from scratch as a model-driven, multidomain MDM solution, EBX5 can be deployed on top of any RDBMS and addresses all of the above capabilities including: 3-way version control, built-in workflow with status management, inheritance engine for master data variations and full audit trail.
In simple use cases, it is difficult to envision the importance of these technical characteristics, but in real-life enterprise-wide deployment, master data life cycle management is one of the most significant aspects of an MDM initiative.
By Christophe Barriolade