Episoden er transkribert av kunstig intelligens, feil vil forekomme.

00:00 --> 01:11

Hei, hei, og velkommen til Plattformpodden. En podkast om applikasjonsplattformer og teamene som lager dem. Mitt navn er Hans Kristian Flåtten, og med meg i studio har jeg som vanlig Audun Fauchald Strand. I sesong to av Plattformpodden løfter vi blikket og utforsker plattformer i privat sektor. Men før vi introduserer dagens gjester, Audun, har du en favorittfagbok? Det synes jeg var et veldig godt spørsmål, og jeg har brukt litt tid på å tenke på det. Jeg kommer fram til at svaret er nei, men jeg kan trekke fram to kapitler og to forskjellige bøker, det var det beste jeg klarte å få til. Og da vil jeg si kaPITel 13 i den blå boka om domain driven design, den som handler om strategic design og hvordan forskjellig … man kan få forskjellige typer modeller til å samhandle, og så husker jeg så veldig godt kaPITelet om Conways law i Team Topology, som kanskje er det beste jeg noen gang har skrevet som ... beste jeg noen gang har lest. Hva med deg, Hans Kristian, hva er din favorittfagbok, eller eventuelt kapitler i fagbok? Jeg tror min favorittfagbok må være den som heter "Site reliabilitye Engineering".

01:11 --> 02:30

En bok som ble skrevet opprinnelig fra Google, og basert på deres erfaringer med å drive store systemer på verdensskala. Men som de har adoptert, eller tilpasset, og gjort det mer forståelig. Forståelig for de som ikke jobber i Google. Så er det to andre bøker hvor det er en "engineering workbook" og en om å lage distribuerte systemer, som også er veldig anbefalt for de som bygger plattformer eller store systemer. Men i dag skal vi ikke snakke så mye om bøker. I dag er vi så heldige å ha med oss Jon Skarpetegg og Rune Synnevåg fra Signikat. Signikat leverer digitale identitetsløsninger, verifikasjon og pålogging, og har årlig 450 millioner sikre pålogginger og sparer samfunnet vårt for 1200 tonn med papiravfall. Det er ganske kult. Jon, kan ikke du begynne å fortelle litt om din bakgrunn og hva du jobber med i Signikat? Jo, utdanna sivilingeniør. Og så kom jeg til Signikat nå for fire år siden. Det er et spennende norsk selskap som har suksess med hovedkontor, ikke i Oslo.

02:30 --> 03:48

Det var litt av inngangen til min. Nå er tittelen min "Tribe lead for global platform", som i praksis er leder for en konsolidert plattform. Vi har hatt vekst og oppkjøp, og er i gang med en ganske storstilt konsolidering, nå på en sentralisert ... Som er vår nye plattform der vi har tatt i bruk ny og moderne teknologi, ny plattform engineering og det som følger med. Dette gleder jeg meg til å dykke mer ned i. Men Rune, hva med deg? Hvorfor begynte du i Signikat, og hva er din rolle? Jeg begynte i Signikat på en litt annen måte. Så jeg var med og spant ut et selskap her i 2016 som het Idify. I 2019 ble Signikat kjøpt, og så kjøpte de oss rett etterpå. Vi var de første selskapene som ble kjøpt opp av Signikat. Så jeg ble rett og slett kjøpt inn, ikke hyret inn. Det var starten på en ganske spennende reise. Grunnen til at vi valgte å gå med Signikat, var at vi hadde kunder i Sverige og Danmark, men så på etterpå.

03:48 --> 04:56

Men vi så på å etablere oss i utlandet, så det er en stor, tøff oppgave. For et lite selskap. Vi var 17 stykker. De skulle fornye plattformen sin litt, og det var en god match å joine dem på reisen. Det var litt sånn "if you can't beat them, join them"-tankeganger, at vi er sterkere sammen. Vi hadde veldig overlappende produkter, og begge var norske selskap. Så dette var egentlig en veldig god match. Jeg jobber som leader architect, så jeg prøver å koordinere teknologiarkitekturen vår på tvers av forretningsområder og synkronisere med forretningsområdene og behovene våre. Og alle de forskjellige produktene, at de snakker sammen. At det er en rød tråd både på API-ene våre, på tax-dekkene våre, og at vi ikke har for mye duplisering av teknologi. Så mye ... Mye business-deler av teknologien i tillegg til bare teknologien. Så ikke så mye koding lenger. Utgangspunktet er koder. Så jeg får lov å skrive litt kode innimellom, men det er litt mindre enn før.

04:56 --> 06:02

Så jeg er utdannet fra Universitetet i Bergen, som utvikler utgangspunktet. Men før vi dykker mer ned i teknologien og plattformen, Rune, vil du gi litt mer i hva er det Signicat leverer, hva er det dere gjør? Vi er et selskap som leverer det som vi kaller det. Det vil si at vi leverer identitetstjenester. Med det så legger vi ikke bare innlogging, men òg signering. Vi leverer òg det som heter EDV, der du bruker pass eller ID-kort og skanner det inn. Skandinav er heldig, vi har bank-ID og tilsvarende i andre land. Men mange land har ikke den type infrastruktur. De er avhengig av å måtte bruke pass og ID-kort i en innskannet, videoløs datamaskin. Dette leverer Signicat hovedsakelig til Europa, men vi har noe utenfor. Vi har noe i Hongkong og Singapore, hvis ikke dette er ferdig. Men vi leverer det til offentlige, bank, finans og en del mindre. Vi har ganske stort spekter. Vi har de store entreprenørene, som Santander, Telenor, DNB, Nordea og Bank of Norwegian,

