Noise, Confusion and the Reality of Data Mesh

Right now, everyone's talking about Data Mesh, but few are getting it right.

Instead of practical solutions, we're hearing theoretical frameworks. Instead of business impact, we're being fed platform diagrams. Instead of simplifying, we're over-engineering.

As Cameron Price recently pointed out in his blog "The Data Catalyst: Shaping the Future of Data-Driven Alliances", many implementations of Data Mesh are being led by well-meaning but inexperienced voices, people who understand the architecture, but not the outcomes. People who've never had to chase down data for an urgent campaign or sit in front of a CFO trying to explain why the numbers don't match.

Even Zhamak Dehghani, the originator of the Data Mesh concept, recently noted that most organizations are "naming the problem instead of solving it".

And as Forrester's Michele Goetz said, there are so many conflicting interpretations of Data Mesh now that it's causing a paralysis of choice and understanding.

"Gartner's recent Hype Cycle positioning reflected growing concern around the complexity, over-marketing, and implementation challenges surrounding Data Mesh initiatives."

This is a problem.

At Data Tiles, we believe the industry drifted away from the original promise of Data Mesh: putting trusted, governed data directly into the hands of the business.

In another recent blog, Cameron Price tackled the myth that data engineers should be the creators of data products. "Data Products Should NOT Be Built by Data Engineers". He said it plainly, and I agree:

Engineers are critical to scale, security, and operational excellence, but they should not be expected to define the business meaning behind every data product.

They're not your marketing team.

They're not your sales manager.

They're not your operations lead.

They don't know the business context behind the data. And without that, you can't build a useful data product.

This sentiment is echoed by Monte Carlo CEO Barr Moses, who reminds us that "data products are not just datasets or dashboards. They are experiences tailored to business needs."

One of the biggest misunderstandings in modern data programs is that ownership still sits primarily with centralized technical teams, when the real business context lives within the domains themselves.

David Vellante from theCUBE, in his analysis of JP Morgan's Data Mesh model, said it best: "The business domain should own the data end-to-end, rather than have to go through a centralized technical team."

That's the promise of Data Mesh. Domain ownership. True decentralization. Actual accountability.

At Data Tiles, we believe in this. That's why we built Latttice, to let domain experts build their own data products using plain language and zero code.

Another idea we need to drop:

It's wishful thinking, and it's holding businesses back.

The reality is that most enterprise data environments are fragmented, constantly changing, and shaped by years of operational complexity. Source systems were rarely designed for modern analytics, AI, or business-led data sharing. Waiting for "perfect" source data before enabling access simply creates more delays, more bottlenecks, and more dependency on technical teams.

What matters more is creating trusted feedback loops around data usage, governance, monitoring, and adaptation over time.

As Cameron Price put it in "Why Data Contracts Don't Solve Data Quality", contracts and rules don't magically create clean data. "Data quality isn't about strict rules; it's about trust, monitoring, and adaptability."

Peter Aiken puts it more bluntly: "An organization without a high level of maturity, or with bad data, can't even have a conversation about Data Mesh."

And Gartner agrees: most organizations lack the data maturity and governance discipline to support source-level quality control.

Harvard Business Review goes further, saying that unless you build a culture of shared data ownership and quality feedback loops, the entire initiative will collapse under misaligned expectations.

Let's be realistic. Data Mesh isn't about perfect data. It's about usable data. Timely data. Governed, trusted, and good-enough-to-decide data.

Strip back the marketing and the pattern is hard to miss. "Self-service" rarely means a business user actually serving themselves. It means raising a ticket, waiting in a queue, and hoping an engineering team has the bandwidth to translate the request. The vocabulary has moved on; the operating model hasn't.

Too often, transformation programs unintentionally create dependency rather than capability. Long implementation cycles, heavily engineered delivery models, and operational complexity slow the very business outcomes these initiatives were meant to accelerate.

The consequences of this disconnect are now showing up across the industry in failed delivery programs, stalled transformations, and unrealized business value.

The numbers speak for themselves.

These numbers don't signal innovation. They signal a system designed to stall.

Strip away the buzzwords, the architecture diagrams, and the vendor promises, and the reality of a Data Mesh initiative becomes surprisingly easy to assess.

1. 01Can a business team create and share a data product without writing code?
2. 02Is governance embedded in the product, not buried in IT bureaucracy?
3. 03Are engineers focused on scaling and optimizing, or still hand-cranking every pipeline?

Why do organizations cling to this outdated model? Because it keeps control, and budgets, firmly in the hands of engineers and consultants. In an AI-enabled world, their relevance shrinks, but clinging to control doesn't create value, it just delays it. Enterprises that insist on legacy practices will watch faster, leaner competitors overtake them.

AI is accelerating a shift the industry has resisted for years: moving data interaction closer to the business user instead of further into technical bottlenecks.

As we talk about domain empowerment and decentralization, we can't ignore the transformative role of AI. In her recent blog "AI Is the Horse-and-Car Moment for Data Engineering", Lili Marsh makes a compelling case that AI isn't just an accelerator, it's a game-changer. Like the shift from horse-drawn carriages to cars, AI is redefining how we think about data roles, especially in engineering.

Instead of fighting the change, Lili encourages us to embrace it: letting engineers evolve their role to become enablers and stewards of automation, while giving domain users the reins. It's a must-read for anyone still debating where engineers fit in a modern data world.

We've overcomplicated a simple idea.

Data Mesh, at its core, is about empowering teams, trusting domain experts, and removing barriers. But the way it's being implemented today? It's full of process, technical jargon, and unrealistic expectations, which creates the barriers it was seeking to resolve.

We need to refocus.

Let the data owners build.

Stop waiting for perfect data.

And amplify the voices of people who've done the work, not just diagrammed it.

Because at the end of the day, what business leaders want isn't more theory, it's access to trusted data, the ability to make decisions at speed when they're needed, and outcomes that move the business forward.

That's why at Data Tiles, we built Latttice: to help domain teams move from chaos to clarity by creating trusted, governed data products where decisions are actually made.

1. Dehghani, Zhamak (2023). "Data Mesh in the Wild." Thoughtworks.
2. Goetz, Michele (2023). Forrester. "Data Mesh Confusion Is Holding Organizations Back."
3. Gartner (2023). Hype Cycle for Data Management.
4. Vellante, David. (2023). "JP Morgan's Data Mesh Transformation." TheCUBE.
5. Moses, Barr. (2023). Monte Carlo Blog. "What Makes a Great Data Product?"
6. Aiken, Peter. (2023). "The Reality of Data Mesh." Industry Podcast Interview.
7. Harvard Business Review. (2023). "Build a Culture of Data Quality That Sticks."