Data Mesh: beyond the hype, what actually works in the field

Four principles, three pitfalls, and the lessons of three real deployments in banking, industry and retail.

Since Zhamak Dehghani formalised the concept in 2019, Data Mesh has gone from provocative idea to watchword in executive committees. Few data paradigms have generated so much enthusiasm, or so much disillusion. Market analysts themselves have been cautious: some predicted that Data Mesh would become obsolete before even reaching maturity, others see it as the natural evolution of data management at scale.

So, passing fad or genuine change of model? Our answer, drawn from the field, is nuanced: Data Mesh is not an architecture you buy, it is an operating model you build. And that is precisely where most organisations get it wrong.

Why Data Mesh emerged

To understand Data Mesh, you first have to understand the dead end it is trying to resolve.

For twenty years, the answer to “how do we make use of our data?” was centralisation: a data warehouse, then a data lake, then a lakehouse, fed and managed by a central data team. This model works very well… up to a point.

Beyond a certain size, the central team becomes a bottleneck. It receives requests from every business line, does not grasp the deeper meaning of the data it handles, and spends its time repairing pipelines broken by changes nobody warned it about. Business teams, for their part, wait weeks for a new indicator and end up bypassing the system with their own Excel extracts.

The outcome is well known: an expensive data lake, low trust in the numbers, and a time-to-insight that no longer keeps pace with the business. Data Mesh starts from a simple observation: the problem is not technological, it is organisational.

What Data Mesh really changes

Unlike centralised approaches, Data Mesh rests on four fundamental principles. Each is simple to state, and demanding to implement.

1. Domain ownership of data

Data is managed by the teams that produce it and understand it best: the Credit domain, the Supply Chain domain, the Customer domain. The central data team no longer “owns” the sales data; the Sales domain does.

What this means in practice: a clear breakdown of domains, often inspired by Domain-Driven Design, and named owners for each scope.

2. Data as a product

Each domain exposes its data as data products: documented, reliable, discoverable assets that others can use, with an explicit service level. A good data product has an owner, identified users, a contract (schema, freshness, quality) and a roadmap.

What this means in practice: a Data Product Owner role, tracked quality indicators, and a focus on consumer satisfaction, as for any product.

3. Self-service infrastructure

So that each domain can produce data products without becoming a fully fledged data engineering team, a platform team provides standardised capabilities: ingestion, storage, transformation, cataloguing, access control, observability.

What this means in practice: a platform designed as an internal product, with golden paths that make good practice easier than workarounds.

4. Federated governance

Decentralisation is not anarchy. A common framework defines the rules that apply to everyone: interoperability standards, security, regulatory compliance, shared semantics. These rules are decided collectively by the domains and the platform, and as far as possible enforced automatically by the platform (policy as code).

What this means in practice: a representative governance body, a limited number of non-negotiable rules, and their automation.

The key point: these four principles form a system. Remove one and the other three collapse. Autonomous domains without a platform burn out; a platform without data products is just another data lake; data products without federated governance cannot talk to each other.

In theory, all of this sounds crystal clear. In practice, these principles involve a deep organisational transformation that touches roles, budgets, incentives and culture.

The most common pitfalls

Pitfall 1: starting with technology rather than organisation

This is the most frequent mistake, and the most expensive. Won over by vendor pitches, many companies invest in costly platforms before clarifying who is responsible for what.

The symptom is easy to recognise: a programme called “Data Mesh” whose first deliverable is a technology tender. Eighteen months later, the platform is in place, but no domain uses it, for lack of owners, skills and motivation.

Our recommendation: start by mapping the domains and the priority data products. Name the owners. Technology will come to serve an organisation that knows what it wants, not the other way round. A good opening question: “Which five data products would create the most value tomorrow, and who would own them?”

Pitfall 2: underestimating the cultural change

Data Mesh asks business teams to agree to become owners of their data, with the responsibilities that entails: quality, documentation, availability, support for consumers.

For many business departments, this is a new burden, perceived as a transfer of work from IT to the business. Without a clear counterpart (budget, headcount, recognition, visible benefits), resistance is immediate and legitimate.

Our recommendation: treat Data Mesh as a change management programme, not as an architecture project. Build data objectives into the domains' objectives, fund the Data Product Owner roles, and quickly show what the domain gets in return: more autonomy, shorter lead times, AI use cases that finally become possible.

