Click to learn more about author Bill O’Kane.
In my eight years as a Gartner analyst covering Master Data Management (MDM) and two years advising clients and prospects at a leading vendor, I have seen first-hand the importance of taking a multidomain approach to MDM. The business challenges that organizations are trying to solve with MDM are complex and rarely involve just a single category or domain of data.
Recently, a new MDM trend has emerged where vendors have begun deploying pre-built single-domain applications (e.g., Customer MDM, Product MDM, etc.), but claim to provide true multidomain MDM capabilities through combinations of these applications. The issue is that while these single, discrete applications together master multiple data domains, they are still managed as multiple, separate applications – what I refer to as “multiple-domain” MDM.
Multiple-domain MDM vendors claim that deploying pre-built applications lets organizations start quickly and more affordably than a broader and more flexible multidomain MDM platform. They even promote the idea that customers can still grow into additional use cases by just deploying additional instances of MDM for every new domain they want to manage. Sounds great, right? Not so fast.
Dissecting the Hidden Costs of Single MDM Instances
While this new multiple-domain approach may seem streamlined at first, it has several limitations and concerns compared to a traditional multidomain MDM platform. It is almost always more complex and expensive because each domain-specific application requires customization and lacks integration with the others. Moreover, as separately licensed products on the vendors’ price lists, they incur far greater incremental costs.
On its face, this multiple-domain approach may seem a more manageable lift for organizations implementing MDM. Because each MDM instance is built with a specific type of data, or domain, in mind, companies can start quickly mastering customer data, for example.
But companies often find that while a pre-built customer data solution has (for example) 100 “standard” attributes available, only 20 or so actually apply to their business and customer base. They may also find that a data model that only contains customer data doesn’t offer much insight when isolated from the products they buy, the channels through which they purchase, and the marketing campaigns they interact with.
In addition, eventually at least one (and maybe all) of the multiple-domain solution applications will need to contain references to the other MDM applications just to serve a single use case. While this multiple-domain solution was sold as an integrated solution to overcome a company’s Data Quality woes, it can become just another siloed application for data professionals to reference when trying to report on data from various enterprise resource planning (ERP), financial reporting, and other systems.
As the enterprise goes through the process of customizing each pre-built MDM instance to fit its specific needs and potentially integrating it to other MDM domain-specific applications, it is apparent why this approach is often more complicated and expensive than a classic data-model-agnostic multidomain platform that handles multiple data domains in a single MDM instance.
This is because each of these single-domain instances of MDM must be modified to fit the specific needs of the business, legacy data sources, and use cases in question. As additional use cases arise and organizations look to expand, the costs associated with the maintenance of multiple instances and separate licensing for each domain can grow exponentially – all without the benefit of an integrated, multidomain platform-based approach to MDM.
While many of these issues could have been foreseen, through careful due diligence by aligning their MDM needs with the enterprise’s real business problems, this single- or multiple-domain approach can present a similarly myopic (and typically deceptively incomplete) view of its business problems and opportunities.
Achieving MDM Flexibility: Multidomain or Multiple-Domain?
Customers of multiple-domain MDM solutions are led to believe multidomain MDM is the serial, or even concurrent, implementation of two or more master data domains. However, multidomain should be taken to mean the freedom and flexibility to model only those master data entities and attributes that contribute to the agreed-upon business outcomes – regardless of the data domains to which they belong.
Of course, this best-practice approach makes sense only if the acquired MDM solution is a data-model-agnostic platform, and that the vendor does not license each domain separately, which is unfortunately often the case even with multidomain platform MDM vendors as well as the multiple-domain players.
My earlier example of an enterprise purchasing a pre-built customer data solution containing 100 attributes becomes exponentially more expensive – and of less value to the customer – as they are forced to purchase additional applications or instances of MDM. Even multiple-domain applications from a single vendor are often simply hardened versions of data models, data integration services, and user interfaces based on a multidomain platform underneath.
Conversely, true multidomain MDM vendors and solutions offer a domain-agnostic licensing model that allows the program to grow incrementally as the implementer identifies additional business needs – without worrying about the simple crossing of data domain boundary lines, which cause an increase in software costs going forward. With a domain-agnostic pricing model, an enterprise can license the 20 customer data attributes they need (in the above example) along with 80 (or whatever number the business requirements warrant) attributes split among multiple other types of data, without incurring unnecessary fixed costs for each additional domain.
The Case for True, Multidomain MDM
Rather than single-domain applications or a multiple-domain MDM, organizations find that the ideal approach is a true multidomain MDM that can expand to additional domains while providing starter-solution templates for specific customer, provider, or other use cases.
As no real business problem can be solved by managing only a single domain, vendors and implementers must take a comprehensive, multidomain approach to MDM. While single- and multiple-domain vendors claim their solutions offer a faster start and lower cost than a multidomain solution, they lack the functionality and feature set of a comprehensive solution. As customers move forward in their digital transformation, cloud migration, or other data initiative journey, they deserve an approach to MDM that scales with their growth and empowers them to face new challenges. They also need to understand the subtle yet costly differences before heading down a path that can stall the results and – even worse – the MDM project as a whole.