author image

Magne Bakkeli

Magne har over 20 års erfaring som rådgiver, arkitekt og prosjektleder innen data & analytics. Han er god til å navigere i både forretningsmessige og tekniske problemstillinger, og jobber like godt med konsernledelsen som IT-avdelingen.

7 spådommer for data og analyse i 2022

13.02.2022 | 10 min lesetid
Emneknagger: #datalakehouse, #dataops

Har du full oversikt over alt som skal til for å bli mer datadrevet? Her er 7 utviklingstrekk du bør kjenne til innen kategoriene arkitektur, utviklerteam, dataflyt, DataOps og governance, data science og analyse, leveransemodell og verdiskapning fra data.

1. Arkitektur

Gled deg, datalakehousene kommer!

Data lakes (aka Hadoop-teknologi, aka Big Data) var mye snakket om en periode, og jeg har selv vært produkteier for en. Data Lakes gir mulighet til å lagre svært store mengder data rimelig, og kan gi stor fleksibilitet til utviklere og data scientists til å lage mer avanserte dataprodukter. Med Spark fikk vi også muligheter for å skalere prosesseringen av store datamengder. Men - dataene må bearbeides videre for å gi verdi, og brukergruppen forble liten fordi datauttrekk og -prosessering krevde betydelig teknisk kompetanse.

Datavarehus har vi hatt i mange år, og også her har jeg vært prosjektleder og produkteier. Den store fordelen med datavarehus at dataene er tilrettelagt for bruk gjennom felles datamodeller.En stor del av arbeidsmengden med å sammenstille og vaske data og å standardisere forretningsmessige begreper blir gjort på forhånd, slik at det for brukere blir en langt kortere vei til selvbetjening. På den andre siden krever det lang tid å bli enige og utvikle dette, og fleksibiliteten til å raskt lage noe nytt oppleves som begrenset.

Enkelte virksomheter har til og med både flere data lakes og flere datavarehus. Data lakehouse-modellen, der vi har en data lake med rådata, og logiske datavarehus-lag på toppen, bidrar til å minimere dataflytting. Delta Lake-filformatet gjør at vi også får logiske databaseoperasjoner til Data lake-filer (ACID, at vi blant annet kan både endre og slette data - og det må vi kunne for å f.eks i møtekomme GDPR-krav). Teknologi som Databricks og Snowflake, kjørt på skyinfrastruktur, gjør det mye enklere å få dette til å spinne rundt. Endelig kan vi bruke energien vår på å skape verdi fra dataene, fremfor å jobbe med å provisjonere hardware, konfigurere for ytelse eller utføre oppgraderinger.

Data lakehouse-arkitekturer får fotfeste
Data lakehouse-arkitekturer får fotfeste

HVA SKJER I 2022?

 

Data lakehouse-arkitekturer får fotfeste

Data lakehouses implementeres nå, også i Norge. Og ja, vi i Glitni har fått førstehåndserfaring!

 

Hva dette betyr for deg kan følge to hovedspor:

  • Har dere ikke noe fra før? Da er det ikke så mye å tenke på, om dere har en både litt data og mange use case.
  • Mye teknisk gjeld og begrenset dokumentasjon? Det tar tid å flytte det gamle og man arver ofte veldig mye av den tekniske gjelden uansett. Vi anbefaler å vurdere hvilke deler av løsningen som bør bygges på nytt, og å gjøre dette med en gradvis tilnærming.

2. Utviklerteam

Sky først - og dataplattform-arkitekter og -utviklere blir det hard kamp om!

Så og si ingen etablerer nye dataplattformer på egen infrastruktur. De 10 prosentene som ikke velger Google Cloud, AWS eller Azure har enten store datasentre selv, for mye data som må prosesseres eller strenge regulatoriske begrensninger som gjør at skyløsningene ikke kan benyttes. Vi andre bruker skyen først.

