Data Contacts

Responding to yesterdays post on LinkedIn, Anna Bergevin wrote:

I agree and interface makes things less tightly coupled. But in order to change this we’d need a big cultural change at the company to seeing publishing data for secondary use cases as a core function of the job. Part of why data teams go in and get the data vs the other team publishing an API is because it’s the data team’s whole job to make data available and takes minimal effort from the software/system team. If the team is expected to make and maintain an API (including change management) that is a LOT of extra work. […]

I came across this on LinkedIn (as a screenshot from Bluesky) this morning.

Good software teams change their database schemas all the time, to add features, improve performance, fix bugs, and so on.

Jesse Anderson ran a survey which had some interesting results. One of the key takeaways that stood out to me is this:

More than anything else, your success is determined by your communication.

That includes:

• Using different formats for different results (newsletters, workshops, tech talks, meetings, etc)
• Celebrating success, and admitting where you got things wrong
• Building relationships with people in different teams and roles
• Using the right language for the audience

You could have the best platform, but without communication your adoption of data contracts, or any transformation, will not be a success.

Rather than wait for high-value projects to come in through your ticket system. Go out and find them.

If you’re looking at implementing data contracts or moving towards a data mesh you will hear a lot about shifting left.

Great data platforms reduce organisational complexity.

They:

• Establish standards, such as processes, interfaces and guidelines, by providing a golden path for teams across the organisation to follow
• Automate tasks, particularly around data governance, allowing users of the platform to focus on what they do best - delivering value
• Ease integration, allowing data to flow between different systems, applications and users seamlessly, preventing silos

Building a platform on data contracts enables each of these.

When:

• One team provides infrastructure for another
• One team provides code libraries for another
• One team provides an API for another
• One team provides data for another

Each of those are a product being delivered by one team to the next, and that product must meet the consumers requirements.

Data contracts are great for declaratively describing the data and the infrastructure you need to make that data available to others and manage it in line with your governance requirements.