Episoden er transkribert av kunstig intelligens

00:00 --> 00:47

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 med meg Audun Fauchald Strand, og i sesong én utforsker vi plattformene i offentlig sektor. Audun, hva er din favoritt, Kubernetes Operator? Det tror jeg faktisk er den første jeg har hørt om. Det hørte jeg om på CubeCon i 2017, tror jeg. Da var jeg på en presentasjon med de som lagde Rook, den operatoren som styrte tilgang til lagring. Da jobba jeg i Finn, og vi hadde slitt så mye med å få til NFS og den type lagring.

00:47 --> 01:39

Å høre om det selskapet som hadde lagd en operator som gjorde alt det kjempeenkelt, det var en ganske kul opplevelse og fikk meg til å tenke annerledes om hvordan man kunne bygge. Hvordan man kan bruke koder til å gjøre infrastrukturting. Hva er din favorittoperator? Jeg tror den operatoren jeg har installert flest ganger må være Cert Manager. Det å plutselig kunne få så mange sertifikater du bare vil gjennom utstedere som Let's Encrypt, har gjort hele oppsettet med ingresser og TLS-kommunikasjon som en lek. Det som jeg tror kanskje ikke så mange vet, er at Cert Manager har veldig mye annen funksjonalitet. Du kan lage dine egne CR-store og utstede sertifikater. Du trenger ikke nødvendigvis noe

01:39 --> 02:24

veldig komplisert og dyrt verktøy for å håndtere sertifikater. Men i dag så er vi så heldige å ha med oss Ronny Birkeli og Eirik Mikkelsen fra Digitaliseringsdirektoratet, eller bedre kjent som DiggDir. Både Ronny og Eirik jobber med Altinn-plattformen, som kanskje noen av dere som hører på oss i dag, har benyttet for å sende inn informasjon til ulike offentlige etater. Ronny, kan ikke du starte og fortelle litt om hvordan du begynte å bygge Altinn? Jo, det kan jeg gjøre. Jeg begynte i DiggDir for 2,5 år siden. Kom fra privat sektor før det. Jeg holdt på å si jeg er utvikler og arkitekt. Det er jeg ikke lenger, for fra august ble jeg produkteier for Altinn Studio, som er en felles løsning for

02:24 --> 03:14

å la andre offentlige etater bygge digitale tjenester. Så min reise inn har vært via de utviklingstimene som er æredignede. Spennende. Hvordan begynte du i DiggDir, og hvor var din reise inn til Altinn? Jeg er en av de som har jobba lengst med Altinn. Første gang var vel i 2002 på gode gamle Altinn1. Så jeg har begynt som utvikler. Gjennom frem til nå. Lært litt ute. Kommer fra privat næringsliv de ti første årene. Begynte i BR i 2010. Og DiggDir fra 2020. Jeg er nå sjefsarkitekt for Altinn og har et litt mer overordna ansvar

03:14 --> 04:07

på tvers av Teams og arkitektur. Jeg har hørt og brukt Altinn mange ganger, men det hadde vært interessant om du kunne si litt om tjenestespektet. For Altinn er jo ikke bare Altinn.no, der du kan sende inn data og fylle ut skjema, men der applikasjonsplattformer og flere ting ... Kan dere ikke si litt om hva det er? Ja. Altinn, hva er det? Det er en plattform for å bygge digitale tjenester. Det har det egentlig vært fra starten av i 2002. Du kan bygge tjenester, skjema, meldinger ... De fleste har vært innom Altinn. Men det kanskje ikke alle vet, er at man har en stor del som er det å utvikle tjenester. Kjøre tjenester. Men det betyr at dere har et stort spenn i brukerne deres?

04:07 --> 04:58

For de skjemaene lages vel av ... Skal vi si som er underpasselige ... Altså forretningsfolk, kan vi si. Mindre teknisk kompetanse som trengs for å gjøre det? Ikke sant? Stemmer. Vi har fokus på ... Vi har to utviklergrupperinger. En er de som er fagpersoner, ikke nødvendigvis tekniske utviklere, som bruker no low code-delen av verktøyet. Og så har vi utviklere som kan kode direkte, hvis man ønsker det. Da har vi Ronny som produkteier for studio, som kanskje kan utdype litt mer. Det er riktig som du sier, det er de to brukergruppene. Det er det som kanskje er unikt med det som er på Altinn 3 og verktøyet vi har der, fordi det lar deg jobbe i low code, no code-delen som en forretningsperson.

