Data mesh isn't a tool, it's an org chart

I've watched four data mesh programmes in three years across mid-to-large ANZ organisations. One worked. The other three rebranded a central data team as the "data mesh team" and changed almost nothing else. The pattern is so reliable I now treat data mesh as primarily an organisational design question, not a technical one, and I screen for the org chart before I'll talk about the platform.

Zhamak Dehghani's original four principles are still the right frame. They're worth restating because most people who use the phrase "data mesh" only remember one or two of them:

1. Domain-oriented decentralised data ownership and architecture.
2. Data as a product, with a product owner inside the domain.
3. Self-serve data infrastructure as a platform.
4. Federated computational governance.

Read carefully, three of those four are organisational claims and one is technical. The technical one, self-serve infrastructure, is the part everyone implements. The other three are the part everyone skips, then wonders why nothing changed.

The pre-conditions nobody wants to talk about

Before a data mesh has any chance of working, four things need to be true. They are organisational, not technical, and you cannot fix them by buying a catalog tool.

A real platform team

Not a renamed central data team. A platform team whose product is the experience of building a data product as a domain engineer. Its success is measured by how many domains can ship without talking to it. If your platform team is also doing the domains' modelling work, it's not a platform team, it's the bottleneck you used to have, with a new title.

Domains that actually want ownership

This is the one that quietly kills most programmes. Marketing does not, in their hearts, want to own the canonical definition of "active customer" and be on call for it. Finance does not want to publish a contract for the GL feed and be paged when it breaks. Ownership has weight, and most domains haven't been told that this is what they're signing up for. If your kickoff doesn't include a frank conversation about who carries the pager when the data product is broken at 9pm, you're not doing data mesh, you're doing domain-flavoured central architecture.

Self-serve infra that is genuinely self-serve

The test: can a domain engineer who has never spoken to the platform team provision a new data product end-to-end, storage, pipeline, schema registry, lineage capture, access policy, observability, in a working day? If the answer involves a Jira ticket to anyone, you don't have a platform yet. You have a managed service with a self-serve veneer.

Executive air cover for hard conversations

Federated governance means the central body sets a small number of cross-cutting policies, interoperability, privacy, naming, and the domains own everything else. This requires an executive who is willing to back the platform team when Marketing wants to ship a metric that violates the interop standard. Without that backing the standard becomes a suggestion and the mesh becomes a swamp.

The failure mode I see most often

A central data team reads the book, gets excited, picks a tool, usually a catalog like Collibra or DataHub plus a lakehouse, and announces a data mesh initiative. Six months later there's a slick portal listing "data products" that are, on inspection, the same tables the same central team has been producing for years. The domains haven't taken on ownership. The platform team is still doing domain work. Governance is still centralised, just with a federated-sounding name.

This isn't a failure of the team. It's a failure to acknowledge that the ask of the rest of the organisation never went through. You can't impose decentralisation. You can only build the conditions under which domains volunteer for it, usually because the central team has become so visibly slow that volunteering looks attractive.

A smaller alternative for orgs that aren't ready

If your organisation isn't ready for full mesh, and most aren't, there's a useful intermediate move. Pick one high-value domain that is already analytically mature (often Finance or a Product analytics group), and run the mesh playbook on just that domain. Give them a product owner for their data, a contract with consumers, and platform support. Leave everything else centralised.

Pair that with a federated catalog that the central team and that one domain both publish into, with consistent metadata and lineage. You now have a working example of the model on one domain, a platform team that has had to confront one real customer, and a catalog that proves the federated governance idea on a small surface area. From there you can either expand or stay where you are. Both are reasonable outcomes; pretending you've done a full mesh when you haven't is not.

What technology choice actually matters here

Once the org conditions are real, the technology choices are mostly boring and mostly fine. A lakehouse, Databricks or Snowflake or Iceberg-on-something, gives you the storage and compute layer. A catalog with lineage, DataHub, Collibra, OpenMetadata, gives you the discovery surface. A schema registry and contract testing framework gives you the interop story. None of these is the differentiator. The differentiator is whether the domain that owns the customer data product also carries the pager when it breaks.

Bottom line

If you're considering data mesh, audit the org chart first. Do you have a real platform team, domains that want ownership, genuinely self-serve infrastructure, and executive cover for hard governance calls? If three of those aren't true, do the smaller version on one domain and tell the truth about it. You'll get more value than a half-built mesh, and a much better read on whether your organisation actually wants the full thing. Where I'm uncertain: there's a version of this argument that's too pessimistic about how quickly orgs can change. The one programme I've seen work changed faster than I would have predicted, mostly because a single executive made the conditions real. I don't know how to manufacture that executive.