Pitfall 3: neglecting federated governance

Without a clear governance framework, Data Mesh quickly turns into a decentralised data swamp: each domain publishes its data with its own conventions, customer identifiers no longer match, definitions diverge (“an active customer”: what does that mean in your company?), and GDPR compliance becomes impossible to demonstrate.

The opposite mistake exists too: recreating heavy central governance that approves every data product in committee, rebuilding exactly the bottleneck you wanted to remove.

Our recommendation: define a minimal set of non-negotiable rules (shared identifiers, classification of sensitive data, data contracts, mandatory metadata) and automate them in the platform. Everything else belongs to the domains' autonomy. Governance that cannot be automated does not scale.

Success factors: what we have observed in the field

We have supported three Data Mesh deployments in very different contexts: a banking player, a manufacturer and a retail chain. The stakes were not the same (regulatory pressure for the bank, IoT and supply chain data for the manufacturer, omnichannel customer knowledge for the retailer), but the successes share three things.

Data Mesh redistributes responsibilities, budgets and sometimes power. No data team, however competent, can impose this change on business departments alone. In all three cases, a member of the executive committee (a CDO reporting to the CEO, a COO, or a CIO with an extended remit) championed the programme, arbitrated scope conflicts and protected the budget during the less visible phases.

The signal to watch: if your sponsor cannot explain in two sentences why the company is committing to Data Mesh, the programme is in danger.

2. Domain teams trained and involved from the start

The domains that succeeded did not “receive” Data Mesh, they co-built it. They took part in the domain breakdown, in defining the first data products and in the governance rules. They also benefited from practical training: what a data product is, how to write a data contract, how to measure quality.

A practice that has proven itself: start with one or two volunteer pilot domains, high in value and with sufficient data maturity, then use their success as a showcase to bring the next ones on board.

3. A self-service platform that is genuinely usable

“Self-service” is probably the most overused term in the data ecosystem. A truly self-service platform lets a domain team create, publish and monitor a data product without opening a ticket. In our three deployments, the platform was run as a product, with its own team, its internal users, its adoption metrics and genuine care for developer experience.

The key metric: the time it takes for a domain team to publish its first data product in production. If it is measured in months, the platform is not self-service yet.

Data Mesh and AI: a natural alignment

One point deserves emphasis, because it changes the picture in 2026: the acceleration of generative AI and agentic AI use cases makes the principles of Data Mesh more relevant than ever.

AI models and agents need data that is reliable, documented, contextualised and governed. That is exactly the definition of a good data product. The metadata, shared semantics and data contracts that Data Mesh requires are precisely what allows an AI assistant to find the right data, understand it and use it appropriately. Conversely, a data swamp feeding an AI produces only confident, wrong answers.

In other words, organisations investing today in quality data products are not just building their data architecture: they are preparing their ability to industrialise AI.

Is Data Mesh right for you?

Data Mesh is not a universal solution. Before you commit, ask yourself these questions honestly:

Is your organisation of significant size, with several distinct business domains producing and consuming data?
Has your central data team become a bottleneck that the business has identified as such?
Are your business domains clearly delineated and do they have a minimum level of data maturity?
Do you have an executive sponsor ready to champion a multi-year transformation?
Are you ready to invest in a platform team run like a product team?

If you answer “no” to most of these questions, a well-governed centralised architecture, possibly enriched with some practices drawn from Data Mesh (data products, data contracts), will probably be more effective and less risky. Data Mesh is not a dogma: its principles can be adopted gradually and partially.

Conclusion

Data Mesh has suffered from its own media success. Presented as an architecture to buy, it disappointed. Understood for what it really is, an operating model that brings responsibility for data closer to the people who know it, it delivers on its promises.

For organisations of significant size, with well-defined business silos, it is an approach that delivers: provided you start with the organisation rather than the technology, invest in culture as much as in the platform, and build federated governance that is both lightweight and automated.

The question is therefore no longer “should we do Data Mesh?”, but “which Data Mesh principles can create value in our context, and in what order?”

Considering a Data Mesh initiative or looking to assess your organisation's maturity? Logbrain's experts, a pure player in data, AI and cloud, support you from the organisational framing to the implementation of your self-service platform. Let's talk about your situation

Data Mesh: beyond the hype, what actually works in the field