04:58 --> 05:48

Du kan bygge skjema, lage prosessene dine, sette på enkel validering. Et eller annet tidspunkt kommer du kanskje litt til kort. Kanskje du skal ha en custom-kobling mot et eller annet API, og da kan du hente inn en utvikler og så kan han lage den delen av det. Du nevnte BR, det er på korts for Brønnøysundregistrene, stemmer ikke det? Det stemmer. Vil du si litt om, for Digder, som mange ikke kjenner så mye til, det er jo en konstellasjon av Altinn, deler av Brønnøysundregistrene og Difi, stemmer ikke det? Ja, Digder ble oppretta i 2020, der man tok én avdeling fra BR-en. De som jobba med Altinn, ca. 100 pers. Og slo det samme med Difi.

05:48 --> 06:50

Som holdt tillidstjenestene i ID-porten og den type løsninger. Og så skilte man ut noen som gikk over i DFØ. Så det står igjen der. Hvordan har den overgangen ... Det må jo ha vært en overgang. Hver sammenslåing og utskilling er jo en overgang for organisasjonen. Har det gått greit? Ja, det har vel det, men det er jo alltid utfordringer i sånne prosesser. Det er et ganske distribuert miljø òg, er det ikke det? Litt sånn geografisk? Ja. Det er jo på en måte Brønnøysund, Oslo og Leikanger som er de hovedkontorene i Digder. Jeg var på en sånn samling, Davops-dagar, er det ikke sånn det uttales? Jo da, vi er i nynorskland da vi er på Leikanger. Da blir det Davops-dager. Da var det jo en sang om Leikanger og disse ulike miljøene.

06:50 --> 07:39

Hvordan de sparker fra seg og jobber sammen. Ja, jeg trodde vi ble enige om at det som skjer i Bergen, det blir i Bergen. Men for å redde dere, hvor mange jobber med Altinn Studio? Vi er på produktgruppa som er for tjenesteutvikling, så er vi fire team. Sånn mellom fem, sju, åtte på hvert team. Og så har vi en stor del med det som heter Altinn autorisasjon, som vi også er inne under Altinn-paraplyen, og der er det vel to team nå. Så da er vi vel seks team der. Og så kommer det noen nye produkter, som er litt i den Altinn-sfæren. Så er det riktig å si sju? Ja, det stemmer nok, sånn cirka.

07:39 --> 08:26

Men fire team, hvordan er de fire timene på selve plattformen delt? Der har vi et team som jobber med Altinn Studio, altså det designer low-code-verktøyet. Og så har vi et team som heter team apps, det er det teamet jeg er på. Som på en måte har run-time-delen av skjemamotoren og prosessmotoren. Og det som brukeren ser når han fyller ut skjemaet. Og så har vi et team som het Plattform, men som nå heter CORE. Litt fordi vi ... Plattform ble et litt misforstått begrep internt, fordi de lager en del fellestjenester som alle tjenesteeierne baserer seg på. Så det kan være hendelser, varsling, PDF-generering, en del sånne tjenester som alle andre tjenester likevel trenger.

08:26 --> 09:12

Ja, for dere, når dere lager Altinn Studio, så har dere jo brukere som ikke har så mye teknisk erfaring som de som lager plattformene. Så hvordan håndterer dere at dere eksponerer brukeren for noe teknologi, men de kanskje ikke har erfaring med å jobbe så mye med det som andre utviklere? Det er riktig, og vi prøver å bake en del av det inn i Altinn Studio i verktøy i seg selv. Vi bygger jo på felles designsystem, så det tar jo unna en del av disse kravene. I tillegg så prøver vi å kommunisere "best practices", for det er jo selvfølgelig mulig for en hvilken som helst bruker å gå feil i forhold til tilgjengelighet og bygge skjema. En del av det tar vi unna med at vi bygger på felles designsystem. I tillegg så prøver vi å komme med en del prinsipper og guidelines i verktøyet.

09:12 --> 10:00

