Data contracts anti-pattern #3: Vanity SLOs
Hello 👋 Welcome to the third part in my series of data contract anti-patterns, following on from:
This one is all about defining SLOs that actually make a difference.
There’s also links to articles on semantic vs context layers, building a semantic layer at Lyft, and data contracts in KCL.
Data contracts anti-pattern #3: Vanity SLOs
There’s been a top-down directive that every data product needs to have SLOs, and so the data producer sets some, but without any conversation with consumers. The data producer asks “what can I safely commit to?” rather than “what does the consumer need?”.
Their targets are calibrated to avoid alerts, not to reflect consumer requirements.
This happens because the data producers are asked to define SLOs unilaterally, which creates the wrong incentive. Minimising alerts is the rational choice.
This results in targets disconnected from what consumers are actually building against.
Now, low SLOs are not necessarily a problem. If a consumer genuinely only needs data refreshed once a day, a daily freshness SLO is fine. The problem is the target has not been validated with the consumers.
To avoid this anti-pattern SLOs should be negotiated, not declared. The data consumers should be asking for SLOs to be defined because they have a business need to build on this data and need a certain level of reliability/performance. The data producers can then decide if that SLO is one they can commit to. If it is, great! If not, are the costs for the data producer to meet that (investment, rearchitecture, on-call rotas, etc.) worth the return for the business? That’s the negotiation.
Of course, this does require data consumers to be able to articulate the value of the work. If they can do that, and do it well, there’s no reason why the case cannot be made to invest in higher SLOs for data products.
Interesting links
A semantic layer is not a context layer by Yali Sassoon
Interesting read on what a context layer does, and why that is beyond what a semantic layer does (which itself is still valuable).
Metric Semantic Layer: How Lyft Governs and Scales Key Data Definitions by Iraklikhorguani
Related to the above, this is a nice writeup of how Lyft built a semantic layer, driven by metadata, and with a focus on governance and ownership.
Enkinex ODCS Tutorial - Governance as Code by Rodrigo de Alvarenga Mattos
Nice tutorial showing how to define an ODCS data contract in code with KCL.
Being punny 😅
A ship carrying red paint collided with a ship carrying purple paint. Both crews thought to be marooned.
Upcoming events
- 🆕 Lost in translation - Data vs Integration Architecture, 2026.07.21 19:00 CEST (GMT+2), LinkedIn and YouTube Live
- Data Community Conference, September, Online
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