06:02 --> 07:17

men vi er òg små kunder. Så vi har noen små kunder. Men vi er òg små kunder, så vi har et hele spekter på kunder. Det som gjør det litt spesielt, er at vi er på så mange land. Vi har 17 kontorer i Europa, og 11 av dem er ingeniørkontorer. Ingenieringavdelingen er spredd utover 11 forskjellige geolokasjoner. Så det gjør jo òg en utfordring, som vi kan komme inn på senere. Møtes, snakkes, kulturforskjeller, koordinering. Så det krever litt mer koordinering enn hvis alle sitter på i banken. Vi er ca. 500 ansatte, og som Jon nevnte, så er dagens signikatur et resultat av at vi har kjøpt seks selskaper de siste fire årene. Og konsolidert inn nå. Fra Nederland, fra Baltikum, Spania. Ett norsk selskap, og ett britisk selskap. Da er det spennende å høre, hvor mange plattformer har dere kjøpt? Hva har dere fått med på kjøpet? Én per selskap. Mer enn én per selskap. Så hvis vi teller, så har vi vel 28 ... Vi kaller det stacks, da.

07:17 --> 08:11

Vi er til og med gitt de farger. Så vi har blue og green og yellow og red og purple og orange deck. Det er jo litt sånn kulturting, da. Vi ønsket ikke å bruke de gamle firmanavnene som referanser til taxdecken. Da henger du deg opp i historien. Så vi måtte finne noen navn, da ble det Farger den gangen i tiden òg. Nå begynner vi å gå tom for farger, så ... Nei da, jeg kan fortelle om at tidlig i Nav sin historie, i det første moderniseringsprogrammet, så kalte man opp teamet etter farger, og da hadde man så mange forskjellige team at det endte opp med et team som var Team Kaki. Så inntil dere er på Kaki, så har dere fortsatt mange farger å ta av. Ja, det høres ut som du har litt å gå på ennå. Men hvor mange plattformer har dere nå? Er alle fortsatt operative, eller? Har dere klart å konsolidere noen? Hvis du mener å konsolidere oss og skru helt av, så har vi ikke det ennå.

08:11 --> 09:21

Men vi nærmer oss førstemann som kan skrus helt av. Det blir milepæl, da blir det kake. Men vi har vel en åtte-john. Og så kan du definere det litt forskjellig. Noen av kundegrunnlaget her, for det er klart at noen av oppkjøpene har produkter som har ikke noe overlapp overhodet, så da er vi ikke så motivert. For de produktene der man har kjøpt et annet selskap som leverer en konkurrerende løsning i de samme markedene òg, i enkelte tilfeller, så er det klart at konsolideringen er høyt på dagsordenen. Og vi prøver å skru av det først, da. Hvordan går dere fram da for å samles til én plattform? Strategien vår har jo vært å lage den nye plattformen som vi snakker litt om i dag. En helt ny tech-plattform der vi hadde et ... Vi begynte på det i 2021. Der vi har hatt en best of breed-strategi, der vi kan ta komponenter fra de selskapene vi har kjøpt, og vi legger til nytt. Så enten kan vi tvike litt på dem, ta dem som de er, eller vi kan bygge noe nytt. Vi har bygd en del nytt, og det skal sies.

09:21 --> 10:26

Dette begynte vi på i 2021, og da var det jo covid, så det var jo gøy. Så alle satt på hjemmekontor, og ingen hadde hilst på hverandre før. Og det var nye oppkjøpte selskaper. Så det var litt sånn ... Vi fikk nå lært noe nytt, da. Så tør jeg påstå at vi gikk ganske grundig til verks. I den prosessen der vi lagde ny plattform, så lagde vi ny arkitektur på løsningene for at alle skulle spille sammen. Og så organiserte vi bedriften rundt den nye arkitekturen. Motvirke Conways lov og få dere til å spille sammen. Så bytta vi hosting-plattform hvor vi skulle konsolidere inn på én. Og så er det dette med cloud native og containerisering som er i praksis et nytt teknologiparadigme. Det her gjorde vi alt sammen på én gang. Så du kan si det var et high risk, high reward-type prosjekt vi satte i gang med. Men fortell litt mer om denne plattformen som dere har bygget for å konsolidere, da, Jønn.

10:26 --> 11:53

Vi bygger jo i praksis det som kalles for en internal developer-plattform. Løst basert på golden path, det skal være selvforklarende. Det er på en måte målet. Og så er det en reise selvfølgelig for å komme dit. Men selve plattformen er relativt rett fram. Det er en kubanetisk rigg, som er det man ofte gjør når man bygger ny plattform i større selskaper. Som har en del krav rundt sikkerhet som er ganske harde for oss, da. Med særlig compliance og krevende store kunder. Så vi har Isteo, kjører full MTLS. Vi har noe som heter Gatekeeper, som er en open policy agent policy for alt du deployer. Så vi har god kontroll på alt som rulles ut. Så kjører vi sterk kryptering på alt, og da særlig EtRest. Der benytter vi òg sånn at vi på en måte ... Custom Managed Encryption Keys kalles det. Vi gjør management på krypteringsnøklene, og de lagres òg i en HSM, som er en hardware security module. Det som er fint med en HSM, er at den er sertifisert. Den har FIPS 140 level 3.

