Data mesh in practice: start with ownership, not tools

Data mesh became a big buzzword, and with buzzwords come tools that promise to "give you a mesh." In my experience the tools are the easy part. Data mesh is mostly an agreement about who owns what.

The problem it solves

In many companies one central data team builds every pipeline for everyone. At first that works. Then the backlog grows, the central team does not understand every domain deeply, and every change needs three meetings. The data team becomes the bottleneck.

The idea in plain words

The team that knows the data owns it and publishes it as a product for others to use. A central platform team makes that easy and safe, but does not build every pipeline itself.

What a data product needs

• An owner. A real team with a name, not "the data team."
• A contract. Schema, meaning of each field, and what changes count as breaking.
• A freshness promise. For example, "updated every hour, by ten past."
• Quality checks that run on every load and fail loudly.
• Documentation in the catalog, where people actually look.

What the platform team provides

Shared storage, CI/CD for pipelines, a catalog, access rules and standard quality checks. The goal is that publishing a good data product is the easy path, and publishing a bad one is hard.

In one setup with six teams, moving to this model with clear governance cut our data delivery overhead roughly in half. Speed was only part of it. The real goal was getting every team to trust the same numbers.

Where it goes wrong

• Declaring a mesh without giving domain teams time or skills to own their data.
• No shared standards, so every team invents its own naming and quality rules.
• Splitting too early. Small companies often do better with one good central team.

Start with two or three important datasets, give them real owners and contracts, and grow from there.