Nasjonale felleskomponenter - hvor er vi nå?

27. desember 2017 Av: Steinar Skagemo

Historien

For syv år siden kom Difi-rapport 2010:17​ om nasjonale felleskomponenter.

Steinar-Skagemo
Steinar Skagemo

Difi-rapporten 2010:17 anbefalte at tre grunndataregistre samt ID-porten og Altinn fikk status som nasjonale felleskomponenter. Videre anbefalte den etablering av et regime for styring, forvaltning og finansiering av felleskomponenter. Formålet med et slikt regime var å sikre at felleskomponentene ble videreutviklet på en koordinert måte, og at behov for ny fellesfunksjonalitet ble identifisert og dekket av en felleskomponent, ett sted.

En del behov var identifisert allerede dengang, som meldingsutveksling og felles forvaltning av samtykke, profiler og identitetsinformasjon.

I årene som har gått har det skjedd betydelig videreutvikling på både ID-porten og Altinn, og det har kommet til flere komponenter. Difi har laget eSignatur og eFormidling og Brønnøysundregistrene har laget felles datakatalog og løsning for samtykke.

For samhandlingen med kommunal sektor har det i tillegg kommet en helt ny aktør på banen. KS har etablert, og forvalter og videreutvikler FIKS, en plattform for digital samhandling med og i kommunal sektor. SvarUt er trolig den mest kjente tjenesten i FIKS. Gjennom SvarUt har snart hver eneste kommune i landet en tjeneste som gjør at de kan sende forsendelser digitalt, uten at de selv må forholde seg til hvor forsendelsen skal; SvarUT ruter forsendelsen riktig avhengig av om mottakeren er en offentlig eller privat virksomhet, eller en privatperson. I sistnevnte tilfelle velger den riktig meldingsboks eller papir dersom mottakeren har reservert seg.

I tillegg til de konkrete tjenestene som er utviklet har også felleskomponentrapportens forslag om et styringsregime fått en oppfølging. Det er etablert et forum der direktørene for alle felleskomponentforvalterne er representert, og der de øvrige plassene rullerer mellom andre offentlige virksomheter. SKATE, som forumet heter, har bl.a. etablert et felles veikart, for å identifisere og prioritere områder der det er behov for utvikling.

Verdien av fellesfunksjonalitet

Når mange virksomheter i offentlig sektor har det samme behovet, så virker det umiddelbart lurt å bygge funksjonalitet som dekker behovet en gang, og gjenbruke den, fremfor at hver virksomhet bygger sin løsning. På sitt beste kan fellesfunksjonalitet akselerere den digitale transformasjonen fordi virksomhetene kan ta i bruk funksjonalitet, fremfor å måtte lage den selv først.

Da Oslo kommune for noen år siden startet en satsing på digital dialog med innbyggere og næringsliv, var et viktig strategisk grep å løse felles behov gjennom fellesfunksjonalitet. En behovskartlegging avdekket at det fantes et sett av felles behov på tvers av innbyggerne, næringslivet og kommunens egne virksomheter, som kunne løses gjennom fellesfunksjonalitet. Min side, digitale forsendelser, autentisering og autorisasjon og en rekke grunndata var blant disse. Noen var allerede dekket gjennom nasjonale felleskomponenter, noen måtte utvikles i kommunen, og noen har kommunen jobbet for å løse hos andre, blant annet gjennom tett samarbeid med KS. For det som allerede fantes var det en utfordring at det ofte er en terskel, både teknisk og avtalemessig å ta funksjonaliteten i bruk for hver enkelt av de femti virksomhetene i Oslo kommune.

Denne høsten har vi sett tydelige resultater av denne tilnærmingen. For det første fikk Oslo kommune årets fyrlyktpris for Min side. For det andre ser vi nå eksempler på virksomheter som ønsker å digitalisere tjenester, og som allerede i prosjektets planleggingsfase opplever å få første versjon av en tjeneste opp og kjøre, ferdig integrert med innlogging via ID-porten, roller og rettigheter fra Altinn og grunndata fra folkeregisteret, enhetsregisteret og matrikkelen og digitale dokumenter sendt til innbyggernes foretrukne postkasse.

Utfordringer med fellesfunksjonalitet