Og også legge til rette verktøy for at det skal være lett å gjøre rett. Du skal ikke lage ting som er tilgjengelig og ikke oppfyller de kravene der, da. Du nevner felles designsystem, og det syns jeg er veldig spennende. Der har det vært litt samarbeid mellom DigDear og andre etater. Vil du fortelle litt mer om det? Ja, det kan jeg godt gjøre. Det var et arbeid som vi som alle andre starta internt med å lage vårt eget designsystem. Så begynte vi litt i det andre miljøet, på de andre fellesløsningene vi har også. Så tenkte vi at dette kan vi ikke holde på med, vi kan ikke lage to, så vi lagde ett. Det er mange andre som også ønsker å ta i bruk dette, og ikke lage det selv.

10:00 --> 10:41

Og så er det en del andre, inkludert Nav, som har lagd eget designsystem. Så da gikk vi ut og løfta det litt opp, og så tok vi kontakt med andre etater. Og så har man egentlig kommet i gang med et sånt samarbeid på tvers av offentlige etater. Det syns jeg er veldig bra. Kjempekult. Og det ligger vel på designsystemet.no, stemmer ikke det? Jo, det stemmer. Veldig kult. Her må vi jo bare dele etter hverandre. Dele erfaringer, og det at det er åpent og tilgjengelig, og at her kan andre benytte seg av det, er veldig forbindende. absolutt. Ja, og da tror jeg vi var inne hos Nav og stjal rått og uhemma en del ikoner, og bygde videre på det dere har lagd.

10:41 --> 11:36

Men for å bygge videre på deling, så er jo veldig tilgjengelig det dere har gjort rundt Altinn Studio. Både dokumentasjonen ligger ute, dere bruker mye GitHub. Det virker som at man ønsker å være åpen, man ønsker å fortelle om hva man gjør, og kanskje også tilrettelegge for å få litt input fra andre òg. Ja, det er faktisk et prinsipp vi følger. Alt vi utvikler skal deles opp som åpen kildekode på Gitube. Vi baserer, altså det vi bygger plattformen på, skal være åpen kildekode. Vi tenker at det å dele og gjenbruke på tvers i det offentlige Norge ... Det er utrolig viktig. Det er eneste måten å få skalert det her på uten å kaste bort for mye midler på å lage det samme om igjen. Det er helt supert. Det å bygge videre på åpen kildekode,

11:36 --> 12:34

hva slags åpen kildekode er det dere baserer dere på i Altinn-treer, da? Det er jo alt fra Kubernetes helt nede, til Linux i ... I containere. Til .net som applikasjon. Så alle lag, egentlig, er åpen kildekode. Også utviklerdelen, VS-code, er noe vi tenker er en bra idé å benytte. Så man skal kunne både utvikle og kjøre Altinn-løsninger uten å være avhengig av kommersiell programvare. Du bruker sky, ikke sant? Ashel. Stemmer. Kan nevne det i den forbindelse. Vi bruker skytjenester, manager-skytjenester, for å enkle drift hos oss.

12:34 --> 13:23

Men vi foretrekker skytjenester som er basert på åpen kildekode. Postgreer f.eks., som database. Men hva er det som møter en bruker når han skal lage en ny applikasjon? Hvordan er grensesnittet mot brukeren? For dere har, i motsetning til andre, som ofte bruker jammelfiler, så dere har også et verktøy som det tilbyr. Det må jo gi noen gode muligheter for å lage en enda bedre utvikleropplevelse. Ja, det gjør det. Det første som møter brukeren, er jo egentlig Altinn-studio. Det hvem-baserte verktøyet, hvor du logger deg på med Githu-kontoen din, og velger å opprette en ny tjeneste eller ny applikasjon. Da får du med en mal fra oss, som har en del standardting satt opp.

13:23 --> 14:06

Bl.a. autorisasjon, en del konfigurasjonsfiler for å bygge sider og navigering og støtte opp under prosessen. Og ellers så tilbyr verktøyet drag and drop for skjemabygging, datamodulering, prosessflyt, teksthåndtering med språkressurser, tilgangskontroll osv. Så du får på en måte litt blanke art. Du får litt blanke art, men du får også veldig mye verktøy med for å bygge tjenester. Men da er det sånn at dere har på en måte en ... Dere retter dere mot én type applikasjon. Med de verktøyene der, en komplisert saksbehandlingsapplikasjon eller noe sånt, vil man ikke kunne lage der. Da må man eventuelt gå dypere ned i koden, men er det også noe dere tenker

14:06 --> 14:49

