Vi takker for svar fra Killengreen og Kristensen på vår bekymring rundt satsningen på fellekomponenter. Vår bekymring kommer fra egne opplevelser av offentlige prosjekter og tjenester, men særlig fra gjennomlesning av dokumenter og møterapporter produsert av Skate.
Det var særlig sluttrapporten til foranalysen for informasjonsforvaltning og -utveksling. Denne synes å være en uforbeholden hyllest til gjenbruk, standardisering og felleskomponenter. Vi blir bekymret av at anbefalingene ikke sier noe om viktigheten av å gjøre fellekomponenter begrensede og «smale», ei heller brukervennlige. En annen ting er at en felleskomponent nødvendigvis blir statisk. Slike løsninger er altså best egnet på områder der vi ikke forventer endringer i fremtiden.
Når Killengreen og Kristensen tar til orde for «smale, gode og fleksible felleskomponenter» blir vi beroliget og bekymret. Smale ja! Men fleksible? Nei. Det er da ikke standardkomponentene som skal være fleksible! De skal utgjøre en fast grunn og gjøre det mulig for andre å legge fleksible, endringsvennlige tjenester på toppen. Omtrent slik Apple og Google har gjort.
Bør ta utgangspunkt i brukerne
Killengreen og Kristensen bedyrer at både utvikler- og brukerperspektivet er godt ivaretatt. Kanskje er det det. Kanskje ikke. Det er vanskelig å bedømme kun ut fra et slikt svar. Dette perspektivet forsvinner i hvert fall i teksten i de ulike dokumentene vi har sett.
Vi er nok fremdeles bekymret for at dette standardiseringsarbeidet tar for lang tid og vil bidra til store, tunge standardkomponenter som ikke tåler den endringstakten fremtiden vil kreve. Vi vet ikke hva som foregår i det praktiske arbeidet, men vi mener kriteriene for slikt arbeid tydeligere bør ta utgangspunkt i brukerne og sette fleksibilitet og endringstakt i fokus.
Felleskomponenter bør først og fremst fokusere på å eksponere og manipulere data. Slikt bør fremkomme i overskrifter og ingresser. På den måten kan dere bidra til små, statiske felleskomponenter med gode API-er (programmeringsgrensesnitt) slik at dynamikken kan ivaretas på nivåene over og brukerne eksponeres for skreddersydde, smale tjenester.
Hvorfor lage egen skjemamotor?
Egentlig bør vi lage så få felleskomponenter som mulig, og heller basere oss på det som allerede er laget av andre aktører som Microsoft, Oracle, Google, Apache og Amazon. Skyen inneholder i aksellererende grad svært kraftig funksjonalitet vi kan bygge på. Det finnes for eksempel standardkomponenter som er gode for å lage et skjema, hvorfor skal man da benytte Altinn sin skjemamotor?
Fokuser på det særnorske som omhandler norske borgere, organisasjoner, kartdata osv. MinID som kan identifisere brukerne på en trygg måte er et godt eksempel.
- Les også: Føler seg tvangsinnmeldt i e-Boks
Går alt for langsomt
Det bekymrer at dette arbeidet er komittédrevet og at åpenheten skal ivaretas gjennom høringer. Dette er en tung, tidkrevende, toppstyrt arbeidsform som gjøre det svært vanskelig for utenforstående både å bidra og å få reelt innblikk. Og det går alt for langsomt.
Hvis dere evner å fokusere på små, smale komponenter kan arbeidet gjøres raskere. Sluttresultatet vil tale for seg, men da er det for sent.
Vi ville blitt beroliget hvis vi hadde sett en tilærming à la Storbritannia. En svært offensiv og klar digitaliseringspolitikk med en imponerende tydelighet på hva som er viktig i fremtiden - med «CTO» Liam Maxwell i spissen. De har blant annet en svært aktiv blogg som er konkret, noen ganger teknisk og tydelig på hva som er viktig. Brukeren (publikum) først, åpen kildekode, smidige metoder osv fremheves overalt. Noe av det samme i USA, og vi mener det sender veldig tydelige signaler når Obama satt et «tech team» på å angripe de store problemene de hadde med offentlige IT-prosjekter. Her er linker til mer interessant stoff om dette.
- Les også: Nav bygger helt ny IT-avdeling