Den med Gabler

Hans Kristian og Audun har hatt gabler på besøk for å snakke om finansielle plattformer.

Creators and Guests

Host

Audun Fauchald Strand

Prinsipal i NAV

Host

Hans Kristian Flaatten

Platformutvikler i NAV

Producer

Tore Græsdal

Innholdsdesigner - video, animasjon og streaming i NAV

What is Plattformpodden?

En podcast om applikasjonsplattformer og teamene som bygger de. Dette er podcasten for deg som bygger plattformer eller som er interessert i lære med om hvordan noen av Norges største om mest fremoverlente organisasjoner legger til rette for sine utviklere.

Episoden er transkribert av kunstig intelligens, feil vil forekomme.

Hei, og velkommen til Plattformpodden, en podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er Hans Christian Flåtten, og med meg i studio har jeg som vanlig Audun Faukalstrand. Audun, har du en favorittdatabase? Ja, det må være Solar. Og det er fordi det er den databasen jeg har misbrukt mest opp gjennom tiden. Jeg er ikke sikker på om det er det nå lenger, men både deler av Telenors infrastruktur og flysøket til Finn bruker Solar veldig annerledes enn man har tenkt å bruke Solar, og det syns jeg er gøy. Hva med deg, Christian? Det må jo bli en SQL-database. Men 2SQLight er vel en av de mest populære, og kan en baddis helt inn i applikasjonen. Og det er litt semirelevant, for i dag er vi så heldige å ha med oss en stor, en stor uavhengig aktør innen pensjon og kapitalforvaltning. Vi har nemlig Geir Alstad og Jo Hatland fra Gabler. Men det er kanskje ikke så mange av lytterne våre som har hørt om hva de jobber med.

Men de jobber med noen av Norges største pensjonskasser. Finansinstitutturer, kommuner, energiselskaper og så flere. Og ser etterser svimlende 143 milliarder kroner i investeringer. Geir, vil du begynne å si litt om deg selv og hva du gjør i Gabler? Ja takk. Mitt navn er Geir Alstad. Jeg jobber som Chief Data Architect i Gabler. Og jeg pleier å si at jeg driver med 3D-ops, jeg driver med Bad-ops, jeg driver med Diving-ops, og jeg driver med Data-ops. Jeg begynte i Gabler i 2020, og kom med da Gabler kjøpte opp mitt tidligere firma. Lillewold og Partners. Jo, hva med deg, hva er din rolle i Gabler? Akkurat nå jobber jeg med migrering av verdikjeder. Det er et prosjekt vi har gående hvor vi skal flytte veldig mye av løsningen vår over på en ny skyplattform. Min bakgrunn i dette her er jo mest ledelse og som teknolog. Og min interesse er å finne kostnadseffektive løsninger, og det tror jeg vi er.

Men kan ikke dere begynne å si litt, jeg har egentlig veldig lyst til å høre litt om denne dataplattformen, hvordan dere jobber med data, for jeg antar dere har mye data og bruker mye data for å lage tjenestene deres, optimalisere dem. Kan dere si litt om hvordan det ser ut sånn rent teknisk? Ja, vi har valgt Databrix og baserer løsningen vår på Databrix. Og det er jo litt sånn i space-dataområdet at det er forferdelig mange alternativer. Og hvis du ser på en sånn plansje over ulike teknologier eller applikasjoner som man kan benytte, så blir man helt svett, altså det er så mange. Og vi er et lite team, og for oss var det veldig viktig å få noe som ga oss mest mulig. Og da sto alternativene mellom Databrix som vi endte opp med, og Synapse som det var på den tiden, fordi vi er en Asher-bedrift i all hovedsak. Så vi har tuftet vår løsning på Databrix, og prøver å være så rene som mulig, men med noe støtte fortsatt av det gjenværende fra Synapse eller Asher Data Factory.

