KOMMENTAR: Registersamordning er nødvendig for økt digitalisering

[Arild Haraldsen]

Arild Haraldsen kommenterer her et annet spørsmål angående Brønnøysundregistrenes store utviklingsplaner.

KOMMENTAR: Registersamordning er nødvendig for økt digitalisering

[Christin Gorman]

Sentralstyring gir en følelse av kontroll. Men det tar også initiativ vekk fra de som jobber "på gulvet". Akkurat som at kapitalisme har vist seg å være mye mer effektivt enn kommunisme, tror jeg også på en mer desentralisert løsning på offentlig IT. Selvsagt kommer de fleste offentlige tjenester til å være avhengig av flere registre. Jeg har selv vært med på å lage et system som integrerte med både Folkeregisteret, Matrikkelen, Skatt, Nav, Statens innkrevingssentral... alt mulig. Det vi gjorde var å kontakte forvalterne av disse registrene og få informasjon om hvordan vi kunne koble oss opp via deres APIer. Også gjorde vi det. Jeg skjønner ikke hvorfor dette skal være noe problem. Så lenge alle offentlige tjenester (og spesielt registre) tilbyr gode APIer slik at andre enkelt kan få tilgang om de trenger det, så har vi ikke noe problem. Vi trenger ikke sentralstyring og samordnede registre. En sentralstyrt løsning vil gjøre det mye tyngre å lage tilrettelagte løsninger for den enkelte tjeneste/det enkelte register. Man blir tvunget inn i en felles mal som passer alle halvdårlig. Oppdateringer blir tunge og vanskelige, ettersom de nødvendigvis vil affektere HELE NORGE, istedenfor å kun ha effekt på en lokal tjeneste. Sentralstyring er dyrt - da man er nødt til å opprettholde et stort byråkrati for å holde det ved like, og fører nettopp til teknisk gjeld, ettersom lokale tilpasninger og oppdateringer er så vanskelig at man tyr til "hack" og rare krumspring for å løse brukerbehov.

[Geir Amsjø]

Arild, jeg er som du vet enig med Christin her. Er denne voldsomme kompleksiteten egentlig et IT-problem? Det er helt sikkert masse teknisk gjeld i kjernesystemer - og det kan ha mange årsaker. Men det som slår meg er at offentlig sektor også har en betydelig prosessgjeld. Siloorganisering fører lett til unødvendig innviklede verdikjeder. Vi kjøper altså ikke at vi bare skal akseptere voldsom kompleksitet og handle deretter. Hvorfor ikke benytte denne anledningen til å virkelig forenkle prosessene, gjennom å snu alt på hodet og starte med brukernes behov. Slik de gjorde i UK med GDS. Bort med siloene, start alltid med brukern.

 

Skulle ønske noen - for eksempel i Difi - kunne gå med på å diskutere om dette i det hele tatt kan la seg gjøre i Norge. Helt enig i det siste avsnittet, der du etterlyser en slik arena.

[Thomas Arp]

Jeg kan se på det du har skrevet her (og i de sakene du ellers har lagt ut her) at vi er veldig enige, Arild. Investeringen er nødvendig. Det er ingen som har jobbet mot BR tidligere i tvil om. Det er en årsak til at mange offentlige instanser lager en lokal kopi av de registre de trenger. Flat-filer en gang i døgnet er en vanlig måte å integrere mot BR.

 

Innlegget "Gi oss oppskriften på IKT-skandaler" viser også at du er klar over hvor skoen trykker. Det er nødvendig å se på hva det er som har fått oss i den situasjonen vi er i i dag - med tunggrodde systemer som krever mye jobb (30% av driften) bare å holde fungerende.

Det er overveldende sannsynlig at det er en kombinasjon av teknologivalg, arkitekturvalg og organisering. Systemet har jo fungert i snart 25 år, så valgene var ikke helt dumme.

 

Den debatten jeg ønsker er nettopp den *systemtekniske debatten* du nevner i ditt innlegg. Den går på mange ting:

Om det alltid er korrekt å konsolidere - og om man kan ta den beslutningen så tidlig?

Om det kan betale seg å starte smått og så ta læring underveis?

Om arkitekturen enkelt kan tilpasses når man finner ut at det man trodde før ikke er riktig likevel?

