Fem arkitekturvalg som bør tas før data- og analysefornyelsen starter

Erfaringer fra komplekse dataplattform- og analyseprogrammer

Innledning

I store data- og analyseprogrammer er det ofte to ting som er faste: ambisjonene og milepælene. Mye annet kan diskuteres – helt til det plutselig ikke er det. Det er gjerne da arkitekturdiskusjonene blir dyre.

Det er fristende å starte bygging tidlig, og tenke at man kan lande de vanskelige valgene underveis. Smidig utvikling kan absolutt fungere godt, men bare hvis man er tydelig på hva som faktisk kan itereres trygt – og hva som blir en bremsekloss hvis det er uklart.

Noen valg er slike: de påvirker hele produksjonslinja for data. Hvis de ikke landes tidlig, får du “smidig” som metode, men “ad hoc” og teknisk gjeld som resultat.

Denne artikkelen beskriver fem arkitekturvalg som vi mener bør tas før bygging starter. Ikke fordi det er fint å ha “arkitektur på plass”, men fordi det reduserer risikoen for merarbeid, forsinkelser og tillitstap når plattformen skal tas i bruk – og øker sjansen for at dere velger noe organisasjonen faktisk kan forvalte over tid.

Valgene er basert på egen erfaring, og dekker følgende områder:

1. Dataplattformvalg: arkitektur handler mer om risiko enn om funksjoner
2. Datamodelleringsprinsipp: struktur som må tåle både tempo og eierskap
3. Lagdeling og standarder: forutsetningen for samarbeid i skala
4. Kvalitet: noe som må bygges inn i prosessen
5. Avveininger: tid og kvalitet er ofte rammer – omfang og kompleksitet er styringsvariabelen

1 Dataplattformvalg: arkitektur handler mer om risiko enn om funksjoner

Plattformvalg ender ofte i en funksjonsdiskusjon: “støtter den X?”, “har den Y?”, “er den integrert med Z?”. I praksis ser vi at store programmer sjelden feiler på funksjonalitet. De feiler på forutsigbarhet. Når flere land, domener og team leverer parallelt, blir plattformvalget først og fremst et spørsmål om: Hvor mye usikkerhet tåler vi innenfor tidslinjen? Hva er godt nok nå?

Plattformvalg bør i praksis starte med å bli enige om hvilke kapabiliteter vi må ha tidlig – ikke hvilket verktøy vi liker best. Det som må være på plass fra start er først og fremst det som gjør at teamet kan bygge dataflyter effektivt uten å bygge gjeld, og det som gjør at dere kan drifte dataflyter i produksjon slik at brukerne faktisk stoler på dem. Kapabiliteter som primært støtter andre typer use case kan ofte vente.

En nyttig måte å strukturere valget på er å knytte kapabiliteter til plattformkomponenter (lagring/compute, ingest, orkestrering, transformasjon, katalog, sikkerhet, overvåking/observability) og vurdere teknologivalg per komponent.

Noen valg blir langsiktige, mens andre kan byttes enklere underveis – hvis dere har tydelige standarder og grensesnitt. Når valgene er vanskelige, anbefaler vi en enkel evalueringsmatrise med vekting og scoring, slik at dere optimaliserer for helhet og leveransesikkerhet – ikke for enkeltkomponenter.

Selv med riktig teknologi kan dere gjøre implementasjonen unødvendig vanskelig. Typiske snubletråder er:

• for mange måter å gjøre samme ting på
• for få “golden paths”
• manuell deploy og manglende kvalitetsgates
• utydelige ansvarsforhold i drift

Ha med noen erfarne tidlig. Det er overraskende lett å gå seg vill og skape merarbeid for data engineering og dataplattformteamet i resten av programmet. Sorter hva dere kan starte enkelt med (enkel feilvarsling, basis monitorering, en enkel datakatalog som kan bygges ut) versus hva som må være solid fundament fra dag 1 (tilgangsstyring, datakontrakter, standard deploy-mønstre og tydelige grensesnitt).

2 Datamodelleringsprinsipp: struktur som må tåle både tempo og eierskap

