Slik kan en faggruppe ta tilbake kontrollen over data engineering-standardene

Mange virksomheter har desentraliserte produktteam og en moderne dataplattform, men likevel ender de opp med en jungel av pipelines, verktøy og lokale løsninger. Denne artikkelen viser hvordan en liten faggruppe kan etablere felles standarder for data engineering – uten å ta eierskap og tempo fra teamene.

Desentraliseringen går ofte på bekostning av standardisering

Mange virksomheter har gått samme løype: man har investert i en dataplattform, organisert seg rundt domener og produktteam, rekruttert flinke data engineers – og likevel ender man opp med en jungel av pipelines, verktøy og «midlertidige» løsninger som aldri ble midlertidige.

Desentralisering skulle gi fart og eierskap. I stedet sitter man med flere versjoner av det samme nøkkeltallet, og ingen helt sikker forståelse av hvor tallene kommer fra.

Med data engineering mener vi arbeidet med å designe, bygge og drifte datasystemer som samler inn, lagrer, transformerer og tilgjengeliggjør data i skala. Når det arbeidet gjøres helt lokalt, uten noen felles standarder, blir konsekvensene ganske forutsigbare.

Når alle bygger sin egen «lille fabrikk»

I en dataorganisasjon uten felles praksis er mønsteret ofte det samme. Ett team kjører batch-jobber i Airflow, et annet i en sky-native orkestreringstjeneste, et tredje har en hjemmelaget Python-jobb med cron «til det blir tid til å rydde opp». Samme begrep – for eksempel «forbruk per time» eller «netto volum» – modelleres i flere varianter, med litt forskjellig logikk og navngivning. Logging og overvåkning varierer fra velstrukturerte dashboards til en loggfil på en server ingen helt vet hvem eier.

Resultatet er at:

• datakvaliteten blir ujevn, og tilliten til tallene svekkes
• kostnadene øker, fordi de samme problemene løses igjen og igjen
• time-to-market blir tregere, fordi hvert team starter med å bygge fundament på nytt
• risikoen øker, fordi kritisk kunnskap sitter i hodet på enkeltpersoner

Teamene gjør ikke noe «galt» – de løser lokale problemer med de verktøyene de har. Problemet er fraværet av noen som har mandat til å se helheten og si: «Slik gjør vi dette som organisasjon.»

Hjernen – dataplattformen

En data engineering-faggruppe kan få et slikt mandat. Ikke som et nytt kontrollorgan, men som en liten gjeng som gjør det enklere å gjøre det riktig, og litt vanskeligere å finne opp sin egen standard for hver pipeline.

Rollen er ikke å overta eierskap til dataprodukter, skrive alle pipelines eller detaljstyre domeneteamene.

Rollen er å:

• definere noen få, tydelige standarder
• bygge og forvalte gjenbrukbare fabrikkmønstre
• hjelpe teamene med å ta disse i bruk på en pragmatisk måte

Målet er ikke å ta tilbake kontrollen i betydningen «sentralt datavarehus 2.0», men å gjøre desentraliseringen bærekraftig.

Pass på: En faggruppe kan også gå for langt. Hvis hvert avvik må gjennom en komité, og alle teknologivalg tar tre runder i et arkitekturforum, har man bare erstattet lokale problemer med sentral byråkrati. Poenget er å lage gode standarder, ikke å straffe alt som ikke passer i mønsteret.

Faggruppen i praksis

Om du kjøper konseptet så langt, er det fortsatt flere spørsmål som gjenstår. Hvem, hvor mange og hvor ofte - og ikke minst mandat og omfang - må avklares.

Hvor mange – og hvem bør sitte i faggruppen?

Hvis faggruppen blir for stor, forsvinner den i koordinering og avklaringer. Blir den for liten – eller fylt med folk uten faktisk tid – skjer det ingenting.

Et realistisk utgangspunkt er: Fire medlemmer, alle data engineers.

En sammensetning som kan fungerer i praksis er for eksempel:

Faggruppen bør bestå av folk som skriver kode, leser logger og kjenner frustrasjonen når en pipeline feiler 03:15 – ikke bare folk som skriver prinsippdokumenter.

Senioritet og tidsbruk: hva må til for at dette ikke blir et hobbyprosjekt?

Her er det lett å lure seg selv. «Dette kan dere jo gjøre litt ved siden av» er omtrent den sikreste måten å sikre at ingenting skjer. Erfaringen er ganske konsistent:

Med mindre minst to personer får rundt 20 % av tiden sin, skjer det lite annet enn møter.

En modell som fungerer bedre:

• To nøkkelpersoner på 20 % hver: De driver frem kode, rammeverk og piloter. De er motoren i faggruppen.
• To medlemmer på 10–15 % hver: De er med i design og review, tar faggruppen inn i eget domene, og bidrar i helsesjekker og opplæring.

Oversatt til en praktisk arbeidskalender:

• 20 % ≈ én dag i uka med reell tid og noe asynk arbeid.
• 10–15 % ≈ en halv dag eller to faste fokusblokker.

Hvis organisasjonen ikke vil avse den tiden, bør man være ærlig: Da er dette et faglig forum, ikke en faggruppe med leveranseansvar. Et slikt fora gir på langt nær samme verdi.

Omfang: Hva er innafor, og hva er utafor?

En klassisk feil er å skyve «alt med data» inn i faggruppen: streaming, integrasjonsplattformer, API-er, MLOps, masterdata, you name it. Det er en effektiv måte å knekke kapasiteten på.

Et tydelig scope kan for eksempel se slik ut:

