Archos Labs
Data as a Decision Infrastructure

Why Data Mesh Fails When No One Owns the Pipe

Rob Angeles4 min readPublished
Share
Why Data Mesh Fails When No One Owns the Pipe

Data mesh fails without clear ownership of the plumbing. Learn how to define responsibility in federated environments and avoid the tragedy of the commons in your data architecture.

Data mesh promises freedom. Teams own their data. No central bottlenecks. Democracy replaces dictatorship. Then the pipes start leaking.

Nobody wants to fix pipes. They want to build products. Analyse customer behaviour. Create dashboards. Not debug why the authentication service stopped working at 3 AM.

This is how data mesh dies. Not from bad architecture. From abandoned plumbing.

The Commons Problem

Data mesh creates a commons. Shared infrastructure everyone uses, nobody owns.

Think about your apartment building's hallway. Everyone walks through it. Nobody vacuums it. Unless someone's explicitly responsible, it stays dirty.

Same with data mesh infrastructure. The authentication layer. The discovery service. The monitoring tools. The network between domains. Everyone needs them. Nobody wants to maintain them.

A financial services company learned this hard. Eighteen months into their data mesh journey, performance tanked. Each team optimised their domain. Nobody optimised the connections. Queries that crossed domains took minutes. The mesh became a web of bottlenecks.

Invisible Until Broken

Plumbing works until it doesn't. Then everyone notices.

Your product team doesn't think about data lineage until they can't trace an error. Marketing doesn't care about schema registry until conflicting definitions break their campaign analysis. Nobody monitors the message queue until it fills up and drops events.

Traditional architectures solve this with centralisation. One team owns everything. They become the bottleneck, but pipes stay fixed.

Data mesh needs something different. Ownership without centralisation.

The Ownership Matrix

Define ownership before building. Not after things break.

Core Infrastructure Ownership

Some things need dedicated owners. Not domain teams pretending to care. Real owners with real accountability.

The mesh platform team owns baseline plumbing. Authentication. Authorisation. Discovery. Monitoring. Not the data—the pipes data flows through.

They're not gatekeepers. They're utility providers. Like city water departments. You control your taps. They keep water flowing.

Interface Ownership

Every connection point needs an owner. Where domains meet, someone maintains the junction.

Domain A publishes customer events. Domain B consumes them. Who owns the contract between them? Not "both teams." Not "whoever complains first." One specific team.

Smart organisations assign interface ownership to data producers. You publish it, you maintain the interface. Consumers can request changes. Publishers decide implementation.

Operational Ownership

Monitoring isn't optional. Every data product needs operational ownership.

This means SLAs. Uptime commitments. Performance targets. On-call rotations. The unglamorous work that keeps data flowing.

Without operational ownership, data mesh becomes a fair-weather architecture. Works great until something breaks. Then finger-pointing replaces problem-solving.

Making Ownership Attractive

Nobody volunteers for thankless work. Make plumbing prestigious.

Recognise infrastructure work in performance reviews. Celebrate reliability improvements like feature launches. Create career paths for platform engineers.

One retail company created "mesh mechanics"—senior engineers who rotate through infrastructure roles. High visibility. Direct impact. Suddenly everyone wanted the job.

The Federation Balance

Data mesh isn't anarchy. It's federation. Like countries with states. Local autonomy, shared standards.

Your mesh needs constitution-level agreements. Who owns what. How conflicts resolve. When central authority overrides local control.

Write these down. Make them explicit. Review them quarterly. Ownership unclear? Fix it before it breaks.

Start With Ownership

Most data mesh implementations start with technology. Kafka clusters. API gateways. Schema registries.

Start with ownership instead. Who maintains each component? Who responds when things break? Who decides standards?

Technology without ownership creates sophisticated failures. Ownership without technology creates simple solutions that evolve.

Your data mesh will hit crisis. Every mesh does. The question: Will you know who owns the fix?

Share
Rob Angeles

Written by

Rob Angeles

Most consulting engagements split the thinking from the doing. Rob doesn't. Principal Consultant at Archos Labs, he owns the full stack — assessment, architecture, delivery — across retail, financial services, healthcare, and government.