Master Data Management – No Place in Data Mesh?

This article around the importance of Master Data Management in a Data Mesh framework is part of a series. The previous articles, although written quite some time back could still be relevant reading. For an introduction to the concepts of a Data Mesh Architecture?please visit this link and for Essential Ingredients for a Data Mesh Architecture please visit this link

With Data Mesh picking up more traction and ears across Enterprises along with it come several opinions, myths, and thoughts most of which are relevant, but some require a deeper investigation. One such Myth is around the non-necessity of Enterprise Master Data Management.?

Opinions/Myths around Master Data Management

Centralized Model – Enterprise MDMs need to be based on Centrally agreed models. How would this align with Domain Driven Principles of Data Mesh?

Domain Specific Attributes – Enterprise MDMs have naming and fields which may not be Domain oriented

Centralized Authoring – All data gets centrally authored and maintained which is against the decentralized principles of Data Mesh.

Monolith Architecture – A Master Data Management Architecture is sometimes seen as a Monolith especially in a big Client – Server/Service Setup.?

Let’s take a step back.?

Master Data Management is essential for an Enterprise to identify its Critical Data Elements, how it flows through various Applications, Processes and Data Landscape and how it should be curated, complete and consistent throughout the Enterprise. In this context, it is very much tied up with the concept of Federated Governance in Data Mesh.

This means that there should be some Master data elements which get defined bottom up by Domains and should be managed and governed at a Domain Level. This can create Domain Master Data Management. But at a Central level, Critical Master data elements, their relationships, people, processes, and policies should interlink with Enterprise Governance. This should then create a network of its own where the Enterprise Master Data can be co-related and detailed into Domain specific Master Data.

How could Enterprise Master Data Management be adopted within a Data Mesh Framework? (Busting the Myths)

Federated Model – An Enterprise MDM can be setup to have a Federated model with Domain specific models linking up towards an Enterprise Master Data Solution. This can be achieved in different MDM Implementation Styles, with Master Data Governance closely tied up.

Business Services modelled towards Domain Specific Attributes – An Enterprise MDM exposes multiple services (typically as REST APIs) which can be consumed by Applications as well as can be transposed as per the needs of different Domains. In this fashion, the MDM Services become part of Data Products which gets produced by relevant Domain Data Owners and consumable either within or across Domains.

System of Reference – Most customers implementing Master Data Management today consider implementing MDM as a System of Reference where MDM becomes a nervous system integrating bi-directionally with applications typically in a real-time fashion becoming part of CORE business processes. This setup can be a crucial pillar towards enabling Data Products integrating with MDM to serve trustworthy, complete Master data.

Modular Architecture –Modern Master Data Management solutions come with a highly decoupled, Microservices Architecture, typically also available as a SaaS service. This enables agile adoption whilst also leveraging Enterprise data/compute infrastructure to enable data fed in or out of the Enterprise MDM. Such a modular architecture enables agile adoption towards underlying Data model or Application landscape changes.

To summarize, it is essential for enterprise organizations to integrate critical master data management with their Federated Governance setup enabling Data products to have consistent and complete master data whilst ensuring that each domain does NOT re-invent the wheel or have disconnected incomplete information about the data that really matters to the key business processes in the organization.

?As always, I appreciate your thoughts and comments to collaborate and understand how these ideas have been?realized in practice.?

Note – The views in this article are my own based on my experiences.