11:53 --> 13:19

Det fins en level 4. Eneste forskjell er at det fins en self-destruct-knapp på denne boksen hvor du lagrer nøkkelmateriale som brukes til kryptering. Det er så sikkert vi klarer å få det til på det som er tilgjengelig i markedet. Jeg snakket med en senior customer manager fra AVS, da de begynte å etablere seg for alvor i Norge. Vi hadde noe partnerskap på gang med dem. Da snakket han om den HMS level 4 som de hadde i noen av sine datasentre. Han kalte det den dyreste knappen på IAWS-sticken. Idet du sjekket den boksen, fikk du en vanvittig regning med en gang. Da var det et kjempeapparat som var der for å montere det. Og at det hadde vært tilfeller hvor det er da ... jordskjelv som da slår ut, og som da tror at noen prøver å dra meg ut med denne modulen, og da kan self-destructe det. Så det måtte man da være veldig klar over. At det finnes noen ganske baksider med den type moduler. Men dette er jo veldig spennende, Jon. At dere har ...

13:19 --> 14:27

Høye krav til sikkerhet. Det gir jo veldig mening gitt det dere jobber med. Men kan dere da kjøre alle kundene på ett sted? Må dere ha flere installasjoner av denne plattformen? Må dere kjøre i ulike skyleverandører eller ulike ompram-datasentre? Hvordan ser topologien ut her? Det som er målet her, er jo flest mulig kunder og alle produktene på den sentrale plattformen. Så har vi noen spesialprodukter eller produkter som har compliance-krav, som er vanskelige å oppnå fullt ut hos en hyperscaler. Et eksempel på det er en kvalifisert tidstempling-tjeneste, som har veldig harde årditt-krav. F.eks. at du skal vite nøyaktig hvem som har tilgang. Det skal stå i et fysisk separat rack for seg selv for at vi skal kunne få den compliance-kraven. Men compliance-biten går opp. For det er en sertifisering som vi er avhengig av for å kunne tilby det i markedet. Så det er sånn at de forskjellige kundene kjører på samme instans av plattformen,

14:27 --> 15:47

men dere har isolasjon ved hjelp av de forskjellige produktene du snakka om? Ja. Så vi har et multitenent-miljø. Vi må håndtere multitenency på tilgangsnivå. Det er en av tingene vi har bygd inn i plattformen nå, at vi har sterk multitenency og regler rundt det. Og så har vi òg bygd inn støtte for dette med at når kunder sletter kontoen sin, så skal data slettes i alle de forskjellige produktene. Sånn at vi har en produktportfølje på ja, 10-12 produkter. Men i microservice-verdenen kan det være mange forskjellige microservices med forskjellige databaser og storage. Da har vi en event-basert løsning, sånn at når en kunde slutter og sletter sin konto, så sendes det ut en event til alle systemene. De skal slette data i sin multitenent-del, og så skal de audit-logge at de har gjort dette. Så vi kan til kunder vise at deres data er forsvunnet når de valgte å slette dataene. Sånne ting må på plass når du har mange kunder, å sørge for at data forsvinner. Hvor fort kan ... Har dere målt hvor lang tid det tar

15:47 --> 16:54

å få slettet alle data fra alle systemer? Eller alle for én gitt kunde? Det tar sikkert 60 dager. Vi har en sånn softelite. For kunder gjør jo feil og bruker jo feil. En sånn softelite hos oss fant vi ut var lurt å ha. Da oppfører systemet seg som om kontoen er slettet. Hvis du som kunde sletter kontoen og ikke merker at den er slettet for 30 dager, så har du ikke brukt den kontoen heller eller fått den vekk fra dine systemer. Da kan vi restaure den innen 30 dager. Så har vi 30 dager til med backup. Men da er det mer, som dere kjenner til. Da må det restaures fra backup. Men vi la inn til en sånn softdelete for at det skal smerte med en gang du blir delitet, men vi skal kunne restaure det ganske fort. De som sier opp om det, velger misforståelser eller serverstesker feil eller ... Sånn kanskje. Asynkron kommunikasjon og meldingstjenester, er det ellers noe som resten av applikasjonsarkitekturen også bygger på?

16:54 --> 17:52

Eller er dette litt sånn: Her bruker vi det, ellers er det mer synkront? Nei, vi har det på en del opprettelser og sånn. Så har vi Incoven Eventbuss. Vi har for PubSub på Google. Der bruker vi for mesteparten de tingene som skal spres rundt i systemet, at en kunde blir lagt til, eller en kunde i Sablet-kontoen sin, eller de har kjøpt et nytt produkt, typisk. Vi har noen ting som går synkront òg. Der fant vi noe som Race Conditions, som de som har jobbet med Event kjenner til. Vi har hatt ting som vi hadde i Event basert, som vi tok tilbake til Synk for å få hindre noe Race Condition, men hovedsakelig har vi valgt oss på en litt distribuert modell der en skal kunne plukke opp dette. Det gjør det mer fleksibelt i akteturen. Du kan legge på komponenter seinere som istedenfor å måtte hooke det inn overalt. Så det er først og fremst på tvers av domener og kanskje ikke så mye internt i ett produkt, så er det mer synkron kall? Men så går det på tvers der.

17:52 --> 18:58