Du trodde verden var enklere i skyen? Det er den, men plattformen i skyen skal gjerne løse flere typer use case utover den historiske rapporteringen. Nye roller for dataplattformen vokser frem. Et datalakehouse i skyen hverken etablerer seg selv, drifter seg selv eller får nye kapabiliteter av seg selv. I motsetning til mange andre hyllevare-applikasjoner så ligger mesteparten av innsatsen i hvordan dataene i plattformen innhentes, lagres og behandles.

Vi trenger dedikerte plattformarkitekter og -utviklere. Merk at dette ikke er data engineers med et nytt navn - dette er en helt egen rolle. Det skader imidlertid ikke at flere i dataplattform-teamet har bakgrunn fra ELT-utvikling.

HVA SKJER I 2022?

 

Plattform-arkitekter og -utviklere blir stadig viktigere, og disse finnes det foreløpig få av

 

  • Plattformteamet må ha god forståelse for forretningskrav som må oversettes til felleskapabiliteter, DevOps/DataOps/MLOps, infrastruktur, integrasjonsmetoder og -grensesnitt, dataflyt (ELT, Pub/sub), modellering, overvåkning og datatesting (data observability) og ikke minst sikkerhet og tilgangsstyring.
  • Super-personen som kan alt dette til fingerspissene finnes naturlig nok ikke, så bygg komplementær kompetanse i teamet. Bruk gjerne også konsulentmarkedet for å få etablert teamet, plattformen og gode prosesser og rutiner. Samtidig er det viktig å sørge for å bygge den interne kompetanse på veien!

3. Dataflyt

ELT, Pub/sub og Reverse ELT: Ja takk!

Selv om ETL (Extract, Transform, Load) har levd godt de siste årtiene, har ELT (du gjettet riktig: Extract, Load, Transform) nå tatt over. Det gir mer mening å prosessere dataene der dataene bor, og da kan vi selvfølgelig prosessere de på alle de måtene use casene krever (analyse, rapportering mv).

Pub/sub-integrasjon kan være arbeidskrevende, men frigjør dataene til all mulig bruk i nær-sanntid, også i miljøer utenfor dataplattformen. Datastrømmmen blir egentlig mikrotjenester av dataprodukter, som ulike løsninger kan abonnere på. Kafka er fortsatt den ledende teknologiplattformen, men i Norge er det fortsatt relativt få som har mye erfaring med denne teknologien. Kompetansen som utvikles nå, vokser frem fra generelle utviklermiljø, og ikke fra den tradisjonelle ETL-tunge datavarehus-verdenen.

Data vil flyte inn til dataplattformen på flere måter fremover, også via Pub/Sub
Data vil flyte inn til dataplattformen på flere måter fremover, også via Pub/Sub

Reverse ELT er et ganske ferskt begrep, og omhandler et subsett av dataintegrasjon knyttet til Master Data Management. Kort oppsummert: det finnes nå verktøy som dytter endringer i f.eks produktattributter inn i løsninger som trenger disse. Kanskje hører vi mer om dette i løpet av årene fremover, eller det blir bare en naturlig feature innen de etablerte MDM- eller dataintegrasjonsverktøyene.

HVA SKJER I 2022?

 

Ja takk, vi trenger flere måter å få tak i data på

En trend som for meg er blitt tydelig, er vi sier som regel “ja takk” til alle måter å få data inn til en dataplattform på. Vi har noen arkitekturmønstre som vi foretrekker (fordi det er billigst/enklest/best å overvåke etc), og noen vi bruker av og til. En kombinasjon av ELT og Pub/sub er nok en lite kontroversiell spådom.

 

Det betyr minst tre ting:

  • Data engineers må enten lære seg flere verktøy og arkitekturmønstre, eller samarbeide med ulike utviklerteam for å få dataene inn.
  • Integrasjonsarkitektene må beherske data-arkitektur i større grad.
  • Det blir viktig å forstå hvor dataene kommer fra, hvordan de er behandlet og hvilke forutsetninger man kan legge til grunn når dataene skal tolkes. Dette betyr at verktøyer og kapabiliteter som datakatalog og data lineage blir viktigere.