Selv om utvikling og gjenbruk av fellesfunksjonalitet virker logisk, viser erfaringene at det ikke alltid er helt rett frem. Å bruke andres fellesfunksjonalitet fremfor å utvikle egen, innebærer å gi fra seg kontroll, og da er man avhengig av å ha troverdige og forutsigbare mekanismer for påvirkning. Kanskje dekker eksisterende fellesfunksjonalitet bare nesten behovet, og istedenfor å starte prosessen med å forsøke å få til de nødvendige endringene, er det mer forutsigbart å løse det selv, innenfor prosjektets kontroll. I et stadig mer omfattende landskap av funksjonalitet er det heller ikke gitt at man har oversikt over hva som finnes av fellesfunksjonalitet og hvordan ulik funksjonalitet kan settes sammen for å dekke mer komplekse behov. Og sist, men ikke minst, om man har den oversikten i dag, hvordan bevarer man den når det samtidig skjer videreutvikling og endringer alle steder?

En erfaring er at prosjekter har en tendens til å foretrekke å bygge videre på den løsningen de allerede er tett på. Når tiden er knapp blir vurderingene av om det finnes fellesfunksjonalitet som kan dekke behovet ofte preget av overfladiske undersøkelser av hva som finnes, eller man tar utgangspunkt i en tidligere vurdering, og satser på at det ikke har skjedd så mye siden den gang. Det er mye som tyder på at utviklingsprosjekter ofte utelukker eksisterende fellesfunksjonalitet av to hovedårsaker: 1) manglende kunnskap om hva som er mulig å få til med dagens løsning, og 2) manglende vurdering av hva som kunne vært mulig å få til hvis man gikk i dialog med forvalterne av fellesfunksjonalitet om endringer og tilpasninger. Kanskje gjelder dette også mellom de ulike forvalterne av fellesfunksjonalitet. Klarer de å holde seg godt nok oppdatert på hverandres tilbud til at de bygger videre på det, fremfor å utvikle løsninger i parallell?

Sandkasser og selvbetjente løsninger for utviklere

Det er vanskelig å lage dokumentasjon av fellesfunksjonalitet som kommuniserer så godt at alle aktuelle aktører umiddelbart forstår hva som er mulig og hvordan man kan komme i gang. Men en erfaring er at kjørende kode kan si mer enn tusen ord. Even Westvang kalte en gang sine åpne data-demoer for “små, retoriske roboter”. Utredninger kommer svært ofte til kort sammenlignet med noe som allerede fungerer.

Å legge til rette for at utviklere kan “ta og føle på” fellesfunksjonalitet, og lære de å kjenne  gjennom utprøving, er antagelig et av de beste pedagogiske virkemidlene som finnes. Selv om det er tradisjon for å tilby dette gjennom testmiljøer, er det en enorm forskjell mellom det å måtte kontakte en virksomhet for å be om tilgang til et testmiljø, kontra det å umiddelbart gjøre noen API-kall for å forstå hvordan en tjeneste virker.

Få oppdatering og oversikt på Software 2018

En svært stor andel av de som jobber med digitalisering i Norge idag kommer på et eller annet tidspunkt bort i en eller flere av de nasjonale felleskomponentene, enten som leverandører til offentlige virksomheter, som skal gjøre bruk av dem, eller til privat sektor som har systemer som skal rapportere data inn eller hente data ut fra det offentlige.

På Software 2018 er det en sjelden anledning til å få en samlet oversikt over landskapet gjennom et eget spor om nasjonale felleskomponenter og åpne API-er. Istedenfor å oppsøke aktørenes egne konferanser, får du alle tre samlet på ett brett. Difi, Brønnøysundregistrene og KS vil presentere sine plattformer, inkludert planer for videreutvikling. Samtidig vil hver av dem vise konkrete eksempler på funksjonalitet, som allerede finnes eller er rett rundt hjørnet, og som kan ha stor verdi, men som kanskje ikke er like godt kjent.

I tillegg vil sporet utforske andre tilnærminger. Spennende foredrag fra Nav, BankID og Direktoratet for e-Helse kan kan gi oss noen viktige innspill om hvor veien videre bør gå. Er konklusjonene i Difi-rapport 2010:17 fortsatt gyldige, eller finnes det helt andre tilnærminger fremover?

Se programmet her >