man skal bruke Altinn til, eller er det mer sånn bonus hvis man må? Jeg smiler litt her, for det er en sånn evig diskusjon. Det er en evig diskusjon internt, hvor langt skal vi gå på den reisen? For man skal ikke tråkke i beina på privat næringsliv og begynne å lage et saksbehandlingsverktøy og ta en del av det markedet. Samtidig er det mange tjenesteeiere som trenger bare et enkelt verktøy for å få innsyn i dataene som brukeren har sendt inn, lage enkle statistikker og ta de dataene litt videre. Og gjøre enkle registerting, egentlig. Har dere eksempler på hvordan noen har brukt plattformen til å lage kompliserte ting?

14:49 --> 15:47

Ja, vi har jo vårt eget oppgjør etter dødsfall og digital gravferdsmelding, som på en måte er ... Den førstnevnte er jo da hva som skjer med arveoppgjøret etter at noen har gått bort. Hvor vi da går ut til alle mulige kilder og henter inn kontonummer, biler, forsikringer. Alt det som den avdøde etterlater seg. Og har en prosess for å støtte opp under den beslutningen du som arvtaker må ta, om du skal ta på deg gjelden og arven, eller om du skal la det gå videre til et annet oppgjør. Så det er en såkalt sammenhengende tjeneste, hvor vi har ganske mange ting som spiller sammen. Brønnøysundregistrene skal bygge den, jeg holdt på å si motstykket, på konkursen. Hva skjer når en bedrift går konkurs? Så er det mye av de samme tingene som skal inn,

15:47 --> 16:30

og så skal dette presenteres på en flate for bostyrer. Sånn at du da kan få gjort opp hele konkursboet. Så vi har alt fra enkle skjemainnsendinger til litt mer avanserte skjemaer, hvor du skal kanskje ha en signering, og du har et signeringssteg. Kanskje du skal ha dobbeltsignering fordi beløpet var såpass høyt at du krever en topersoner som signerer. Vi har tjenester som vi holder på med nå, hvor vi skal lage støtte for betaling. Det er noen som har lov til å ta betalt for de tjenestene de utfører, og sånn sett skal støtte det i prosessen. Ligger det da inn som drag and drop-komponent? Da havner det inn som typisk en drag and drop-komponent på et stegnivå.

16:30 --> 17:04

Da legger vi inn et betalingssteg, og så kan du da konfigurere det steget. Hva er det som skjer bak når noen legger inn en av komponentene, betaling eller slow pit-register? Hva skjer i plattformen under og bak? Bak da er det en kobling ferdig satt opp mot Nets. Det har tjenesteegner eller kunder, våre egne avtaler mot dem, som vi bruker den avtalen. Så har vi integrasjonen mot Nets og sørger for at vi sender over handlekurven, som ofte kanskje er én linje ved navn på en tjeneste. Så gjennomfører vi betalingen og er tilbake igjen til prosessen, så kan vi gå videre og fullføre den og sende inn skjema.

17:04 --> 17:50

Så kan etaten begynne prosesseringen av den. Så dere lager sånn som integrasjon mot nett eller integrasjon mot database? Det er noe deres team lager, og som blir en del av den prosessen brukeren setter opp? Ja. Og da vil jo den være tilgjengelig for andre, og kunne konfigurere en sånn type prosess. Du sa jo i stad at det er det ene, men så går det an å gå inn i koden. Så det betyr at det genereres kode ut fra det, som man ser i gitt? Ja, alt det som vi lager i alt en studio, det ligger over et gitterpost-story. Så det kan jo en utvikler bare sjekke ut og bygge videre på den. Da bruker vi pattern som er kjent med dependency injection, og du har et interface du implementerer, eller vi har ferdige hooks

17:50 --> 18:37

hvor du kan gå inn og legge på din kode som du ønsker skal kjøre, f.eks. i forbindelse med lagring eller i forbindelse med avslutning av prosessen, eller når du går fra et prosesssteg til et annet typisk sted hvor du hekter på kode. Det er .nett-kode. Kan du kombinere det med å bruke Visivig-editoren òg, at du kan fortsette å utvikle skjemaet ditt, og de komponentene er samtidig som at du kan legge til egen kode? Ja, det kan du gjøre. Så du kutter ikke snora fordi du går over til egen kode. Det er ganske greit skille egentlig, på hva du ender opp med å konfigurere. Det er nære 80 % som vi har konfigurasjonsfiler for. Du kan sette opp Gui og skjema alt sammen.