Men så har vi ganske stor frihet på applikasjonsteamene òg, så vi vet at det er en del team som kjører dette her. For eksempel for sending av e-post og SMS, så er det asynkrone prosesser. En del av disse tingene for å kunne håndtere last og garantere at det faktisk blir gjort. Men si at jeg utvikler oss døre og skal lage en ny mikrotjeneste. Hva er det første jeg møter med plattformen? Vi har Backstage, men vi har ikke per i dag tatt i bruk Templates-systemet. Så det er litt sånn at du ser på de teamene som er kommet lenger enn deg. Få se hvor du begynner. Men vi har en slags sjekkliste. Dette må på plass skal du kunne slippes ofte på plattformen. Det er litt hygienefaktorer, som at vi har valgt en løsning for sentralisert API-autorisering basert på Open Policy Agent. I en mikrotjenestearkitektur, i hvert fall for oss som har pop og java og nett alle om hverandre,

18:58 --> 20:09

så var bibliotekstilnærming litt vrien. Så vi har valgt en mikrotjenestetilnærming for autentisering og autorisering. Så det integrerer vi den. Og så er det en tips om at du må sette resource requests, for det er det vi kjører autoskaleringen vår på. Du må ha high-ability design med minimum replicas og litt sånne ... ting du må ha. Ting du må ha på plass for å kunne kjøre production grade workloads med de volumene som Signicat får inn. Så det er litt der, altså. Du går og ser hva andre har gjort tidligere. Så passer du på at du har dekket det du trenger å dekke. Så skipper du software uten å spørre noen om lov. For det er jo plattformingeniering i ånden, at det er team autonomy fra kode til produksjon. Og det er det de er designet for å kunne supportere dem. Hvert team får sitt eget namespace kubanetisk på hvert cluster. Og så får de et eget Google-prosjekt per miljø, der de ikke har ressursene sine,

20:09 --> 21:17

databaser, storage etc. Og hvis de ønsker, så kan de få MongoDB Atlas. Og så har vi noen felles Helm-charts som kan brukes, på tvers av kodespråkene. Men vi har ikke noen sånn ferdig lagede Deploy pipelines og sånt PT. Det har vi ikke. Det er noe som vi eventuelt må se på på sikt. Men hvis jeg skal ha litt pubzeb og litt postgress, kan jeg lage det sammen med applikasjonene, eller er det terraform? Eller hvordan løser dere det? Det er opp til teamene selv å bestemme akkurat hvordan de ønsker å gjøre det. Terraform er veldig mye brukt. Der er det moduler som gjenbrukes. Men da oppretter de det i sitt eget Google-prosjekt. Så det er litt sånn vote by credit guard, at du står fritt til å benytte det du kan. Da er det jo da opp til plattformgruppa å lage attraktive løsninger som skal være enkle å ta i bruk, sånn at man ikke går fullstendig av den veien som vi ønsker at flest mulig skal gå, da. Hva slags type løsninger er det dere har lagd?

21:17 --> 22:28

Men vi har ikke noen sånn sentral database. Nei, altså det er jo den interne levelen på plattform som er guider, og det er container-plattform. Det er container-plattform, metrics-collection og logging som er infrastrukturbitene av det. Så har vi et ganske stort tjenestelag på toppen. Tjenester der det for oss har gitt mening å sentralisere. Hvordan sende SMS, hvordan sende e-post, webhooks, en del sånne støttefunksjoner som vi òg kjører på toppen, som er en del av tjenestelaget som vi tilbyr internt. Så har vi en del ekstralogikk rundt, siden vi skal selge og tjene penger, imotlevert offentlig, så må vi òg sjekke: Har du kjøpt produktet? Det er òg en ting som vi tok med oss inn i denne plattformen, at vi har en god måte å sjekke at du kun får tilgang på ting du faktisk betaler for. Så det at du får tilgang til en tjeneste hos oss, er summen av at du har IRM-tilgang og at du har kjøpt produktet. Hvis begge de to er true, så vil du få true tilbake fra Open Policy Agenten, at du kan fullføre API-kallet ditt. Så det er det dere bruker Open Police Agent eller Gatekeeper,

22:28 --> 23:27

å lage de sjekkene der? Ja, og så selve permission-sjekken. Vi har ganske mange roller av permissions, som du sjekker. Og da sjekker du at du har tilgang på den kunden, ikke at du har tilgang til alt på det produktet. Så skal du bruke noe, så sjekker du: Har du denne tilgangen på denne kunden? For å styre at ikke du har. Så least privilege-prinsippet. Vi har kunder som òg har avanserte byggopp. Vi har partnere, f.eks., som skal ha en struktur der de har mange underkunder, og må ta høyde for at de skal få én tilgangsnøkkel, så de kan styre sitt og sine kunder. Og så har vi enkeltkunder som bare skal styre sine, og så skal vi ha enkeltkunder som bare skal fordele tilgangen utover på forskjellige ansatte. Så rolletilgangen vår begynner å ligne litt på cloudwenderne med mange forskjellige roller. Vi har sett litt på Google med permissions og roller, og prøvd å lage et oppsett som ligner litt på deres.

23:27 --> 24:41

