The Master Data Model vs the Information Model
When speaking of Master Data, you will likely encounter several opinions about what it is. An IT person will say it is a technical integration that happens to be related to Master Data. A businessperson will say it is a business process and has nothing to do with IT.
The truth is that both are right, sort of. Master Data is indeed a business process, including ownership, governance, information security, data quality and more. This is 80 % of the work. However, the remaining 20 % is an IT-effort; establishing a technical platform and building integrations. This is also important.
You could say the businessperson is 80 % correct, or that the IT person is 80 % wrong, depending on what argument you think suits best...
In short, the business process decides what Master Data is and how to govern it, whereas IT makes it work seamlessly between systems on a technical level.
Business-driven is the key to success
Given the dependency between the business side and IT-side, it is therefore not surprising that establishing a Master Data process has traits of both worlds. The most obvious example is the Master Data Entity Model. Although abstract Information Models are very much a tool used by IT, it is in the Master Data respect “The tool” that allows business concepts to be translated to something that IT can actually use as near-IT-lingo understandable list of requirements.
What is most important though, is that the Master Data-work 100 % of the times is driven by the business. Having an IT-initiative-only in the Master Data-area is a certain failure.
The Master Data Model is an information model of business concepts, or entities, and how they relate to each other. The key importance is that it uses business terms, and to serve the business interests and purpose a Master Data Entity Model is simplified.
There is a major difference in the purpose and audience of a Master Data Entity Model and the overall Information Model! Be very aware of people not being aware of this!
The dataset hierarchy
From a business perspective the three main data subset types are:
- Transactional Data
- Reference Data
- Master Data
The Reference Data are non-transactional data that does not require governance, e.g. due to not being business critical. As soon as Reference Data requires to be governed it becomes promoted to Master Data and part of the Master Data Entity Model and the Master Data Management (MDM) process.
The Master Data Entity Model is of course related to the Information Model, the first is an (somewhat) aggregated subset of the later.
For example, where an information model often abstracts business information objects, or entities, into theoretical supertype concepts (i.e. person, place), the Master Data Model stays true to the business view and avoids super-typing as much as possible (i.e. keeps employee, office).
The reason is that the Information Model is tightly coupled with how information is stored and processed in IT-systems, where a Master Data Entity Model expresses how the business sees and defines their own concepts and entities for governance purposes.
An information model for IT is very often system focused while the Master Data Entity Model is process focused. In general.
And while EVERYTHING is part of the Information Model, the Master Data Entity Model mostly focuses on the question: "What needs to be governed?". Governance is something that is extremely important and requires thoroughness and patience. Hence, it should not be targeted at everything but only the key business critical information entities.
What is the purpose of this clear distinction?
FIRST - Integration Message Structure
The Information Model drives integration message structure in the enterprise service bus. Since the Master Data Model does not contain all attributes of an entity, it becomes apparent that confusing the two models will result in a poor match and severe headaches in the integration layer.
SECOND - Enable Data Stewardship
Another thing to consider is that the Master Data Entity Model must consider end-users ability to easily participate in data stewardship of the Master Data; and facilitate effective, efficient match, merge and deduplication processing.
THIRD - Domain Data Model as a looking glass
A Master Data Architect creates a common Master Data Model that is used as a looking glass against source data, using the Master Data Model as the bridge between related data in separate sources. This is the Domain approach. Instead, an Integration Architect matches Master Data on data point level trying to solve the integration one data point at a time.
Integration data points without having a Master Data Entity Model quickly becomes increasingly difficult. Without a target model the work might actually succeed but still produce the wrong result. Very much as saying "The operation was a great success, but the patient died".
FOURTH - Confusion of Reference Data
An Integration Architect likely says that Master Data is any data that is not transactional data. This is very different compared to the business view and not being aware of this gap in understanding might result in major havoc in the Master Data Management (MDM) process. While the business separates Master Data from Reference Data, an Integration Architect and other IT-roles does not. Having Reference Data creeping into the MDM-process will cause an extreme workload and result in lack of focus on what is business critical information.
FIFTH - Share the Master Data
A fifth aspect is that the Information Model provides an enterprise with a standardized data model, while a Master Data Model provides an enterprise with a way to master shared and critically important data. The first provides the enterprise-view of attributes, and the other provides a way to master the Master attributes.
In summary, the two information models have two very different purposes. And that is fine.
Final Note: As humans love sorting, pay close attention to "improvements" to the Master Data Model, especially by non-business-sources. Remember that these are distinct and separate information models; don’t confuse them, don’t try to merge them!
Also, if you own Dell Boomi or OneData and think you have a Master Data Management-platform, you actually don’t. Read our blog "Common pitfalls of choosing an MDM platform" to understand what you have and what gaps in expectations and capabilities you need to address.
Do you want to know more about the Master Data Model vs the Information Model? Please don't hesitate to contact me.