Data Mesh

Data finds its own path. Design the landscape, not the channel.

I come from coastal engineering. Water is stubborn—it finds the path of least resistance. The harder you force it into rigid channels, the more likely it breaks out or silts up. Data behaves the same way.

Organizations build rigid data channels: pipelines, handovers, governance walls. Then people work around them because they just want to get their job done. You can't force data into structures that don't fit reality.

In coastal engineering, we learned to work with nature instead of against it. Build with natural processes, not concrete walls. Data mesh is the same idea: let data meander through domains that understand it, rather than channeling everything through a central dam.

Design the landscape, not the channel. Give teams space and tools. Set standards so streams connect properly. But don't try to control every drop of water.

Rivers silt up without maintenance. Data quality degrades without ownership. The key is putting maintenance where the knowledge is—with the teams who understand what the data means.

Why you may need a data mesh

The central data team bottleneck

You built a central data lake and hired a data team. It worked well at first. Then the team became a bottleneck.

  • Cannot handle all analytical questions quickly enough
  • Spends too much time fixing broken data pipelines
  • Lacks domain expertise for meaningful insights
  • Creates dependencies that slow down decision-making

Data mesh: let teams manage their data

Let the teams who actually understand the data manage it. They know their domain, they know what the data means, and they can answer questions faster.

  • Domain teams manage their own data products
  • Other teams can consume these products
  • No more central bottleneck
  • Teams that know the data make the decisions

Four principles

Data mesh builds on four ideas

01

Decentralized teams

Teams manage the data they understand. Split data by business domain, like you split software into services.

02

Treat data as a product

Your data serves other teams. Make it good: reliable, documented, and usable.

03

Self-serve infrastructure

Build a platform that lets domain teams create and manage their data products without constant central team involvement.

04

Federated governance

Set standards so data products work together. Define quality rules, security policies, and compliance requirements.

Technical blog

Exploring data mesh patterns, implementations, and architectural decisions

Contact

I'm Kees Pruis, a civil engineer turned data architect. I work with organizations in manufacturing, maritime, and logistics to design data architectures that actually work.