18:37 --> 19:16

Så har vi de stedene hvor vi begynner å programmere litt. Gjøre litt oppslag og kalle noe opp i-er, fylle ut datamodellen basert på de verdiene. Hvordan er ansvarsforholdet på de applikasjonene? Jeg ser for meg at jo mer low-code, jo mer ansvar er det hos dere. Og ikke hos de som setter det opp. Men etter hvert som folk begynner å kode sjøl, er det vanskeligere og vanskeligere for dere å ta det ansvaret, kanskje? De som har ansvaret for applikasjonen, er tjenesteeierne selv. Men den delen av koden som er vår, tar vi ansvaret for. Det ser vi fort i loggene også. Hvis noe tryner med en 500-eksepsjon, så overvåker vi og følger med på det.

19:16 --> 19:57

Vi ser den delen: Oi, den er vår. Dette må vi fikse. Så får vi selvfølgelig henvendelse fra kunder eller tjenesteeiere som sier at appen min er krasja. Så går vi inn og analyserer, siden de har beklager, men det er den koden som dere har skrevet der. Det er den koden som dere har skrevet der som burde ha håndtert det. Så vi får begge deler. Tilbereder det også en form for overvåkingsverktøy? Hvis en kommune har lagd et annet lite verktøy der de har koda litt, er det noe feil? Kan de også følge med på status, eller? Ja, akkurat der har vi kanskje et forbedringspotensial. I dag baserer vi oss på Application Insights og en tjeneste fra Ashore.

19:57 --> 20:56

Der jobber vi nå med en Promitius/Grafana-løsning. Hvor tjenesteeierne i mye større grad kan sette opp og måle trikkene de selv vil. Få på varsling og den biten av det. Der er vi nå på veien som ... Så blir dette bygget som en docker-image, vil jeg tro. Det ble jo nevnt Kubernetes. Vi vil fortelle litt om hvordan den deployment pipen der skjer. Etter at tjenesteeier har vært inne og laget et skjema? Ja, når tjenesteeieren har utvikla applikasjonen sin, så ligger jo koden i et repository. Med en docker-file og koden. Så når man trigger deploy, og ønsker å deploye til et miljø, om det er Prod eller test, så trigger man det. Og da hentes koden av en action. Det bygges en container, som da pushes til et ...

20:56 --> 21:39

Et containerregister, så hver organisasjon har sitt eget register. Og så trigges det the Helm-charter som deploy-applikasjon til riktig cluster. Det jeg syns var litt spennende ... Jeg skjønner at når du har de som koder, så er det ganske ... Men for de som ikke koder, de som bare bruker den visivik-editeren, lager seg ... Mye av det der må jo være noe gresk for dem. Bare hvis vi begynner å snakke om Prodotest og Grafana og alt mer sånn. Hvordan klarer dere å få god nok kvalitet, sånn at det ikke bare lages tullball? Ja, hva skal jeg svare ...

21:39 --> 22:28

I forhold til det å bygge og lage tjenestene, så gjør jo tjenesteeierne ganske mye testing. Sånn i forhold til kvaliteten på testing og sjekkede interaksjoner, og se at dataene kommer inn som de skal. Så der har jo de et ansvar, helt klart. Og så eksponerer vi kanskje noen ikke-tekniske brukere for forhold til testmiljøer, du må trykke her for å bygge, trykke her for å deploye. Så det kan være en liten terskel, men det har vel stort sett gått greit. Det er klart, med en gang du sender en ikke-teknisk ressurs inn i Git, og Git-kommandalinene, da stopper det kanskje. Vi har hatt mye funksjonalitet.

22:28 --> 23:27

Mye funksjonalitet som har ligget nede i konfigurasjonsfiler. Den funksjonaliteten har vi jobba mye med sist år. Du skal ikke måtte gå inn i noen kode for å gjøre konfigurasjon. Når du skal inn i WAS-code, da er det for å programmere SeaSharp. Det er her en av styrkene med Altinn-studio, hvor du virkelig kan styre hva du eksponerer. Som lager de viktige knappene store og de dumme knappene små, på en måte. Disse Kubernetesklusterne, er det sånn at hver organisasjon eller etat får sitt eget cluster? Eller er det ett cluster per type prod og test, eller hvordan gjør dere det på clustersiden? Hver organisasjon får et testcluster og et prod-cluster i Ashore. Så vi bruker AKS som managed kubernetes-løsning under.

