How I applied data mesh to my organisation

My post the other day on understanding the concepts, and applying them at your organisation reminded me of how I first encountered data mesh, and how I started applying some of the concepts to my organisation.

The original data mesh articles came out at the same time I was starting to think about the problems we had with data and how to solve them.

I felt the root cause of our data problems were:

1. The distance between those producing data and those consuming it, meaning those producing data had no idea what it was being used for, or the challenges using it
2. Building on the raw data, extracted from source systems through change data capture, rather than on data that has been built for consumption

I felt data mesh was broadly attempting to solve those same problems, and I agreed with many of the concepts.

But, it just felt too big. I couldn’t change our entire organisation to the one described there.

So, I took the concepts I thought could help us most (a self-service data platform and a move to decentralised data domains) and combined that with the ideas I already had about an interface (an API-like contract between domains).

I then needed a name I could use internally to drive this.

I didn’t want to call it data mesh internally, as I didn’t want people (especially non-data people) thinking we were driving a large transformation project. I also didn’t want anyone to be turned off by some of the language used in data mesh (quantum, planes, etc).

And that’s pretty much how data contracts started.

Today, while I still don’t talk about data mesh internally, I am still looking at the concepts it described and if there is value in applying them to my organisation.