Teknologi og arkitektur

Portalen er bygget av én person. Det har styrt valgene mer enn noe annet: hvert verktøy må kunne læres, driftes og feilsøkes uten et team i ryggen. Der et stort miljø kan bære en spesialisert løsning, må dette prosjektet velge det som er godt nok og godt dokumentert.

Portalen har to måter å behandle data på, som lever side om side. Det er verdt å si rett ut, fordi det ellers ser ut som rot.

Grunnen til at begge finnes er ærlig nok: den enkle veien kom først og virker godt nok for det den gjør. Å skrive om alt til den nye ville kostet mye og gitt leseren ingenting. Nye og vanskelige kilder bygges på den nye, og på sikt kan den ta over.

Kapittel 1 sa kort hva et datalager er: data fra mange kilder samlet i sin opprinnelige form, med en katalog over hva som finnes og hvor hvert tall kom fra. Det som gjør den formen verdt bryet, er det neste.

Den viktige forskjellen er at rådataene blir liggende urørt. De bearbeidede utgavene bygges opp fra dem på nytt hver gang, framfor å endres på plass. Oppdager vi at en beregning var feil, retter vi oppskriften og kjører kjeden om igjen. Vi trenger ikke lete etter hvilke tall som ble påvirket, for de finnes ikke lenger enn til neste kjøring. Det er også derfor et tall alltid kan spores tilbake til kilden sin.

Prisen er at det er tyngre å komme i gang enn å hente et tall rett fra et API og skrive det inn på en side. Det er nettopp derfor portalen har to dataarkitekturer og ikke én: den enkle veien bærer fortsatt det meste, og datalageret brukes der det faktisk gir noe den enkle veien ikke kan.

I datalageret går tallene gjennom navngitte lag, og hvert lag har én jobb. Regelen er at ingenting tolkes ved innhenting: det som kommer inn, lagres som det kom. All logikk ligger i stegene etterpå, der den kan leses, testes og kjøres om igjen.

Et ord om ordet: en datamodell er en oppskrift på hvordan én tabell regnes ut fra en annen. Den har ingenting med en språkmodell å gjøre, som er det vi mener når vi skriver om AI lenger ned. Vi skriver alltid ut hele ordet, nettopp fordi de to ellers glir sammen.

Til sammen 38 datamodeller. Alle har en beskrivelse og minst én automatisk test som sier fra hvis et tall plutselig mangler, blir negativt eller får en dato i framtiden.

Hvert kvartal publiserer NAV et notat om arbeidsavklaringspenger. Det inneholder tall som er verdt å følge over tid - hvor mange som mottar ytelsen, hvilke diagnoser som dominerer, hvordan utviklingen går. Notatet er en PDF. Vil du se ti års utvikling, må du åpne ti dokumenter og skrive av tallene for hånd.

Her gjør datalageret noe den enkle veien ikke kan: en språkmodell leser dokumentet i selve databehandlingen, henter ut de konkrete tallene i strukturert form, og skriver i tillegg et kort sammendrag på norsk. Resultatet er én rad per notat, i en tabell du kan spørre på tvers av.

Det interessante er ikke at det virker, men hva det krevde. Notatene bruker to ulike definisjoner av «antall» om hverandre: de som mottar ytelsen, og det bredere antallet registrert med nedsatt arbeidsevne. Forskjellen er titusener av mennesker. En tolkning som blander dem, gir et tall som ser riktig ut og er feil. Å lære tolkningen å skille konsekvent var mer arbeid enn å få den til å lese dokumentet i det hele tatt.

Tallene tolkningen ikke klarer å lese sikkert, blir stående tomme framfor å bli gjettet. Et hull er ærlig. Et gjettet tall i en statistikkportal er det ikke. Siste kapittel går nærmere inn på hva slikt arbeid faktisk koster.

Når de ferdige tabellene først ligger der, kan flere ting lese dem. Portalen er den mest synlige flaten, men ikke den eneste - og heller ikke den første.

Poenget er at grunnarbeidet gjøres én gang. Å tolke ti år med dokumenter er dyrt; å lese den ferdige tabellen fra en ny flate er nesten gratis. Det er hele begrunnelsen for å ha et datalager framfor å hente rett til hver enkelt visning.

De fleste nettsteder legges ut på nytt hver gang koden endrer seg. Denne gjør ikke det, og det er med vilje.

Portalen henter data mange ganger i døgnet. Ville hver slik henting utløst en full utlegging, ville nettstedet blitt bygget om igjen dusinvis av ganger daglig - også for endringer ingen leser merker, som en rettet skrivefeil i en intern beskrivelse. I stedet skjer utleggingen når en datajobb faktisk har noe nytt å vise, eller når noen ber om det.

Prisen er at en kodeendring ikke er synlig før neste utlegging. Gevinsten er at det som legges ut, er en samlet og kontrollert tilstand framfor en tilfeldig.