3 steps to getting started with data contracts
Hello!
I’ve been working hard on an online, self-paced version of my Implementing Data Contracts course, and I can’t wait to share it with you! It should be ready in the next week or so, and I’ll send you an email when it is.
For now, onto the newsletter, and this week’s post comes from part of the course and describes 3 steps to getting started with data contracts.
There are also links to articles on dealing with shrinking teams, positive reinforcement for data contracts, and data quality guidelines.
Enjoy!
3 steps to getting started with data contracts
When looking to get started with data contracts I always advise against starting a large migration or transformation projects.
These big IT projects rarely succeed, particularly those that take 6, 12, 18 months to lay the “foundations” before delivering any real value.
Instead, follow these 3 steps.
1. Run some proof of concepts
Identify a dataset where adding data contracts would solve a real business problem and start implementing a proof of concept (PoC) of data contracts to solve that problem.
While it might be perfect if this was the most critical dataset in the business, it doesn’t have to be!
In fact, it’s better to start with a dataset owned by a team who are ready and willing to work with you on this.
This could be a team who has data people in it already, or a team who as both consumers and producers of data understand and agree with the problems you are trying to solve.
Or just a team you have a good working relation with and you know they will be receptive to these ideas.
Whoever it is, get them involved in this PoC early and ensure they feel joint ownership of this PoC, including the problem you are solving together and the solution you are implementing.
2. Build minimal tooling
Once you have identified a PoC and agreed the solution, use the PoC to start building out the minimal tooling you need for your data contracts implementation.
This could be as simple as:
- A way to define the data contract
- Use that data contract to create the interface
- Apply change management on that contract (and by extension, the interface)
This should not be weeks of effort to build! In fact, in my course we do a minimal but working version of this in just 20 minutes.
3. Talk to everyone
This is probably the hardest part!
You need to get really good at communicating the benefits of data contracts to different audiences.
Sometimes that could be software engineers, in which case using the analogy of data contracts being an API for data would likely resonate.
It could be a project manager, and then you might want to highlight how the deployment of interfaces allows their team to move fast without worrying about breaking downstream applications.
It might be the CDO, the CTO, or anyone else.
Just make sure you are using the right language for the person you are talking to.
Repeat
Once you’ve completed your first PoC and demonstrated the value, repeat!
Each time you repeat these steps you are applying data contracts to another dataset, building out more of your tooling, and getting more people onboard with your ideas.
After all, nothing breeds success more than success.
Interesting links
Team got cut. Scope didn’t. by Anton Zaides
Not data specific, but a familiar position for many of us and some good suggestions on how to handle this situation.
The Data Contract Illusion: Why They Fail and How to Fix Them by Julia Bardmesser (on LinkedIn)
Julia suggests positive reinforcement as one way to ensure data contracts work.
I agree, that’s a good tactic and well worth doing!
There’s more to do though, and one of my favourites is to make data contracts useful for as many functions as possible. For example:
- Use the data contract to create and manage the interface (e.g. the table in your data warehouse)
- Use the data contract to alert the right people to data quality issues
- Use the data contract to define and apply access controls
And so on.
The more useful the data contract is, the more likely they will be maintained even as the data evolves.
The team at SYNQ have written up some nice data quality guidelines.
Being punny 😅
To dentists, X-rays are really just tooth pics.
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, or if you have it already please leave a review on Amazon.
Enjoy your weekend.
Andrew