Data Mesh: A Reality Check from the Trenches

In 2022, Data Mesh was the answer to every enterprise data problem. Decentralized ownership. Domain-oriented architecture. Self-serve infrastructure. It sounded perfect.

Fast forward to 2025, and I’ve seen dozens of organizations attempt Data Mesh implementations. Some have succeeded. Most have struggled. A few have quietly abandoned the approach entirely.

Here’s what I’ve learned about what actually works.

The Promise vs. The Reality

The Promise: Empower domain teams to own their data products. Break down the centralized data bottleneck. Scale through federation.

The Reality: Most organizations weren’t ready for the organisational complexity Data Mesh requires.

What Actually Works

1. Domain Ownership (with caveats)

Works when: Domains are clearly defined, teams are mature, and there’s executive sponsorship for cultural change.

Fails when: You try to force domain ownership on teams that don’t have the capability, capacity, or desire to own data.

Reality check: At Westpac, we had domains with 200+ engineers who could absolutely own their data products. We also had smaller domains with 5-person teams who couldn’t take on this responsibility without significant support.

Lesson: Domain ownership isn’t binary. You need a spectrum:

• Full ownership: Mature domains with dedicated data engineers
• Shared ownership: Central team provides templates and support
• Managed service: Central team owns data products for smaller domains

2. Data Products (the good part)

This is the genuinely valuable idea from Data Mesh: treating data as a product with clear SLAs, documentation, and customer focus.

Even if you don’t implement full Data Mesh, adopting data product thinking transforms how teams approach data:

• Clear ownership: Who do I contact if this breaks?
• Quality guarantees: What SLA can I expect?
• Discovery: How do I find the data I need?
• Evolution: How do I request new features?

We’ve implemented data product contracts that specify:

product: customer_360
owner: customer_experience_domain
sla:
  freshness: < 4 hours
  quality: > 99% completeness
  availability: 99.9%
support:
  slack: #customer-360-data
  email: customer-data@company.com

This alone has been game-changing, regardless of organisational structure.

3. Self-Serve Infrastructure (sort of)

The vision: Domain teams can provision data infrastructure without central IT tickets.

The reality: Most domains don’t want to become cloud infrastructure experts. They want guardrails, templates, and reasonable defaults.

What works:

• Paved paths: Pre-configured infrastructure templates
• Golden patterns: “Clone this reference implementation”
• Platform team: Central team that builds self-serve capabilities

We built an internal platform that lets teams spin up:

• Data pipelines (using templates)
• Analytics dashboards (from patterns)
• API endpoints (with governance built-in)

It’s “self-serve” but with heavy investment in making the platform usable. Don’t underestimate this effort.

What Doesn’t Work

1. Expecting Immediate Decentralization

Organizations try to flip a switch and suddenly become federated. It’s chaos.

Better approach: Gradual migration. Start with one or two mature domains. Learn. Iterate. Then expand.

2. Ignoring the Platform Team Requirement

Data Mesh says “federated” but someone has to build and maintain the federation platform. That’s a significant engineering investment.

Budget for a platform team of 8-12 engineers minimum. Otherwise you’re asking domains to reinvent the wheel repeatedly.

3. Underestimating Governance Complexity

When everyone owns data, who ensures consistency? Who enforces standards? Who resolves conflicts?

Decentralized ownership requires more governance effort, not less. You need:

• Data councils: Cross-domain decision-making
• Standards: Non-negotiable patterns for security, privacy, quality
• Stewardship: Someone ensuring the mesh doesn’t become a mess

The Organizations Getting Data Mesh Right

I’ve observed a pattern in successful implementations:

1. They start small: 2-3 domains, prove value, expand
2. They invest in platform: 10-15% of total data team dedicated to self-serve tools
3. They maintain central standards: Federated execution, centralized governance
4. They’re patient: 18-24 month journey, not a 6-month project
5. They customize: They take Data Mesh principles and adapt to their reality

Alternative Approaches Worth Considering

Data Mesh isn’t the only way to solve data scaling problems:

Data Fabric: More centralized, focuses on metadata and automation. Works well for organizations that aren’t ready for federated ownership.

Hybrid Hub-and-Spoke: Central data team with domain-embedded data engineers. You get domain proximity without full decentralization.

Enhanced Centralization: Scale your central team and make them really good at stakeholder management. Sometimes the bottleneck isn’t the model, it’s execution quality.

My Recommendation

Before jumping into Data Mesh, honestly assess:

Prerequisites for Success:

• Clear domain boundaries
• Mature engineering teams in domains
• Executive commitment to multi-year transformation
• Budget for platform team
• Culture that supports cross-functional accountability

If you have 3+, consider Data Mesh.

If you have 1-2, start with data product thinking and enhanced centralization.

If you have 0, fix your foundations first.

The Real Lesson

Data Mesh isn’t wrong, but it’s not a silver bullet. It’s a sophisticated organisational pattern that requires significant maturity to execute.

The valuable insight isn’t “everyone should decentralize.” It’s “treat data like a product, clarify ownership, and invest in self-serve capabilities.”

You can adopt those principles regardless of your organisational structure.

That’s what I’m seeing work in 2025: pragmatic adoption of Data Mesh principles without dogmatic implementation of the full pattern.

Curious about whether Data Mesh makes sense for your organisation? Let’s talk through your specific context and constraints.