Forklaring

Datamodellering: det vanskelige er å vite hva dere skal bygge

Å bygge er blitt lett. Det vanskelige er å vite hva dere skal bygge. Slik blir en felles datamodell fundamentet for hele virksomheten.

Av Steffen Sande7 min lesing

Å bygge en tabell på en moderne dataplattform tar ikke lang tid lenger. Det som tar tid, er å vite hva den skal inneholde. Her er hvorfor datamodellering handler mer om forståelse enn om teknologi, og hvorfor en felles modell for hele virksomheten lønner seg.

For ti år siden kunne et nytt datasett ta uker å få på plass. Noen måtte sette opp servere, konfigurere lasteverktøy og passe på at jobbene kjørte i riktig rekkefølge.

I dag skalerer plattformen selv, pipelines finner rekkefølgen på egen hånd, og en AI-assistent kan skrive første versjon av en transformasjon på minutter. Likevel opplever mange team at leveransene går tregt.

Flaskehalsen har flyttet seg. Den ligger ikke lenger i byggingen, men i spørsmålet som kommer før: hva er det egentlig vi skal bygge?

Å bygge er ikke lenger det vanskelige

Gi en erfaren dataingeniør en tydelig beskrivelse av en tabell, og den er ofte bygget samme dag. Kolonnene er kjent, nøklene er bestemt, og det står hva hver kolonne betyr. Det som gjenstår, er å hente dataene og skrive transformasjonen, og det er den delen verktøyene har blitt gode på.

Uten en slik beskrivelse må ingeniøren gjette, spørre rundt eller bygge noe som virker fornuftig og håpe at det treffer. Tabellen blir bygget, men ofte flere ganger, fordi det først etterpå blir klart hva forretningen faktisk trengte. Den raskeste veien til en ferdig tabell går derfor sjelden gjennom koden. Den går gjennom en avklaring av hva tabellen skal være.

Det vanskelige er å vite hva dere trenger

Tenk deg en nettbutikk som skal bygge en dataplattform. Utgangspunktet er begreper alle i bedriften kjenner: kunde, ordre og produkt. Allerede her ligger spørsmål som må besvares før noen bygger noe:

  • Er en kunde en person, en husstand eller en bedrift? Og hva skjer med ordrene når to kundekontoer slås sammen?
  • Kan en ordre ha flere produkter? Hører prisen i så fall til produktet eller til ordrelinjen?
  • Når regnes en ordre som solgt? Når den legges inn, når den betales, eller når den sendes?

Dette er ikke tekniske spørsmål. Svarene finnes hos dem som kjenner forretningen, og de er ofte ikke enige med hverandre før noen stiller spørsmålet høyt.

Hvis ingen tar stilling, tar koden stilling for dem. Utvikleren som skriver lastejobben, velger én tolkning av «solgt». Analytikeren som bygger omsetningsrapporten, velger kanskje en annen. Begge har gjort noe fornuftig, men tallene stemmer ikke, og møtet som skulle handle om salget, handler om hvilket tall som er riktig.

Når dere er enige om svarene og har avstemt dem med forretningen, er selve byggingen den enkle delen.

Område for område, med hele virksomheten i bakhodet

Ingen modellerer hele virksomheten på én gang. Det tar for lang tid, og forretningen må vente for lenge før den får noe. I praksis bygger man ett område om gangen: først salg, så innkjøp, så økonomi.

Poenget er å gjøre det med hele virksomheten i bakhodet. Når salg trenger en kundetabell, bygges den ikke bare for salg. Den bygges slik at økonomi, kundeservice og logistikk kan bruke den samme tabellen når deres tur kommer.

Dette er ikke en ny idé. Kimball Group, som står bak en av de mest brukte metodene for dimensjonsmodellering, har i flere tiår anbefalt å kombinere et overordnet perspektiv på hele virksomheten med leveranser som tar én forretningsprosess om gangen. Bindeleddet er felles begreper, som kunde, produkt og dato, som defineres én gang og gjenbrukes av alle prosessene.

Forskjellen fra å bygge for ett behov om gangen er liten i starten, men stor over tid. Hvert nytt område kan bygge videre på det som allerede finnes, i stedet for å starte fra bunnen.

Sølvlaget: én felles modell for hele virksomheten