Jeg vet ikke så mye om data ... Si litt mer om hva Databrix er. Hva slags funksjonalitet ligger der, og den type ting. For oss er Databrix en intern plattform. Som vi bruker for å få ned tashmen, for å få forretningen inn på samme datademene. Det er det forretningsperspektivet. Og så kan Geir si noe om det tekniske. Databrix blir jo på mange måter definert som ... Managed Spark. De som grunnla Databrix er de som fant opp Spark. Og det tilbyr da et helt økosystem knyttet til databehandling i Spark. Primært som motor. Og det startet jo med Skala, som all Spark, men er nå Pyton og Sequel som er de mest brukte. Men det er jo da Jupiter-notebook som er primærmåten å kommunisere med hvor man definerer API-ene, eller bruker API-ene til Databrix. Men i bunn og grunn så er det jo et filbasert system. Og da med Spark på toppen.

Men ... Ja. Så det er i sånn som Databrix ... Så dataene oppstår et eller annet sted i applikasjonen deres, og så kommer det inn i plattformen? Dere bruker Sparks for å transformere og gjøre dem om, og lage rapporter og sånn, da f.eks.? Men er det også ... For jeg liker veldig godt den DataMesh-artikkelen. Har dere de samme tankene rundt dataprodukter og sånne? Har Databrix det som et definert konsept? Ja. Og der er det jo litt sånn at ... Jeg liker å si at vi følger mer Hubspoke. Fordi altså ... Jeg, bredside, følger. Jeg synes at Datamesh-konseptet er litt sånn ... Det er veldig fint, men jeg tror det er langt dit. For oss er det mye mer naturlig og sentralt. Mer naturlig å sentralisere datavirksomheten,

og da heller ha eksterne småteam som vi fòrer. Det blir så mye overhead med fullt datamesh. Men Databrix støtter datamesh. Absolutt. Noe av premisset her er at vi er en tjenestetilbyder for kundene våre. Så dataen er ikke nødvendigvis vår egen, det er kundene sin. Så vi er veldig flinke til å segregere og passe på at ting er atskilt. Og kun rapporterer på det aggregerte. Er det en multitenent-løsning, eller setter dere opp en hel stek for hver enkelt kunde? Hybrid. En hybrid, ja. Ja, sånn som ... Så det er jo da, i Dactyplix så kaller de det det ... Det er et konsept som heter Feathered Workspace. Og det er ... Så vi jobber oss dit. Det er en vanlig vei å starte med ett workspace, og så jobber du deg videre. Og vi er nå ... Vi har kommet opp i to.

Hybriden her er at vi kommer til å ha primærkundene til hver virksomhetsdel i hvert workspace. Sånn sett så vil vi samle kunder. Per workspace. Som er klynget under en forretningsenhet. Vi hopper kanskje litt over det. Hva er de konkrete produktene som Gabler leverer, og som deres kunder igjen bruker? Hvilke data er det vi snakker om, som ligger i disse systemene? Vi har vel to hovedprodukter. Det ene er pensjonsadministrasjon. Og det andre er kapitalforvaltning. På Pensjonsadministrasjonen tilbyr vi både en SAS- og en BPO-løsning. I dag sitter vi med noen onprem-løsninger, men vi beveger oss nå over til en multitenent-sky-løsning. Vi bruker databriks på veien for å komme fra det ene til det andre. Da er det en hel verdikjed som skal migreres. Dataene der er jo da veldig mange pensjonskassers medlemmers arbeidshistorikk, pensjonshistorikk, ubetalingshistorikk. Mens for kapitalforvaltningen er det jo

porteføljer vi sitter på. Da er vi da ferdig med en migrering. Da er jo da: Hva har avkastningen vært historisk? Hva er benchmarkene? Hvilke porteføljer er interessante? Og hvordan skal vi kunne få rådgivning til hvordan vi skal gå videre framover? Så da er det en del data det er snakk om å gå ut fra? Ja, det er mye data. Men det er jo sånn at veldig mye av dataene ... Veldig mye av dataene er da brede, mer enn de er dype. Så konseptet "big data" her er jo ... Spørsmålet er om det omtrent finnes noen foretak i Norge som har nok data til at det blir "big data". Men ja, vi har relativt sett ganske mye data. Og vi kommer til å generere ... Etter hvert som tiden går blir det mer og mer produksjon av data. Det er ønsket om å ha hyppigere oppdateringer. Det er en av grunnene til at vi valgte Datablex. Lovgivning endrer seg jo også, og det er viktig for oss å kunne være ... Det å kunne sørge for å være compliant, og kunne vise til hvem som har gjort hva, med dataene, det er jo noe av det som Datablex støtter.

