Datamodellering - hot or not?
27.10.2024 | 7 min lesetidKategori: Data Governance | Emneknagger: #Podcast, #Datamodellering, #Organisering
Datamodellering har gjort et sterkt comeback etter å ha vært i skyggenes dal en periode. Denne artikkelen utforsker hvorfor strukturering og standardisering av data igjen har blitt en kritisk del av dataøkosystemet, og hvordan informasjonsarkitekten bidrar til å balansere fleksibilitet og kontroll i moderne dataplattformer.
Informasjonsarkitektens comeback - ordning og reda er på moten igjen!
På 1990- og 2000-tallet var informasjonsarkitekten en sentral figur i datavarehusets storhetstid. I denne perioden handlet mye om å bygge strukturert, pålitelig og sentralisert data for rapportering og analyse. Informasjonsarkitekten sørget for enhetlig datamodellering og harmonisering. Et eksempel på dette kan være datavarehusprosjekter i store bedrifter der informasjonsarkitekten sikret at informasjon fra ulike kildesystemer ble samlet og harmonisert, slik at organisasjonen fikk et helhetlig bilde av dataene sine.
Så kom data scientistene fra ca 2011 og utover, og datamodellering ble gradvis mindre populært. Fokus flyttet seg mot ustrukturert og semi-strukturert data, fleksibilitet og eksperimentering, hvor det var mindre behov for de strenge strukturer og standarder som informasjonsarkitekten tradisjonelt har stått for. Data lakes ble sett på som en vei til å håndtere større datamengder med færre restriksjoner, og data scientists tok over som de sentrale aktørene i dataøkosystemet. Spesifikke verktøy som Hadoop og NoSQL-databaser gjorde det enklere å jobbe med ustrukturert data, noe som førte til at informasjonsarkitektene ble delvis parkert på sidelinjen.
Nå ser vi derimot en renessanse for informasjonsarkitekt-rollen. Vi har nå levd noen år i data lakehouse-eraen, der vi har både ustrukturerte og strukturerte data, i originalform som rådata og modellerte data for ulike analytiske formål. Informasjonsarkitekten er tilbake, og viser seg igjen viktig for å balansere fleksibiliteten fra data lakes med behovet for konsistens og kontroll som trengs for å understøtte moderne dataanalyse og beslutningstaking. Data lakehouse-modellen kombinerer fordelene ved data lakes og datavarehus, noe som gjør det enklere å både eksperimentere og sikre at dataene er pålitelig nok til analytiske formål, og dermed gir informasjonsarkitekten en nøkkelrolle i å oppnå denne balansen.
Informasjonsarkitekt-rollen er basert på etablerte rammeverk
Mange har erfart vanskeligheten med å slå sammen data fra forskjellige kilder, for eksempel når data fra CRM-systemer og ERP-systemer skal kobles sammen. Ulike formater og manglende felles definisjoner kan gjøre dette svært utfordrende. Her kommer informasjonsarkitekten inn. Rollen handler om å legge til rette for data som kan brukes på tvers av dimensjoner som tid, geografi og produkt, og om å sørge for felles definisjoner og standarder.
Informasjonsarkitekten har ansvar for en rekke oppgaver, inkludert datamodellering, etablering av datastandarder, sikring av datakvalitet, og utforming av datakontrakter. De bruker verktøy som ER-modellering, SQL, og datakataloger for å sørge for god strukturering og tilgjengelighet av data. Viktige teknikker inkluderer normalisering, dimensjonsmodellering og dataintegrasjon. Normalisering bidrar til å redusere redundans og forbedre datakvaliteten ved å organisere data i relasjoner, mens dimensjonsmodellering hjelper med å strukturere data for analytiske formål, slik at dataene blir enklere å forstå og bruke i rapporter og analyser. Kompetansen deres spenner fra teknisk datakunnskap til forretningsforståelse, og samarbeid med andre roller som Data Engineers, Data Scientists og Enterprise-arkitekter er avgjørende for å lykkes.
Informasjonsarkitekten er mest involvert i de tidlige stadiene av utviklingsløpet for et dataprodukt, når dataene struktureres, kvalitetssikres, og tilgjengeliggjøres for videre bruk. Dette inkluderer oppgaver som å definere datastandarder, etablere datakvalitetskrav, og sikre at nødvendige valideringsregler er på plass for å fange opp feil tidlig i prosessen. Bøkene til Kimball og Inmon på 80- og 90-tallet etablerte det teoretiske rammeverk for datamodellering, som informasjonsarkitektene praktiserer. Disse rammeverkene har satt dype spor i hvordan vi forstår normalisering, dimensjoner og fakta, og de har dannet grunnlaget for mange av dagens dataplattformer.
Arkitektene har nøkkelen til å få en domene-inndeling til å fungere
Enterprise-arkitektens rolle har også utviklet seg i takt med skiftende teknologiske landskap. Mens informasjonsarkitekten fokuserer spesifikt på strukturering og forvaltning av data, har enterprise-arkitekten et bredere perspektiv som inkluderer både teknologisk infrastruktur, forretningsprosesser og strategisk tilpasning. Begge rollene er nødvendige for å sikre at data og teknologi støtter virksomhetens mål på en helhetlig måte.
En konkret utfordring i en domeneinndelt arkitektur er å sikre at ulike domener ikke utvikler overlappende eller motstridende datamodeller, noe som kan føre til problemer med datakvalitet og interoperabilitet. Her spiller informasjonsarkitekten en avgjørende rolle ved å utforme felles datastandarder og sørge for en helhetlig arkitektur som kan brukes på tvers av domener. For eksempel kan det å standardisere kundedefinisjoner på tvers av domener bidra til at alle team har en felles forståelse av hva en “kunde” er, og dermed unngå inkonsistens i analyser og rapporter.
I dag, hvor distribuert ansvar for arkitektur og data gis til funksjonelle eller prosessorienterte domener blir stadig mer utbredt, må både informasjonsarkitekten og enterprise-arkitekten tilpasse sine tilnærminger. Informasjonsarkitekten bidrar til å sikre effektiv deling og skalering av dataprodukter med datakvalitet, mens enterprise-arkitekten sørger for at de teknologiske og organisatoriske rammene muliggjør effektiv samhandling. Tilpasningen til distribuerte datadomener krever at begge rollene jobber tett sammen for å definere klare retningslinjer, standarder og arkitekturprinsipper som kan sikre både skalerbarhet og fleksibilitet i virksomhetens dataøkosystem på tvers av domener.
Informasjonsarkitekt vs Data Engineer: To sider av samme mynt
Det er vanskelig å trekke en klar linje mellom informasjonsarkitekter og Data Engineers. Sistnevnte er ofte mer dyptgående på spesifikke dataområder og bruker mer tid på skrive logikk/kode, mens informasjonsarkitekten er mer overordnet og ser helheten. Et eksempel på forskjellen kan være at en Data Engineer jobber med å optimalisere en ELT-prosess for å hente data fra en kilde, mens informasjonsarkitekten fokuserer på hvordan denne dataen skal struktureres og brukes i en bredere forretningskontekst. Mange Data Engineers utvikler seg gradvis til i større grad ta informasjonsarkitekturroller over tid, der mer og mer tid går på å ivareta helheten fremfor koding.
I et komplekst dataøkosystem er det vanskelig å ha én informasjonsarkitekt med fullstendig oversikt over alt. I stedet kan datamodelleringskompetansen spres til flere personer. Det skalerer bedre, og vi unngår flaskehalser. Jeg foretrekker selv å ha få rendyrkede informasjonsarkitekter (dvs som ikke koder), men heller ha Data Engineers som kan modellere.
Rolle | Informasjonsarkitekt | Data Engineer |
---|---|---|
Hovedfokus | Overordnet strukturering og modellering av data | Skrive logikk og kode for datainnsamling og prosessering |
Oppgaver | Datamodellering, datakvalitet, datastandarder | Dataflyt, ETL-prosesser, optimalisering |
Verktøy | ER-modellering, SQL, datakataloger | Python, SQL, Spark, verktøy for datatransformasjon, orkestrering, lineage mv |
Kompetanse | Forretningsforståelse, datamodellering | Programmering, databehandling, systemintegrasjon |
Samarbeidspartnere | Data scientists, enterprise-arkitekter, data engineers, domene-eksperter/nøkkelbrukere | Data scientists, informasjonsarkitekter, utviklere, kildesystem-eiere, nøkkelbrukere |
Mest involvert i | Tidlig fase av dataproduktutvikling | Alle faser av dataflyt og dataproduktutvikling |
Er datamodellering fremdeles relevant i AI-æraen?
AI har revolusjonert måten vi analyserer data på, og det kan være fristende å tenke at mye av datamodelleringen ikke lenger er nødvendig. Med AI kan man identifisere mønstre, trekke ut innsikt, og bygge prediktive modeller med minimal menneskelig intervensjon. For eksempel, verktøy som AutoML og store språkmodeller kan redusere behovet for manuell modellering ved å automatisere visse aspekter av prosessen. Likevel har datamodellering en viktig rolle å spille, spesielt når det gjelder å forstå dataene og dataenes kontekst.
Datamodellering sørger for en strukturert tilnærming til dataanalyse og gjør det enklere å kvalitetssikre resultatene. Selv med kraftige AI-verktøy trenger vi fortsatt menneskelig forståelse for å sikre at dataene blir brukt på riktig måte og for å unngå skjevhet og feiltolkninger i modellene. Modeller trent på dårlig eller feil strukturert data kan gi upålitelige resultater.
Datamodellering har kanskje fått en mindre synlig rolle i de tidlige stadiene av utviklingen av et dataprodukt, men verdien kommer tydelig frem når dataene får bredere bruk. Eksperimentering kan gi verdifulle innsikter, men for å sikre konsistente resultater over tid, er modellering nødvendig. Når dataene blir en del av virksomhetens langsiktige strategi, blir kvalitetssikring og modellering kritiske steg. Dette er hvor informasjonsarkitekten spiller en avgjørende rolle – i å sikre balansen mellom frihet til eksperimentering og behovet for stabilitet og struktur.
Selv om informasjonsarkitektens rolle må tilpasses nye verktøy og metoder, forblir kjerneoppgavene relevante. Ved å kombinere erfaring, tekniske ferdigheter og forretningsforståelse kan informasjonsarkitektene ikke bare støtte effektiv utvikling av dataprodukter, men også sikre at dataene har nødvendig kvalitet og er klar til å understøtte AI-anvendelser på en pålitelig måte.
Lyst til å lære mer?
Hør på podcasten “Datautforskerne”, episode 8 der Eystein Kleivenes og Magne Bakkeli snakker om at inforamsjonsarkitekten er tilbake. Episoden er tilgjengelig på Spotify, Apple og Acast.
Lik og abonnér!