DataOps | Vi slår et slag for å ha et sentralt dataplattformteam

Med ny arkitektur følger også muligheten til å organisere oss annerledes. Vi mener denne muligheten bør gripes, og at man spesielt bør vurdere å etablere et eget dataplattformteam

I gamle dager opererte vi som regel med ett team som håndterte drift av datavarehus og verktøy (on-premise), utviklet ETL/ELT og utviklet standardrapporter for virksomheten. Vi hadde et samlet, teknisk fagmiljø, men hadde utfordringer med at kapasiteten til å utvikle nye løsninger gikk dramatisk ned over tid, da vi fikk stadig mer til forvalting.

Plattformkapabilitetene var relativt stabile, og endret seg bare ved oppgraderinger av verktøyene. Disse oppgraderingene spiste mesteparten av kapasiteten til teamet i periodene de foregikk.

Skybasert arkitektur gir oss nye gleder - og sorger

I data lakehouse-verdenen i skyen har vi mulighet til å organisere oss annerledes. Vi får løpende nye muligheter/funksjonalitet vi kan ta i bruk. Vi trenger ikke DBAer lenger til å drifte databasene, men har et stort behov for plattformutviklere og -arkitekter som evner å sette sammen komponenter som støtter behovene. Og behovene er nå bredere: vi har gått fra kun rapportering, til selvbetjening, avansert analyse og sanntidsstrømming. Dette gir masse muligheter, men er mer krevende å navigere i.

Med DevOps/DataOps og smidig tenker vi annerledes rundt leveranser til brukerne. Vi jobber sammen i team med brukerne, med leveranser som utvikler seg i takt med behovene.

Mesh eller ei, vi har i stadig større grad desentralisert utvikling. Transformasjoner og -logikk utarbeides i tett samarbeid med brukerne som har domenekunnskap, og i mange tilfeller av brukerne selv. Med DevOps har vi ikke overleveringer fra utvikling til drift – de som utvikler er også ansvarlig for drift – for drift er jo egentlig videreutvikling i mindre steg.

Hva betyr dette for organisering av dataplattformteam?

Vi slår et slag for å ha et sentralt dataplattformteam, som har et tydelig ansvar for drift og videreutvikling av tjenesten dataplattform, som benyttes for å levere ulike former for dataprodukter av mange ulike team/miljøer.

Vi synes det er krevende for én person å beherske – og ha tid til – å både være ELT-utvikler og dataplattformutvikler, som er en kombo som vi ser ofte. Det blir morsommere og bedre løsninger om vi spesialiserer oss. Dataplattformutviklere bidrar til bedre funksjonalitet og økt stabilitet, ytelse, sikkerhet og kostnadseffektivitet. I tillegg vil spesialisering øke sannsynligheten for at nye kapabiliteter utvikles riktig. Det er jo lurt.

Dataplattformteamet bør ikke ha ansvar for utvikling av MLOps, datasett og rapporter, prognosemodeller etc.

Alle trenger så klart gode ELT-utviklere og data-arkitekter, som

• Liker å utvikle pipelines i en skybasert infrastruktur
• Er glad i å sette opp transformasjoner med SQL
• Trives med med datamodellering
• Har interesse for datastreaming og tilhørende løsninger
• Synes det er gøy å utvikle dataprodukter

Alle trenger også gode dataplattformutviklere og -arkitekter, som

• Synes det er gøy skape solide og skalerbare dataplattformer
• Trives med å sette opp CI/CD- pipelines og å bygge dataplattform som kode
• Liker å jobbe med dataarkitektur
• Er glad i å bygge robuste og automatiserte pipelines for å innhente og prosessere
• Er komfortabel med smidig metodikk og leveranser med en kontinuerlig utvikling av kapabiliteter

Her er hvordan vi synes det skal funke, sånn cirka:

Er du en dataplattform- eller ELT-utvikler som er nysgjerrig på fagmiljøet Glitni bygger? Les gjerne mer om hvordan vi har hovedfokus på data - hver eneste dag.