Mange dataplattformer er bygget etter medaljongarkitekturen, et mønster Databricks har gjort kjent og som også brukes i Microsoft Fabric. Dataene går gjennom tre lag, og hvert lag har sin egen oppgave.

  • Bronse holder rådataene slik de kommer fra kildesystemene.
  • Sølv vasker, slår sammen og samordner dataene fra de ulike kildene. Ifølge Databricks skal sølvlaget gi et helhetlig bilde av virksomhetens sentrale forretningsobjekter, begreper og transaksjoner.
  • Gull inneholder tabeller tilpasset bestemte behov og analyser. Fordi gullaget modellerer ett forretningsområde, har mange virksomheter flere gullag, for eksempel ett for økonomi og ett for HR.

Det betyr at den felles modellen naturlig hører hjemme i sølvlaget. Det er her kunde, leverandør, produkt og salgsordre beskrives én gang, uavhengig av hvilket system de kom fra. Gullagene for salg, innkjøp og økonomi bygger på de samme sølvtabellene, og får dermed de samme definisjonene.

For nettbutikken betyr det at kunden fra nettbutikken og kunden fra kundeservicesystemet blir én kunde i sølvlaget. Når innkjøp senere trenger leverandører og innkjøpsordrer, kobles de til det samme produktet som salg allerede bruker.

Hvorfor det lønner seg

En felles modell gir tre konkrete gevinster:

  • Raskere leveranser. Kimball Group peker på at gjenbruk av felles begreper korter ned tiden fra behov til leveranse, fordi man slipper å designe og utvikle det samme flere ganger. Skal nettbutikken analysere leveringsevne, finnes kunde, produkt og ordre allerede. Bare det som er nytt, må bygges.
  • Like tall på tvers. Når salg og økonomi henter kunden fra samme tabell, med samme definisjon, viser rapportene de samme tallene. Diskusjonen kan handle om hva tallene betyr, ikke om hvilket tall som er riktig.
  • Data kan kombineres. Felles begreper gjør det mulig å se på tvers av prosesser, for eksempel å sammenligne hva som er solgt, med hva som er kjøpt inn av samme produkt.

Gevinsten er liten den første måneden og vokser for hvert område. Det første området tar omtrent like lang tid som før, fordi begrepene må avklares grundig. Det andre går raskere, og det tredje enda raskere.

Alternativet er kjent for de fleste. Uten felles definisjoner glir plattformen gradvis over i en samling isolerte løsninger, der hvert område har sin egen versjon av kunden. Etter noen år finnes det flere kundetabeller, ingen vet hvilken som gjelder, og nye behov starter med å finne ut hva som allerede finnes.

AI trenger forretningskonteksten

Mange virksomheter ønsker at AI skal svare på spørsmål om forretningen: hvordan gikk salget forrige uke, hvilke kunder handler mindre enn før. En språkmodell kan skrive spørringen, men den kan ikke vite hva «solgt» betyr i akkurat denne bedriften.

Forskningen peker i samme retning. Tidligere studier har vist at nøyaktigheten faller kraftig når språkmodeller skal svare på spørsmål mot ekte virksomhetsdata, fordi tabellstrukturen sjelden forteller hvilke forretningsregler som gjelder. En studie fra 2026 testet tre språkmodeller på det samme datasettet fra detaljhandel. Da modellene fikk et kort dokument med forretningsdefinisjonene, økte nøyaktigheten med 17 til 23 prosentpoeng for alle tre.

Det AI trenger, er altså det samme som mennesker trenger: definisjoner av begrepene, kunnskap om hvordan tabellene henger sammen, og beskrivelser av hva kolonnene inneholder. En felles datamodell med gode beskrivelser gir nettopp det.

Hvor dere kan begynne

Start med det neste området som står på listen, men løft blikket før dere bygger.

  1. Finn begrepene området berører, for eksempel kunde, ordre og produkt.
  2. Sjekk om noen av dem allerede finnes i sølvlaget. Gjør de det, bygg videre på dem i stedet for å lage nye.
  3. For begrepene som er nye: tenk på hvem andre i virksomheten som vil trenge dem, og definer dem slik at de passer for flere enn dette ene området.
  4. Avstem definisjonene med forretningen, og gi hver tabell en eier.
  5. Bygg det dere er blitt enige om.

La modellen ligge sammen med koden i Git, slik at den endres i den samme prosessen og ikke glir fra virkeligheten. Neste område starter da med det som allerede finnes, og fundamentet vokser for hver leveranse.

Kilder