Vi valgte å bygge løsningen i Microsoft Azure, hvor vi tok i bruk både mikrotjenester og større plattformkomponenter.

Som hovedlagrings- og bearbeidingsplattform benyttet vi Microsoft Fabric, med Dataverse som primærkilde for data. Arkitekturen fulgte Medallion-modellen, der sluttproduktet besto av ferdig kuraterte gold-tabeller tilpasset rapportering og analyse.

I tillegg integrerte vi flere sentrale Azure-tjenester:

• Azure Data Factory for orkestrering og dataintegrasjon.

• Azure SQL Database for strukturert lagring og tilrettelegging av spesifikke datasett.

Helheten gav en robust og skalerbar dataplattform som støttet hele reisen fra rådata til ferdige forretningsrapporter.

Kilden til data var Dynamics og Dataverse.

For å tilordne og strukturere data benyttet vi Microsoft Fabric og bygget løsningen basert på en Medallion-arkitektur med tre lag: bronze, silver og gold.

Prosjektet ble utviklet som en utvidelse (add-on) av en relativt standardisert løsning. Vi brukte derfor tid på å etablere en solid kjernearkitektur i Fabric, slik at vi kunne bygge både standard- og kundespesifikke deler oppå denne.

For å dekke fellesbehov på tvers av flere kunder etablerte vi en todeling i både silver- og gold-laget:

• Et core-lag, med felles datasett og logikk som kunne gjenbrukes.

• Et kundespesifikt lag, med tilpasninger som håndterte individuelle krav.

Arkitekturens lag

• Bronze (Lakehouse): Inneholdt rådata hentet direkte fra kildesystemene. Data var lite strukturert, lite kuratert og beholdt tekniske navn. Kvaliteten ble forbedret ved å rense feil og sikre konsistens.

• Silver (Warehouse): Data ble strukturert etter forretningsdomener, for eksempel kunde, leverandør og finans. På dette nivået slo vi sammen tabeller, etablerte relasjoner og endret navn til mer forretningsrettede betegnelser.

• Gold (Warehouse): Her lå de mest kuraterte datasettene, ferdigstilt for rapportering og analyser. Dette laget fungerte som fundament for forretningskritiske rapporter.

Samspill med Power BI

Gold-laget inkluderte også et semantisk lag til bruk i Power BI. Dette laget ble eid av dataanalytikere, men endringer ble bestilt gjennom dem og utført av dataingeniører, slik at tilpasningene alltid fulgte definerte forretningskrav.

Vi benyttet dbt Core for å utvikle SQL-transformasjoner og prosedyrer som produserte data i de ulike lagene i Medallion-arkitekturen. Endringer kunne implementeres i dbt, og ble automatisk tatt i bruk ved neste planlagte kjøring.

I bronze-laget benyttet vi materialized views for å sikre rask tilgang til oppdaterte rådata, mens silver- og gold-lagene hovedsakelig besto av views for å strukturere og tilrettelegge data til forretningsformål.

Datapipelinen ble trigget av en tjeneste som kjørte én gang i døgnet og bygget opp de materialiserte viewene i silver og gold samt oppdaterte data fra kilden og inn til bronze. Dette ga en daglig oppdatert datastrøm fra rådata til ferdige rapporteringsklare datasett.

For mer spesialiserte oppgaver tok vi i bruk Azure Data Factory. Dette gjaldt særlig kundespesifikke behov, utvikling av unike dataprodukter eller oppgaver som krevde beregninger og prosessering utover det som var hensiktsmessig å håndtere i dbt.

Mens dbt Core ble brukt til generisk og standardisert kode for felles dataprodukter, fungerte Data Factory som et supplement der mer komplekse eller skreddersydde løsninger var nødvendige.

Vi benyttet ulike Azure-tjenester for datalagring i mer spesialiserte prosjekter. I tilfeller hvor det ikke var hensiktsmessig å bygge et standardisert produkt i Fabric, tok vi i bruk en kombinasjon av Azure Data Factory for orkestrering og transformasjon, og Azure SQL Database for strukturert lagring og tilgjengeliggjøring av data.

Vi benyttet Microsoft Power BI både internt og eksternt. Internt ble Power BI brukt til å visualisere nøkkelindikatorer (KPI-er) for styring og oppfølging. Eksternt fungerte Power BI som en integrert del av dataproduktet levert til kundene.

Kundene stilte ofte detaljerte krav til innhold, datakilder, oppdateringsfrekvens samt design og brukervennlighet i dashboards. Utviklingen av selve dashboardene og de semantiske modellene ble håndtert av en egen avdeling, mens data engineers hadde ansvar for å tilrettelegge og levere data frem til gold-laget i Medallion-arkitekturen.

Vi benyttet Python som et supplement i dataprosessen, spesielt der standardverktøy ikke var tilstrekkelige. Python ble brukt til å håndtere datakvalitetsutfordringer, for eksempel å ekstrahere spesifikk informasjon fra lange tekststrenger eller gjennomføre større, generiske endringer i kodebasen, som innføring av navnestandarder.

I enkelte tilfeller brukte vi også Python til å generere dbt-skript, som igjen produserte SQL-kode og etablerte datastrukturer. Disse ble videre satt sammen og kuratert til ferdige dataprodukter, klare for analyse og rapportering.

Vi benyttet Visual Studio Code som primært utviklingsmiljø, og Git for versjonshåndtering av kode. Git ble også brukt til prosjektstyring, der vi organiserte arbeid gjennom tickets og boards for å sikre god oppfølging, struktur og samarbeid i utviklingsprosessen.