Data contracts and data mesh
There is strong alignment between the goals of data mesh and data contracts.
In fact, data mesh was one of the inspirations behind data contracts.
The articles came out around the same time I was thinking about solving the same problems and when I eventually came up with the concept.
So, they should be considered complimentary, rather than in competition.
What’s missing from data mesh is how, exactly, you provide the tooling that enables the pattern and supports the organisational structures proposed.
Data contracts fills that gap by providing an architecture that provides the interfaces where domain ownership is defined and the expectations around the data products are set, enabled through the delivery of a self-served data platform that automates data governance.
In fact, you probably can’t implement a data mesh without using data contracts.
However, data contracts are an important architectural component even if you’re not attempting to implement a data mesh.
- You still need an interface to the data
- You still need to automate data governance
- You still need somewhere to set expectations
Just like you don’t need to be building micro-services to benefit from good API patterns and tooling, you don’t need to be implementing a data mesh to benefit from data contracts.