23:27 --> 24:19

Så det er kanskje det som gjør løsninga litt spesiell i forhold til de andre vi har hørt på tidligere i podkasten her. Det at vi har full isolasjon, og egentlig hver organisasjon har sitt eget cluster. Full multitenent-løsning på tvers av organisasjoner. Hvordan er oppsettet av de clusterne? Renner med det noe automatikk fra deres side for å få disse på plass? Ja, vi bruker terraform for å provisjonere de clustrene her. For det er et poeng at de skal være så like som mulig i utgangspunktet. Så terraform for deploy av clusters. Hva med tjenester utenom, som databaseform? Er det også terraform? Bruker dere operator eller ...?

24:19 --> 25:13

Vi bruker egentlig terraform for alt av infrastruktur som duplayes. Hvor mange organisasjoner bruker dette nå? Siste telling, ca. 50 eksterne applikasjonsteam som bruker plattformen. Jeg sjekka nå, 80 cluster sånn cirka, som jeg kjører. Det betyr at det er noen som ikke har trodd det ennå, eller er det ... Ja, det stemmer. Det var vel sånn 30 i prod., 40 i test-ish. Er det kommuner, er det mange offentlige etater? Hva er liksom typiske brukerne? Det er vel hovedsakelig offentlige etater. Har vi noen kommuner i perioden? Ja da, vi har Digitale Helgeland, som er et sånt digig samarbeid med 16 kommuner.

25:13 --> 26:13

Så har det vært mye henvendelser ellers fra kommunemarkedet. Men det er mest andre offentlige etater. Oslo kommune tror jeg også har i hvert fall testet det ut, tror jeg. Men Kubernetes får de ikke tilgang til. Det skjuler dere for disse brukerne. I stor grad så gjør vi det. De fleste kan sitte i studio som lowcode-verktøy. Og egentlig ikke forholde seg til det overhodet, inkludert Dockerfile. Men vi har en helmshart som ligger litt gjemt i repoet, som peker på en felles, sentral helmshart. Der vi har satt Config settings, som vi har sett er fornuftige defaults for de fleste apper. Og så kan man, hvis man har behov for det, overstyre en del av de innstillingene i den enkelte app.

26:13 --> 26:57

Ja. Det går på de basic tingene som minne, CPU, antall instanser. På sikt er det også ting som er naturlig å løfte fram i studio. Vi har heller kanskje ikke lyst til å sende alle inn på den helmsharten. Men det betyr også at man ... Er det sånn at man kan lage Duploy i helt egne containere, eller er det bare det som lages via denne prosessen, som er en del av det? Altså, en app i studio er jo egentlig bare en container. Som på en måte bygger seg sjøl, i teorien. Eller, man kan egentlig deploye whatever applikasjoner man måtte ønske, men vi har ikke lagt til rette for det.

26:57 --> 27:32

Men det er ikke noe som teknisk sett er veien for det. Ja, i prinsippet så kan de lage sine mikrotjenester, eller flere mikrotjenester, for å støtte disse skjemaene og applikasjonene sine. Sånn sett kan vi gå andre veien også. Vi har jo ... Vi har et lite veikart-issue som handler om å kjøre alltid en tre-applikasjoner på andre plattformer enn vår egen. For vi bryr oss egentlig ikke om hvilken plattform vi kjører på, om det er en nice plattform eller noe annet. Det hadde vært morsomt å prøve. Du som jobber med Naysand, Kristian, få fikse det.

27:32 --> 28:28

Nei, det er absolutt noe vi burde se videre på. Du nevner en veikart, og det ligger en lenke på Altinn.studio, Vil du fortelle noe om hva som ligger i veien videre fra Altinn3? Ja, hvis du er på github-kontoen til Digdir, så det er der du ser på worldmappen ... Nå ligger det en på Digdir-organisasjonen på Digdir, og det er veikart for alle produktene til Digdir som ligger åpent. Så for Altinn Studios del så handler det veldig mye om det neste halve året om å bli feature-par med det som er på, Vi har fortsatt noen store funksjonelle områder som vi skal dekke opp. Det handler om betaling, parallellsignering og masse sånne funksjonelle ting. Så der er vi litt bundet opp det neste halvåret, egentlig.