Og ikke gjør det for avansert. En ting som er veldig fint med Open Policy Agent, er jo at det nettopp er policies, de er veldig fleksible. Så en annen ting som vi òg sjekker i reglene våre, er jo KTAS. Har du kjøpt stor nok pakke, eller har du tilgang til å lage så mange kontoer eller så mange av noe på systemet, og det sjekkes òg i den samme tilgangspakke. Men har dere da en API-gateway som integrerer med Gatekeeper og Open Policy Agent? Eller bygges dette rett inn i applikasjonen? Hvor er det den valideringen skjer? Når applikasjonen mottar en request, så kaller den på Open Policy Agent. Vi ser på om vi kan integrere det med Istio, men vi vil ikke få det til for alle tilfeller. I noen tilfeller må du faktisk sjekke request body-en i forhold til om du skal sjekke denne tilgangen eller denne tilgangen eller dette produktet eller andre produkter. Men vi driver og ser litt på for de forenklede use casene, om vi kan integrere direkte i Istio. Så det har vi faktisk et prosjekt på.

24:41 --> 26:00

For å ta ned dette med kompleksiteten på ... Eller hvor mye hver applikasjon skal gjøre, da. For hva ligger foran der igjen, da, hva er det som ligger mellom den som sender requesten og applikasjonen som mottar den, sånn lastbalanserer, DDos protection, de bitene der. Nei, det er en helt standard Google lastbalanserer som vi kjører. Og så har vi valgt å terminere TLS på Istio, så vi bruker Istio som oppe i Gateway. Og det er det et par grunner til. Den viktigste grunnen er nok manglende støtte. Vi fikk noe som heter OCSP Stapling, som er et krav for oss for å kunne tilby tjenester i Danmark på min tid. Men det mangla òg på Istio, så der var vi i gang og måtte patche upstream Istio for å få det inn. Så vi fikk til et samarbeid med Sisko på Lysaker. Og fikk inn en patch som løste ... eller la inn støtte for OCSP Stapling. Kult, så dere jobbet med upstream der og fikk det inn. Vil du forklare litt med OCSP Stapling, det er et uttrykk jeg har hørt før, men jeg tror ikke jeg har helt oversikt over hva det betyr i realiteten?

26:00 --> 27:10

Kort fortalt så finnes det to hovedmekanismer for å sjekke om et sertifikat er tilbakekalt. Certificate revocation list er den mest kjente, den eldste av de. Og så har det kommet en ny måte, der man ikke skal laste ned helt. Men du kan spørre på et enkeltsertifikat, som er den OCSP-protokollen. Men når du gjør en OSCSP-spørring, så får du tilbake en sånn OSCSP-respons. Det som er stapling, er at i TLS-handshaken kan du legge på OSCSP-responsen direkte i handshaken, så du slipper den ekstra rundturen ut for å sjekke om sertifikatet er tilbakekalt. Så Istio-gatewayen vil presentere det, slik at klienten kan gjøre den valideringen uten noen ekstra kall? Det er riktig. Da lærte vi noe nytt, i hvert fall jeg. Noe nytt i dag òg. Der kommer litt av moroa vår inn. Vi har en del av disse tredjepart-aidene som vi jobber med norsk bank i, vi har Midt-ID i Danmark, vi har FTN i Finland, og vi har Svensk Bank i det. Alle har forskjellige krav.

27:10 --> 28:24

Noen har krav om DNS-hack, andre har TLS1.3, noen har OSSP-stapling. Så skal vi prøve å få en plattform som skal tilfredsstille alle disse kravene. Det er en av utfordringene vi har hatt. Noen av disse kravene slår hverandre litt. Det er å finne balansen på en plattform som støtter alle, og ikke tar vekk noen ting. Men utfordringen er det vi lever av, så ... Hvordan har dere organisert plattformområdet deres når dere prøver å jobbe med én plattform, men samtidig har alle disse andre plattformene som eksisterer? Litt usikker på hva du spør om helt. Tenker du på personell, eller tenker du på teknologi? Nå tenkte jeg på personell. Ja. Nei, det er ... Vi har konsolidert størstedelen av de infrastrukturnære teamene. Så der sitter vi tett på. Det er litt for at de som er ansvarlig for det nye, skal kunne være ansvarlig for det gamle, sånn at incentivene kommer riktig sted. Så de som kjenner smerten, er òg i stand til å kunne gjøre noe med det.

28:24 --> 29:34

Og det har med hvordan du skal kunne prioritere riktig og hvordan du skal få det inn. Men vi er i en litt sånn overgangsfase, i og med at det har vært mange oppkjøp. Vi har mange produkter, og ikke alle er fullt ut konsolidert. Så det er litt smerte fortsatt som ikke er alina med alle insentiver, det er det. Ja, et oppfølgingsspørsmål er hvordan, med så mange forskjellige brukere, og da liksom ikke helt enhetlig plattformorganisering, hvordan klarer dere å håndtere kontakten med brukerne fra de forskjellige miljøene og til alle de forskjellige miljøene? Hovedsakelig kontakt er vi med de forskjellige teamene vi har. Vi har vel en 20-25 team, der tre av de fire er i plattform. Så vi er jo ikke i tack, så er vi vel 180 stykker. Så vi er ikke så store at vi ikke klarer å organisere oss. Vi prøver å ha tett kontakt. Vi har flere måter vi deler kunnskap og har kontakt på. Vi har litt av den der GILDS-tankegangen.

29:34 --> 30:43

