weaving its way into the highlight over the past few years, as organizations try to seek out alternatives to centralized data architectures.
I’ve had a front-row seat to observe early adopter teams come to grips with this paradigm shift. I’ll highlight a few of early adopter realities that include 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 major observations that I see in real implementations.
What’s Data Mesh?
For these early adopter insights to resonate with you, I do expect a intermediate to advanced level of information of what Data Mesh is and the way it differs from different architecture approaches. But for the sake of completeness I’ll give a summary based on what I consider is essential.
Zhamak Dhegani, who coined the term and wrote the primary paper on it in 2019¹, was frustrated with the persistent limitations of “centralized, monolithic data architectures” — particularly data lakes and enterprise data warehouses . The primary whitepaper was born out of those frustrations that she experienced at clients.
She got here from a powerful software engineering background and she or he believed lots of the issues were already well addressed in software architecture but not adopted into the world of knowledge. In brief, Zhamak created Data Mesh to scale data practices in the identical way modern organizations scale software delivery.
Since then she and others have written books about it and a number of other corporations have been created across the topic.
I would love to indicate that the constructing blocks of knowledge mesh aren’t latest concepts, but what’s latest is the mix of those fundamental principles and applying it to the historically termed “BI” space.
There may be a plethora of fabric available on Data Mesh but it surely really borrows several fundamental principles and packages it under one umbrella. The 4 major principles might be seen here:
Early adoption realities
Here I’ll elaborate on the major early adopter realities of Data Mesh either in projects where I even have been involved in or my peers within the industry. At this point I can even refrain from giving solutions, but merely add some commentary on the observations.
Constructing While Flying
Whether you might be an early adopter domain team or a part of the enablement teams, throughout the early days, Data Mesh looks like constructing an aircraft mid-flight. Firms can’t afford to pause operations, so teams must balance short-term demands with long-term architecture goals.
As a substitute of having fun with in flight entertainment and a soothing cruising altitude drink, you will probably be expected to serve water yourself to everyone whilst also patching up the wing.
When facing such a momentous decision, which requires a substantial investment in people and tools, organisations will typically need to pick out one in all these options:
(a) Buy & Construct first, then roll out OR (b) Wait for complete alignment before investment
Neither of those will ever be chosen, the value tag is simply too high for the primary and there won’t ever be complete alignment, therefor you remain with just one logical option, secret option c) Just fly, despite the fact that the plain shouldn’t be fully built
No clear consensus of what a Data Product is
I even have personally spent countless hours discussing what an information product is and isn’t. And you may most certainly as well if you happen to are implementing Data Mesh.
“What’s an information product”, “what varieties of data products are there”, “when is something reusable vs. consumer orientated”. Often the nuances are available attributable to our experience with traditional data architectures. For instance, how does Mesh correlate with Medallion architecture, Data Vault and dimensional modeling? Can an information product be raw data, a warehouse or a mart? Or is it the entire above, only with domain boundaries drawn around it? What if the info set is used cross domains? Should we create one data product per source that get’s used cross domains.
I used to be 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 will’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 only a technical change — it’s a cultural shift. Without top management support, preferably business, the initiative is more likely to face resistance. A powerful alignment with corporate strategy is crucial to push through inevitable hurdles. It shouldn’t be seen as an IT only strategy.
There will probably be several scenarios you end up in that you’ll need to drop the phrase “but it surely is the strategic direction of the organisation” or something to that extent. Whether it’s budget , political or social hurdles.
Growing Pains for Early Adopters
The primary teams to adopt Data Mesh will face significant pain points. These might be typical growing pains with any large transformational program, be it integration challenges, platform bugs or Data Mesh specific — like determining what a Data Product is as mentioned in the opposite observed realities.
Making adoption as smooth as possible for these pioneers will increase the likelihood of long-term success. This may most certainly result in several exemptions being granted to the early adopter teams, otherwise they might return to their blissful state of shadow IT.
Existing Process Gaps will probably be exposed
While the intention of Data Mesh is to make sure scalability and efficiency going forward it can most certainly first discover 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 final word goal.
Greenfields is sort of inconceivable
By its nature, Data Mesh is fitted to large, complex environments where multiple teams must collaborate. Nevertheless, existing IT policies and governance frameworks may not at all times support decentralization. The teams will most certainly not give you the option to start out green fields tailored to a process that’s fit for purpose, they will probably be tied to the hip by a sometimes outdated and archaic rules and processes.
For example, with roughly 80% of the projects I dived into, the ingestion was still administered from a central team, and never owned by the domain teams, at the least to start with. That is attributable to multiple reasons listed here, but not limited to
- Technical skills sits in IT, not within the business domains
- Easier to justify a smaller dedicated team that connects to several sources and makes them available. (Legal is happier)
- Still numerous advantages in standardising the best way data is extracted, especially around vendor management and historisation of sources
There is no such thing as a easy technique to define domains and ownership
Defining domains and ownership in a Data Mesh isn’t so 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 a single organization may unravel in one other.
That being said, mapping it closely to the organisation chart is by far the best solution and solves the ownership issue and still appears to be a standard application to this query.
Final Thoughts
As with all big oganisational transformation, the early adoption phase could make or break the journey. The fact is, for now plainly Data Mesh isn’t any different. It’s a balancing act of flying the plane while sketching the blueprint, persuading leadership the destination is price it, and navigating the messy realities of ownership and process gaps along the best way.
[1] Dehghani, Z. (2019) , . Available at: https://martinfowler.com/articles/data-monolith-to-mesh.html (Accessed: 13 August 2025).