4. DataOps og Data Governance

Data observability + hva skjer med datakatalogene?

Det finnes mange +Ops-begreper. For et par år siden kom MLOps - dvs drift og videreutvikling av maskinlæringspipelines. Og nå snakker vi om DataOps. Ingen har vel helt landet definisjonen av begrepet, og de praktiske konsekvensene, utover at det handler om å få prinsipper knyttet til DevOps+Smidig fra programvareutvikling til å møte dataverdenen.

HVA SKJER I 2022?

 

Det er to områder som peker seg ut som trender for 2022 innen DataOps og Data Governance:

 

Data observability blir noe data engineers begynner å prate om, men få virkelig får til å svinge

  • Data observability handler om å automatisere overvåkning av dataflyten, med vekt på data lineage (hva som har skjedd med dataene frem til et punkt) og datakvalitet (ulike logiske sjekker som viser om dataene har endret karakter utover det vi forventer). Her modnes både verktøy og metoder over tid, men foreløpig er vi startgropen.

Mye data, mange brukere, og mange ulike use case krever at datakatalogen må på plass

  • Datakataloger krever mye av mennesker og prosesser for å enes om definisjoner, eierskap og rutiner. Den praktiske konsekvensen er at datakatalog-initiativ skaleres ned til de mest sentrale data-domenene og holdes på et minimum. Og det er greit. Og kanskje er det også slik at vi kommer til å ha datakatalog-kapabiliteter spredd på flere verktøy. Hva ønsker vi oss? Jo, automatisert generering og deling av metadata gjennom hele dataflyten, tilgjengelig for alle som trenger de, med muligheter for sosial samhandling slik at vi kan lære av hverandre hvordan dataene bør brukes.

5. Data Science og analyse

Leve forretningsanalytikerne!

Vi er ute etter å løse forretningsproblemer og bruke data til å støtte operativ drift. Min påstand er at fleste virksomhetene heller ikke er klare for å ta i bruk de mest avanserte metodene. Så lenge de ikke har kontroll på grunnleggende prosesser knyttet til dataforvaltning og å bruke data til å svare på forretningsspørsmål som “hva har skjedd/“hvorfor skjedde det”, så vil en oppskalering av virksomhetens kollektive datakompetanse ha relativt mye større verdi enn å optimalisere smale use case.

HVA SKJER I 2022?

 

Forretningsanalytikere først

  • Data science som begrep roer seg ned litt, og forretningsanalytikerne inntar rampelyset. Forretningsanalytikerne kan vi som regel dyrke frem selv, mens produktive data scientists er svært vanskelig å hente inn.

Økt bevissthet rundt kompetanseheving? Ja takk!

  • Dyrking av den kollektive evnen til å bruke data er viktig, og for mange ligger det fortsatt stort potensiale for verdiskapning fra data her. Interne kompetanseprogrammer fortsetter å bli gjennomført for å øke kompetansen, men dessverre vil fortsatt de fleste være fokusert på hvordan bruke Excel/PowerBI/Tableau og andre selvbetjeningsverktøy, fremfor å bruke data til problemløsing.

6. Leveransemodell

Desentralisert eierskap brer mer om seg, inspirert av Data Mesh

Jobber du innen data-verdenen har du sikkert fått med deg begrepet data mesh-begrepet for en tid tilbake. Konseptet ble først beskrevet i to blogginnlegg skrevet av Zhamak Dehghani i 2019: How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh og Data Mesh Principles and Logical Architecture. Kjerneideen er at virksomheter kan bli mer datadrevet ved å flytte fra sentrale datavarehus og data lakes til domene-orientert dataeierskap og arkitektur, drevet av selvbetjent analyse og et sett felles retningslinjer. Svakheten med dagens organisering er at vi skaper flaskehalser i det sentrale leddet som en dataplattform er. Data Mesh søker å fri seg fra en sentralisert arkitektur ved å desentralisere både eierskap og ansvar for å utvikle dataprodukter.

