Guide til datakontrakter

Datakontrakter har de siste årene blitt et hett tema i moderne dataarkitektur. Det handler ikke om jus, men om noe mye mer hverdagslig og teknisk; hvordan sikre at data som produseres og konsumeres i ulike team faktisk fungerer sammen – over tid.

En datakontrakt fungerer som et API for data

I takt med at plattformer blir mer desentraliserte, og flere team produserer egne dataprodukter, vokser behovet for tydelige og teknisk validerbare avtaler mellom de som eier data og de som bruker dem. En datakontrakt fungerer som et API for data – en spesifikasjon av struktur, kvalitet og forventninger som både produsenter og konsumenter forholder seg til.

Kort fortalt: datakontrakter reduserer overraskelser, øker kvaliteten og bygger tillit på tvers av team og teknologi.

Problemet datakontrakter bidrar til å løse

Data kan være virksomhetskritiske – men ofte er spillereglene uklare.

Færre feil i dataflyten

Data flyter mellom systemer og mennesker – og ofte skjer dette uten eksplisitte avtaler. I praksis betyr det at når en utvikler endrer en kolonne i en database, kan det føre til at en rapport feiler, en maskinlæringsmodell gir feil, eller et dashboard slutter å virke.

Slike feil oppstår ikke fordi folk gjør feil med vilje – men fordi avhengighetene er skjulte. Ingen har sagt ifra hva som er lov og ikke. Og ingen fanger opp at noe har gått galt – før det går galt.

Link til presentasjon

Datakontrakter gjør disse avhengighetene eksplisitte, og gir verktøy for å teste at de holder. Det gjør det mulig å bygge løsninger som både er selvbetjente og pålitelige.

Bedre støtte til datadeling

Offentlige og sektorovergripende krav stiller også høyere forventninger til strukturert datadeling:

• NOU – Med lov skal data deles stiller krav om tilgjengeliggjøring av offentlige data, inspirert av Open Data Directive og Data Governance Act.
• PSD2 krever API-baserte grensesnitt som åpner nye markeder og øker tryggheten i deling.

Datakontrakter er et praktisk svar på slike krav – og kan sees på som en teknisk implementasjon av prinsippene bak reguleringen.

Økt verdi i større økosystemer

Datakontrakter må være forståelige og implementerbare. Her er det mye å lære av andre standardiseringsforsøk, som har bevist sin verdi over tid:

• HL7 (helse): Svært detaljert, men for komplisert i praksis
• EHF (handel/økonomi): Enkel nok til å fungere, bredt tatt i bruk

Dette er eksempler der datakontrakter gir verdi på tvers av et helt økosystem. Men - vi ønsker oss en implementering av datakontrakter som ligner mer på EHF enn HL7, der minimumskravene på sikt blir standardisert ift et bruksområde, type data og/eller bransje.

Datakontrakter og Data Mesh

I en Data Mesh-organisering er datakontrakter en sentral byggestein.

Data som et produkt

I en data mesh-inspirert organisering deler man opp ansvaret for data til domene- eller produktteam. Disse teamene utvikler egne dataprodukter – ofte i form av tabeller, APIer eller datasett – som andre skal kunne bruke. Dataprodukter må derfor ha tydelige egenskaper: standardiserte, delbare, eid av et team, og forvaltet i hele sitt livsløp. Og husk: ikke alle data kvalifiserer som dataprodukter.

Dataprodukter trenger spesifikasjoner av egenskaper som kvalitet, garanti og service, på samme måte som fysiske produkter:

Når du kjøper en elsparkesykkel, forventer du spesifikasjoner på rekkevidde, garanti og hastighet. Uten disse ville produktet vært vanskelig å selge og umulig å stole på. Det samme gjelder dataprodukter – uten tydelige spesifikasjoner mister datakonsumentene raskt tilliten, og verdien avtar.

Kontrakten operasjonaliserer dataproduktet

Datakontrakten blir bindeleddet som operasjonaliserer «data as a product». Den spesifiserer nøyaktig hva som leveres, kvalitet og frekvens (SLA), og brukes aktivt i CI/CD-pipelinen og kommunikasjonen mellom team. Kontrakten gjør at produsentteamet kan spesifisere nøyaktig hva de lover å levere – og konsumentteam kan stole på at det de bygger oppå ikke plutselig endrer seg.

Eksempler på bruk av datakontrakter

Her er tre eksempler på bruk av datakontrakter:

Eksempel 1: Kundedata i bank- og finanssektoren

Et team i en bank leverer kundedata som dataprodukt til risikostyringsavdelingen. Datakontrakten spesifiserer:

