Data Contracts

Data evolves over time, and as such a data contract needs to support that. We do that by ensuring each data contract has a version.

While data products are for people, they still require an interface that allows people to access them - usually through a system such as a database, an analytics tool, a notebook, and so on.

Data is at the heart of every meaningful service, and it’s the effective use of that data which builds a product, and a business.

𝗧𝗵𝗲 𝟭-𝟭𝟬-𝟭𝟬𝟬 𝗿𝘂𝗹𝗲 𝗼𝗳 𝗱𝗮𝘁𝗮 𝗾𝘂𝗮𝗹𝗶𝘁𝘆

One of my favourite talks at Big Data LDN was by Hannah Davies on The Building Blocks of Data Culture During Transformation.

My post the other day on understanding the concepts, and applying them at your organisation reminded me of how I first encountered data mesh, and how I started applying some of the concepts to my organisation.

There’s a lot of great writing out there about interesting ideas like data contracts, data mesh, and much more.

David Jayatillake published an interesting post recently titled “We don’t need data contracts”. The title was enough to ensure it caught plenty of attention… but the subtitle more accurately describes what David is arguing for: “We need data to be part of product engineering”.

The definition and evolution of the data contract should be a collaboration between the data producers and the data consumers.

Someone reached out to me and asked me to present on data contracts to their organisation after they had a data quality issue that directly resulted in multi-million dollars of lost revenue.

It can be tempting to view data contracts as a large program that requires support from the top of the organisation to be successful.