Ideen har fått fart, og et selskap som Zalando er nå aktive med å fortelle hvordan de implementerer Data mesh. Det som gjør det hele litt forvirrende, er at Data mesh ikke er noe som kan kjøpes. Det er mer et konsept for organisatorisk design, som består av biter som skal settes sammen som et puslespill.

Ideer fra Data Mesh om desentralisert eierskap kommer snikende
Ideer fra Data Mesh om desentralisert eierskap kommer snikende

HVA SKJER I 2022?

 

Desentralisert eierskap kommer snikende

Desentralisert eierskap til datasett, rapporter og analysemodeller brer mer om seg, men vi er ikke fanatiske. Det tar lengre tid med dataflyter og datadomener (tenk “Kunde” eller “Produkt” som domener). Og det er ikke sikkert alle bør desentralisere alt - data mesh som designkonsept passer ikke alle typer virksomheter - spesielt ikke de små og mellomstore.

 

Ekte data mesh har de færreste enda, siden de fleste organisasjoner må skalere opp analyse- og teknisk kompetanse betydelig for å kunne drive frem domene-basert eierskap og -arkitektur. Og mange er i ferd med å innse at det blir krevende å skille ut eierskaps- og leveransemodeller kun for dataprodukter, når resten av det digitale økosystemet også bør ses på på samme måte.

 

Det kan også være verdt en debatt om man trenger å desentralisere arkitekturen (vi får til mye med teknologier som Snowflake, Databricks og dbt i en sentral plattform), det er vel egentlig gjennom organiseringen verdien av Data Mesh realiseres?

7. Fra data til verdi

(Nesten) alle innser at de må bli datadrevet

Blir norske virksomheter mer datadrevne? Kanskje, det finnes nok flere som har gjort undersøkelser her. Modning krever tid, og kommer ikke tilfeldig. Heldigvis har vi fått svært synlige synlige internasjonale - og noen få norske - eksempler på at data er den store forskjellen på å være bransjeleder og den som ligger bakerst i feltet.

Vi trenger ikke lenger mye bruke tid på å argumentere for at data kan gi verdi. I stedet handler samtalene handler primært om å konkretisere hvor stor verdi, hvor vi har størst potensiale, og hva må til for å komme dit. De fleste har gjort noe, og er i ferd med å gjøre mer.

HVA SKJER I 2022?

 

Mer datadrevne prosesser - og kanskje kan vi begynne å snakke mer om fremtiden?

Vi prater mindre om avansert analyse, og mer om å bli datadrevet gjennom alle prosesser. Vi må rett og slett få faktabaserte beslutninger, kunne se mer fremover gjennom predisjon og automatisere der vi har repetetive oppgaver som som følger standardmønstre. Og apropos prediksjon, jeg skulle gjerne ønsket flere lederne spurte forretningsanalytikerne sine om vi kan forsøke å se på hva som kan skje fremover (neste uke, neste måned og neste år).

 

Prosessforbedringsarbeid blir (endelig) mer datadrevet

Personlig har jeg et håp om at prosessforbedring, der Lean har vært moteordet i årtier, kan på sikt fusjonere med datadrevet automatisering og problemsløsning. De store konsulenthusene har nå både Lean-konsulenter og datakonsulenter, men samordningen og samarbeidet har ikke vært imponerende så langt. 2022 må bli året der noen griper muligheten, og får de første norske suksesshistorene som alle snakker om. Hansken er kastet, som de sa i gamle dager.

author image

Magne Bakkeli

Magne har over 20 års erfaring som rådgiver, arkitekt og prosjektleder innen data & analytics. Han er god til å navigere i både forretningsmessige og tekniske problemstillinger, og jobber like godt med konsernledelsen som IT-avdelingen.