Data Mesh | En komplett guide

I denne artikkelen vil vi utforske Data Mesh-konseptet og de fire prinsippene som ligger til grunn for det. Vi vil også se nærmere på hvordan Data Mesh bygger på tankegods fra software- og team-organisering, samt vurdere fordelene og kritikken av konseptet.

Data mesh er en ny tilnærming til dataarkitektur og organisering som har som mål å hjelpe virksomheter med å utnytte data på en mer effektiv og skalerbar måte. Konseptet ble introdusert av Zhamak Dehghani gjennom artikkelen “How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh” i 2020, og har siden fått mye oppmerksomhet i databransjen siden . Oppmerksomheten er ikke blitt mindre etter boka Data Mesh: Delivering data-driven value at scale kom ut i 2022.

Data Mesh er ikke teknologi eller et produkt, og det utvikles fortsatt. Det finnes ingen referansearkitektur for øyeblikket, og å implementere det er komplekst og tidkrevende fordi det krever at et samspill mellom flere bestanddeler: eierskap, data, organisering og teknogi. Data Mesh kan ses på som en måltilstand, som vi tilstreber å nærme oss over tid gjennom bevisste tiltak som gir modning.

Var dette litt vagt? Les videre, så håper jeg det blir tydeligere.

Hvilke problemene søker Data Mesh å løse?

I løpet av det siste tiåret, spesielt med fremveksten av skytjenester, har mange initiativ innen BI og analyse, slitt med å oppnå de gevinstene de var tiltenkt. Data-initiativene kan ha tatt lengre tid eller vært mer utfordrende enn først antatt, løsningene har kanskje ikke oppnådd den nødvendige kvaliteten (spesielt datakvalitet), og eksisterende problemer rundt datatillit og styring kan fortsatt forårsake problemer og i noen tilfeller ha blitt forverret ved overgang til skyen.

Når datamengdene vokser, blir det vanskeligere å lagre, behandle og analysere data på en effektiv måte. Mange virksomheter benytter fortsatt et sentralisert datavarehus on-premise som ikke er i stand til å håndtere den økende mengden av data, noe som fører til forsinkelser og redusert muligheter til å utføre analyser og rapportering. Det sentrale utviklerteamet forsøker etter beste evne å utvikle nye rapporter, levere data til data science (som har bygget egne løsninger på siden), og flikke på alt det gamle. Og misnøyen øker.

Samtidig er det å bli datadrevet et av de øverste strategiske målene for mange virksomheter, der de ønsker å ta bedre beslutninger basert på fakta og prediksjon, tilby bedre og mer skreddersydde tjenester og produkter, øke kvaliteten på produkter og tjenester, gi ansatte en morsommere og mer effektiv hverdag og ikke minst redusere driftskostnader.

Data Mesh tar sikte på å adressere flere problemer som er vanlige i datahåndtering og analyser når datamengder og forretningskompleksitet øker.

Mulige årsaker til problemene

En av hovedårsakene til utfordringene som data-initiativ møter, er at de i stor grad har vært tekniske øvelser. Fokuset på produkt, plattform og funksjonsvalg har overskygget områder som mennesker, prosesser og kultur. Dette betyr ikke at disse løsningene nødvendigvis må mislykkes, eller at de tekniske problemene er uviktige. Men - det er derfor Data Mesh som konsept nå ressonerer godt.

Det er ofte et kunnskapsgap mellom IT og forretningsbrukere; IT har vanligvis svært sterke tekniske ferdigheter, men har ofte mindre innsikt i hvilke data forretningsbrukere bruker, hvordan de bruker dem og når, i hvert fall ofte mindre innsikt enn de tror de har. Samtidig kjenner forretningsbrukerme ofte ikke de underliggende dataene, kildene og kvaliteten så godt som de tror de gjør.

Data Mesh to the rescue!

Data mesh tilnærmingen anerkjenner at data er en sentral ressurs for organisasjonen og at det er nødvendig å involvere alle deler av virksomheten for å utnytte dataressursene effektivt. Dette innebærer at man må se på mennesker, prosesser og kultur som like viktige som teknologi.

De fire prinsippene i Data Mesh

For å forstå data mesh, er det viktig å kjenne til de fire grunnleggende prinsippene som ligger til grunn for konseptet.

Prinsipp 1: Domene-inndelt og forretningsmessig eierskap