Datamodellering blir fort et spørsmål om preferanser og hva arkitekter og data engineers kjenner fra før. Det er sjelden produktivt. Det som er produktivt er å snakke om kontekst og konsekvens.

Valg av modelleringsprinsipp påvirker:

• hvor raskt du kan levere første “riktig nok”-versjon
• hvor mye governance og kompetanse som kreves for å holde kursen
• og hvor lett det er å overføre ansvar til linja

Noen mønstre (som Data Vault) er sterke når kildene er mange og lite harmoniserte, og når endring er normalen. Andre (som 3NF-orientert standardisering og harmonisering) gir ofte raskere vei til fungerende analyse når kildene er færre og mer like i datastruktur.

Her er tre ting som bør avgjøre valget:

• Hvor heterogent er kildelandskapet (nå og i overskuelig fremtid)?
• Hvor mye endring forventer vi i prosesser og begreper i løpet av programmet?
• Hvem skal ha varig eierskap til modellen – og hvordan bygger dere kompetanse tidlig nok til å faktisk forvalte og videreutvikle den?

Dokumenter og lås beslutningen: Lås prinsippet tidlig, og dokumenter det i en beslutningslogg. Det er billig å velge én vei, dyrt å støtte to - eller ombestemme seg underveis.

3 Lagdeling og standarder: forutsetningen for samarbeid i skala

Lagdeling, navngivning og standarder havner ofte i kategorien “vi tar det etterpå”. Det er en klassiker. Og den kommer sjelden alene – den kommer med:

• duplisering av logikk
• utydelige forventninger
• og diskusjoner om hvor feil faktisk oppstår

En tydelig lagdeling gir et felles språk for både utviklere og brukere. Det viktigste er ikke navnet på lagene, men at utviklere og brukere kan ha en tydelig forventning til hva laget skal levere. Den gjør det mulig å levere i parallell uten at alle må forstå alt. Den gjør også feilsøking langt mer presis: hvor i verdikjeden oppstod avviket?

Her er et eksempel på en enkel, forklarbar lagdeling:

• Rå: Dette har vi fått fra kilden, full historikk og sporbart.
• Standardisert: Renset, normalisert, teknisk harmonisert.
• Samlet: Integrert på tvers, med felles begreper og dimensjoner.
• Konsum: Det som kan brukes i rapporter/KPI-er – med kvalitet og styring. Tilpasses use casene.

“Standarder” betyr ikke dokumenter. Standarder betyr at to team løser samme problem likt – uten å måtte møtes tre ganger først. Standarder kan ofte operasjonaliseres gjennom navngivning, maler, init-kommandoer, CI/CD-krav og kodeeksempler. Men - standarder fungerer ikke av seg selv. I praksis må de også håndheves. Det betyr at noen har mandat til å bestemme “slik gjør vi det her”, og at avvik fanges i leveranseflyten (for eksempel gjennom pipeline-gates og code review). Med 2–3 team uten beslutningsmandat blir det fort kaos, uansett hvor fin standarden er.

4 Kvalitet: noe som må bygges inn i prosessen

Kvalitet er sjelden et mål i seg selv. Kvalitet er en forutsetning for at noen skal tørre å bruke dataene, og at programmet vil få fornyet tillit. Problemet er at kvalitet ofte blir definert som “vi må bare være nøye”. Det holder ikke. Arkitektur og arbeidsform må gjøre det konkret.

God kvalitetssikring i et analyseprogram handler typisk om tre ting:

1. Korrekthet: Tallene må kunne avstemmes mot dagens rapportering der det forventes kontinuitet. Vi må også ha en plan for hvordan vi skal håndtere historikk, og hvor viktig det er at denne kan benyttes på samme struktur som nye løsninger.
2. Stabilitet: Dataflyter må være stabile, og kunne kjøres med forutsigbar oppdateringsintervall.
3. Opererbarhet: Det må være mulig å forstå, overvåke og fikse plattformen uten å være avhengig av enkeltpersoner eller leverandøren i hverdagen.