• Oppdatering: hver time, fra kl. 08 til 18.
• Felter: kunde_id, kredittrisiko, lånebeløp, status.
• Kvalitetskrav: ingen duplikater, maks 0,5 % nullverdier.
• Varsling: automatiske varsler ved brudd, integrert med bankens risikostyringssystemer.
• Semantisk definisjon: kredittrisiko beregnes basert på kundens kredittscore, betalingshistorikk og eksterne data.

Dette gjør at risikoteamet raskt kan stole på dataene, og raskere avdekke og håndtere risikosituasjoner.

Eksempel 2: Strømforbruk og nettbalansering i energibransjen

En energileverandør leverer strømforbruksdata fra smarte målere som dataprodukt til nettoperatøren for balansering av strømnettet. Kontrakten spesifiserer:

• Oppdatering: hvert 5. minutt.
• Felter: måler_id, strømforbruk_kWh, tidspunkt, kunde_type.
• Valideringsregler: kun positive verdier; måler_id må eksistere i masterdata.
• Semantikk: strømforbruk_kWh gjelder faktisk forbruk, ikke estimater.
• Prissetting: internfakturering basert på datavolum og oppdateringsfrekvens.
• Varsling: automatisk melding til driftskontrollsystemer dersom verdier uteblir eller er utenfor forventede intervaller.

Dette muliggjør presis og pålitelig balansering av strømnettet i sanntid, samt transparent kostnadsdeling.

Eksempel 3: Vedlikehold av maskiner i industriproduksjon

Et produksjonsteam leverer sensordata for tilstandsbasert vedlikehold av maskiner til et vedlikeholdsteam. Kontrakten spesifiserer:

• Oppdatering: hvert 15. minutt.
• Felter: maskin_id, temperatur, vibrasjon, driftstid.
• Datakvalitet: maks 1 % unormale verdier, 100 % dekning av kritiske maskiner.
• Varsling: automatisk varsling direkte inn i vedlikeholdssystemer dersom kritiske verdier overstiger terskler.
• Semantisk definisjon: vibrasjon og temperatur brukes til å forutsi maskinslitasje basert på definerte grenseverdier.

Vedlikeholdsteamet kan dermed effektivt planlegge vedlikehold før feil oppstår, redusere driftsstans og optimalisere ressursbruk.

Hva inneholder en datakontrakt?

Datakontrakter er en praktisk anvendelse av prinsippet “governance as code”. De fungerer som kontraktsfestede grensesnitt for data, og gjør det mulig å spesifisere og validere forventninger til data – helst så tidlig som mulig i utviklingsløpet. I beste fall inngår kontrakten som en integrasjonstest i CI/CD-pipelinen, slik at feil oppdages før kode og data flyttes til produksjon.

Tre sentrale komponenter

Datakontrakter er en praktisk anvendelse av “governance as code”. En god kontrakt beskriver alltid:

1. Schema – Struktur, kolonner, datatyper, formater.
2. Forretningslogikk – Forventede verdier, null-toleranse, intervaller og domener.
3. SLAer – Frekvens for oppdatering (f.eks. SLA1 for kritiske data hvert 5. minutt, SLA2 for mindre kritiske data daglig).

Kontrakten bør alltid valideres programmatisk i en CI/CD-pipeline. Hvor de håndheves avhenger av organisasjonens arkitektur og teknologistack, men som et minimum bør de overvåkes og ha en prosess knyttet til seg om kontrakten brytes.

Kontrakten som metadataobjekt

I tillegg bør kontrakten ha tydelig:

• ID og versjonskontroll: En unik identifikator for gjenfinning og referanse i pipeline og dokumentasjon, samt grunnlag for å håndtere endringer
• Ressursnavn og namespace: Hvilket konkret datasett eller dataressurs kontrakten gjelder for. Bør være 1:1 (f.eks. vehicle_status i domenet transport).
• Dokumentasjon: Hva betyr dataene? Hvordan brukes de? Dokumentasjon bør være påkrevd.
• Eier: Produsent har eieransvar, kontrakten utvikles sammen med de viktigste konsumentene.

Når fundamentet er på plass, kan man utvide med:

• PII-klassifisering og personvernkrav
• Compliance-regler
• Kobling til taksonomier og ontologier
• Kvalitetsmål (f.eks. i henhold til DQV-AP-NO)

En datakontrakt er ikke bare en spesifikasjon – den er et testgrunnlag, et styringsverktøy og et viktig bindeledd mellom mennesker og systemer i moderne data-organisering. Man kan se kontrakten som en forsterket variant av et skjema – men med semantikk, validering, kontekst for bruk og styring bygget inn.

Mer om semantikk og taksonomi

Datakontrakter beskriver ofte én entitet – f.eks. «kunde». Men for at dette skal gi mening, bør det kobles til en semantisk struktur – en taksonomi eller begrepsmodell.