Så ... Ja. Er det også noen regulatoriske krav som påvirker bruken av asher og sånn, eller er det ok i finansbransjen nå? Nei, det er masse krav. Det har vært en stor dora-runde nå. Ja, det er det nye regelverket! For det er ikke den doraen som vi kjenner med DevOb Research ... Ja, for det er finansdoraen, sant? Hva er det det står for, husker du? Digital Atlant Resilience ... Sikkert Act. Hva er oppsummeringen da? I og med at vi er en utkontrakteringsbedrift, så er vi nødt til å gi veldig store avhandlinger på risikovurderinger og forsvarlige valg vi har gjort overfor kundene våre. Så kundene kan gjøre sin egen risikovurdering på oss som utkontrakteringsleverandør. Det er ekstremt mye regelverk vi skal forholde oss til.

Jeg har lyst til å hoppe litt tilbake til plattformen. For hvis dere f.eks. skal lage en ny rapport eller en ny analyse, eller kanskje noe annet, det kommer en ny datakilde i andre enden, hva er det man må gjøre? Hva er flyten for å lage noe nytt hos dere? Da må du jo opprette en kobling, og du kan jo på en måte velge. Altså skal du være filbasert eller databasebasert? Og det starter jo som ... Hvis vi tar filbasert først, da, så er den typiske produktlinjen å få dataene inn i en storage account. Vi er jo en Asher, så vi snakker Asher storage account. Hvordan kommer de dataene inn, typisk? Det er jo det som er litt vanskelig. Ja, det er forskjellige valg. Vi har valgt å bruke veldig mye Asher Data Factory, for å flytte de dataene som er on prem. Eller så tilbyr jo Datablix også veldig god støtte for å lese rest-API, så hvis vi har et API-kall som vi kan gjøre, så kan vi gjøre det direkte. Og da blir igjen valget om vi skal lagre dataene på fil i storage account.

Med sånn Datalake-tankegang. Eller om vi skal lese det rett inn i databriks. Men Asher Data Factory er det vi bruker primært for å flytte dataene våre fra on prem og opp i sky. Og da har det kommet data inn, hva er resten av jobben for å ...? Vi har jo en sånn blanding hvor vi enten skriver notebooks ... Vi gjør transformasjonene i Spark eller Sequel. Enten Pie Spark eller Spark Sequel. Og så blir det en livssyklus, og Datablix har jo laget konseptet Lakehouse, og under Lakehouse laget de også da konseptet Medalian Architecture. Hvis man leser alt som er Lakehouse, så hører du om dette Medalian Architecture. Og det er egentlig feil bruk av ordet. Det er ikke Medalien Architecture, men det er mer et framework. Konseptet er jo egentlig bare en rebranding av det gode gamle Raw, eller Staging Raw Refined, liksom. Så det er jo akkurat det samme.

Enten så bruker vi Notebooks til å oppnå dette, eller så bruker vi et rammeverk innenfor Datablix som kalles Delta Live Tables. Som er en konkurrent til DBT. Ja, for dere bruker ikke DBT? Nei, vi bruker ikke DBT, eller det er noe av virksomheten som gjør det, men vi som driver med Datablix, vi bruker ikke DBT. Og det kommer av at vi ønsket å være Datablix-native. Og DBT er veldig fint, men for at det skal fungere i sky, så må du typisk kjøpe skytjenesten til DBT, som koster veldig mye penger. Eller så kan du selvfølgelig bruke open source-varianten, men da må du hoste alt selv, og så kjøper du deg mye ekstra hodepry. Så det var vurderingen som vi gjorde. Vi ønsket å ha så få verktøy som mulig å forholde oss til, grunnet størrelsen på teamet. Hva er kostnadsdriverne i Datablix-dekken? Hvordan er prismodellen der?