I stedet for å sentralisere eierskap til alle data, oppfordrer Data Mesh-tankegangen til å dele dataeierskapet mellom de ulike domenene i organisasjonen. Dette kan bidra til å redusere flaskehalser og forbedre samarbeidet mellom ulike team og avdelinger.

For å oppnå suksess i utviklingen av data- og analyse-løsninger er samarbeid mellom forretningssiden og utviklermiljøet avgjørende. Den tradisjonelle ansvarsmodellen samler utviklerkompetanse og systemeierskap på ett sted og forretningsbehov på et annet sted, noe som fører til ansvarsforhold som faller mellom to stoler, spesielt når det gjelder dataeierskap.

Dehghani understreker viktigheten av å ha eierskap og utvikling av data- og analyse-tjenester på forretningssiden, slik at dette ikke bare blir noe IT-miljøet jobber med, gjennom Data Mesh. En direkte løsning er å flytte ansvaret for data- og analyse-løsninger til forretningssiden, kalt domeneorientert dataeierskap og arkitektur.

Dette innebærer at ansvarlig leder for hvert domene tar eierskap til forretningsprosesser, -behov, arkitektur, systemer og data, og legger til rette for at data kan brukes av andre domener i virksomheten. Forretningseieren av et domene, for eksempel Leder for Produktutvikling i en produksjonsbedrift, er ansvarlig for egne mål, og rammebetingelsene for å levere på målene. Et datateam innen produktutvikling vil i dette eksemplet ha ansvar for å forvalte og vedlikeholde sine egne data om produktene (tekniske data, spesifikasjoner, etc), men også sørge for at de kan deles med andre.

Prinsipp 2: Data som produkt

Data mesh-konseptet anser data som et produkt, noe som betyr at dataene skal være lett tilgjengelige, forståelige og anvendelige for de som trenger dem. Dette krever et fokus på brukervennlighet og gode data-APIer.

Terskelen for å utnytte data i mange virksomheter i dag er ganske høy, noe som kan tilskrives flere faktorer som at data kan være vanskelig å finne, forstå og få tilgang til. I tillegg er det ikke alltid at man kan stole på datakvaliteten. For å senke denne terskelen, må data tilbys som et produkt som er lett å finne og enkelt å bruke. Men hva innebærer det egentlig å tilby data som et produkt?

Først og fremst innebærer det å ta utgangspunkt i brukerne og deres behov. Dette er ikke en ny tankegang innen dataverdenen, da mange av oss bruker tid på å forstå og adressere brukernes behov i dag. Men Data Mesh-konseptet tar dette et steg videre: Et dataprodukt må inneholde alt som er nødvendig for å kunne tas i bruk.

Det betyr at det ikke er tilstrekkelig å bare tilrettelegge noen datastrukturer på en dataplattform og be folk forsyne seg. Man må også tilby nødvendige beskrivelser, forklaringer og verktøy, slik som programkode, API-er, eksempler på analyser osv., som kan bidra til å senke terskelen for bruk. Ved å tilby disse elementene, kan man gjøre det enklere for brukerne å forstå hva dataene inneholder og hvordan de kan brukes.

Dataene må også være selvforklarende og skape tillit. Hvis brukerne ikke stoler på kvaliteten, eller må lese gjennom utdatert eller mangelfull dokumentasjon, vil de ikke benytte seg av dataene. Derfor er det viktig å sørge for at dataene er renset for det som brukere oppfatter som støy og at de er utformet på en slik måte at det fremkommer tydelig hvordan de henger sammen med forretningsprosessene. På denne måten kan man øke sannsynligheten for at brukerne vil benytte seg av dataene og dra nytte av det de har å tilby.

Prinsipp 3: Delt/federert styringsmodell

Dataproduktene innen et domene må forvaltes og utvikles av et eget produktteam som har best kunnskap om dataene. Et slikt team settes sammen av utviklere og personer med god kjennskap til dataene det dreier seg om, det vil si personer som er involvert i forretningsprosessene som skaper dem.

Samtidig kan man ikke overlate alt til produktteamene. For at et slikt system skal fungere, er det nødvendig at man fra sentralt hold tar ansvar for å definere og være sparringspartner på standarder som det ikke er hensiktsmessig at alle finner opp selv.

Eksempler på dette kan være hvordan man definerer metadata om dataproduktene, navngivning på grensesnitt for dataproduktene eller klassifisering av dataprodukter i henhold til informasjonssikkerhet og personvern.

