Data platforms for data leaders

While yesterday I wrote about prioritising data quality projects, I think it’s important to note that while for many of us the quality does need to be improved, we don’t need to be aiming for perfect.

It’s likely going to be difficult to get a project prioritised if the goal is defined only as “improving data quality”.

After mentioning the title of my talk for apidays in Paris was “Data Contracts: The API for Data”, I had a couple of responses saying that data contracts are not APIs, and that they’re for communication and facilitating an agreement between the generators and consumers of data (or something along those lines).

If you’re building key product features on top of your data, shouldn’t it be as dependable as your software-backed features?

I’m writing this on the train back from Paris, having spent the last few days at the apidays conference, where I gave a talk titled “Data contracts: The API for Data”.

Interfaces are powerful.

I had a really great chat last week with Juan and Tim on their Catalog & Cocktails podcast.

I liked this post by Robert Sahlin and Johan Gunnarsson about how they used BigQueryML to create alerts for cost anomalies.

I get asked a lot if there is, or should be, a standard for a data contract.

I wrote yesterday about how by promoting autonomy we can empower the users of our data platform to take on more ownership and responsibility.