Another big topic at the MDM Summit was the concept of using Master Data Management in order to build a Single Version of the Truth. There seemed to be a consensus with large enterprises at the Master Data Management conference that there should be a separate database to act as the central data repository in order to view and analyze the Single Version of the Truth. With large organizations having so many data sources and not necessarily a single system of record, it makes sense that larger enterprises use a separate database as their Master Data Management central repository for analytical purposes.
In the Mid-Market, many organizations also use a separate central repository to create the “Golden Rule” record just like larger enterprises. This is a record that the Master Data Management solution creates based on the best information in separate data silos and is only for analytical purposes. When using a separate repository for analyzing the Single Version of the Truth, the “Golden Rule” record is not disseminated into any operation systems as there may be good reasons to keep the information in the operational systems exactly how it was originally entered. Instead, this “Golden Rule” record is used to help provide crisp and clean reports.
However, we also have Mid-Market clients who use a Master Data Management application to match and link separate data silos to help populate an operational system that becomes their Single Version of Truth. For example, a Mid-Market organization may choose to use their CRM system as their central hub in order to view and analyze their Single Version of the Truth regarding their clients, prospects, and centers of influence. Since a Mid-Market firm’s Master Data Management scope may be more limited than larger MDM initiatives, (less data, data sources, and data types) this approach may be reasonable for some Mid-Market firms.
Steven,
The location of the MDM server holding the "single version of the truth" is highly dependent on some of the factors that you've mentioned e.g., data source disparity. I would also like to add the following:
1. Data heterogeneity across application data repository (DBMS engines from different vendors)
2. Data model heterogeneity (different database engine types support different data models
3. Change sensitivity (a separate MDM instance must be capable of delivering configurable change sensitivity in relation to disparate data sources)
Coincedentally, I have actually used the CRM approach to integrate data from disparate data sources bu using ODBC and/or JDBC as the I/O mechanism between my data virtualization layer (how I prefer to describe MDM), but that only got me so far.
Basically, I ended up using RDF to concpetualize the logical data structures across the disparate data sources within our enterprise, and then leveraged HTTP for making the derived Concepts (entities e.g. Customers, Orders, Products etc..) directly accessible from anywhere within the company i.e., I could hyperlink to a given Customer entity in exactly the same way I would a document/report about that Customer.
If you are interested in live demonstrations of some of these emerging capabilities for MDM, take a look at the following live demo using the standard Northwind Database schema to demonstrate my point.
1. http://demo.openlinksw.com/Northwind/Customer/ALFKI -- Document about customer "ALFKI"
2. http://demo.openlinksw.com/Northwind/Customer/ALFKI#this - Entity "ALKI" of Type "Organization"
Note, the above is a simple demonstration of Conceptual Level interaction with data via HTTP, a process commonly known as: RDF based Linked Data.
To conclude, we also need untethered access to the "single version of the truth" even when we surmount the often overlooked challenge of "change sensitivity" across disparate data sources.
Kingsley
Posted by: Kingsley Idehen | October 30, 2008 at 03:26 PM