Den er transparent, men du kan fort få en overraskelse uten å passe på testerne. Som det meste annet i sky og ... ja. Ja. Det man kan brenne seg på, er jo at man overprofesjonerer compute. Så Datablix skiller jo veldig hardt mellom storage og compute. Og i stor grad så betaler man for storage til Microsoft. Eller de som bruker Google eller A2S, det betaler åpenbart til dem. Og da er det jo selvfølgelig alt ettersom hva leverandøren har satt på inngress- og egresskostnader knytta til det. Men så er det jo Datablix Compute, da. Så det kostnadsdrivende det er valget av cluster. Og der er jo Datablix mer fleksible enn f.eks. noen av konkurrentene som Marcus Fabric og Snowflake. I og med at du kan ... Altså hva skal vi si, det blir sånn frihet under ansvar-opplegg. Så det er lettere å gjøre feil. Og vi har i dels brent oss litt på det. Men en annen ting som er veldig viktig, er det å kunne slå av clusterne. Og det er noe som vi jobber med, å prøve å få det inn i kulturen.

Når vi sitter og utvikler, så må vi prøve å skru av. Vi må også passe på at når vi gir data ut, at de som skal bruke dataen, forstår litt av sammenhengen her. Men også få dataen på en sånn måte at de ikke går i fella selv og drar på kostnader. Ja, for de kan kjøre ting hos dere? Ja, vi inviterer brukerne våre rett inn på Datablix, så de kan kjøre sine egne queries. Men de kan da lage sine egne rapporter, slå sammen tabeller på det de har tjenestelig behov for. Og da er det dere som tar kostnadene ut fra det de gjør, eller lager dere noe så de betaler for sin egen? Nei, vi kjører en allokering, så vi tar kostnaden, og så allokerer vi det ut til bruk etterpå. Det er mye mindre byråkrati på den måten der. Men sånn pay-as-you-go er jo fortsatt ungt på mange områder. Jeg tenker at bank og finans er kanskje de som ligger senest eller lengst under den, og adopterer det og veier hele fjølet. Jeg kommer fra applikasjonens verden og liker, eller og tenker ... Hver gang jeg hører noen snakke om data, så prøver jeg å finne ut hvordan man har klart

å inkorporere de moderne systemutviklingsteknikkene inn i dataverdenen. Kan du si litt om hvordan dere gjør det? Vi bruker Delta Live Tables som transformasjonsverktøy, og så bruker vi Datablix Asset Bundles som en CACD-løsning. Og det er en lettvekt terraform ... rammeverk. Og som da vi kan pushe jammeldefinerte workflows via Git. Så vi bruker da Asher devops til å pushe koden på typisk etter ... Tester er gjennomført, og at kode er akseptert, så dytter vi det ut til de ulike workspacene våre. For da har dere infrastruktur og transformasjoner som er liksom ... Dere dytter ut i alle de forskjellige miljøene, der alle de brukerne ... Ja. Strengt tatt, så er vi jo litt i støpeskjeen fortsatt på akkurat det. Men det er ... Enn så lenge så dytter vi til ett miljø. Men det blir straks to, og så vet jeg ikke hvor mange vi kommer til å ende opp med. Det er også en av de styrkene vi har, for at vi kan kjøre en open approach

for å gjøre prototyping, og så kan vi lage ordentlige workflows som er koder. Har dere, mulig jeg bare ikke har helt skjønt på det, men de forskjellige selskapene, har de muligheten til å lage egne rapporter, eller er det dere som står for all utviklinga på det? De har absolutt mulighet, men det er klart at det er vi som gjør mesteparten av jobben, sånn som det er nå. Fordi altså ... Finansbransjen er jo veldig, veldig Excel-tung. Og det er veldig stor grad av å kun stole på sine egne transformasjoner. Men vi jobber med å prøve å få dem inn, og de som ... Å prøve å få opp entusiasmen knytta til det å kunne være selvhjulpen, da. Så det langsiktige målet er jo å få brukt mer av databrikkstacken knytta til maskinlæring og data science, og få aktuarene våre, som er de som vi definerer som data scientists, til å bruke det direkte. Så det er jo en mer langsiktig målsetting for oss. En ting jeg lurer på er hvordan dere håndterer det at dere har forskjellige brukere som kanskje har forskjellig format på dataene deres.

