There Shouldn’t Be A Single-Version-of-Truth, it’s a “myth”, and there is none; in addition to being all or part of catchy titles upping the click-rates for these esteemed commentaries, the excerpted statements also represent a sampling of reactions to the over simplification, and at times, magical thinking employed to explain the highly desired, end result of Master Data Management. (My original title was going to be “Whose Single-Version-Of Truth Is This, Anyways?” – but enough’s enough, already.
Firstly, the concept of SVOT (yes, there is an acronym), or Single Version of Truth, preexists Master Data Management. In data warehousing, (an MDM precursor and now, co-existing data management solution), SVOT essentially represents the familiar practice of data consolidation for the purpose of centralizing specific enterprise data across multiple – and disparate – contributing systems. Once consolidated into the data warehouse, merged data provides a starting point for reconciliation, including the reduction of data redundancy. A starting point, because even with the inclusion of ETL and Data Quality Tools, data warehouses are really more about using enterprise centralized data for robust, if potentially, flawed analytics and reporting. Flawed, because a data warehouse repository is not known for storing the MDM-type metadata associated with certain data governance rules and functionality. Consequently, it’s not unusual these days for RfPs and RfIs written in support of data warehouse initiatives to include a request for MDM as a means creating an independent, and more viable SVOT, prior to sending data sets to the corporate data warehouse or data mart. This use case is a significant subset of what Gartner coined as Analytical MDM.
(To point out what may seem obvious, when the discussion around MDM implementations turns to the subject of different dataset domains, SVOT adjusts accordingly, e.g., Single-View of Customer, Single-View-Of-Product, etc.)
System Survivorship Rules
When it comes to customer data, SVOT’s greatest enabler is probably Survivorship. While there are multiple, crucial steps to a achieving, for example, a CDI (Customer Data Interchange) process flow, survivorship rules are so critical to the CDI process-flow, that its exclusion from any MDM solution would disqualify any product for consideration as a customer data hub.
Survivorship is directly integrated into the MDM consolidation or merger process. Since MDM is receiving data from multiple enterprise databases and applications, system survivorship empowers business data stewards to delegate which different system fields will be the trusted source for SVOT data, allowing that chosen system to supersede all other sources. In reality, (and depending on application), some business systems are more authoritative for certain data attributes than others (an HR system may be the be the best source for employee age, for example – or a logistics system might be considered best for location addresses). Survivorship, therefore, needs to support data models or data fields in a granular way, and be ready to exercise rule-based conditions, and what-if scenarios.
Despite this emphasis on tools (and as in all MDM), the key is understanding business system interrelationships around the creation of survivorship (and by the way, system is only one type of survivorship rule).
The post Determining MDM’s ‘Single-Version-of-Truth” appeared first on Reality Check.