Daily data contracts tips

When it comes to defining SLOs, I’m aiming for good enough.

Good enough to meet the requirements of the consumers.

A great analogy for a data contract is an API. So, let’s walk through how I’d decide if I want to build something important to me on a particular API.

In 2012 the authors of the Go programming language published a document that made clear their intention for backwards compatibility:

How many times do you find something that is not working as it should be, and after digging around you find it has no clear owner?

It’s a misconception that data contracts are just for tabular data.

Sure, they work really well for tabular data in a data warehouse, and that’s where many people start their implementation.

What’s the right organisational structure for a successful data contracts implementation?

The reality is every organisational structure is imperfect, and you’re unlikely to be in one that explicitly aligns you with your data producers.

A question I received on a LinkedIn post about change management with data contracts asked (lightly edited for clarity):

Data governance initiatives often deliver a set of rules for people to follow when they create and manage data.

When it comes to data contracts I’m always talking about well structured data.

That’s deliberate, as we use data contracts to make data available to others (teams/groups/domains), and the aim is to provide data that is easy to consume with confidence.

I was asked on LinkedIn how I might approach data contracts with dbt.

I have thought a little about how to apply data contracts to dbt targets, but not a lot and I haven’t done this in practice yet.