Vi har et DevOps-GILD som synkroniserer og deler kunnskaper og "best practices for devops" og Deploy. Som er jeg leder. Som har alle arkitektene for de forskjellige produktene og stakkene og oppkjøpene. Som koordinerer og lager standarder. Restguildland er et eksempel på det. Vi har laget Restguildland som alle selskaper skal følge. Og vi har ... Vi heter Signicats. Vi har noe som heter Catwalk hver torsdag, der vi har alle i selskapet, kan bruke 20 minutter på å presentere noe. Det kan være alt fra produktdemoer fra produkt til det mest nærhetlige. Var jo en av ... Jeg demonstrerte HSEM-er og hvordan skrive PKS11-interfacer, som var et ganske smalt emne. Så vi prøver å ha en del sånne fora der vi kan dele erfaringer og møtes på tvers av team og avdelinger og lokasjoner. Men det er jo ikke lett med elleve kontorer. Det gir jo en utfordring. Og så er det litt kulturforskjeller òg.

30:43 --> 31:51

Vi har 40 nasjonaliteter i selskapet, sist gang jeg telte. Så det gir jo litt utfordringer, men òg gjør det til et veldig spennende selskap å jobbe i. Det er ikke så mange norske selskaper der du får lov til å jobbe med så mange land og så mange interessante utfordringer. Og så er det det vi har organisert rundt en produkteier. Så alle deler av løsningen, de ulike produktene, har én produkteier. Og så kjører vi registeret på hvem som eier hva på backstage. Så hvis du lurer på om noe om en eller annen spesifikk tjeneste, så gjør du et oppslag for å treffe riktig team og riktig personer. Vi hadde et stort arbeid i fjor å legge alt inn i backstage. Jeg tror vi telte 260 komponenter og 57 API-er, hvis jeg ikke husker helt feil, av ting som lå i backstage. Men det er teamet som lager den nye plattformen, hvor stort er det jo? Det er jo hovedtyngden. Så produktene tilpasses jo. Vi har produkter fra mange ulike plattformer og ulike taxdacker.

31:51 --> 33:01

Noen kommer fra å kjøre i en virtuell maskin der de ikke har vært eksponert for produksjonen i det hele tatt. Mens andre har hatt kontinentalisering lenge og er komfortable med det. Så du kan si at de ulike produktgruppene er selv ansvarlig for å planlegge og slippe sine produkter. Men det jeg kan si er at da vi holdt på å bygge den i starten, var vi på et tidspunkt opp mot 30 % av utviklingsressursene tilgjengelig. Utelukkende på å få den opp å kjøre. Det sier litt om omfanget. Vi har valgt oss et litt smalere featuresett for å få som en proof of concept eller MBP. Og så var strategien etterpå å legge til: Nå er plattformen klar, nå må det være hvert produktområde join over. Så det er ikke noe som er dedikert jobbet med dette. Vi har ikke ønsket å skille selskapet i de nye og de gamle. Så det er i samme team som lagde den gamle løsningen, så lager de også den nye løsningen. Da tar vi med oss all læringen og alle erfaringene fra det vi hadde og det vi har,

33:01 --> 34:01

som har fungert veldig bra, over en ny plattform. Vi har jo 10-15 års erfaring med hvordan lage bank-ID på den beste måten eller hvordan gjøre signering på den beste måten. Den erfaringen vil vi ikke miste, eller den vi ønsker vi tar med oss over. Det vil det si til en god grad vi har klart, altså. Hvordan gikk dere fram for å finne featuresetter for MBP-en? Nei, det var til en viss grad litt sånn topp. Til en viss grad litt sånn topp da han bestemte at vi ikke ville ha en plattform som ikke hadde noen produkter fra dag én. At det skal være noe når vi lanserer, så skal vi kunne sette trafikk på den. Så da valgte han ut at det skulle være norsk og svensk bank-ID, som skulle være én i det fra Nederland. Så vi tok med oss alle deler av selskapet. Så de tre tingene måtte vi ha på plass, sånn at vi kunne selge ting i de tre markedene, eller migrere kunder. Men det skulle liksom være klar for business, klar for å tjene penger når vi satte i gang hjulene.

34:01 --> 35:13

For de to første oppkjøpene, så var det konkurrerende løsninger. Så da hadde vi tre ulike løsninger som løste det samme kundeproblemet. Så hovedmotivasjonen for at vi starta den reisen akkurat da, det var at vi trengte å løse det problemet. Det var der vi hadde størst overlapp, da. Så det tror jeg det var det som var grunnen til at vi var. Det var tre avdelinger som jobbet med autentisering. Men de som jobber mest og kanskje utelukkende med plattformutvikling, altså ikke produktutvikling, hvordan jobber dere sammen? Hvordan ser en dag ut for den jevne plattformutvikler i Signekad? Nå er den jevne plattformutvikler ikke så veldig igjen, men vi har infrastrukturtime. Det er hovedtime. Det er på en måte litt mer sånn som man er vant med, men at man drifter kybernetisk, man drifter og passer på at nettverket er der, og at man har det man trenger for å rulle ut software. Og så har man en relativt stor gruppe som er vanlige programmerere.

35:13 --> 36:42

Tjenestelaget som er på toppen, men mange av de er tett knytta opp mot infrastruktjenester. Integrert direkte mot ISTI og CRD-ene på API og via selvbetjeningsportalen. OPA er tett på noen av komponentene. Vi har skilt ut det vi har kalt for observability. Som da er i praksis Grafana Labs-stacken. Som ikke er infrastrukturutimet, men som selvfølgelig jobber tett med infrastruktur for å få det til å spinne rundt. Så har vi en komponent til som er litt annerledes. Det er Opener DConnect. Vi lager og shipper vår egen OEDC-løsning. Som da er kjernen i token-fabrikken, som brukes for alle API-ene. Og i tillegg gjenbruker vi den til autentiseringsproduktet vårt. Så for våre API-er er sikkerhetsnivået og teknologien som brukes, den samme. Om du kaller på våre API-er, eller om du logger inn med en bank i det for en bank. Vi har veldig sterkt fokus på dogfooding, altså bruke våre egne produkter. Så det gjør vi i mange tilfeller der vi bruker våre egne produkter om igjen i andre produkter. For den OEDC-plattformen så bruker vi open source, det som heter identity server før. Men nå heter det vel Duende identity server, som vi bygger på.

