There is a trend on the data management market that the solutions are either going very niche (best-of-breed) in the data domain covered or they are encompassing a broader range of data types.
This can be seen in the spectrum of master data and product information as reported in the post MDM, PIM or Both.
We also see that governance and management of reference data is included in addition to managing master data as told in the post What is Reference Data Management (RDM)?
Some MDM (and RDM) solutions also extend the reach to cover aspects of transaction data and big data. The main scenarios covered are:
- Matching of party entities in traditional systems of record with the parties referenced in social streams and weblogs (systems of engagement) as well as in sensor data. This can be used in creating a Customer Data Platform (CDP).
- Extending data quality and data performance dashboards related to master data to cover aggregated transaction data and big data held in data warehouses and data lakes by using a shared set of reference data.
When product information is to be shared in business ecosystems through Product Data Syndication (PDS), this can be accelerated by using a data lake concept and new data stores as staging areas. This is due to that a main challenge here is that the data quality standards on the providing side most often are different from the data quality standards on the receiving side.
The diagram is a variation of a diagram included in the whitepaper Intelligent Data Hub – Taking MDM to the Next Level. The original is developed together with Salah Kamel, CEO at Semarchy.
Many of the recent posts here on the blog have been around some of the most essential capabilities that Master Data Management (MDM) and Product Information Management (PIM) solutions are able to provide.
Having the ability to match and link master data records that are describing the same real-world entity is probably most useful in MDM and in the context of party master data. However, there are certainly also scenarios where product master data must be matched. While identifying the duplicates is hard enough, there must also be functionality to properly settle the match as explained in the post Three Master Data Survivorship Approaches.
While the first MDM / PIM solutions emphasized on storing “a single source of truth” for master data, most tools today also provide functionality for processing master data. This is offered through integrated workflows as examined in the post Master Data Workflow Management.
Master data comes in hierarchies (and even graphs). Examples are company family trees, locations and product classifications as told in the post Hierarchy Management in MDM and PIM.
Handling Multiple Cultures
If your solution will be implemented across multiple countries – and even in countries with multiple languages – you must be able to manage versions of master data and product information in these languages and often also represented in multiple alphabets and script systems. This challenge is described in the post Multi-Cultural Capabilities in MDM, PIM and Data Quality Management.
Reference Data Management
The terms master data and reference data are sometimes used synonymously. The post What is Reference Data Management (RDM)? is about what is usually considered special about reference data. Some MDM (and PIM) solutions also encompasses the handling of reference data.
The Capabilities That You Need
The above-mentioned capabilities are just some of the requirements you can mark in a service that can draft a list of MDM/PIM/DQM tools that are most relevant for you. Try it here: Select your solution.
One of the specialized data management solution types encompassed by this Disruptive MDM / PIM / DQM List is Reference Data Management (RDM).
Reference data are typically smaller lists of data records that are referenced by master data and transaction data. These lists do not change often. They tend to be externally defined but can also be internally defined within each organization. The below table have some examples of reference data lists used across many organizations and industries:RDM solutions may offer this functionality around the reference data:
- The data store that holds the data
- The user interface for maintaining the lists
- Access control
- Hierarchy management as for example how countries have (or not have) states/provinces that have postal codes
- Managing relationships and mapping between the list values as for example how a SIC industry sector code relates to NACE industry sector codes
- Versioning of the lists
- Language and further context management
- Audit trails
- Approval workflows
- Data integration capabilities
There are applications that is purely focussing on RDM as well as MDM and broader data management solutions / suites that have RDM as a one of several capabilities where the above-mentioned functionality is shared with master data and perhaps other critical application data.
If you use the select your solution service here on the site, RDM is one of the capabilities you can mark as a requirement for your solution.
There is a tendency on the Master Data Management (MDM) market that solutions providers aim to deliver an extended MDM platform to underpin customer experience efforts. Such a platform will not only handle traditional master data, but also reference data, big data (as data lakes) either directly or by linking to the data in there as well as linking to transactions.
The recent acquisition of AllSight by Informatica is an example hereof.
In this context traditional MDM will, supplemented with Reference Data Management (RDM), enable the handling of:
- Customer, supplier and product identity
- Customer, supplier and product hierarchies
- Customer, supplier and product locations
Additionally, the data lake concept can be used for:
What is your view: Should MDM solution providers stick to traditional master data or should they strive to encompass other kinds of data too?