Har dere liksom en felles modell for ting? Eller transformerer dere inn til en felles modell? Eller er det bransjestandard, eller hvordan håndterer dere interoperabilitet på data? Vi prøver vel å lage en felles modell der hvor det domenet er likt. I bunn og grunn så er det jo veldig mye økonomisk teori som ligger bak her. Så det kan modelleres veldig likt. Og så er det noen kundespesifikke forskjeller. Tilbake til det Geir sa i sted. Noe vi ønsker er å hjelpe kundene våre å bli mer effektive. Så vi søker jo, og det er grunnen til at vi holder til i Dataprix, å automatisere lenger ned i verdikjeden. Hvis vi kommer lenger ned i løypa. Det handler da om å ta opp noen av disse aktuarjobbene som i dag går i Excel og prosesseres der. Vi kan flytte dette inn i Dataprix og gi et mer ferdigtygd produkt ut. Men der hvor dere har disse modellene og lokale tilpasninger, hvordan har dere noe dokumentasjon for det? Hvordan håndterer dere det? Har dere dataprodukter internt som de ulike teamene kan inn og se på og forstå og lære, eller hvordan er den?

Det er dit vi forsøker å komme, da. Men dette er jo et langt lerret å bleke. For som sagt så har det jo vært veldig sånn silo-basert. Det er jo veldig mye kunnskap knyttet på få hoder. Det norske pensjonssystemet er jo helt utrolig komplisert. Så det ... Men altså ... Vi forsøker så godt vi kan å gjøre det. Så altså ... Vi har på en måte ... De har altså ... De har alle de produktene som de trenger for å gjøre transformasjonene. Og så er vi veldig opptatt av å prøve å få laget standardiserte tabeller, slik at man kan bruke standard SQL på dem. Men det er klart at det blir jo litt sånn ... Modellene må tilpasses, alt etter hvem som er sluttbruker. Det må det. Hvordan er dere organisert rundt det? Har dere noen som er plattform, noen som er domenespesialister? Eller hvordan er dere organisert? Vi er organisert på den måten at vi har noen plattformspesialister.

Og så har vi noen domenespesialister. Men med tanke på teamstørrelsen så må vi ha veldig mange hatter. Så det blir en del sånn Data Magicians. Mer enn Data Engineer, da. Så det er noe med det. Data Magicians, det syns jeg òg. Nå vet jeg ikke hvor mye dette gjelder når dere bruker Datablic, men hvordan klarer dere å finne ut hvordan dere skal sette opp og bruke plattformen for å løse problemene til de som er mer som domenespesialister? Snakker dere sammen med dem? Har dere noe ... Men dere løser jo litt med at dere har mange hatter, kanskje? Ja. Det er også mye intern diskusjon. Vi snakker mye med både brukere og kunder på hvordan de ønsker å få ut både hva de sier og hva de ikke sier. Så vi kan lage modeller som hjelper de både nå og kanskje neste gang de trenger data. Så det er den "magiker-delen" som Geir og jeg snakker om.

Vi må kunne mye om faget vårt for å kunne gjøre det vi gjør. Det nytter ikke å komme inn og sitte og bare være data. Du må også kunne. Det som i hvert fall har vært min erfaring med å jobbe med plattform, at det er litt vanskelig å vite hvor grenseoppgangen går. Hva er det som man skal si nei til? Hva er det som dere må løse selv? Hva er det som er verdt å lage plattformen? For det er selvfølgelig mye bra med effektivisering, men det fører også til litt stramme rammer noen ganger, at man egentlig ikke får til å løse alt. Man må begynne å gå omveier for å klare å få det til, fordi plattformen er så sterk. Har dere de samme utfordringene noen ganger? Ja, absolutt. Absolutt. Så det ... Ikke sant, så ... Vi må jo prøve å ... Vi prøver jo å lage ... Å lage ... Altså ... Vi prøver jo å følge god datavarehusmodellering, da.