Faggruppen trenger ikke eie alt – den trenger å eie det som gjør det mulig å bygge gode analytiske dataprodukter uten at hvert team må finne opp hjul, aksling og hjuloppheng hver gang.

Noen områder faggruppen bør ta ansvar for

I stedet for å spre seg tynt, er det ofte mer effektivt å jobbe ordentlig med noen få kjerneområder. En måte å ramme det inn på er å se for seg én konkret pipeline – for eksempel datagrunnlaget til en ukentlig styringsrapport og spørre: hva må fungere for at denne skal være forutsigbar, driftssikker og forståelig?

1. Orkestrering Ukeskjøringen skal trigges, feile forutsigbart, og kunne re-kjøres uten dramatikk.

2. Ingest-rammeverk Data kan komme fra økonomisystemer, fagsystemer og eksterne kilder.

3. Transformasjon som kode Selve logikken – filtrering, aggregering og andre forretningsregler – bør ikke være spredd i notebooks og ad hoc-SQL.

4. Datakontrakter og observability Til slutt handler det om å vite når noe er feil, før ledergruppen sitter i møte med tall som ikke henger sammen.

Sett i sammenheng blir dette en forskjell som merkes: Før hadde man ulike scripts og verktøy, manuell feilsøking og de samme feilene i stadig nye varianter. I stedet har man en kjent måte å sette opp, kjøre og overvåke batch-løp på – uansett domene.

Andre tema en faggruppe kan ta ansvar for – når grunnmuren sitter

Når disse fire områdene begynner å fungere, er det fristende å kaste seg over alt annet med en gang. Det er ikke nødvendigvis lurt. Men noen temaer ligger så tett på hverdagen til data engineers at de er naturlige «fase to»-kandidater for faggruppen.

5. Tilgangsstyring i analyseplattformen Faggruppen skal ikke overta alt som har med sikkerhet å gjøre, men det finnes et tydelig skjæringspunkt der data engineers faktisk sitter med hendene på rattet: hvordan man implementerer tilgang i dataplattformen.

Poenget er ikke å erstatte sikkerhetsfunksjonen, men å sikre at tilgangsmodellene faktisk lar seg implementere konsistent i koden.

6. Automatisert dokumentasjon gjennom kode «Vi dokumenterer det etterpå» er kanskje den mest utbredte løgnen i datafaget. En faggruppe kan gjøre det litt mindre løgn og litt mer realitet, ved å bygge dokumentasjon inn i verktøyene og standardene.

Målet er at dokumentasjonen skal være en naturlig del av arbeidsflyten – ikke et separat, ikke-oppdatert Confluence-side ingen leser.

7. Utvikleropplevelse for data engineers Hvis det er tungvint å gjøre det riktig, kommer folk til å gjøre det feil – eller ikke i det hele tatt. En faggruppe har ofte best oversikt over hva som faktisk gjør hverdagen frustrerende eller helt nydelig for data engineers.

Dette er ikke «nice to have». En god utvikleropplevelse er det som avgjør om standardene blir brukt, eller bare nevnt.

8. Kost og kapasitet – FinOps for datapipelines Når alt kjører i skyen, er det kort vei fra en litt for raus cluster-konfigurasjon til en regning som gjør vondt. Faggruppen kan ta en praktisk rolle her, ikke som økonomer, men som de som kjenner hvordan pipelines faktisk oppfører seg.

Poenget er å gjøre kost synlig tidlig, ikke når fakturaen kommer.

9. Onboarding og kompetansebygging Standarder og mønstre har begrenset verdi hvis nye data engineers starter hvert sitt lille økosystem.

Da slipper man at hver nyansatt får sin egen personlige versjon av «hvordan vi gjør ting her».

Faggruppen må levere mer enn retningslinjer

Det finnes mange intranett fulle av prinsipper og «slik bør vi gjøre det»-dokumenter. Det de færreste trenger, er enda ett. Det som faktisk gjør en forskjell, er konkrete artefakter teamene kan ta i bruk neste uke.

Tre ting skiller seg ut som særlig effektive:

1. Maler og «spin-up»-verktøy En enkel måte å starte nye pipelines på kan være et cookiecutter-prosjekt eller tilsvarende som:

Målet er at et nytt team skal kunne komme i gang på én dag – ikke én sprint.

2. Helsesjekk for team En kort helsesjekk gir både faggruppen og teamene et felles bilde av hvor de faktisk står.

Den kan dekke ting som:

Det trenger ikke være mer avansert enn en enkel score per område og noen anbefalte tiltak. Poenget er å gjøre gapene synlige.

3. Et lite sett KPI-er Noen få indikatorer er nok til å se om faggruppen faktisk gir effekt:

Det viktigste er ikke millimeterpresisjon i første omgang, men at man kan vise en trend – og knytte den til konkrete tiltak faggruppen har gjort.

En realistisk 90-dagers plan

For å unngå at faggruppen dør i PowerPoint-fasen, kan det være nyttig å tenke i tre enkle steg:

Uten den siste setningen er alt bare «anbefalt praksis». Da vinner som regel vanene.

Er dere klare for en faggruppe? Fem raske spørsmål

Til slutt, en liten sanity check før man kaster seg rundt:

Hvis svaret er nei på flere av disse, er kanskje ikke tiden riktig ennå. Hvis svaret stort sett er ja, har dere et godt utgangspunkt for en faggruppe som gjør mer enn å skrive dokumenter: en liten, effektiv mekanisme for å ta tilbake kontrollen over data engineering-standardene – uten å kvele desentraliseringen som skulle gi fart og eierskap i utgangspunktet.