Data Contracts

As a software engineer, we would never make our database directly available to consumers.

Instead, we would always create an API.

I see data contracts as being at the cross-section of best practices.

In particular, they take the best practices from APIs, Data Governance, and Platform Engineering.

I mentioned yesterday how by using friction we can influence how users behave and how the business is organised. That’s because friction is a great lever

Yesterday I wrote about Conway’s law and the challenges it causes in organisations where data teams are placed in a separate part of the organisation to where the data is generated.

Unless the data contract is being used, no one is going to put effort into creating or maintaining it.

Yesterday I wrote how data teams often start with accessibility, which helps you get started, but leads to a number of problems:

I wrote yesterday about the patterns of data contracts, giving a small example. But there are many more patterns that can be applied through data contracts.

Data contracts is really a set of patterns you can apply to your organisation, once you have data contracts defined and containing sufficient information to drive those patterns.

JSON Schema is the most widely adopted representation of JSON APIs. As stated on the website:

Data contracts, like any documentation or specification, will only be kept updated if they are part of the workflow.