Så vi er på en måte tradisjonelle sånn. Og da er det meningen at du skal kunne svare på en gitt mengde spørsmål. Men Databricks tilbyr jo også da mye AI på toppen av dette. De bygger inn LLM-modeller i applikasjonen sin. Og det er jo den veien vi prøver å gå. Strategien vår er å trekke ut så mye som mulig kunnskap av sluttbrukerne. Vi har begynt med å berike dataene våre, slik at de kan bruke det som Databricks kaller "AIBI-genie", til å svare på spørsmål som de i utgangspunktet kanskje ikke hadde. Igjen, vi prøver å bruke plattformen til å hjelpe oss, uten å måtte lage det selv. Hvordan kom utviklere i gang med plattformene? Ja ... Nei, det er jo bare sånn "velkommen til oss, her har du en PC", omtrent. Altså vi ... Nei, altså, vi har jo litt mer enn det, så. Vi går jo gjennom tankene knytta til hvordan vi vil at praksisen skal være.

Og så gir vi mye ansvar til utvikleren, slik at de skal kunne oppfylle de generelle kravene våre. Men i og med at plattformen er bygget, så er det jo ... Så er det jo litt begrensa hvor mye feil du kan gjøre, annet enn at det kan koste litt penger. Men det er også en av de behagelige tingene med å jobbe med databrakes, når man kommer fra en sequel-bakgrunn som jeg gjør. Hvis man gjør en feil, så er det veldig lett å rette opp i den feilen. Det var jo definitivt ikke sånn i gamle dager, og i mareritt. Altså sånn alle de horror-storyene med ... Har du gjort dette i Prod.? Ja, det er fortsatt horror-stories, selvfølgelig. Men det er veldig lett å komme tilbake til en tilstand. Fortell litt mer om det. Hva legger du i at det er lett å komme tilbake til en tilstand? Delta-konseptet har innebygget tidsreisemulighet. Så det betyr at du kan reise tilbake til ... Du kan bestemme selv også hvor mange versjoner som skal ligge inne, eller hvor langt tilbake du kan gå.

De folk er 30 dager. Som burde være nok, for så vidt. Men du kan velge å sette det lenger, eller kortere. Men da kan du gå tilbake enten til en gitt versjon, eller til et gitt tidsstempel. Og da kan du, selv om du bytter skjema underveis, så kan du sammenligne skjemaet ... Du kan sammenligne både data og skjema med én kommando. Og det er veldig kraftig relativt til mye annet. Er det et visuelt grensesnitt hvor de kan sammenligne skjemaene før og etter? Det blir typisk i kode, men du kan også sammenligne ... Unitic Catalog, som er datakatalogproduktet til Databrax, støtter visuelt grensesnitt knytta til historisering av tabellene. Er det et verktøy dere ellers bruker internt? Til å kategorisere data? Unitic Catalog er jo "hjertet i Databrooks". Og det er det som gir oss mulighet til å kunne tilby enhetlig governance. Det lagrer alt av metadata. Og du kan også registrere maskinlæringsmodeller der.

Og du kan følge lineage, som jo er også veldig viktig. En grunn til å velge Databricks relativt til f.eks. å bygge absolutt alt selv, er jo å ha disse verktøyene tilgjengelig. Det å kunne grafisk vise en lineage er utrolig styrke i, og det gjør det så mye lettere å kommunisere med sluttbruker. Er det noe som dere jobber aktivt med, eller er det Databricks som får en del av dette, eller er det kundene dere selger på den? Nei, vi har noen lærlinger som vi er satt til å jobbe, kanskje ikke med LLM-er, men med chatpoter, så vi kan bruke noe av den kunnskapen som ligger der. Med tanke på at vi kan gi det til kundene senere. Det som ligger i Innbygd i Databricks, er en form for tagging og metadatabeskrivelse. Så folk kan bli mer selvhjulpne. Den har ikke tatt i bruk ennå, for vi har ikke rukket ennå. Men hvis det hjelper oss, hjelper kunden, så er vi interessert i det. Hva vil være et use case for en chatbot, fra et sluttbrukerståsted?