28:28 --> 29:14

Så er det andre ting, som den innsikten vi snakka om i stad, med Promitius og Grafana, å få eksponert den innsikten til tjenesterne gjennom studio. De kan kanskje se hovedtallene sine der, og så velge å drille seg videre inn på et Grafana-dashboard, hvis de skulle ønske det. Nå sitter jeg og klikker inn på dette, det er veldig gøy. Det er på github.com/digdir. Der er det et eget repo for roadmap. Så bruker dere GitHub Projects, det syns jeg er veldig kult. Vil du si noe om ... Har du noen erfaringer selv, hvordan det fungerer? Jeg var veldig happy da Github Project kom. Jeg kom fra Jira-verdenen en gang i tida

29:14 --> 30:05

hvor issues var litt uavhengig av repos. Så det å få Github Project, som kan ligge over mange repos, og samle alle issuene til et team og lage forskjellige views og kjøre actions på dem, har jeg vært veldig fornøyd med. Enkel måte å legge på litt custom felter også. Bruker dere det veikartet og kommunikasjonen med brukeren, får dere mye feedback og krav tilbake fra brukerne? Ja, vi har kanskje ikke snakka så mye om det, men vi har egentlig hatt det på veikartnivå. Særlig nå når vi er i den prosessen med å være feature complete innen en viss tid. Sånn at andre tjenesteeiere klarer å komme for migrert sine tjenester. Så finleser de veikartet for å si "klarer dere å levere til den datoen hvor jeg må begynne?".

30:05 --> 30:51

Så på det nivået får vi veldig mye tilbakemeldinger. Vi har jo fått mye bidrag ellers også. Og det er litt kult at ... Hva sa du, Eirik? Vi hadde 2000 brukere på den Slack-kanalen vår med ... Stemmer. 2002, sies det. 500 aktive siste måneden, som er inne og jobber med utvikling. Og mange av de bidrar også med open sower, så vi har mange komponenter i studio som andre har lagd. Card-komponent, kart-komponent for plassering på ting geografisk, UDI-lagde språkvelger, støtte fra høyre til venstre-språk ... Man kan velge å lage de tingene man kanskje savner og mangler,

30:51 --> 31:27

hvis man ikke finner det i standard-studio. Hva må man gjøre for å lage en sånn komponent? Annet enn en pullyquest, tenker du på? Hva er i pullyquesten? Er det liksom ...? Nei, det er, holdt jeg på å si, på komponentnivå. Så er det den rekte komponenten som skal til for å rendre den. Så tar vi en column review og tar det inn, så tar vi forvaltningen etterpå. Så du får lov til bare å drive med greenfield-utvikling. For alltid. Det er fint. Men kunne Nav tatt med sitt designsystem og deployet inn i alt i studio? Er det noe problem med det?

31:27 --> 32:17

Foreløpig nå er det sånn at de appene vi bygger ... Vi importerer jo. Vi importerer jo inn den MPM-pakka fra designsystemet vårt. Så vi har vel ikke lagt til rette for at vi skal kunne dra inn andre designsystempakker der. Det har vi nok ikke gjort. Men ellers er jo de ganske like. Skulle vi ikke bare ha ett designsystem? Jo, aller helst det. Men så vil jo gjerne de ulike etatene ha sine farger i hvert fall. Kanskje litt sånne variasjoner. Er det mulig å gjøre noen tilpasninger til på layouten der? Det er det. På laveste nivå legger designsystemet opp til teaming support med font, farge, spacing-typer. Så legger vi på toppen av det logo på skjemaene.

32:17 --> 32:59

Vi har ikke kommet så langt som vi ville ennå. Vi vil ha teaming-supporten inn i tjenesten også. Men vi har definitivt lagd tjenester som ikke ser ut som et alltid-skjema. Var ikke det valgkortet i litt rosa farge? Jeg kan jo ingenting om designsystem, men jeg tenker jo uansett at det var én ting, er litt lite. Kanskje man kan ha to eller tre som løser noe av det samme, så man kan bli inspirert av hverandre og kanskje har litt mindre risiko for at noe stopper opp og sånn, ved at man har noen alternativer. Det tror jeg er bra på mange ting. Norge er ikke så stort, men vi er stort nok til at vi kan ha et par, tenker jeg.

