Data mesh has been the number one topic of conversation among the data crowd over the past few years. From the CDO Exchange to Big Data London, which even had a stage dedicated to the subject!
The four principles of data mesh have been debated, dissected, and diagnosed at length via books, blogs, conferences, and roundtables. But doing Data Mesh right can be expensive and undoubtedly a multi-year journey. A journey that is best undertaken in sensible steps for the most businesses.
What is the first step toward a Data Mesh implementation?
Of any of the four foundational data mesh principles, data products are, based on our current industry evidence, the most sensible place to begin.
Firstly though, it’s worth recapping what a data product means in a data mesh context. A data product is a reusable data asset built using data from trusted sources that directly solves a business problem or generates value via robust decision-making.
A data product typically corresponds to one or more business entities such as customers, orders etc. And the key feature of a data product is to make it easy to understand and use, discover and replicate and build upon (with other datasets either sourced centrally, locally, or externally).
In her seminal book ‘Data Mesh,’ Zhamak Dehghani explains the characteristics that set a data product apart from a traditional data mart or asset. A data product needs to be:
- Discoverable
- Addressable
- Understandable
- Trustworthy and truthful
- Natively accessible
- Interoperable and composable
- Valuable on its own
- Secure
She also declares the data product as the basic architectural quantum of a data mesh. To be clear, an architectural quantum is the smallest unit of architecture that can be deployed independently and still have all the structural components to do its job. So, this effectively means that a data product should encapsulate not only the data and its usability characteristics but also the data transformation logic and relevant data governance policies.
Current thinking shows that organisations considering or already implementing data products are grouping them into either analytical data products versus operational data products.
So why start with Data Products?
It’s the easiest to sell to people
Data products are the easiest of the data mesh principles to explain to those who use the data (design, build, and run) and, perhaps more importantly, those who control the data purse strings. Demonstrating that having a data product will give a scalable and repeatable solution that everyone can use and build upon is a powerful message that is more likely to achieve a commitment.
It’s the easiest to show value
Data products will show a return on investment far sooner than the implementation of the other three principles. Arguably get your end-to-end data product(s) right, and the value will be pretty immediate, which in turn will encourage you to do more deployments quicker and faster as momentum is developed.
You can do it under the radar
You can build data products without having to reconfigure your whole data estate. It can be done without needing a big data budget or data programme. You can start designing and building data products immediately if you have the right blend of technical and non-technical data teams working together.
You don’t need to worry too much about tooling
As mentioned above, a data product can be created in Excel (not something we would necessarily advocate!). Still, you don’t have to use expensive data tooling to get going in data mesh. You probably already have all the ingredients to design and build data products from a people, process, and technology point of view.
You don’t even need to worry about Data Mesh
Over recent years, the wider data mesh discussion has driven the debate on data products. But in fact, successful data product deployment can be data mesh agnostic. You can start and end your journey here. There are benefits to pursuing the other three steps. However, doing data products can be a totally discrete activity to enhance your data capability, but beware of the constraints of doing this in isolation.
Sounds Great – But there are some things to think about longer-term
Thinking you’ve done enough
While there might be good intentions to consider data products as only the first phase in a data mesh journey, it can be tempting to stop there and think, “That’s good enough.” Given the strong relationship between data products and data mesh, this might create the false belief that the company has successfully transitioned to a complete data mesh solution.
Struggling to maintain data quality at scale
Implementing data products will surely deliver immediate value and short-term satisfaction for data consumers. However, as the business scales, it will be difficult to maintain data quality without domain ownership due to the gap between data product developers and the domains where data is produced.
Bottlenecks!
If a centralised data team is responsible for maintaining your data products, requests will inevitably get backed up and must be prioritised. This will lead to frustrated data consumers. So data product developers might even be tempted to cut corners on quality or usability under pressure to reduce the backlog. This should be carefully managed, and a clear data product deployment plan should be created to minimise this from happening.
Interested in finding out more?
If you are starting your data mesh journey and wondering where to start, you could benefit from engaging with an experienced consultancy. At The Oakland Group, we help our clients see the big picture and avoid falling into traps like the ones we have talked about in this blog. We can draw on our skills and experience to help you plan your journey and implement your vision to a successful outcome.
Talk to the Oakland Group Team about how to build out your Data Products capability and how we can best assess whether Data Mesh is the right solution for you.
Andrew Sharp is a Principal Consultant at Oakland
