What 'Contract' really means in Data Contracts

Hey! Hope you’re well :)

Today I write about what ‘contract’ really means in data contracts (hint: it’s interfaces!).

There’s also links to articles on ontologies, why data pipelines exist, and how data quality is always an ownership problem.

Also, early bird pricing for Data Mesh Live, where I am speaking and also running my only workshop this year, ends on 28th February (next week!). Don’t miss out!

What ‘Contract’ really means in Data Contracts

In 14 More Lessons from 14 years at Google, Addy Osmani writes:

6. You can’t “communication” your way out of a bad interface between teams.

Team interaction modes exist for a reason: collaboration (working closely together), service (clear API and SLAs), or facilitation (one team helping another build capability).

Most cross-team pain isn’t about effort or good intentions. It’s about unclear boundaries and messy contracts. I’ve watched teams “improve communication” by adding more meetings, more Slack channels, more syncs - and it doesn’t make things better.

The problem isn’t that people aren’t talking. It’s that the interface between teams is undefined. Who owns what? What’s the contract? What can team A depend on team B for, and vice versa?

Choose deliberately, and you’ll need fewer meetings to make things work. Try to paper over a bad interface with communication, and you’ll burn out your most collaborative people while the underlying dysfunction remains.

This is exactly what the word contract in data contract is meant to mean.

The data contract defines this interface between systems that produce and consume data, so that we don’t have to rely solely on communication to decide whether a data consuming team/service can depend on a data providing team/service to provide reliable, quality data that meets their use cases.

It removes ambiguity and assumptions and allows that decision to be made quickly.

It codifies this in platform features that ensure the data contract in code matches the data contract that’s been agreed, allowing data consumers to build on the data with confidence and for the long term.

I’m not saying you shouldn’t focus on good communication with stakeholders and people in other teams—that’s still really important for many reasons—but the only way you can confidently depend on the output of another team is to have a contract-backed interface such as an API, a software library, or a data contract.

Interesting links

ONTOLOGIES - SOME PERSPECTIVES by Bill Inmon and Jessica Talisman

The word “ontology” is widely used in IT circles, but hardly anyone knows what an ontology really is.

I thought this was just me 😅

This is a long but great read on what exactly ontologies are and the problems they solve.

Why Data Pipelines Exist by Ben Rogojan

If all your data pipeline is doing is moving data from A to B, you’re doing it wrong! Instead, think about the business outcome they deliver. Great post.

Never seen a data quality issue that wasn’t actually an ownership problem by John Wernfeldt

Data quality becomes a proxy for unresolved ownership. But quality cannot exist in a vacuum. It only improves when someone is accountable for the outcome. Until then, every fix is temporary.

Being punny 😅

I have written a book on how to fall down the stairs. It’s a step by step guide.

Thanks! If you’d like to support my work…

Thanks for reading this weeks newsletter — always appreciated!

If you’d like to support my work consider buying my book, Driving Data Quality with Data Contracts, or if you have it already please leave a review on Amazon.

🆕 I’ll be running my in-person workshop, Implementing a Data Mesh with Data Contracts, in June in Belgium. It will likely be only in-person workshop this year. Do join us!

Enjoy your weekend.

Andrew