Data Mesh has come a long way from the initial idea of a fellow Thoughtworker to a movement that has spread across the globe. The concept itself has sparked a lot of interest across Data, IT and business professionals. Organizations are considering adopting Data Mesh, often driven by IT. But is that sufficient to be successful? Let me start with a controversial statement:
If you do not develop the organization at the same pace and with the same intensity as you develop the technology around data products, Data Mesh is going to fail.
When embarking on a Data Mesh journey, it is important to identify those in the organization who believe in the concept and want to benefit from it. A Data Mesh Transformation requires a business executive in your organization who believes in the concept and has a pain point they need to solve. They must be ready to invest in an experiment and transform their approach to technology and parts of their organization. The business domain must be willing to take true ownership of their data and establish their very own data product team. Once successful, further domains may follow the example and the Data Mesh can grow. Here are my top 10 steps how to successfully introduce Data Mesh (from a business perspective):
1. Find a business executive with a strong pain point that can be solved with improved data access, data quality or data interoperability.
This will be your sponsor and the domain will be your first mover business domain to deliver your initial use cases. Educate them about Data Mesh and show them how Data Mesh will help solve their problems. Two use cases with shared data are ideal as a ‘light house project’ to later start an organization-wide roadshow. Begin with a Data Mesh Discovery to define the initial use cases and data-products. Responsibility for the data should be located in the business, not IT.
2. Set up a long standing data product team with a mix of highly data fluent people and domain subject matter experts within the business domain.
The team should have dedicated resources like a Product Owner, Business Analyst and Data Engineers. You may staff from internal resources or find an external partner to help. The business domain should start to carve out new ways of working without doing a major reorganization. Keep the effort reasonable. For budgeting reasons, you may frame it as a project for the first 12 months.
3. Set up a centralized self-serve data platform team within the IT organization.
A dedicated product team should build and maintain the self-serve data platform. The Data Product Teams are their customers and the platform should be provided based on the customers requirements. The team may act in the true fashion of a product mindset, driving user value with short feedback loops, short lead time and high deployment frequency. More than one platform team may be required when scaling, depending on the size of the organization.
4. Adopt Lean Value Tree mapping to work towards the right business goals.
Define clear business goals, value hypotheses to reach them and ways to measure your success. Use the Measures of Success to monitor the impact the use case delivers towards the business goals. Data products are developed with a product mindset and therefore require fast experimentation and regular reviews.
5. Prioritize use cases by highest value and lowest effort.
Make sure to start with the right use cases. Start with a business goal and identify the use cases that would best serve that goal. Ask yourself two questions: Which use case will have the highest value and reach? Which use case might be the easiest to implement? By prioritizing value delivered and simplicity, you reduce risk at the same time. Additionally, you might take the cost of delay into account. Don’t build a data product just because you can!
6. Deliver two Use Cases and show initial (small) economies of scale with reusable data products.
The initial goal is to create reusable data products for at least two use cases within the first mover business domain. This will enable you to show the value of reusable data products by being able to deliver the second use case way faster than the first. Imagine the savings in time and effort for use case number 3 and ongoing! This is where you find the beauty of the mesh.
7. Introduce quarterly value-driven portfolio reviews in your domains’ operating model.
Review the impact the use cases and the individual data products have, at least quarterly, with the business domain lead. Reprioritise (if necessary) based on the learnings you have made and focus on the business goals you have defined. Identify which data products can be re-used for other use cases. This is an iterative process that is never really done. Never prioritize data products without a use case.
8. Install a central Program Management to drive scaling.
The Program Management will be helpful in onboarding business domains and their teams to the Data Mesh. At the same time, it will help to set expectations: Business domains won't magically transform their data capabilities overnight. The Program Management will drive internal marketing, education, organizational change and build the internal community to encourage cross domain communication and collaboration. The Program Management will assist all business domains on their journey and ensure top management attention once required.
9. Leverage the story of the ‘lighthouse’ project to convince other business executives.
Data Mesh brings immense value, such as elimination of redundancies, faster time to market for data and insights, improved data quality and access. The goal is to find other business executives who will become early adopters and engage in initial community building across domains. The community will be key to identify cross-domain use cases and thus leverage the value of Data Mesh.
10. Keep a balance between organizational development and technology.
It may look appealing to focus on tech only at first glance but it will bite you later. Technology will only show its value together with organizational development. Product thinking and domain ownership are absolutely key to success.
While this is a rather intense guide to introduce Data Mesh in your organization, it isn't as hard as it may seem. I would like to encourage you to follow these steps and promote working from a business perspective. You might align with your IT professionals and make sure the data product teams and data platform teams operate in a DevOps environment. Short release cycles and an optimized path to production are key for fast experimentation in software delivery. Apply the 4 key metrics of Accelerate to monitor the performance of your Data Product Teams. Following these tips should help you to reach a certain maturity. Early Data Mesh alignment on the organizational model doesn't have to be disruptive. A small team will be sufficient for the start.
What are you waiting for?
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