Det enkle use caset er å ... Hvis du tar det lærlingene jobber med, er det fint å finne tilbake dokumentasjon. Hjelpe med å få oversikt over compliance-biten eller bare få hjelp til selvhjelp. I plattformen er det å få kontroll på den lange dataen. Vi har ikke big data, men ... Vi har ikke big data, men vi har lange data. Det er å få hjelpe de som skal lage rapporter, med å se data i et mye større tidsperspektiv enn du kunne gjøre enkelt. Det er kjedelig å se på dataene hvis du ser på et lite tidsvindu. Men det er spennende hvis du ser på en lang karriere. Alle arbeidsforhold, og hvordan det påvirker opptjeningen din. Databricks har sterkt AI- og LLM-fokus, så du kan angi modell, og så bruker den jo den modellen. Så vi har ikke ... Altså vi har tenkt på tanken, men spørsmålet er kostnad, altså. Det koster jo helt sinnssykt mye å trene en sånn modell. Så inntil videre ... Så inntil vi ser et veldig sterkt "use case",

så får vi se om det holder å kunne bruke en av de i Out of the Box-modellene. For hvordan stiller kundene deres, som ellers er en veldig risikoavers kundegruppe, til denne type funksjonalitet? Er det noe de etterspør aktivt, eller? Nei, det vil jeg ikke si. Det er vel heller et spørsmål om hvordan dette kan hjelpe våre kunder. Jeg har ikke funnet entydige svar på hvordan jeg kan hjelpe dem, bortsett fra å lage rapporter. Men det er et forholdsvis statisk domene. Du skal være ganske kreativ for å finne nye måter å rapportere en pensjon på. Nei, det er ikke veldig mye innovasjon. Nei. Det tror jeg kan stemme med mine egne opplevelser og erfaringer. Men det svaret der var i pensjonskonteksten, unntatt i kapitalforvaltningen, så er det litt andre. Hva er annerledes i kapitalforventningen enn i pensjonskontekst? I kapitalforvaltningen så er det jo ...

Da er kunden ... Har ikke da andres data? De har jo sine egne investeringer, og den kan du gjøre mye mer morsomt med. Vil det være en bank eller en institusjon sine egne investeringer? Det kan være en pensjonskasse, det kan være Private Welf, det kan være Private Welf ... Det kan være firmaer har kapital de skal investere. De er interessert i å få mer informasjon, og de er mye mer åpne for LLM-modeller og få ekstra kunnskap og avkastning. Ja, for det er ikke da deres bruker igjen sine data. Det vil jo være noe helt annet ... Ja. Fra privat privacy-ståstedet. Vi er veldig opptatt av å ha et sterkt skille mellom de analytiske dataene, som vi typisk har i Datablex, og som vi kan bruke nedstrøms, og de operasjonelle dataene som ligger i fagsystemet. Det er noe vi er opptatt av. Og da er det pipeline som fører fagsystemene inn i de analytiske dataene?

Ja. Det er her vi forsøker å holde oss innenfor rammene av Datablex, for å kunne styre hvordan de transformasjonene fungerer. Kjøres de øvrige fagsystemene også i Ashore, eller er alt i sky? Vi har en stor on-prem-legacy. Den skal vi avvikle. Vi avvikla den på kapitalforvaltning, ikke på pensjonspensjon ennå. Riktig. Det tror jeg er mange selskaper som er i samme gate der, med pågående arbeid. Ja, og så er det jo sånn at nå er vi i sky, og vi kan skalere opp og ned, og det er jo kjempeviktig i en testutviklingsfase. Men vi må igjen se når vi er ferdig med den, hva er mest kostnadseffektivt? For det er ikke dit at Ashore eller Datablix er det valget vi tar om to eller tre år igjen. Ja. Vi begynner å gå inn for landing, men før vi avslutter, så har vi jo dette faste spørsmålet som vi stiller, og det har sikkert klart å gjette hva det allerede er, om det kan fortelle om en gang ting ikke gikk helt etter planen.

