Noise, Confusion - and the Reality of Data Mesh

There’s a lot of noise around Data Mesh. Too much, actually. In this post, I share a few uncomfortable truths: the wrong people are leading the conversation, engineers are being asked to build the wrong things, and we’re still clinging to the myth that data quality starts at the source. This is a call to reset—and re-centre the people who actually need data.

Let’s Talk About the Chaos

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" (Dehghani, 2023).

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 (Goetz, Forrester 2023). Gartner even labelled it as "obsolete before plateau" in its 2023 Hype Cycle report, due to its complexity and over-marketing.

This is a problem.

We Need to Stop Asking Engineers to Build Data Products

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”, Sept 2024). He said it plainly, and I agree:

Engineers are critical—but 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."

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.

Stop Pretending You’ll Fix Data Quality at the Source

Another idea we need to drop:

"Just clean the data at the source."

It’s wishful thinking—and it’s holding businesses back.

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.

The Role of AI in Reinventing Data Engineering

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.

So Where Does This Leave Us?

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 clarity, speed, and results.

That’s why at Data Tiles, we built Latttice—so domain teams can go from chaos to clarity.

Join a data conversation.

Jessie Moelzer.

References:

1. Price, Cameron. (2024). "The Data Catalyst: Shaping the Future of Data-Driven Alliances." Data Tiles.

2. Price, Cameron. (2024). "Data Products Should NOT Be Built by Data Engineers." Data Tiles.

3. Price, Cameron. (2024). "Why Data Contracts Don’t Solve Data Quality." Data Tiles.

4. Marsh, Lili. (2024). "AI Is the Horse-and-Car Moment for Data Engineering." Data Tiles.

5. Dehghani, Zhamak (2023). "Data Mesh in the Wild." Thoughtworks.

6. Goetz, Michele (2023). Forrester. "Data Mesh Confusion Is Holding Organizations Back."

7. Gartner (2023). Hype Cycle for Data Management.

8. Vellante, David. (2023). "JP Morgan’s Data Mesh Transformation." TheCUBE.

9. Moses, Barr. (2023). Monte Carlo Blog. "What Makes a Great Data Product?"

10. Aiken, Peter. (2023). "The Reality of Data Mesh." Industry Podcast Interview.

11. Harvard Business Review. (2023). "Build a Culture of Data Quality That Sticks."