---
title: "Interfaces, control, and data contracts"
date: 2025-04-25
description: "In this week's newsletter I write about control.\n\nThere's also links to an article on how metrics influence behaviour, and another on how to work as a data team in \"wartime\" (i.e. when investments are not growing)."
categories: ["Data Contracts"]
source: https://andrew-jones.com/newsletter/2025-04-25-interfaces-control-and-data-contracts/
---

# Interfaces, control, and data contracts

Hey all, hope you had a great week! In this week's newsletter I write about control.

There's also just a couple of links, one on how metrics influence behaviour, and another on how to work as a data team in "wartime" (i.e. when investments are not growing).

Enjoy the weekend :)

---
## Interfaces, control, and data contracts

You can't use data contracts — or anything — to gain control over something owned by someone else.

It's the same as any API or interface.

Stripe could change their API tomorrow, causing breaking changes for everyone who has integrated with it. There's nothing any of those integrators could do to prevent that change from happening, as they have no control over it.

Of course Stripe won't, because they know stability is important to their consumers. In fact, [they invest in a lot](https://newsletter.pragmaticengineer.com/p/stripe-part-2) of tooling and reviewing to prevent this happening, deliberately or otherwise.

The stability of their API is fully in their control. And they agree to take on this responsibility because it's important to their consumers.
  
Similarly, the authors of Pandas could change the `dataframe` interface and release it as a patch release, which would break lots of things for their users. As someone who uses Pandas I can't do anything to prevent that change from happening.

There's an implicit agreement they won't, and instead would create a new major version and provide a migration path. But again, only they have the control here, which means they have the responsibility to manage changes to their library as expected by their users.

That's why the data contract must be owned by the data producer, and not a data consumer.

Only they have control over the data, it's change management, and it's quality.

And they need to be incentivised to take on this responsibility, because it's important to their consumers and, ultimately, the business.

---
## Interesting links

**[Data Science Without Alignment is Just Expensive Maths](https://genevievehayes1.optin.com/newsletter/awlist6259602/MjY5Nzg5Nzc=/data-science-without-alignment-is-just-expensive-maths.htm) by Genevieve Hayes**

Choose success metrics that aligns with business problems.

**[Wartime Data Teams](https://joereis.substack.com/p/wartime-data-teams) by Joe Reis**

Many of us are not getting the investments we were. Instead, Joe argues we should be:

1. Focused
2. Visible
3. Resourceful
4. Collaborative
5. Agile

---
## Being punny 😅

When I started my first job at a bank, I decided to take notes during my training. Or as my manager called it, "stealing".

---

## Upcoming workshops

- **Implementing a Data Mesh with Data Contracts - Antwerp, Belgium - June 5**
	- Alongside the inaugural [Data Mesh Live conference](https://2025.datameshlive.com?ref=andrew-jones.com), where I'll also be speaking.
	- ​[Sign up here​](https://ddd.academy/implementing-a-data-mesh-with-data-contracts/?ref=andrew-jones.com)

---
## 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).

Speak soon,
Andrew