In our last post, we addressed the market definition of data mesh.
Now we’re sharing our point of view on how you should implement it.
The most important aspects of data mesh
First, as a socio-technical approach, we believe data mesh is as much about people and culture as it is technology. Yes, technology is integral, but it is not the defining characteristic.
Second, we believe that the two most important aspects of data mesh are:
- Treating data as a product
- Finding a balance between centralization and decentralization that works best for your organizational culture
Why you should treat data as a product
Treating data as a product means bringing product thinking to data management. This is already a common practice applied to software development: a product manager gathers requirements and use cases from end users and defines a roadmap and plan. The product team then executes on the plan, and tests, releases, and iterates in an agile fashion to improve that product.
Product management teams care deeply about whether end users are getting value from the product, and consider factors like feasibility, usability, viability, maintainability, reusability, and scalability in their decision making. Data product management teams can serve the same role for data.
By establishing standards for data products, data product management enables domains and those serving in data ownership roles to curate high-quality data assets that are consumable by business and technical users alike.
The Data Product ABCs framework
For those new to product thinking, the Data Product ABCs framework provides insights into the types of questions data leaders should be asking when developing data products. These include questions about:
- Accountability - e.g., "Who's responsible for this data?"
- Boundaries - e.g., "What is the data?"
- Contracts and Expectations - e.g., "What are the sharing agreements, consented uses, and policies?"
- Downstream Consumers - e.g., "Who are the current consumers?"
- Explicit Knowledge - e.g., "What is the meaning?"
Additionally, domain teams must maintain a consistent and usable interface to their data. Consumers should agree on the style of the interface as it pertains to their needs: well-defined tabular structure, API endpoint, SQL or SPARQL interface, Parquet, Graph, etc.
What’s most important, regardless of the interface, is that the semantics – underlying logic – of the data products are the same. This includes keeping the Contracts and Expectations in place and notifying producers and consumers if something goes wrong.
To cash in on the full value of a data mesh, it’s imperative that your organization establish a documented method of federated data governance that balances centralization and decentralization.
We’ll explore how you do that in the next post in this series.
Learn more about data product creation
For more information about the role of data products in data mesh, download our white paper, The Data Mesh Governance Framework You Can Implement Today. Then, when you're ready to get to work on your first data product, download the Data Product ABCs Worksheet as a guide to kick off your journey.