Standardiseringsarbeidet blir dermed et av de viktigste (om ikke det viktigste) bidragene fra det sentrale teamet, som kanskje ligger under Chief Data Officer.

Prinsipp 4: Felles dataplattform for selvbetjening

Til forskjell fra en tradisjonell, monolitisk dataplattform der det sentrale datateamet gjerne deler samme miljø, bør heller hvert enkelt domeneteam tilby sine dataprodukter på et eget logisk område av en felles løsning som forvaltes og driftes sentralt.

Alternativet ville vært å skape mange konkurrerende plattformer som ikke samarbeider godt sammen, med utallige teknologier og arkitekturmønstre. Det er urealistisk å forvente at hvert enkelt domene selv skal sørge for infrastrukturen i en desentralisert modell.

Det legges vekt på å ha en felles plattform for dataintegrasjon, datalagring og -transformering, med støtte til MLOps og DataOps. Verktøy for analyse og visualisering kan være en del av den felles plattformen eller være mer frittstående.

I en slik løsning er det viktig å abstrahere bort mest mulig av kompleksiteten og minimere arbeidet med å etablere en ny instans, samtidig som man unngår fellen det er å tilpasse felles løsninger til individuelle team sine behov.

Merk at Data Mesh egentlig ikke er et arkitekturkonsept, selv om mange tror det. Men prinsippene krever ofte at teknologi og arkitektur må tilpasses. En slik selvbetjent, felles plattform vil for mange virksomheter representere både ny teknologi og en ny metode for hvordan løsninger tilbys til sluttbrukere.

Glitni tror sterkt på å bygge en god utvikleropplevelse for alle brukere av dataplattformen - og at det krever spesialisering innen DataOps og MLOps for å utvikle og forvalte disse felles kapabilitetene. Dette er nettopp det som Data Mesh-konseptet også legger vekt på.

Data Mesh bygger på tankegods fra software og team-organisering

Data Mesh høres litt kjent ut, tenker du kanskje. Det kan du ha rett i, fordi Zhamak Dehghani bygger på både prinsipper fra software-utvikling og team-organisering. Det er ikke noe feil å hente inspirasjon fra og bygge videre på andre, spesielt ikke når det er gjort på en måte der alle puslespillbitene som må på plass forklares godt.

Data Mesh henter inspirasjon fra software-utvikling

Data Mesh-konseptet henter mye inspirasjon fra IT-utvikling, spesielt fra prinsippene og metodene som ligger bak mikrotjenester, DevOps og agile utviklingsmetoder:

1. Desentralisering: Akkurat som mikrotjenester oppmuntrer til desentralisering av applikasjonsarkitektur ved å dele den opp i mindre, selvstendige og lett integrerbare komponenter, legger Data Mesh vekt på å desentralisere datalagring og -behandling. Dette innebærer at ansvaret for dataene blir delt mellom flere autonome team, i stedet for å være sentralisert i ett enkelt team eller system.
2. Eierskap og ansvar: I likhet med DevOps og agile metoder, som fremmer eierskap og ansvar blant utviklingsteamene for hele livssyklusen til et produkt, oppmuntrer Data Mesh til at dataeiere og dataforbrukere har et tett samarbeid. Dette innebærer at teamene både er ansvarlige for kvaliteten og tilgjengeligheten av dataene de produserer, og for hvordan dataene blir brukt og integrert i organisasjonen.
3. Tverrfaglige team: Data Mesh støtter prinsippet om tverrfaglige team, som er vanlig i agile metoder. Hver team har både dataeksperter og domeneeksperter som arbeider sammen for å sikre at dataene er tilpasset brukernes behov og forretningsmål. Dette fremmer effektivitet og smidighet i datadrevne prosesser og beslutningstaking.
4. Evolusjonær arkitektur: Data Mesh tar inspirasjon fra prinsippene for evolusjonær arkitektur, som betyr at systemet er bygget for å kunne endres og tilpasses over tid. Dette er viktig for å kunne håndtere den stadig økende mengden av data og for å imøtekomme endringer i organisasjonens behov og mål.

Tankegodset er altså ikke helt nytt, men det er tilpasset og videreutviklet betydelig (spesielt gjennom boken) for å passe til data og analyse.

Data Mesh henter også inspirasjon fra boken “Team Topologies”

Data Mesh-konseptet henter inspirasjon fra boken “Team Topologies” av Matthew Skelton og Manuel Pais, som fokuserer på hvordan organisasjoner kan designe team og samarbeid for å oppnå bedre resultater og skape mer effektive systemer:

