Data mesh is an org design pattern. Here are the 5 things you need before you start.
Most “data mesh failures” come from starting before the org was ready. The pattern requires preconditions. If they’re missing, no tooling will save you.
Five prerequisites. Score yourself 1-5 on each.
Domain ownership maturity. Do your domains already own their own services, APIs, and on-call? If software ownership is centralized, data ownership won’t magically decentralize.
Self-serve platform. Can a domain team spin up infrastructure without filing a ticket? If they need central platform team approval for everything, “self-serve data product” is fiction.
Product thinking. Does your org build products or projects? Data products need owners who think in roadmaps, SLAs, and consumers - not in deliverables and end dates.
Federated governance. Can you make decisions where some standards are global (security, PII, naming) and others are local (schema choices, transformation logic)? Most orgs are either fully centralized or fully chaotic. Mesh requires the middle.
Engineering maturity. Do your domain teams have the engineering bench to operate a data product? CI/CD, testing, observability, on-call rotation. If they barely keep their service running, adding a data product is overload.
The #1 predictor of mesh success: domain ownership maturity. If the rest of your engineering org doesn’t decentralize, the data org can’t either.
The pattern: most teams who fail at mesh score 4-5 on prerequisite #2 (they bought the platform) and 1-2 on prerequisites #1 and #3. They had the tools without the org maturity to use them.
Score your org 1-5 on each prerequisite. What’s your weakest?