36:42 --> 37:49

Så vi slipper å bygge helt fra bunnen av, men vi bygger på et sterkt fundament. En av kjernene til vårt produkt leverer også autentisering, og OEDC er jo en veldig mye brukt protokoll. Når det er så mange kontorer, mange nasjonaliteter, det er jo et ganske hybrid og distribuert selskap, hvordan holder dere kontakten, hvordan er kommunikasjonen? Er det stort sett at man jobber mest med de som man sitter på kontor sammen, eller er det stor grad av digital samhandling på tvers her? Det er noen team som er lokalisert på samme lokasjon, og noen er delokalisert. Vi har noen team der to sitter i Bergen og to i Portugal, eller to i Trondheim og to i Portugal. Ene team er vel to i Bergen, én ... To i Romania og én i Portugal. Vi har en grense på maks to lokasjoner, men så skjer det jo av og til at det blir ... Og så er det et stort unntak for infrastruktur. Vi har valgt å konsolidere mellom alle oppkjøpene,

37:49 --> 39:04

så der er det vel seks-sju ulike siter. Vi kjører noen sitesamlinger fra tid til annen, sånn at en prøver å ha litt sånn fysisk. Det er jo kjekt med Zoom og Teams, men en får ikke helt det samme, syns jeg personlig. Der er det jo smak og behag. Enkelte liker helst å gjemme seg bak en skjerm, og enkelte syns det er kjekt å treffes fysisk, der er jo vi mennesker skrudd sammen litt forskjellig. Men vi har prøvd å ha Teams-samlinger eller Tribe-samlinger i løpet av året. Men det blir jo mye av ... Det blir mye digitalt, da. Men slack selvfølgelig er veldig mye brukt. Syns vi har fått til en ganske god slack-kultur. Det er ikke mange minuttene det går hvis du spør et eller annet på de åpne kanalene at folk vil hjelpe og hopper på, du får svar på det du lurer på som regel. Vi har et prinsipp at hver team har sin kanal. De kan ha både en public og en intern. Og så har vi òg kanaler rundt produktene og rundt plattformer. Det tror jeg vi glemte om. Har denne konsolerte plattformen et navn? Ja, han heter faktisk DTP, Digital Trust Platform. Det var ikke det opprinnelige navnet. Vi hadde et kodenavn først.

39:04 --> 40:20

Men det var det som kom til oss etterpå. Så det syns vi passer bra. Det tok litt tid å få nye navn til å rulle av tungen, men nå ruller det greit. Litt sånn russebusstaktikk med dekknavn først og så dekte navnet på? Ja. Jeg må ofte ha et navn, ellers blir det bare snakket om den nye plattformen. Vi holdt på med dette prosjektet i alle fall et år før vi kom live med det. Der lærte vi litt sånn rundt mye. En av de hovedleggingene jeg tok med meg fra den perioden, var at vi sleit veldig med å snakke om de samme tingene. Da jeg snakket om accounts, sa de i Nederland at det var noe helt annet for dem. De snakket om tenants og federations. Og i andredelsselskapet snakket de om services. En av de tingene jeg satte meg ned og gjorde, var å lage en ordliste, terminologylist. Disse terminologiene skal vi bruke i den nye plattformen. De betyr dette. Dette het de de gamle teknologistekkene. Og så fikk vi ... Vi fikk litt sånn forankret den litt forskjellige plasser. Og så fikk vi banket den litt gjennom. Og det hjalp.

40:20 --> 41:28

For vi satt i en del møter, og det var høy temperatur. Men så viste det seg at vi kanskje var enige likevel. Men folk hadde litt misforstått hva det er vi diskuterte. For de betydde det noe helt annet. Og der kommer den kulturforskjellen og det at du sitter på Teams eller Zoom istedenfor å sitte i samme rom litt inn, da. Så det var en veldig læring for meg, iallfall. Å være sikker på at vi snakker om det samme. At vi har etablert en felles begrepsapparat. Men hvor er det de produktteamene går for å finne dokumentasjon og informasjon om DTP? Nei, du kan si at noen av de plattformtjenestene er tjenester som er tilgjengelige utad. Så der er det jo å utvikle dokumentasjon som er public i tillegg. Hm. Riktig. Jeg ser vi begynner å gå inn for landing. Superinteressant. Men før vi avslutter, så har vi et spørsmål som vi spør alle gjestene våre. Og det er om dere kan fortelle en gang hvor ting ikke gikk helt etter planen.

41:28 --> 42:42

