I’ve been pretty opinionated with customers, colleagues, and attendees to my various conference sessions. I don’t like Data Mesh. I don’t think it works.
That’s not the full story though. It’s not inherently wrong or deeply flawed as a concept. The problem isn’t Data Mesh, its us.
What is Data Mesh?
If you’ve avoided everything Data Mesh over the past 6+ years, and not read Zhamak Dehghani’s book on it, I’ll boil it down for you;
It’s an operating model. Data Mesh describes a data culture where each domain (think business unit or team) owns their own data. They are responsible for producing, cleaning, and maintaining the data from that domain. That includes data quality, documentation, access, and its reliability. This means the team responsible for the data is the one most familiar with it, its purpose, and its uses.
This approach reduces or eliminates any bottleneck on a centralised team, which may still exist but generally serve as a guiding hand for common standards, governance and enabling domain teams.
Overall, Data Mesh drives a few key principles:
- Ownership – the data should be owned by the teams that know it the best. They serve it to the business, not IT.
- Platform enablement – A central team provides shared infrastructure, tooling, and guardrails so domain teams don’t reinvent the basics.
- Federated governance – Standards and controls are defined centrally but applied locally, balancing autonomy with consistency and trust.
All of this is tech agnostic, and as you’re probably thinking, is more about people and process than it is about technology. And that’s where the problem lies.
This isn’t Star Trek
The analogy I like to use when I describe why data mesh doesn’t work is that we don’t live in Gene Roddenberry’s world. This isn’t a future where everyone cooperates for the good of the human race, with a single unified vision and drive.
In practice, Data Mesh needs a lot of things in place for it to work with any level of success, primarily these three building blocks;
Clear domain boundaries and empowered owners
For domains/departments to take ownership of their data they need to already exist. There needs to be a cultural understanding of the value of their data. You can’t just hire a “Sales Data Manager” and call it a day. Each domain will need technical practitioners, sure. But they must also want to own their data as a team and know where that responsibility and ownership starts and ends.
I’ve seen this evolve in motion when working with a customer. When I steered them towards thinking about what data they needed to do their jobs, and what information would make their job easier they started to get invested. We hadn’t talked sources, tables, tools or anything yet.
The skills and the time to own data properly
I have heard many a “Data Steward” grumble that they came to work one day with their new data governance title tagged onto their existing one with no time, training, or interest in supporting the business’ new data quality and governance initiative.
This extends to Data Mesh too. Domains need to have the skills to support the data you want them to own. That may involve additional hiring, retraining, or even migration of centralised team members to domains.
Beyond the technical skills required, if you want all members of the domain to engage with data in a more positive, useful way then they need the time and training to do that too.
I’ve got a whole other post planned on why Data Platforms fail and spoiler: it’s not the tech – it’s adoption.
Mature Governance and Trust
The most successful implementations of Data Mesh are driven by strong governance at every level. I’m not talking about reems of paperwork and processes but a clear understanding of expectations, responsibility, and controls by all areas of the business. The tech should support this, not define it. Here’s a few examples I’ve seen in the wild;
- Automated infrastructure deployments to stand up domains in a consistent, efficient way.
- Training, alerting, and monitoring used to positively support domains instead of create barriers and punish.
- Data quality and observability is an integral part to how data is used across the business.
Leadership, Culture, and Trust…
There are many other factors that I’ve not focused on here but the key takeaway is that you can’t expect a positive outcome without doing the work on these foundational factors.
It’s all about Maturity
This is where I drop the “it’s about the journey, not the destination” cliche. It’s very relevant though and in reality, you aren’t going to reach the 23rd Century where money is no longer required, any time soon.
Adopting a Data Mesh is about planning for and expecting continual change, continual improvement, and continual growth. It’s not all of nothing either. One of the main approaches I advocate for is building out a federated data mesh, retaining control and ownership centrally for shared data and using that model to decentralise over time and as domains mature.
The clients I’ve worked with that have seen the most success here have a central IT team that supports each domain in their journey to become data-driven, to take ownership of their data, and to share that back with the business. Taking them on a journey that hands domains control and responsibility of their data over time.
Where do you start?
There’s no single recipe to fit all situations and I’ve seen similar sized and shaped organisations stumble on very different aspects. There are a few key starting blocks that help you start the journey though;
- Start centralised but design for future federation
- Engage with one or two capable teams to pilot domain ownership
- Federate decision making on domain data first (not the tech)
- Adopt Data Mesh principles – Ownership, data contracts, product thinking
- Consider hybrid models, such as federation. This is normal!
Analytics Masterminds have well-defined Data Strategy Enablement and Data Culture Establishment offerings to support the path to Data Maturity. Get in touch with us to find out more!