“Open Data Contracts are required to be well-structured and templated. It defines and logically represents only one single entity to help producers and consumers understand the schema and semantics around it.” – opendatacontract.com

Ved å koble kontrakter til begreper og taksonomier, får man gjenbruk og forståelse på tvers av team. «Kunde» kan da være en type «personlig aktør», og kontrakten kan arve regler eller definisjoner derfra.

Teknisk implementering i praksis

Datakontrakter bør leve som kode, og kunne valideres og testes. Det kan gjøres med:

YAML/JSON

Kontrakten beskrives i et maskinlesbart format. Eksempel i dbt:

models:
  - name: transaksjon
    columns:
      - name: transaksjon_id
        tests:
          - not_null
          - unique
      - name: status
        tests:
          - accepted_values:
              values: ["NY", "FERDIG", "ANNULLERT"]

dbt contracts

Dbt støtter enforced: true på modeller, som validerer at output matcher kontrakten. Dette kobles direkte inn i CI/CD-pipelinen.

Testverktøy

• Great Expectations brukes til deklarative datatester
• Avro, JSON Schema, Protobuf brukes for kontrakter i APIer og meldingssystemer

Eksempel på arbeidsflyt

Som illustrert i figuren kan arbeidsflyten for datakontrakter bestå av følgende steg:

1. Datakonsumenten identifiserer et behov eller en begrensning i dataene.
2. Datakonsumenten ber om en datakontrakt for en gitt dataressurs.
3. Dataprodusenten bekrefter at datakontrakten er gjennomførbar.
4. Datakontrakten bekreftes og formaliseres i kode.
5. Dataprodusenten oppretter en pull request for å endre dataressursen.
6. Endringen sjekkes automatisk for å se om den bryter med eksisterende datakontrakter.
7. Endringen medfører brudd eller ikke brudd: a. Dersom datakontrakten brytes, varsles eieren av dataressursen, og endringen håndteres etter en feilprotokoll. b. Dersom endringen ikke bryter kontrakten, oppdateres dataressursen for videre prosessering.

Fallgruver og anti-patterns

❌ Typiske anti-patterns inkluderer:

• Kontrakten er bare dokumentasjon – den testes ikke
• Endringer skjer uten versjonering – konsumenters bruk av dataene brekker
• Ingen tydelig eier

✅ En god kontrakt:

• Er maskinlesbar
• Er testbar
• Er versjonert
• Har forankret eierskap i produsentteamet
• Har forankret med de mest sentrale konsumentene
• Har en klar prosess for endringshåndtering

Eier produsent eller konsument kontrakten?

Formelt eies kontrakten av produsenten. Det er teamet som forvalter dataproduktet som publiserer grensesnittet. Men god praksis tilsier at kontrakten utarbeides i samarbeid med konsumenter – gjerne i felles møter eller pull requests.

Kontrakten skal være presis og stabil – og endringer må skje gjennom versjonering, slik at gamle konsumenter fortsatt fungerer.

Organisatoriske utfordringer

Implementering av datakontrakter krever organisatorisk forankring og støtte fra toppledelsen. Husk at det krever tid og prioritering å få på plass kontrakter – men det er mindre enn tiden man bruker på å rydde opp i feilsituasjoner.

Her er noen tips fra felten:

• Start med ett team og ett dataprodukt
• Vis frem suksesshistorier internt
• Få støtte fra CDO/dataansvarlig fra starten
• Bruk eksisterende verktøy og formater (f.eks. dbt, Terraform, Databricks, Great Expectations)

Oppsummering

Datakontrakter hjelper virksomheter med å skape robust, skalerbar og tillitsvekkende datadeling. Det er ikke vanskelig å komme i gang – men det krever litt struktur, eierskap og verktøystøtte.

Link til presentasjon

Start lite. Formaliser det du allerede gjør. Bygg så gradvis opp tekniske valideringer og kultur for deling og eierskap.

Lyst til å lære mer?

Besøk:

• Open Data Contract Standard
• DCAT-AP-NO brukes for å publisere og katalogisere dataprodukter
• DQV-AP-NO beskriver datakvalitet, med dimensjoner som Accuracy, Completeness, Timeliness, Validity og Lineage
• Les: Andrew Jones: Driving Data Quality with Data Contracts (2023)  
• Les: Chad Sanderson, Mark Freeman: Data Contracts (planlagt nov. 2025)

Du kan også høre på podcasten “Datautforskerne”, episode 15 der Safurudin Mahic og Magne Bakkeli snakker om datakontrakter. Episoden er tilgjengelig på Spotify, Apple og Acast. Lik og abonnér!