Data contracts: Hur du dödar broken pipelines för alltid

De flesta brutna pipelines jag felsökt har samma grundorsak. Någon ändrade en kolumn långt uppströms utan att veta att tio nedströms berodde på den. Ingen gjorde fel med flit, det fanns bara inget avtal om vad som fick ändras. Data contracts gör det avtalet explicit, och i den här texten beskriver jag hur jag inför dem utan att skapa byråkrati som ingen orkar med.

Jag vill genast avliva en vanlig farhåga. Data contracts låter byråkratiskt, som ännu en process som saktar ner team som redan har fullt upp. Men poängen är den motsatta. Utan kontrakt ägnar team enorm tid åt att felsöka saker som gick sönder utan förvarning, och åt den ständiga oron att en ändring någon annanstans tyst ska sabotera deras arbete. Ett kontrakt byter ut den otrygga gissningsleken mot tydliga förväntningar, vilket faktiskt frigör tid.

Vad ett data contract är

Ett data contract är en överenskommelse mellan den som producerar en datamängd och de som konsumerar den. Det beskriver schemat, betydelsen av fälten, vilka garantier som gäller och hur förändringar ska hanteras. Det förvandlar underförstådda antaganden till något skrivet som kan kontrolleras automatiskt.

Problemet det löser

Utan ett kontrakt är varje nedströmskonsument beroende av att producenten råkar låta bli att ändra saker. När producenten oundvikligen ändrar något går något sönder, ofta tyst, och felet upptäcks först när någon undrar varför en siffra ser konstig ut. Kontraktet gör beroendet synligt och ändringar förutsägbara.

Vad jag lägger i ett kontrakt

• Schema: vilka fält som finns, deras typer och vilka som är obligatoriska.
• Semantik: vad fälten faktiskt betyder, så att ingen gissar.
• Garantier: hur färsk datan är och vilken kvalitet konsumenten kan räkna med.
• Förändringsregler: hur en ändring aviseras och hur lång varseltid som gäller.

Att etablera den här typen av tydlighet mellan team är något jag ofta gör som en del av vårt arbete med dataplattform, eftersom det löser en organisatorisk smärta lika mycket som en teknisk.

Att kontrollera kontraktet automatiskt

Ett kontrakt som bara lever i ett dokument hjälper föga. Jag kopplar det till pipelinen så att en ändring som bryter mot kontraktet stoppas innan den når produktion. Då blir kontraktet en grind, inte en god intention. Producenten får veta direkt att en ändring skulle skada konsumenter, medan det fortfarande går att rätta.

Versionering och bakåtkompatibilitet

Ett kontrakt är inte hugget i sten, det måste kunna utvecklas. Frågan är hur. Jag skiljer på förändringar som är bakåtkompatibla, som att lägga till ett nytt valfritt fält, och de som bryter, som att ta bort eller byta typ på ett befintligt fält. De första kan oftast införas utan dramatik, medan de andra kräver en planerad övergång där konsumenterna får tid att anpassa sig. Att versionera kontraktet, så att en gammal och en ny version kan samexistera under en period, gör brytande förändringar hanterbara i stället för katastrofala. Utan den möjligheten tvingas alla ändra samtidigt, vilket sällan fungerar i en organisation av någon storlek.

Den organisatoriska sidan

Data contracts handlar lika mycket om människor som om teknik. De tvingar producent och konsument att prata med varandra om vad som faktiskt behövs. Min erfarenhet är att den dialogen i sig löser hälften av problemen, eftersom mycket av friktionen kommer av att team inte vet vad andra förlitar sig på.

Vem som äger kontraktet

Den svåraste frågan kring data contracts är sällan teknisk utan handlar om ägarskap och ansvar. Vem bestämmer vad kontraktet ska garantera, och vad händer när producenten vill ändra något som konsumenterna är beroende av? Om producenten ensam bestämmer riskerar konsumenternas behov att ignoreras, och om konsumenterna får veto blir producenten förlamad. Jag försöker etablera en lättviktig process där ändringar i kontraktet aviseras och diskuteras, men där det också finns ett sätt att fatta beslut när parterna inte är överens. Det handlar mer om kultur än om verktyg.

Börja där det gör ont

Jag inför inte kontrakt på allt. Jag börjar med de datamängder som oftast orsakar incidenter eller är mest kritiska, och bygger ut därifrån. Ett kontrakt på den viktigaste tabellen ger mer värde än tio kontrakt på sådant ingen rör. Över tid täcker du det som faktiskt betyder något. Fler exempel finns i vår casebook.

Relaterat

• BigQuery-dataplattform från noll: Referensarkitektur 2026
• dbt-projektstruktur: Mappar, modeller och tests som skalar
• ETL vs ELT vs Reverse ETL: Modern data stack för svenska bolag

Vill du ta det vidare?

Om dina pipelines gått sönder en gång för mycket och du vill ha ett strukturerat sätt att stoppa det, hör av dig via kontaktsidan. Jag hjälper dig införa data contracts utan onödig byråkrati.