Om man kan la seg inspirere av andre lande som har løst slikt før ( https://www.gov.uk/service-manual/making-software/apis.html / https://github.com/WhiteHouse/api-standards )?

Om man kan organisere det annerledes enn et mega-prosjekt?

Om man kan få god oppetid og svartid og sikkerhet og smidighet (slik at registrene kan tilpasses regler og lover)?

Om saksbehandlingsløsning må lages på nytt (fins det ingen som selger slikt)?

Om det er mulig å bli finansiert av staten og så ikke gjøre presis som man har fått kvalitetssikret?

 

Det er bare noen av de spørsmålene som kommer frem når jeg tenker på om det er en bedre metode enn mega-prosjekt.

Min personlige mening er at det vil være bedre å starte smått, ta lærdom og så utvide. Bruk av teams med utviklings- og forvaltningsansvar for hvert register (eller for flere, dersom det gir mening) som ikke bare står for fornyelse av de registrene men også har ansvar for å følge opp utfordringer og feilsituasjoner i etterkant (pager duty). Her kunne pengene brukes til å forsterke disse teams.

 

Når det kommer til et forum for å avklare spørsmål om prosjektorganisering er jeg også enig - dette er langt innenfor Difi sitt mandat, hvis jeg har tolket det riktig.

[Arild Haraldsen]

Enig i det Thomas Arp skriver. En må skille mellom nødvendigheten av å innføre nye systemer - store eller små, og gjennomføringen av disse. Samtidig er jeg overbevist om at årsakene til at noen gjennomføringer ikke lykkes og utvikler seg til skandaler, er mangeartet og forskjellig fra prosjekt til prosjekt. Fra manglende planlegging, bestiller-kompetanse, dårlig styring, for mye makt til konsulenter, utviklingsmetodikk, etc. Men jeg tror det er forskjellig fra prosjekt til prosjekt. Jeg mener derfor en å må ha en kvalitativ gjennomgang av hvert gjennomført prosjekt for å avdekke de reelle årsaker, og ikke ha kun statistisk oversikt. Det er bedre med flere røntgenbilder enn ett flyfoto (over offentlig sektor).

En slik diskusjons- og erfaringsarena som foreslått er mer krevende enn å samle sammen statistikk, både rent faglig, men også mht til tillit - etatene i mellom, og mellom etatene og Difi. Men utfordringen ligger i første rekke hos Difi. Spent på om den nye direktørene i Difi, Steffen Sutorius tar den ballen.

[Anders Jensen]

Jeg tror dere tenker litt for vanskelig om hva som er suksessfaktor for en levende IT tjeneste. Det er egentlig veldig enkelt. "you build it, you run it" Werner Vogels, Amazon.

 

Den negative feedback loopen som skapes av dette er nøkkelen til å skape robuste anti-fragile systemer. Da er konsulenter (dessverre/heldigvis) ute av loopen, men så kan en jo ha et bevisst forhold til hva som skal leveres av hvem. Så lenge BR kan levere gode APIer og ha full kontroll på utvikling og forvaltning av disse selv, så er det fortsatt god frihet til å utvikle apper og tjenester på toppen av disse.

Endret 2. august 2016 av Anders Jensen

[Geir Amsjø]

Ja, ting er utvilsomt veldig sammensatt og årsakssammenhengene kan være mange. Problemet er bare at det er svært vanskelig, mange vil hevde umulig, å gjennomføre en objektiv og god analyse av noe så komplekst som et IT-prosjekt. Jeg har deltatt i sikkert 30 prosjektevalueringer og har svært ofte tatt feil. Alt for ofte konkludert med at vi skulle gjort enda grundigere forarbeid - fordi jeg på den tiden ikke så alternativet, nemlig å lære underveis. Problemet ligger i at et menneske alltid "biased". Du oppdager det du forventer å oppdage og vil overse uventede ting. (Dave Snowden får fram dette godt her i denne ferske Keynoten:

)

I stedet kan vi betrakte de store linjene og se etter mønstre. Og vi kan se på samfunnet rundt oss og forsøke å forstå hva det vil kreve av oss. Et helt klart utviklingstrekk er raskt forarbeid, med læring og tilpasning underveis. Vi ser det overalt. Og vi kan støtte oss på teori. Som Dave Snowdens kompleksitetsteori og Cynefin modellen. Vi kan bruke systemtenkning og CLD. Og hvorfor ikke helhjertet prøve ut smidige metoder? Gjøres dette vil det være HELT umulig å feile fatalt - slik IT-prosjekter ofte gjør. Du vil fremdeles feile, men altså ikke så fatalt og det vil være godt rom for å skifte kurs (eller stoppe helt opp) når det trengs. Mener vi må angripe problemet på det nivået - og det kan gjøres uten å ta veldig stor risiko.

[Thomas Arp]

Jeg tror dere tenker litt for vanskelig om hva som er suksessfaktor for en levende IT tjeneste. Det er egentlig veldig enkelt. "you build it, you run it" Werner Vogels, Amazon.

 

Jeg forstår hva du mener, men det er ikke _nok_ å delegere til utviklerne. Man må endre noen av de rammene som fins omkring. Herunder prosjektoppsett, finansiering mv.

Brønnøysundregistrene er ikke et system som er enkelt og overskuelig nok til at ett (to-pizza) team kan håndtere en oppgradering.

[Geir Amsjø]

 

Jeg tror dere tenker litt for vanskelig om hva som er suksessfaktor for en levende IT tjeneste. Det er egentlig veldig enkelt. "you build it, you run it" Werner Vogels, Amazon.

 

Jeg forstår hva du mener, men det er ikke _nok_ å delegere til utviklerne. Man må endre noen av de rammene som fins omkring. Herunder prosjektoppsett, finansiering mv.

Brønnøysundregistrene er ikke et system som er enkelt og overskuelig nok til at ett (to-pizza) team kan håndtere en oppgradering.

Nei, vi må ikke overforenkle dette. Men det finnes gode modeller for storskala, smidig utvikling. LeSS (http://less.works/) er brukt på virkelig store systemer/virksomheter med mange titalls feature-teams. Her finner man gode verktøy, prinsipper og veiledningsmateriale som er gjennomprøvd. Rikelig med case studer også. En god kombinasjon av LeSS og Beyond Budgeting kan gjøre susen i enhver moderne stor virksomhet.

[Anders Jensen]

 

Jeg tror dere tenker litt for vanskelig om hva som er suksessfaktor for en levende IT tjeneste. Det er egentlig veldig enkelt. "you build it, you run it" Werner Vogels, Amazon.

Jeg forstår hva du mener, men det er ikke _nok_ å delegere til utviklerne. Man må endre noen av de rammene som fins omkring. Herunder prosjektoppsett, finansiering mv.

Brønnøysundregistrene er ikke et system som er enkelt og overskuelig nok til at ett (to-pizza) team kan håndtere en oppgradering.

Jeg prøver ikke å oppsummere all kompleksitet på seks stavelser, gir dere bare en "enabling constraint", ref Dave Snowden. F.eks blir prosjekt invalidert om en ikke definerer prosjektet til å leve like lenge som tjenesten det produserer.

 

LeSS er det mye samme ulla som SAFe? Vi holder på med innføring av SAFe hos oss. Personlig tenkte jeg først at det var overengineered, men det kan sikkert gjøres riktig. Det handler om kontekst...

 

http://www.scaledagileframework.com/

Endret 2. august 2016 av Anders Jensen

[Geir Amsjø]

-----

LeSS er det mye samme ulla som SAFe? Vi holder på med innføring av SAFe hos oss. Personlig tenkte jeg først at det var overengineered, men det kan sikkert gjøres riktig. Det handler om kontekst...

----------

Hei Anders, dette er selvsagt en het diskusjon for tiden. SAFe beholder hierarki og dedikerte roller og inneholder i langt større grad konkrete oppskrifter på hvordan man skal gjøre f.eks governance. De blir veldig kritisert for å ikke kunne være smidig, siden det er så beskrivende. Minner litt om RUP. Svaret fra SAFe er at man trenger ikke ta hele rammeverket, bare bruke det man trenger.

 

LeSS har valgt en helt annen tilnærming. Akkurat som i Scrum har de sagt at LeSS er minimalistisk og inneholder veldig få krav og regler. Til gjengjelde finner man en hel rekke prinsipper, råd og tips. Larman og Vodde er svært erfarne og bra folk som ser at organisasjoner kan være svært forskjellige og trenger ulike metoder og regler.

 

Vi kan godt diskutere dette videre et annet sted - jeg har [email protected]