--- title: "What 'Contract' really means in Data Contracts" date: 2026-02-20 description: "Contracts are the interfaces between teams" categories: ["Data Contracts","Interfaces"] source: https://andrew-jones.com/newsletter/2026-02-20-what-contract-really-means-in-data-contracts/ --- # 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](https://2026.datameshlive.com/?ref=andrew-jones.com), where I am speaking and also running [my only workshop this year](https://ddd.academy/implementing-a-data-mesh-with-data-contracts/?ref=andrew-jones.com), 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](https://addyosmani.com/blog/14-more-lessons/), 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. ![Flowchart showing four teams labeled A, B, C, and D connected through data contracts, with arrows indicating data exchanges among them. Team A exchanges data contacts with Teams B, C, and D, while Team D exchanges data contacts with Teams A, B, and C.](https://andrew-jones.com/images/newsletter/2026-02-20/Boundaries-of-ownership-1.png) 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](https://williaminmon.substack.com/p/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](https://seattledataguy.substack.com/p/why-data-pipelines-existl) 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](https://moderndata101.substack.com/p/data-ownership-model)** > 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_](https://data-contracts.com), or if you have it already please leave a review [on Amazon](https://amzn.to/3Nm4lN9). 🆕 I'll be running my in-person workshop, _[Implementing a Data Mesh with Data Contracts](https://ddd.academy/implementing-a-data-mesh-with-data-contracts/?ref=andrew-jones.com)_, in June in Belgium. It will likely be only in-person workshop this year. Do join us! Enjoy your weekend. Andrew