weaving its way into the spotlight over the past few years, as organizations try to find alternatives to centralized data architectures.
I’ve had a front-row seat to watch early adopter teams come to grips with this paradigm shift. I’ll highlight some of early adopter realities that come with being early to the Mesh party.
Over the past few months, I’ve stitched together insights from several conversations with Data Mesh practitioners to see if our threads align. This post highlights the main observations that I see in real implementations.
What is Data Mesh?
For these early adopter insights to resonate with you, I do expect a intermediate to advanced level of knowledge of what Data Mesh is and how it differs from different architecture approaches. But for the sake of completeness I will give a summary based on what I believe is key.
Zhamak Dhegani, who coined the term and wrote the first paper on it in 2019¹, was frustrated with the persistent limitations of “centralized, monolithic data architectures” — particularly data lakes and enterprise data warehouses . The first whitepaper was born out of these frustrations that she experienced at clients.
She came from a strong software engineering background and she believed many of the issues were already well addressed in software architecture but not adopted into the world of data. In short, Zhamak created Data Mesh to scale data practices in the same way modern organizations scale software delivery.
Since then she and others have written books about it and several companies have been created around the topic.
I would like to point out that the building blocks of data mesh are not new concepts, but what is new is the combination of these fundamental principles and applying it to the historically termed “BI” space.
There is a plethora of material available on Data Mesh but it really borrows several fundamental principles and packages it under one umbrella. The four main principles can be seen here:
Early adoption realities
Here I will elaborate on the main early adopter realities of Data Mesh either in projects where I have been involved in or my peers in the industry. At this point I will also refrain from giving solutions, but merely add some commentary on the observations.
Building While Flying
Whether you are an early adopter domain team or part of the enablement teams, during the early days, Data Mesh feels like constructing an aircraft mid-flight. Companies can’t afford to pause operations, so teams must balance short-term demands with long-term architecture goals.
Instead of enjoying in flight entertainment and a relaxing cruising altitude drink, you will be expected to serve water yourself to everyone whilst also patching up the wing.
When facing such a momentous decision, which requires a considerable investment in people and tools, organisations will typically need to select one of these options:
(a) Buy & Build first, then roll out OR (b) Wait for complete alignment before investment
Neither of these will ever be selected, the price tag is too high for the first and there will never be complete alignment, therefor you remain with only 1 logical option, secret option c) Just fly, even though the plain is not fully built
No clear consensus of what a Data Product is
I have personally spent countless hours discussing what a data product is and isn’t. And you will most likely as well if you are implementing Data Mesh.
“What is a data product”, “what types of data products are there”, “when is something reusable vs. consumer orientated”. Often the nuances come in due to our experience with traditional data architectures. For example, how does Mesh correlate with Medallion architecture, Data Vault and dimensional modeling? Can a data product be raw data, a warehouse or a mart? Or is it all of the above, only with domain boundaries drawn around it? What if the data set is used cross domains? Should we create one data product per source that get’s used cross domains.
I was attending a joint Domain Driven Design and Data Mesh Live conference and different speakers also had different takes on the matter. So let’s face it, we can’t exactly agree on it.
Securing Business Leadership Buy-in
Data Mesh cannot remain (but often does) an IT for IT initiative. Transitioning to Data Mesh isn’t just a technical change — it’s a cultural shift. Without top management support, preferably business, the initiative is likely to face resistance. A strong alignment with corporate strategy is essential to push through inevitable hurdles. It should not be seen as an IT only strategy.
There will be several scenarios you find yourself in that you will need to drop the phrase “but it is the strategic direction of the organisation” or something to that extent. Whether it is budget , political or social hurdles.
Growing Pains for Early Adopters
The first teams to adopt Data Mesh will face significant pain points. These can be typical growing pains with any large transformational program, be it integration challenges, platform bugs or Data Mesh specific — like figuring out what a Data Product is as mentioned in the other observed realities.
Making adoption as smooth as possible for these pioneers will increase the likelihood of long-term success. This will most likely lead to several exemptions being granted to the early adopter teams, otherwise they would return to their blissful state of shadow IT.
Existing Process Gaps will be exposed
While the intention of Data Mesh is to ensure scalability and efficiency going forward it will most likely first identify existing gaps in data processes, security, and compliance. Often, early adopters are tasked with fixing these issues, sometimes even facing blame for pre-existing flaws.
The enablement teams should bare the burden and remember the ultimate goal.
Greenfields is nearly impossible
By its nature, Data Mesh is suited for large, complex environments where multiple teams need to collaborate. However, existing IT policies and governance frameworks may not always support decentralization. The teams will most likely not be able to start green fields tailored to a process that is fit for purpose, they will be tied to the hip by a sometimes outdated and archaic rules and processes.
As an example, with roughly 80% of the projects I dived into, the ingestion was still administered from a central team, and not owned by the domain teams, at least in the beginning. This is due to multiple reasons listed here, but not limited to
- Technical skills sits in IT, not in the business domains
- Easier to justify a smaller dedicated team that connects to several sources and makes them available. (Legal is happier)
- Still lots of benefits in standardising the way data is extracted, especially around vendor management and historisation of sources
There is no easy way to define domains and ownership
Defining domains and ownership in a Data Mesh isn’t as simple as drawing lines on an org chart. It requires navigating overlapping responsibilities, evolving business capabilities, and legacy systems that don’t neatly map to current teams. There’s no one-size-fits-all model — what works in one organization may unravel in another.
That being said, mapping it closely to the organisation chart is by far the easiest solution and solves the ownership issue and still seems to be a common application to this question.
Final Thoughts
As with any big oganisational transformation, the early adoption phase can make or break the journey. The reality is, for now it seems that Data Mesh is no different. It is a balancing act of flying the plane while sketching the blueprint, persuading leadership the destination is worth it, and navigating the messy realities of ownership and process gaps along the way.
[1] Dehghani, Z. (2019) How to move beyond a Monolithic Data Lake to a distributed data mesh, martinfowler.com. Available at: https://martinfowler.com/articles/data-monolith-to-mesh.html (Accessed: 13 August 2025).