Ja, altså vi liker å si, vi på IT liker å si at vi gjør feil så raskt vi kan. Og altså noe av det som vi opplever stadig, det er jo kommunikasjonen. Med fag. Og hvor vi snakket jo så vidt om det i stad, men hvor vi forventer ... Vi gjør en implisitt forventning om hva fag mener. Og det er jo forståelsen, eller den manglende forståelsen kanskje, for hva som er komplekst innenfor hvilket domene. Og opplevelsen av å snakke forbi hverandre. Og så når man prøver å lage et produkt, så blir det ... Noe annet enn det alle så for seg, kanskje. Der har vi jo gått på mange smeller. Men det er da det er fint med å kunne jobbe idrettivt, da. Og forsøke å levere et bedre produkt. Så det å være rause med hverandre ... Men vi er i prosess der, å lære hvordan kan vi få trukket ut informasjonen vi trenger.

Så ... ja. Det er et eksempel på der hvor vi ... Altså det å få gjort migrering sånn som vi ønsker. Der har vi ... Det har gått ... Uten å kunne gå inn i detaljer på det, men det er klart at det er utfordrende. Er det noe vi har glemt å spørre om? Nei, det må jo være veien videre, så. Nei, det må jo være veien videre, da. Nei, så vi ønsker jo så med alle forbehold som Jo nevnte her, med hvorvidt Datablix blir det fortsatte valget, så ønsker vi i hvert fall på kort sikt å få inn mer terraform. Og få mer infrastructure as code, få mer fokus på software engineering practices i utviklingen vår. Og ja, fortsette å bygge en god plattform for kundene våre, også på leveransen ut, da. Til liksom de endelige pensjonskassene. Så det er målsetningene våre i året som kommer. Hva med deg, Igo? Noe du vil legge til? Nei, jeg risikerer å høres ut som Datablix-fanboy.

Så vi har valgt det riktige verktøyet for å gjøre jobben vi skal gjøre nå. Og så er vi entusiastiske over det. Så skal vi gå en vei og avslutte noen store prosjekter. Vi er et veldig lint og agilt team. Så jeg vil påstå at vi gjør noen av de største jobbene med minst mulig folk i Norge. Selv om vi ofte er magikere. Magi er veldig effektivt. Ofte har jeg sett det på film òg. Vi vil komme til noen veiskiller, vi også. Da blir det spennende å se hvordan den nye driftshverdagen ser ut. Og hvilke muligheter vi trenger da. Men det skal de finne ut av underveis. Jeg vil si tusen takk til Geir Alstad og Jo Hetland, som har delt med oss og lytterne våre om hvordan Gabler har bygget sin analytiske plattform med Datablix og skyteknologi. Nå Audun, nå er jeg spent. Har du et høydepunkt fra episoden? Å få høre mer om Datablix, som var en plattform jeg ikke kunne så mye om.

Det syns jeg var spennende. Hva med deg, Jan Sisan? Jo, jeg må egentlig si det samme. Dette er ikke en verden som jeg kan supermye. Og jeg syns jo dette med data magician var et utrolig artig uttrykk. Og gøy å høre om hvordan man tar inn mer programvarepraksis inn i den analytiske verden. Så det var veldig, veldig gøy. Du har hørt nok en episode av Plattformpodden med Hans Christian Flåtten og Audun Faukal Strand. Teknisk produsent har vært Tore GGræsdal med god hjelp fra Arild Stenbekk. Nyeste episoder finner du alltid på plattformpodden.no eller i din lokale podkastapp. Følg oss gjerne på LinkedIn. Ha det bra. Ha det bra! Ha det bra!