Og kanskje enda viktigere, hva lærte dere av det? Ja, nei, altså, du kan si at da vi gikk i gang med å utvikle vår interne utviklerplattform, så ... Har man jo alltid en del antagelser om hvordan ting virker. Og en plass der vi trådde litt feil, da, det var innføring av et loggsystem. Sentralisert loggsystem. Der hadde vi tre stykker i bruk. Vi hadde en som vi kjøpte fra Datadog. Vi hadde Elkstakken, og vi hadde Grafanalabstakken med Loki. Og på papiret så er jo Loki veldig kostnadseffektivt og fint, og jeg tenkte at ja ja. Men det vi bruker allerede, vi har god erfaring med det. Vi kjører på. Det vi oppdaga veldig fort, det var jo at det var ikke alle som har hatt med Loki. Så lærdommen var jo egentlig dette med "batteries included". Lage ferdig dashbord som ligner litt på hva du er vant med fra f.eks. Kibana. Her er det in twice, her er fritaksfeltet, her er søkerknappen, så får du opp noe. For det å lage sånne Curie Language-spørringer for å få ut logger, det var for høy terskel for å komme i gang, rett og slett.

42:42 --> 43:49

Så lærdommen var jo litt at det å lansere en ny internal level på plattform, det er litt som en startup. Du må lage noe som brukermassen din vil ha, du må markedsføre det. Du må være lav nok terskel til å komme i gang, og du må ha tid nok til å lage den. Og så er jo utvikleren Kresna. Absolutt. Men en annen lærdom, ikke direkte relatert til den her, men det var dette med når man tenker på en plattform som produkt, så kan man ta i bruk Product Management. Der er det bøker som er skrevet om Product Management, som har vært en nyttig lærdom å hente inspirasjon fra. Og en ting som har vært veldig vellykka for min gruppe, det har vært dette med referansekunder. Å identifisere en viktig bruker av plattformen, passe på at vi løser de problemene som de treffer, sånn at du i hvert fall har én gruppe som er strålende fornøyd.

43:49 --> 44:56

For det å løse alles problemer, det blir bare en sånn midjoker plattform. Det blir ikke bra nok, rett og slett. Det er super ... Det treffer så riktig, John, og det tror jeg ... Alle de som lytter på, kan relatere til dette med hvordan begynne med MVP, finne product marketfit, finne noen som det funker for, og så vokse derfra. Det er en super holdning å ha med. Før vi runder av, noe dere vil legge til eller noe om veien videre for Signicat? Vi kan jo begynne med deg, Rune. Vi har litt å gå på på Developer Experience, og så jobber vi en del med dette med å legge på enda mer sikkerhetslag. Så vi ser på dette som John har snakket mye med, med tråtling av trafikk, identifisering av potensiell falsk trafikk i forhold til IP-er, i forhold til mønstre, og det å kunne blokke den type ting enda tidligere med mer sikkerhetslag.

44:56 --> 46:15

Det er ikke til å stikke under stol at verden er blitt litt mer farligere de siste årene. Litt mer ubehagelig å være i. Og jo større den blir, jo mer blir den et mål for aktører. Og Signicat er faktisk kritisk infrastruktur i en del land, bl.a. Norge og Litauen, der vi står for store deler av bank- og finansverdenen. Så vi har en solid plattform i dag, men vi ønsker å ikke hvile på laurbærene. Vi ønsker å legge til mer sikkerhetsløsninger, flere "layer of defence", rett og slett. Synd at vi ikke har så gode norske ord for alt, men det blir litt enklere. Litt engelsk termologi, dessverre, men mer lag i sikkerhetsløken. Hva med deg, John? Noe du vil legge til? En av fordelene med at vi nå konsoliderer på én plattform, det åpner med muligheter teknisk å krysskonsumere og integrere alle produktene som tidligere har vært litt sånn hver sine øyne, til å lage en litt mer helhetlig løsning, der vi kan lage pakkeløsninger. Altså si at du skal onboard. Så kan vi levere alle de stegene som trengs for at vi skal gjøre KAVB, KAVT, AML, sjekk, sterk autentisering, elektronisk signering for å åpne konto.

46:15 --> 47:25

Gjøre dette som en pakke på en måte som har vært vanskeligere tidligere. Vi har gjort det tidligere, men det blir mulig å helintegrere på den samme plattformen med ett API-nøkkel gjennom vår felles API-gateway, én self-service-tjeneste og alt. Ja, det er kjempespennende. Tusen takk til Jon Skarpeteig og Rune Synnevåg fra Signikat for at dere har vært med oss i studio i dag. Audun, har du et høydepunkt fra episoden? Jeg syns det var morsomt å høre om hele den virkeligheten med konsolidering og oppkjøp, det har jeg aldri vært så veldig eksponert for, men jeg ser jo for meg at det skaper litt andre typer problemer og muligheter når man må slå sammen ting som finnes hele tiden, ikke bare enten skrive om gamle ting eller begynne fra scratch. Så det syns jeg var gøy å høre om. Hva med deg, Hans Kristian? Jeg tror jeg sa det i episoden òg, men det var veldig gøy å høre om disse upstream contributions og bidragene til Open Source. Jeg er veldig glad i Open Source, og det er kjekt å høre om norske selskaper som bidrar til communityet, og at alle de som måtte bruke Istios gateway-funksjonalitet,

47:25 --> 48:01

at de kan få nytte fra det. Så det setter vi veldig pris på. Dette har vært nok en episode av Plattformpodden. Mitt navn er Hans Kristian Flåtten, og med meg har jeg Audun Faukast Strand og teknisk produsent er Tore Græsdal. Nyeste episode finner du alltid på plattformpodden.no, eller i din lokale podkastapp. Del gjerne episoden med en kollega og få en emoji i retur fra Audun. Ha det bra.