Kvalitet og pålitelighet

Tre nivåer, få SLO-er, og en respons som gjør at folk stoler på produktet.

Kvalitet er en del av produktløftet

Når dere sier at noe er et dataprodukt, sier dere samtidig at andre kan bruke det over tid - uten å måtte gjette på ferskhet, endringer eller kvalitet.

Dette kapittelet handler ikke om “perfekte data”. Det handler om å gjøre løftet tydelig og driftbart:

• hva betyr “godt nok” for den navngitte bruken?
• hva måles for å oppdage avvik tidlig?
• hva skjer når avvik oppstår?

Datakvalitet blir fort en diskusjon uten rammer. I dataprodukter bør rammene være enkle:

Kvalitet = godt nok for en navngitt bruk, for en navngitt kundegruppe.

Det gjør det mulig å være konkret. For de fleste dataprodukter er det tre ting som betyr mest:

• Ferskhet: data kommer når den skal brukes
• Stabilitet i semantikk/keys/tidslogikk: det dere mener med “ordre”, “kunde”, “omsetning” endrer seg ikke uten kontroll
• Kvalitetssignal: kundene kan se om produktet er “ok”, “degradert” eller “stoppet”

Nivåer: ikke alt skal ha samme strenghet

Legger dere samme krav på alt, ender dere med for mye regime eller for lite troverdighet. Tre nivåer holder for å være presise uten å bli tunge.

Utforskning Data brukes til å lære og teste hypoteser. Her er poenget å være tydelig på at løftet er begrenset: hyppige endringer er ok, og dere trenger først og fremst synlighet (status + grunnmålinger).

Standard Data brukes i rapportering og løpende beslutninger. Her bør dere love stabil semantikk for definert bruk, og ha noen få tester/alarmer dere reagerer på.

Forretningskritisk Feil har høy kost eller høy risiko. Her må løftet være tøffere: tydelige SLO-er, klar respons ved avvik og kontrollert endring. Se kapittel 9 om endring og utfasing for hvordan dere håndterer dette i praksis.

Ta Kunde 360 - Core som eksempel: de navngitte konsumentene (salgsteamet og kundeservice) har ulike toleranser. Salgsdashboardet kan tåle én dag gammelt tall. Kundeservice-systemet kan ikke. Det er to SLO-er, ikke ett felles krav.

Hvis konsumenten er en AI-agent, er det også et nivå-spørsmål, men ofte med strengere krav til kontekst enn til ferskhet. Et produkt som er “Standard” for menneskelig bruk kan likevel være utilstrekkelig for AI-agenter hvis kontekstlaget er tynt - mer om det i kapittel 8 om AI-klare dataprodukter.

SLO: løfter dere kan måle og følge opp

SLO fungerer best når dere er strenge på antall. Start med 2-4 per dataprodukt.

De fleste dataprodukter trenger ikke mer enn disse kategoriene:

• Ferskhet (oppdatering)
• Tilgjengelighet (lesbarhet)
• Kvalitetssignal (noen få indikatorer som treffer bruken)

SLO må knyttes til målbare indikatorer:

• minutter siden siste vellykkede refresh (ferskhet)
• andel vellykkede leseforsøk mot produktflaten (tilgjengelighet)
• andel null/ugyldige nøkler, duplikater på business key eller ugyldige statusverdier (kvalitetssignal)

Det viktigste er ikke å velge “riktig” måling på første forsøk - det viktigste er at dere velger noe dere følger opp.

Respons ved avvik: stopp, degrader eller signal

Kvalitet blir først reelt når dere har en tydelig respons. Tre responstyper holder:

• Stopp: Brukes når risikoen for feilbruk er høy, eller når feil gir stor konsekvens. Produktet publiseres ikke som “ok” hvis kritiske gates feiler.
• Degrader: Brukes når produktet fortsatt kan brukes, men med tydelig begrensning (for eksempel “stale”, eller en kjent del av innholdet har avvik). Status må være synlig på produktsiden.
• Signal: Brukes når risikoen er lav, eller i utforskning. Avvik gjøres synlig og varsles, men uten at det automatisk blokkerer bruk. Poenget er at kundene skal slippe å gjette på tilstand.

Tester: få som treffer bruken slår mange generiske

Start med 3-7 valideringer som treffer bruken av produktflaten:

• obligatoriske felt
• unike keys (der det skal være unikt)
• gyldige verdier (status/enum)
• referanseintegritet (der det er relevant)
• én eller to forretningsregler som skaper feil eller misforståelser

Har dere ikke en definert respons på en test som feiler, er det et signal om at testen enten er feil valgt - eller at terskelen/ansvaret er uklart.

Kodekvalitet: den tredje dimensjonen

Output (riktige tall) og tid (ferskhet) er to av tre kvalitetsakser. Den tredje er kodekvaliteten i transformasjonslaget som faktisk produserer produktet.

Et dashboard som viser riktige tall i dag kan være uhåndterbart om seks måneder fordi SQL-en er kopiert mellom modeller, ingen eier logikken formelt, og endringsradiusen er ukjent. Dere får et produkt som leverer i går og er en kostnadsbombe i morgen.

Andrew Jones (april 2026) argumenterer for å behandle pipeline-koden som et serviceprodukt med eierskap, katalog og kontrakter - ikke som “noe noen skrev for tre kvartaler siden”. Konkret: en service catalog for dbt-modeller med eksplisitt eier, SLA på ferskhet og korrekthet, og stabile kontraktsgrensesnitt som skiller “offentlige” felt fra interne.

I praksis betyr dette tre ting for et dataprodukt:

1. Pipeline-koden har en navngitt eier (samme som produkteieren, eller en utpekt vedlikeholder)
2. Det er tydelig hvilke felt og logikk som er “stabile” (interface) vs interne (motorrom)
3. Endringsradiusen er kjent: én endring i logikken har en spesifikk liste av downstream-konsekvenser

Dere trenger ikke et fullt service catalog-system fra dag én. Men hvis SQL-koden bak et “forretningskritisk” produkt ikke har eier, er løftet skjørt uavhengig av hvor mange tester dere skriver på output.

Minimum for driftbarhet: en kort rutinebeskrivelse

For dataprodukter som deles på tvers av team holder en kort rutinebeskrivelse:

• kontaktpunkt + ansvarlig team
• hva betyr “stopp” og “degradert” for dette produktet?
• vanligste feilkilder (upstream/transform/tilgang)
• hvor status og changelog oppdateres

Hensikten er at både eierteam og kunder får en forutsigbar håndtering - ikke at dere skriver en manual.

Neste steg er å se hvordan dataprodukter må endre seg når en ny brukergruppe tar over: AI-agenter. Dataprodukter som fundament for AI.