Why Your Approach to MDM Matters: Single Domain MDM Versus Multidomain MDM
Table of Contents
Multidomain MDM and single domain MDM are two major approaches to Master Data Management (MDM), which are evaluated in this article. Master Data Management itself is a vital part of digital transformation and therefore remains a key consideration on the strategic roadmap within enterprises. Underlining its importance, a Market Study Report forecasts that the total MDM market will reach USD 57.7 billion by 2025, representing an increase of over 20% from 2018.
Why Master Data Management (MDM) matters
A definition of MDM also illustrates why it matters. As experts Berson and Dubov explain, “Master Data Management (MDM) is a framework of processes and technologies aimed at creating and maintaining an authoritative, reliable, sustainable, accurate, and secure data environment that represents a single version of truth, an accepted system of record used both intra- and inter-enterprise across a diverse set of application systems, lines of business, and user communities.”
Traditionally, MDM solutions have been largely focused on product or customer data ‘domains.’ In the MDM environment, the term ‘domain’ is used to describe the subject or topic to which a specific set of data relates. Finance, location or employee domains are other examples of common domains selected for MDM.
 Alex Berson and Larry Dubov, Master Data Management and Customer Data Integration for a Global Enterprise. McGraw Hill, 2007
Single version of truth
As the definition of MDM highlights, establishing a ‘single version of truth’ or aiming for a ‘golden record’ – that is a master data source from which all else across the organization can be referenced – within the domain in question is a common factor that unites all MDM solutions. From a domain perspective, supplier data is becoming increasingly important. It has become even more urgent since the fallout of COVID-19 revealed drastic shortcomings in supplier data that held many organizations back in their response to the crisis. Accurate information on suppliers has been shown in this period to improve resilience, reduce risk and increase competitiveness.
Supplier Information Management (SIM), underpinned by MDM, is therefore leading the digital transformation in Procurement. On the other hand, organizations without SIM experience weaknesses in their abilities to create and maintain an accepted system of record for their suppliers. This results in bad data, wasted time and increased cost.
Single domain MDM versus multidomain MDM
In order to assess fully one solution versus another, it is important to first clarify some terminology. There are three main terms to bear in mind:
- Single domain MDM: these are solutions that specialize in providing the master data for one specific domain due to their expertise in understanding the workflows required to capture and maintain accurate data relating to that field. We call this domain-expert MDM.
- Multidomain MDM: a solution to manage all master data across all domains within one application, applying single governance to all domains in scope
- Multiple domain MDM: often used interchangeably with multidomain MDM, this is actually a solution that manages master data from different domains in one application, but with separate governance for each domain
Two dominant approaches for the implementation of SIM are multidomain MDM and domain-expert MDM, which drives an ongoing debate on whether to select one versus the other. In practice, the selection of multidomain versus domain-expert is not necessarily a mutually exclusive choice as often presented. Both approaches support MDM strategy and, in today’s world of seamless data integration, the danger of creating a silo does not stem from a technology choice, but from how technologies are implemented and adopted by the organization. The solution or solutions selected, however, will lead to different approaches to address use cases and overcome pain points.
A multidomain MDM solution offers the following benefits:
- Centralization of data into a single location outside of transactional systems
- Good data governance and control or maintenance of inputted data
- A single, consistent, authoritative version of the truth for core data. It provides ability to consolidate and clean data.
- Strong technical integration capabilities. Data can be made available across multiple systems and can be used for BI and analytics projects.
A word of caution, however. The first bullet point in this list frequently leads to an inaccurate conclusion that multidomain MDM will achieve a lower total cost of ownership and a more rapid time to value compared to a single domain, or domain-expert MDM solution. The perception often is that the one-size-fits-all approach removes the need for any other systems or technologies. In reality, while multidomain MDM supports many analytics use cases, domain expertise is still required to fully realize the benefits of data integration and make them available to end users.
With this in mind, the advice therefore, when undertaking a supplier-related data project, is to: “Evaluate a solution based on business requirements, rather than data problems to fix.” Business requirements for supplier data (and to support the collection and ongoing maintenance of accurate data) include, for example, operational aspects such as communication, engagement and collaboration with suppliers.
It is the distinction between a purely analytical MDM solution with workflows supported separately at extra cost, versus an operational MDM solution which can also support centralized analysis. Both analytical and operational MDM rely on good quality data, which in turn relies on governance; and both can support an organization’s goals of digital transformation through automation and other Big Data or potentially AI-related projects.
To contrast, a best-of-breed, domain-expert approach therefore warrants consideration from a cost, governance and digital transformation perspective.
Total cost of ownership
Despite offering strong technical integration capabilities, multidomain, or generic, MDM solutions lack the detailed context of integrating supplier data, particularly with ERPs, in the real-world. While theoretically possible, it is a big driver of cost in practice. Additionally, there will be no supplier portal or only limited support for workflows to allow for collaboration with suppliers. A solution is to buy a workflow tool to overlay on top of the MDM platform, but again cost implications must be taken into account. Architecturally, this results in many moving components that make multidomain MDM far more complex – and more akin to a build exercise – compared to a ready-built, out-of-the-box solution.
In a recent HICX white paper, Implementation of Supplier Information Management, we interviewed a number of practitioners to understand in more detail how this point impacts the implementation of multidomain MDM compared to domain-expert MDM. The research revealed that a common scenario for multidomain MDM involves configuring a low code platform to work in combination with an MDM solution, an application portal and a data governance service, which all need to be interconnected. Far from being a one-size-fits-all, single solution, the approach adds specific and, many times, unpredictable drawbacks.
For example, in the environment illustrated, low code platforms may charge by case type. Therefore, in a project estimate that perhaps starts with three cases being in scope, it can quickly become apparent over time that there is realistically a requirement for around forty cases (for a list, please see the white paper), which now all need to be factored in after the event. This means not only higher costs during implementation, but also it increases the annual recurring cost. Licensing costs go up and predictability decreases, which is unfavorable to the business, especially if new funds are not available until after another budget cycle.
For a full comparison of the timeline of multidomain MDM projects and domain-expert MDM implementations that take into account these effects, please refer to our white paper.
Contrary to popular belief, connecting silos in order to establish end-to-end consistent, accurate data sustainably is not a technology or a system issue. It is a data governance issue. In fact, integrating systems has been a staple activity in enterprises for decades. With the right expertise, connecting systems is straightforward these days. Too many executives continue to base their decisions on incorrect assumptions, as Vivek Bharti, general manager of product management at contract management specialists Icertis, explains, “They think it’s going to be like it was ten years ago, when you had two different systems that could never talk to each other.”
This assumption – and the argument that only multidomain MDM can support end-to-end process governance – has led over the last decade or so to a preference for less optimal, and predominantly data led solutions, rather than business led solutions. However, this view is becoming much less common organizations realize that data governance goes wider than MDM alone and involves the combination of technology, process and people. A change of attitude is also being driven by the realization that having data in a single domain solution or a standalone system does not mean that the data within it sits in a silo. A silo exists when data cannot be accessed or shared due to its location or structure. Conversely, data that can be retrieved and used organization-wide in conjunction with other end-to-end processes is not siloed. There is no technical requirement to say that this latter point depends on having technology from a single vendor.
Therefore, regardless of the technology infrastructures or approaches chosen, it is imperative to set up a data and information governance framework that defines how supplier data is to be proactively managed. It should incorporate policies on roles and responsibilities of data owners and establish ownership of data quality, including procedures for hand-off between systems, documentation and data security.
The key phrase here is ‘proactively manage’ rather than ‘retrospectively fix’, the latter of which occurs in most cases because the mechanisms for capturing and maintaining accurate data are not embedded into business processes. This is an important advantage of an operational MDM approach to supplier data, as opposed to the analytical multidomain MDM alternative. All too often, siloed data management functions are set up centrally, which is a mistake because it detaches the people who create the data from the people who will use it.
One business requirement that derives from governance is that a process for capturing excellent data must be established upfront. This translates into a technical need for a single-entry point for data. Much of the time, where this does not exist, suppliers are onboarded to a number of disparate systems, as many diagrams of Procurement technology stacks within enterprises reveal. They are not onboarded ‘to the enterprise.’ Hence, data enters the organization via systems that are structured differently and work in very different ways. An MDM supplier information management platform with supplier onboarding, on the other hand, is able to consolidate, integrate and govern the data across different systems.
However, while some governance considerations may relate to technical requirements, as stated, this is not a technology issue. The solution deployed must be flexible enough to support any governance framework established, but technology in and of itself does not fix governance. Do not fall into the trap of assuming that governance is fixed by selecting one specific technology solution (or more likely, combination of solutions) over another, but do focus on the requirements that, first, ensure that accurate information is collected at the point of creation and, second, that it is accurate at point of use.
Data governance is not about a single person, or group, taking sole responsibility for data management and quality, but rather it is about collaboration and everyone contributing to a wider aim. A way to facilitate this is to clearly explain to stakeholders that efforts will be shared and that the commitment is hugely valuable to the broader digital transformation aims of the enterprise.
A common problem is that many wish to distance themselves from data as it is perceived as either low-value or ‘admin’ work. However, as Costas Xyloyannis, CEO of HICX explains, “If you’re thinking about solving your data challenges by isolating them in a data function, shared services or IT to ‘protect’ your internal partners, then think again. All you are doing is creating another type of data silo, which, in turn, will continue to be a barrier to digital transformation efforts.”
Domain-expert, single domain MDM: requisites for success
Points to ensure a successful MDM strategy include:
- Have a vision: every organization’s MDM needs are different, but regardless of what they are, it is crucial to define them and communicate them clearly.
- Put governance in place: as described above, building your governance structure allows you to define who is responsible for what data, who’s responsible for data maintenance and how its quality is going to be tracked over time.
- Create processes: once the vision and governance structure has been approved, they must then be turned into working processes. Examples of such processes could be defining how data cleansing will work between different systems, creating new data and maintaining the quality of existing supplier data.
- Use systems: for your Supplier MDM strategy to be successful, it needs to be supported by systems that can help with key aspects such as extracting and consolidating data and approving workflows.
As well as working out what your strategy is, you also need to make sure you execute it correctly and adhere to it. Each part of the process lays the foundations for the next stage, so they need to be carried out in order to achieve the best results.
Download our white paper Implementation of Supplier Information Management for more information on the next steps.