1. Teaminteraksjonsmønstre: Boken “Team Topologies” introduserer fire teaminteraksjonsmønstre: samarbeid, X-as-a-Service, tilrettelegging og undervisning. Data Mesh bruker disse mønstrene for å skape et samarbeidsmiljø der dataeiere, dataforbrukere og domeneeksperter arbeider sammen for å forstå, tilrettelegge og optimalisere bruken av data.
2. Klarhet i ansvarsområder: “Team Topologies” legger vekt på å definere klare ansvarsområder for hvert team, noe som også er viktig i Data Mesh-konseptet. Ved å tildele ansvaret for data til spesifikke team, sikrer man at dataeiere og dataforbrukere vet hvem de skal samarbeide med og hvilke ansvarsområder de har i forbindelse med datadrevne prosesser.
3. Plattformteam og strømlinjeformede team: “Team Topologies” beskriver plattformteam som team som leverer tjenester og verktøy til strømlinjeformede team, som fokuserer på å levere verdi til kunder eller brukere. Data Mesh inkorporerer denne tankegangen ved å ha separate team for å håndtere datainfrastruktur og dataverktøy (plattformteam) og team som fokuserer på å levere data som et produkt og skape verdi fra data (strømlinjeformede team).
4. Kognitive belastninger: Boken understreker betydningen av å begrense den kognitive belastningen på teammedlemmer, slik at de kan fokusere på sitt kjerneområde. Data Mesh tar hensyn til dette ved å desentralisere datahåndtering og la team fokusere på deres spesifikke domene og data, noe som reduserer kompleksiteten og den kognitive belastningen for hvert team.

Fordeler med data mesh

Det er flere potensielle fordeler med Data Mesh, om prinsippene blir implementert som en helhet, og understøtter hverandre.

• Skalerbarhet og fleksibilitet: En av de største fordelene med data mesh er skalering og fleksibiliteten det gir. Ved å spre dataeierskapet over flere domener og team, kan det kan bli enklere å skalere opp eller ned etter behov. Dette kan også bidra til en mer fleksibel arkitektur som kan tilpasses og utvides etter hvert som virksomheten vokser og endrer seg.
• Bedre datautnyttelse: Data mesh kan bidra til å øke datautnyttelsen ved å gjøre data mer tilgjengelige og brukervennlige. Når data behandles som et produkt og organisasjonen har en plattformtilnærming, kan det bli enklere for ansatte å finne, forstå og bruke dataene de trenger i sitt arbeid.
• Reduserte kostnader: Ved å redusere avhengigheten av sentraliserte dataressurser og flaskehalser, kan data mesh føre til reduserte kostnader knyttet til datahåndtering og -analyse. Dette inkluderer kostnader for infrastruktur, vedlikehold, og personell.

Kritikk av Data Mesh-konseptet

Kritikken mot Data Mesh handler ofte om tre ting: 1) kultur og kompetanse, 2) teknologi og arkitektur og 3) siloer og fragmentering.

• Kultur- og kompetanseendringer: Implementering av data mesh krever ofte store kulturelle og kompetansemessige endringer i en organisasjon som er MYE bredere enn å kun gjelde data. Eierskap til et domene bør jo inkludere både prosesser, organisering, teknologi/systemstøtte OG data. Datadimensjonen kan og bør ikke optimaliseres for alene. I tillegg vil det være utfordrende å få alle ansatte til å forstå og akseptere de nye prinsippene, og det kan være nødvendig med opplæring og kompetanseutvikling for å sikre at alle team er i stand til å håndtere de nye ansvarsområdene som følger med Data Mesh.
• Manglende modenhet i teknologiske løsninger: Selv om data mesh-konseptet har fått mye oppmerksomhet, er det fortsatt relativt nytt, og det finnes ikke alltid modne teknologiske løsninger som støtter alle aspektene ved data mesh rundt domene-eierskap til data og metadata, APIer og datautveksling etc.
• Risiko for siloer og fragmentering: En annen bekymring knyttet til data mesh er at den økte autonomien til de ulike datateamene kan føre til siloer og fragmentering, spesielt hvis det ikke etableres klare retningslinjer og prosesser for samarbeid og datautveksling mellom teamene. Dette kan i verste fall motvirke noen av fordelene ved data mesh og skape nye utfordringer.