Planning the data mesh journey

01 Agree on the destination — and a few other details

As with any journey, before you embark, it’s essential to first agree on the destination, which in this case includes:

• Firmwide clarity on what data mesh is and is not going to deliver, and specifically the pain points it is intended to address
• A complete understanding and acceptance of the magnitude of the investment that will be required, including investment for cultural and organizational impacts.

As they say, the devil is in the details, and beyond this big picture strategic alignment you’ll need to agree on a few other things as well:

• While it may sound trivial, you must align on nomenclature and definitions — what do terms such as data domain, data product and data ownership mean, for example. Wherever there’s a lack of firm definitions, you’ll find plenty of room for misunderstandings and miscommunications that can result in inconsistency in implementation.
• Similarly, you must clearly define and agree upon roles and responsibilities. For example, which role is responsible for updating metadata? This will help in data domain autonomy and foster cross-product collaboration.
• Finally, you’ll need to align on your tolerance for data siloes versus data duplication. Although the purpose of data mesh is to break down data silos and avoid data duplication, at some level both are unavoidable. For example, if Finance requires transformed Human Resources (HR) data for a regularly run report, does it pull and transform the data each time — a potentially time-consuming and processing-intensive activity? Does it replicate the data instead? Should HR do the transformation to avoid the duplication? Does HR have the domain expertise to do the transformation? Having a framework for the teams to get answers to these questions is essential for the success of implementation.

02 Identify data domains and data products

Clearly identifying and drawing the boundaries of data domains and products enables teams to own and manage each product efficiently. You typically start with your data sources, grouping them based on relevance and use cases. It also involves deciding how granular each data product should be. At the highest level, each business domain — HR, Finance, Accounting, Manufacturing, Supply Chain and so on — would be a separate data domain, and the functional areas within them will be data products. But chances are you’ll need much finer granularity than that to make the products useful and more easily manageable.

How granular do you go? There’s no one right answer. Fine-grained data products will result in teams having a higher degree of domain knowledge and autonomy, but they’ll increase data silos. Coarse-grained data products will result in teams having limited domain knowledge as they manage vast datasets, but they tend to reduce data system complexity. This same question of scope applies at the macro level, too. For larger enterprises, it may be more efficient to create a mesh of meshes rather than one very large mesh. For example, each line of business might build and manage its own data mesh and share it with other lines.

As with any product design, this can be more of a creative exercise than anything else, a collaborative effort that can require many hours of brainstorming. KPMG Ignition Centers can be a useful resource for this exercise.

03 Select the tools and define the architecture

You’ll need a well-stocked toolbox to build and operate your data mesh, including specialized tools for data ingestion, catalog, metadata management, lineage, access management, etc.

It can take a surprising amount of time and effort to identify, select, implement, and integrate these tools — and to maintain them going forward. The approach you take has an impact on the timeline.

You might, for example, select tools from multiple vendors, but that requires you to assemble, integrate, and maintain them — a time-consuming process. You might choose pre-integrated tools from your cloud provider. That can accelerate the effort, but it may limit features and capabilities. You could also go with a curated collection of best-of-breed tools that’s pre-assembled for you — the KPMG Modern Data Platform is one such option.

04 Plan for the cultural shift

Last but certainly not least, as the cliché goes, you’ll need to plan for the cultural and organizational changes that go along with adopting a data mesh and its product-mindset approach to data.

In a pre-data-mesh construct, your data professionals tend to be domain agnostic. Their expertise is likely focused on specific technical skills — data extraction, transformation and loading; analytics; reporting, etc. — regardless of the source or type of data or the purpose for which it is being used.

Data mesh changes this in two significant ways:

• Now, your data professionals must be domain focused and will develop a domain-specific product. To be effective, they’ll need to understand what the data is, where it comes from and how it can be used.
• You’ll also need to establish a talent development program for their technical upskilling to adopt modern data technologies.

KPMG is here to help

At KPMG, we have the digital transformation talent, technology experience and advanced tools to help you execute on your technical debt management and modernization initiatives. Our business process and operating model acumen can help you map the right path to take your enterprise into the future.