Kvalitet er at det som leveres virker, tåler drift, og kan eies videre. Men i dataverdenen er “kvalitet” ikke bare en IT-disiplin: den kvaliteten brukeren opplever i tall, KPI-er og rapporter må eies og styres av forretningseieren. Plattform- og datateamene kan (og bør) bygge mekanismene som gjør kvalitet mulig å måle, teste og overvåke – men innholdet, definisjonene og aksepten for “riktig nok” må forankres hos de som eier prosessen og resultatet.

Lag en enkel avstemmingsfasit per domene og leveransepakke: hvilke tall avstemmes, hvordan, og hvem signerer. Det er overraskende effektivt. Dette må jobbes med i definisjonen av hver leveranse, sammen med eier og brukere av leveransen.

5 Avveininger: tid, kostnad og omfang kan diskuteres - kvalitet er gitt

Det mest undervurderte arkitekturvalget handler ikke om teknologi. Det handler om hvilke kompromisser dere faktisk er villige til å ta.

Min erfaring er at dette fungerer best når programmet er eksplisitt på følgende:

• Tid er ofte en fast ramme. Samtidig er noen milepæler “hellige” uten reelle konsekvenser. Finn derfor de faktiske konsekvensene ved å forskyve tidslinjen før dere låser alt.
• Kostnad er ofte en ramme. Det kan være en betydelig investering som er godkjent av ledergruppen, og som man ønsker å holde.
• Kvalitet er baseline for det som leveres. Dataleveransene må være korrekte for å være brukbare, og plattformen må være operativ og kunne forvaltes.

Når tid og kost er rammer, og kvalitet er gitt, er det som regel omfang og kompleksitet som er den reelle styringsvariabelen.

Omfang er derfor variabelen dere bør styre etter. Minste nødvendige omfang (MVP) er styringsverktøyet. Det gjør en stor forskjell i styringsgruppen: Når noe skjærer seg, kan dere justere omfang og kompleksitet uten å begynne å forhandle om dataenes korrekthet. Det er en vesentlig forskjell.

Lag en prioriteringsliste: Hvis dere begynner å “diskutere kvalitet” i styringsgruppen så er det ofte et tegn på at omfanget ikke er tydelig nok. Lag prioriteringslisten i oppstarten, og diskuter ferdigkriterier (minimum og ønsket) for hver enkelt leveranse.

Hva gjør du med dette i praksis?

Dette er ikke en invitasjon til å skrive en arkitektur-bibel før dere starter. Tvert imot.

Et pragmatisk opplegg vi ofte ser fungere:

• En kort beslutningsperiode (typisk 2–3 uker) med konkrete workshops
• Én side per beslutning: kriterier, valg, konsekvens, og “hva betyr dette for teamene i praksis” – inkludert hvilken kompetanse som må være på plass, og hvordan dere bygger den mens dere leverer
• En tydelig beslutningseier (ofte CIO/CTO eller tilsvarende)
• En beslutningslogg og en enkel endringsprosess ved behov: Beslutninger kan endres, men da må det være verdt prisen. Tilrettelegg for at ledende utviklere kan foreslå forbedringer – og legge teknisk gjeld på bordet før den blir permanent.

Dette gjør det mulig å starte bygging tidlig – uten å starte i feil retning.

Avslutning

Arkitektur i dataprogrammer handler sjelden om å finne den perfekte løsningen. Det handler om å ta noen få bevisste valg tidlig, slik at resten av leveransen kan være smidig i praksis – ikke bare i ord.

Hvis du lander disse fem valgene tidlig, får du ofte:

• høyere tempo,
• mindre friksjon mellom team,
• færre overraskelser i produksjon,
• og enklere eierskap og videreutvikling over tid – fordi dere velger løsninger organisasjonen faktisk kan forvalte, og bygger kompetanse mens dere leverer, ikke etterpå.

Ta diskusjonen i styringsgruppen, og legg inn den tiden som kreves for å lande basics. Det bremser ikke programmet. Det sparer dere tid brukt på rework og konsekvenser av uklare valg – og øker sannsynligheten for varig gode løsninger.