Leaky abstractions are ok
All abstractions leak some details of the complexities it is trying to hide.
And that’s ok!
All abstractions leak some details of the complexities it is trying to hide.
And that’s ok!
Your data platform shouldn’t presuppose what can be built upon them.
It should provide the capabilities that allow your users to innovate.
Many of us engineers enjoy building things.
That’s why we’re good at what we do!
There will be times when you look at the data platform you’ve got and think how great it would be to rip it out and start again.
An effective data platform provides the right tooling and abstractions that allow its users to get things done without the need for constant support from your team.
Data contracts are great for declaratively describing the data and the infrastructure you need to make that data available to others and manage it in line with your governance requirements.
The more autonomy your data platform promotes, the more our users can get done without involving us directly.
Your data contract tooling should be designed for data producers.
In many organisations, much of the most important data is produced by in-house software.
While a lot of people associate data contracts with data quality (and I did call my book Driving Data Quality with Data Contracts!), one of the problems data contracts is great at helping to solve for is change management.
When building a (data) platform you end up thinking a lot about the abstractions you are providing, and the trade-offs they cause.
Want great, practical advice on implementing data mesh, data products and data contracts?
In my weekly newsletter I share with you an original post and links to what's new and cool in the world of data mesh, data products, and data contracts.
I also include a little pun, because why not? 😅
(Don’t worry—I hate spam, too, and I’ll NEVER share your email address with anyone!)