When selecting solutions to help support your master data management and data governance ambitions, one of the many aspects you are likely to evaluate will be support for “multidomain” MDM. Your initial inclination is almost certain to be selecting a solution that can “do-it-all.” In many cases, this will be despite the fact you currently have a business use case for only one data domain; customer or product data, for example. A single solution that could do more in the future would, of course, be desirable, to make more efficient use of available resources.
People often use the terms multidomain and multiple domains in an interchangeable fashion but there are inherent and important differences. Not all “multidomain MDM” solutions are created equal. There is a distinct difference between a solution that manages multiple domains and one that is multidomain. Understanding the difference could radically improve your MDM business case and outcomes.
To explain why, we need to revisit some basic concepts and definitions.
A domain generally refers to the type of master data we are focusing on. Keep in mind master data is generally low-volatility, business critical, information. Common domains include customer, supplier, product, asset and location.
Mastering the customer data domain requires the establishment of unique ways to identify customers by their names, addresses, identifiers and other distinguishing attributes. MDM achieves this by creating transparency around this data, ensuring quality, uniformity, coherence, etc., so it can be shared and consumed reliably across the enterprise.
Some MDM solutions focus more on mastering a single data domain, like customer or product information. The reason is the use cases for managing some types of data domains can be very specific.
For example, the use of machine learning to help identify products in images is unlikely to be commonly employed to identify customers. On the other hand, customer data tends to originate in, and be enriched by, multiple external systems, in addition to following more of a consolidation or registry implementation style. These are characteristics that can make the customer domain different in the way it is governed.
In contrast, product data tends to follow a more “linear,” single source method of creation, enrichment and syndication. It thus lends itself to a more centralized implementation style and workflow-led approach.
The choice between a multidomain vs. multiple domain MDM solution to manage these different kinds of use cases is important to consider when seeking to create incremental value to your MDM business case.
| Multiple Domain MDM |
Multidomain MDM |
|
May require additional “modules” or “tools” to provide support to additional domain use cases
|
Integrated, native governance functionality that applies across all domains and at their points of intersection where they are related
|
|
May lack the ability to manage both choice of domain and implementation style
|
Able to mix implementation styles and use cases (multivector MDM) across different domains
|
|
May require significant configuration or coding to make the management of multiple domains possible
|
Configuration-based approach to data modelling and governance
|
MDM solutions that can manage multiple domains tend to have unique governance functionality relative to each domain being managed. Yet a true multidomain solution will provide identical governance functionality uniformly across all data domains. A multidomain solution allows cross-domain and contextual data relationships to be governed.
Multidomain MDM allows you to establish relationships between data of different domain origins and bring governance across these relationships, with governance policy written for the data in the context of these extended relationships.
When cross-domain data governance is considered as an element of an evaluation process, it provides a unique opportunity to measure the extended value of the solution, even if it does not play a role in the first phase of your implementation.