Building a data mesh at enterprise scale: lessons from the field

Data mesh is one of the most discussed architectural patterns in enterprise data. The idea is compelling: decentralise data ownership to the teams that understand the data best, and treat data products with the same rigour as software products.

We've helped several enterprises move toward data mesh architectures. Here's what we've learned.

The problem data mesh solves. Centralised data teams become bottlenecks. By the time an analytics request gets prioritised, scoped, built, and deployed, the business need has often changed. Domain teams know their data best, but don't have the infrastructure or skills to productise it.

What actually changes. Data mesh is primarily an organisational change, not a technical one. It requires domain teams to take ownership of their data products — which means they need data engineering skills, or access to self-service infrastructure that doesn't require deep expertise.

The hardest part: data contracts. For data mesh to work, producers need to publish data contracts: schemas, SLAs, quality expectations. Getting domain teams to commit to these contracts — and hold themselves accountable when they break them — is harder than any technical implementation.

The technology layer. A data mesh requires a self-serve data platform: a governed catalog, infrastructure templates, and standardised tooling that any domain team can use without deep data engineering knowledge. Building this platform is significant investment, and shouldn't be underestimated.

When to choose it. Data mesh makes sense at scale — when you have multiple large domain teams, high data volume, and clear ownership boundaries. It's overkill for smaller organisations, and the organisational investment may not pay off for another two to three years.