32:59 --> 33:43

Da må vi få en støtte for Rolf sitt, da. Jeg har virkelig ingen meninger eller makt eller myndighet over designsystemet. Da er vi to. Vi nærmer oss slutten og går inn for landing. Da pleier jeg å spørre om noen erfaringer fra når ting gikk helt som det skulle, om dere har noe å dele når ting gikk litt galt, for det kan vi alle lære av. Ja, ting går jo på trynet innimellom. Også hos DiggDyr. Jeg kan bare først nevne at vi kjører et opplegg der vi har post mortems etter type hendelser. Så vi har et eget github-repo

33:43 --> 34:31

som beskriver hendelsen og hva vi lærer av den. Inkludert peker av til de andre repoene for konkrete forbedringer av løsningen. Sånn at samme feilen ikke skal skje igjen. Den backloggen tidligere i dag. Og en interessant failure var kanskje det her med CDN. Jeg har en egen CDN-løsning for å hoste statiske GUI-ting. Javascript og sånt. Og den gikk plutselig ned. Og det viste seg at underleverandøren til underleverandøren hadde trøbbel. Og der traff jo flere løsninger enn bare alt i en studio. Så den viktigste læringen der er jo at CDN ...

34:31 --> 35:23

Man må ha flere CDN-løsninger. Man må ha fallback for CDN også. Og det er jo litt ironisk, egentlig. Og så har vi jo den uoffisielle varianten av post mortem, Slack-kanalen som heter "Alltin' Fuckups", som er kanskje de litt mindre ... Blir det sånn beep-beep nå? Jeg tror vi har få barn som hører på en oppdrag sånn i utgangspunktet. Ja, men vi ønsker å dele noe vi feiler og gjøre det litt ufarlig. Det er en måte å få til en kultur der vi tør å prøve på ting. Det er kjempegøy å høre, og spesielt gøy å høre at det er så mange organisasjoner som adopterer som post mortem-kultur. Og det å lære av feil, så det er veldig gledelig.

35:23 --> 36:16

Er det ellers noe dere har lyst til å nevne helt på tampen? Hvor går veien videre, er det noe vi har glemt å spørre om? Veien videre for vår del går i 120 på å levere nye features, egentlig. Sånn sett driver vi med produktutvikling, og det er litt gledelig for en som kommer fra det private, det er å se at det offentlige, selv om kanskje ikke all finansiering følger like glatt med på sånne ting, så klarer man i større grad å tenke produktutvikling og jevn videreutvikling av løsningene. En ting er dette med deling og samarbeid internt på tvers av det offentlige i Norge. Så kan det være greit å nevne også at Altinn har blitt et såkalt digitalt fellesgode. Så ambisjonen for både studio, men også andre fellesløsninger som vi lager i DigDir,

36:16 --> 37:01

er å dele det med verden, at andre land kan benytte de løsninger vi lager. Rike Norge bruker mye penger på digitalisering, la oss dele det med resten av verden også. Man bytter navnet til "everything" inn, da. Kjempebra, og tusen takk for at dere ville dele med oss i dag. Audin, hva er det du sitter igjen med i dag? Det jeg syns var veldig bra, var at de var så åpne om veikartet sitt. Det er også ganske tøft å kjøre et publikt veikart med datoer for leveranse. Det er kult. Og det at man er så flinke til å være åpne og be om feedback, er noe alle kan lære litt av. Hva med deg, Jan Kristian? Hva lærte du i dag?

37:01 --> 37:57

Jeg lærte hvor enkelt det kan være å lage disse skjemaene her. For jeg har laget noen skjemaer i mitt liv, og det er slettes ikke så lett som det ser ut til alltid. Og det at det nå er så greit å komme i gang på de som skal ha et nytt skjema på luften, er veldig gøy. Og dette tror jeg virkelig hjelper oss å få fart på moderniseringen av ... Av Norge. Og med det vil vi si tusen takk til Ronny Birkeli og Eirik Mikkelsen fra DigDir, for at dere har vært med oss i studio her for å dele det dere gjør med Altinn. Og så runder vi av denne episoden av Plattformpodden med Hans-Christian Flåtten og Audun Fauchald Strand, teknisk produsent av vår eminente Tore Gresdal. Tusen takk for oss. Ha det bra!