Ny registerplattform er avgjørende for sikkerheten til Brønnøysundregistrene

[Redaksjonen.]

Brreg-direktøren mener kritikerne henger seg på gammel retorikk.

Ny registerplattform er avgjørende for sikkerheten til Brønnøysundregistrene

[Anders Jensen]

Nå har jeg kun overfladisk innsikt i hvordan Brønnøysundregistrene jobber, men har absolutt inntrykk av at de henger med i timen på teknologi, selv om mange av systemene nok ligger langt bak.

 

Det som bekymrer meg er prosjekt tankegangen. Alarmen går allerede der. Fordi et prosjekt er feil medisin. Innleide konsulenter er mer av samme feil medisin. Det som trengs er et løft i forvaltningsregimer slik at en unngår å bygge så mye teknisk gjeld som de nå sitter med. Det er helt meningsløst å ta dette i 6 års skippertak, det må gjøres kontinuerlig. BRsys blir et levende system, den underliggende plattformen bør antagelig byttes ut i løpet av 6 års perioden selv om en velger helt ny nå, og det er uansett ikke noe en ønsker å gjøre etter vannfallsmetoden. Ta en endring om gangen og fokuser på evnen til å ta kommende endringer raskere. Det er sånn alle webscale suksessene har jobbet. Det er sånn en bygger sikre systemer selv fra scratch og spesielt når en har et stort komplekst system å forholde seg til fra før av.

 

Spørsmål til Brønnøysundregistrene; Hvordan har dere tenkt å migrere inn og ut av BRreg? God arkitektur tar høyde for hele livsløpet. Skal det bli nytt megaprosjekt om 8 år? Hvordan skal en unngå å gjøre samme tabben som er gjort frem til i dag, dvs. bygge massiv teknisk gjeld?

[Kennet Nilsen]

Ta til fornuft..

 

SITAT:

"Vår infrastruktur og vår drift vekker internasjonal oppsikt, og registrene er garantisten for et velfungerende samfunn"

 

Så hvorfor skal du kaste dette og lage noe nytt?

 

Sikkerhet IT Systemer er viktig, men rettferdiggjør ikke prislappen på 1,2 milliarder. Forandringer utvikling bygging nye IT systemer består av kontinuerlig fokus på forbedring og utvikling. Ikke en plan på 6 år , og 1,2 milliarder. Dette er et arbeid som må gjøres vær dag av små IT grupper med flere lanseringer i løpet av året. Viktigste av alt her er og tenke , sandtids dokumentasjon, og bruker opplevelse design. Glem ikke design dette er kanskje det viktigsete delen av en fornying.

 

Digitalisering går i et enormt tempo, en ting som er sikkert er at mer og mer utføres via Internett. Droner vil om 10 år gi høyhastighets nett til hele verden. Programmer som Word-xl og powerpoint vil forsvinne. Mobilen er kanskje den som blir fremtidens trygge id kort, og kan identifisere riktig bruker. Et nytt fag i skolen blir kanskje "data språk", siden mange av fremtidens arbeidsplass blir her. Alle ønsker enkelt og identifisere seg på nett, for deretter raskest mulig bli ferdig med det som må gjøres. Din største utfordring er og tenke enkelt, og samtidig holde seg innenfor lover og regler. For du må innse en ting, ingen synes det er morsomt og gøy og besøke dine registre. Og glem ikke at myndigheter helt sikkert klarer og tenke regel forandring om dine argumenter for dette er god nok. På den måten skapes innovasjon bedre bruker opplevelse og gi enda høyere samfunns gevinst.

 

Men du kan allerede nå starte med en ting. Vi som driver med systemutvikling jobber til dagen mot Altinn for og bygge og lage noe av det som du har tenkt bruke 1,2 milliarder på. Vi har 100% fokus på brukeren, og tilrettelegger integrasjoner mot Altinn der de skal slippe unna skjemaveldet. Men her møter vi en enorm motstand dårlig oppfølging. Altinn er til nå den verste integrasjonen vi har utført så langt. Ingen faste kundebehandlere, bare en manual på uendelig mange sider vi selv må studere. Vi bruker i gjennomsnitt 5 ganger så lang tid på intrigering mot Altinn en det vi burde gjøre, og dermed 5 ganger høyere kostnader. Dette kan du ta tak i allerede nå. Så burde dere se på hva vi private utvikler. Jeg vil tro dere har mye her og lære, og det hadde du sett om det var en person som fulgte intrigeringen, samtidig som vi får den hjelpen vi trenger.

 

Jeg håper denne debatten kan dra inn politikeren som snart kan uttale seg. Offentlig sektor har enorme utfordringer med IT systemer men gjøres dette riktig er det ingen kostnad, men en gevinst. Går man den andre veien med store bevilgninger over kort tid for da og stanse opp, kan dette koste vår neste generasjon store summer. Husk milliardene vil trolig ikke lenger rulle inn fra Nordsjøen og de som burde merke dette best er alle konsulenter som i dag produserer papir og grafer, ikke selve utviklere som produserer nyttige tjenester .

God helg!

[Christin Gorman]

Det hadde vært veldig interessant å høre hvordan dere tenker å dele prosjektet/plattformen opp. Fra hva jeg kan lese her https://www.mercell.com/m/file/GetFile.ashx?id=42481709&version=1 ser det ut som om det er tenkt å lage _ett_ system for alle registrene. Det er først og fremst dette jeg reagerer på. Slike "alt-i-ett"-systemer gir notorisk dårlig brukervennlighet, og er veldig tunge å forvalte. Som en kommentar på facebook (Ove Gram Nipen) så fint illustrerer:

"

- Hei, i forbindelse med neste jaktsesong trenger vi å gjøre noen endringer i jegerregisteret.

- No can do. Det er endringsfrys i foretaksregisteret på grunn av årsavslutningen

"

 

Dersom alle registrene og all saksbehandling av data i dem blir gjort i samme applikasjon, blir prosessen med å gjøre endringer i en av dem mye tyngre.

 

Det er ingen som tviler på at dere trenger modernisering. Men som prinsipp, mener jeg og mange med meg at man bør sette bruker-opplevelse først. En enkelt brukerinteraksjon vil neppe krysse både jegerregisteret, foretaksregisteret og partiregisteret. Applikasjonsarkitekturen bør speile reele bruksmønster. Det er ganske tilfeldig at akkurat Brønnøysund har ansvaret for både partiregister og jegerregister. Hvorfor skal denne tilfeldigheten styre applikasjonsarkitekturen? At man har felles biblioteker som brukes på tvers av de forskjellige applikasjonene har jeg ingenting imot. At man lager gode APIer for hver enkelt, slik at de kan integreres mot hverandre er en nødvendighet. Men å lage dette som ETT eneste system, slik deres noe vage illustrasjon i den første artikkelen viste, det tror jeg er et stort feilsteg. Ingenting i denne nye teksten deres har beroliget meg, men jeg tar gjerne imot ny informasjon om hvordan dere tenker dere å organisere både arbeid og arkitektur. Håper jo at mine bekymringer er ubegrunnede.

[Bolson]

Ta til fornuft..

 

SITAT:

"Vår infrastruktur og vår drift vekker internasjonal oppsikt, og registrene er garantisten for et velfungerende samfunn"

 

Så hvorfor skal du kaste dette og lage noe nytt?

 

Fordi alderen på teknologien gjør at systemene risikerer å stoppe opp. Økt nedetid vil ha en samfunnsmessig kostnad, kan fort bli langt høyere enn de 1,2 mrd.

 

Og så går vedlikeholdskostnadene rett til værs. Til slutt blir vedlikehold dyrere enn å bygge nytt.

[Kennet Nilsen]

Det er forståelig at man vil over på ny teknologi, men burde ikke koste 1,2 milliarder. Jeg er forundret over at ingen forstår hvor mye penger dette egentlig er:

1 200 000 000,-. Det er også merkelig at man allerede ikke er igang med utbedringer i mindre skala. Dette virker mer som et argument for og skremme politikerne.

[Bolson]

Tror nok de utbedrer gjeldende plattform så mye som de kan, de har også utviklet mye funksjonalitet over de siste 10 årene på den plattformen de har idag. Husk at selv om de starter i år, så vil ikke nytt system være fullstendig på plass før i slutten av 2022. Og kontinuerlig utvikling betyr ikke nødvendigvis at man slipper slike store "oppgraderinger". En dag kan så sentrale deler av plattformen være så "død" at man må ta et skippertak. Særlig gjelder det systemer som har så gammel kodehistorie som her.

 

Løpende utvikling var heller ikke den vanlige måten på 90 og tidlig 2000 tallet. I tillegg ingen tradisjon for løpende utvikling budsjettmessig.

 

Utvikling av store komplekse IT-systemer kost penger - svært mye penger. Og det gjør det uansett om man velger smidig metodikk, deler opp prosjektet i mange små prosjekter eller utvikler en "monolitt".  Fordelen med smidig og oppdeling er primært at man reduserer risiko, og øker muligheten til å snu underveis.

 

Jeg forstår at du jobber i bransjen - da burde du kanskje se om du klarte å få deg invitert til Brønnøysund for mer informasjon.

 

PS! Jeg har også ofte syntes offentlige IT-prosjekter var altfor dyre og med visse muligheter til litt mer inside informasjon har jeg faktisk fått sett mer på detaljer. Noen ganger har jeg hatt rett, de er for dyre - men de fleste gangene har jeg faktisk misset mange svært sentrale forutsetninger som var prisdrivende.

[Anders Jensen]

Men å lage dette som ETT eneste system, slik deres noe vage illustrasjon i den første artikkelen viste, det tror jeg er et stort feilsteg.

 

Kommer jo veldig an på hva en definerer som "ett eneste system". Siden BRreg ser på k8s baserte PaaS løsninger regner jeg med monolitt er lite naturlig, kanskje heller et sett av (mikro)tjenster.

 

Kunne vært interessant å vite, men etter min mening ikke mest signifikant i denne sammenheng.

[Christin Gorman]

Ifølge dette dokumentet ser det ikke ut til at de tenker på mikrotjenester. https://www.mercell.com/m/file/GetFile.ashx?id=42481709&version=1

Det er her lagt opp til at systemet deles i "regelmotor" "saksbehandling", "kommunikasjon" og tilsvarende vage generiske konsepter. Jeg mener man bør dele opp etter reelle bruksmønster. En applikasjon som f.eks. tar for seg interaksjon med jegerregisteret, med gode APIer utad slik at det kan integreres med andre systemer ved behov.

[Geir Amsjø]

Vi ønsker da Brønnøysundregisterne alt godt og håper virkelig dere klarer å lage fremtidsrettede, gode løsninger for samfunnet. Og vi tviler ikke på nødvendigheten av å ta et krafttak og betale teknisk gjeld. Men svaret beroliget ikke. Med denne typen planlegging og budsjettering vil risikoen være stor for at dere låser dere alt for tidlig, basert på antagelser. De 6 delprosjektene kan potensielt utnyttes til å redusere risiko - hvis de kjøres i sekvens, leverer delleveranser, og bare det første er låst. På denne måten skapes verdier raskere og man er ydmyke for at læringen underveis kan utnyttes til å lage et best mulig system. Håper det er dette dere mener med de 6 reirene (fin metafor, forresten) som jo må bety at de er autonome.

Det er svært positivt at dere han en solid stab med flinke egne ansatte. Dette synes å være en ambisjon også hos andre i offentlig sektor (som NAV). Bra. Men da blir det egentlig enda vanskeligere å forstå at det kan være nødvendig å klumpe sammen et slikt gigantprosjekt på 1,2 Mrd. Her burde det vært mulig å både finansiere og "restaurere" eksisterende systemer gradvis og mye tryggere.

Det vi egentlig kritiserer her er anskaffelsesregimet som tydeligvis promoterer digre ustyrlige prosjekter, framfor å fremme solid nok investering i utvikling og vedlikehold for å unngå opphopning av teknisk gjeld. Softwareutvikling er og blir Business As Usual for de aller fleste virksomheter og burde behandles deretter, med kontinuitet og høy håndverksmessig standard.

[Thomas Arp]

Jeg henger meg på det Geir skriver her over - det fremgår ikke, hverken av denne artikkel eller noen andre kilder jeg har funnet om saken, om oppdelingen i 6 delprosjekter er låst (er det allerede planlagt hva det skal skje i 5. og 6. delprosjekt? Og hvordan det så skal implementeres?).

 

Ulempen med lange planleggingsperioder er at man ikke vet nok, når man tar beslutningene. En løsning kunne ha vært å starte med ett av registrene og så ta lærdom underveis.

 

Jeg har forståelse for at de mange kommentarer oppleves som en hindring for dere på Brønnøysundregisterne. Dere har jobbet med å navigere i det mildt sagt ulendte terreng som er offentlig IKT-finansiering, levert analyser, kvalitetsikring, designskisser og meget annet jeg ikke har peiling på. Og så, når dere er klar til å søke om midler, kommer en flokk med folk som ikke har den samme kunnskapen om eksisterende systemer og stiller spørsmål ved den jobben dere har gjort og de løsninger dere har valgt. I noen tilfeller også den prisen dere har kommet frem til.

Vit at vi (eller, jeg kan bare tale for meg selv) ikke gjør dette fordi vi ikke tror at systemene på BR trenger oppgradering. Det er tydelig at det er nødvendig, ut fra de beskrivelser det er kommet i de ulike artikler, at noe må gjøres. Uenigheten er altså ikke OM det bør brukes penger på å gjøre systemene tidssvarende. Den går på HVORDAN det bør gjøres.

Langt på vei er det dessverre slik at innkjøps- og finansieringsreglene i det offentlige krever at man lager prosjekter for denne typen skippertak for at det kan bli betalt. Det får den uheldige konsekvens at man ofte lager kjempeprosjekt, som - når de er ferdige - viser seg ikke å ha levert det man nå vet man trenger, eller som vokser underveis og blir dyrere fordi man legger det til etter hvert som man oppdager det. Dette er ikke noen kritikk av enkeltmennesker - en slik prosess krever at man er synsk, hvis man skal få alt planlagt på forhånd. Det er dette vi reagerer på. Hver gang. Uheldigvis får vi litt for ofte rett i at budsjettet sprenges eller at løsningen ikke blir optimal.

 

En alternativ løsning som fungerer godt i utlandet (Christin lenket til dem i artikkelen sin) er å i stedet "utvide linja" - enten gjennom ansettelse eller innleie - og så utvikle forbedringene som en del av forvaltningen. Forvalterne (de interne utviklere) kjenner kundene sine og trenger uansett å kjenne til det nye systemet.

[Svært Undrende]

 

"Langt på vei er det dessverre slik at innkjøps- og finansieringsreglene i det offentlige krever at man lager prosjekter for denne typen skippertak for at det kan bli betalt."

 

Dette er dessverre en framtredende og feilaktig antagelse både i offentlige institusjoner og i leverandørmenigheten.

 

Faktum er at det offentlige innkjøpsreglementet gir svært stor frihetsgrad dersom en velger å se på hva som faktisk står der. Det er f.eks. ingenting som tilsier at Brønnøysundregistrene må lyse ut dette arbeidet samlet. De kan f.eks. beholde prosjektledelsen selv og lyse ut bistandsbehovene etter hvert. Det er også de selv som definerer betingelser for den utlyste bistanden og kan da velge å gå for en eller flere leverandørerer for kortere eller lengre tidsrom. Innenfor dette igjen kan de enkelt dele opp bistandsbehovet innenfor områder som arkitektur, teknologi, database, mellomvare, brukergrensesnitt etc. Gjort riktig er det derfor fullt mulig å kjøre et stort prosjekt på en smidig måte innenfor gjeldende innkjøpsreglement.

 

Utfordringen er vel kanskje dette med pengene. De som bevilger penger i det offentlige er gjerne svært budsjettfokusert og forventer å få vite prisen på morroa lenge før prosjektet settes i gang. Trass i at dette gjentatte ganger har vist seg å være umulig så mener mange 'revisorer' i det offentlige at det er slik det må være. Hadde en fått til litt mer smidighet hos disse så ville en kanskje sluppet det ofte unyanserte fokuset på kostnadsestimater.

[Thomas Arp]

"Langt på vei er det dessverre slik at innkjøps- og finansieringsreglene i det offentlige krever at man lager prosjekter for denne typen skippertak for at det kan bli betalt."

 

Dette er dessverre en framtredende og feilaktig antagelse både i offentlige institusjoner og i leverandørmenigheten.

[...]

Utfordringen er vel kanskje dette med pengene.

[...]

 

Ja...

[Anders Jensen]

Å få penger til forvaltning av IT er vanskelig fordi mange ikke forstår at store systemer er levende og trenger kontinuerlig oppdatering. Videre er det mange ledere innen offentlig IT forvaltning som tenker at dette skal vi ikke ha kunnskap om selv. Vi skal bare kjøpe prosjekter og så kan vi drifte det med et minimum av endring. New public management tankegang. Det er ekstremt destruktivt for IT systemer og fører til fragmentering, lokal optimalisering og teknisk gjeld til langt over halsen slik BRreg politiet nav med fler har viklet seg inn i.

[quantum]

 

Ta til fornuft..

 

SITAT:

"Vår infrastruktur og vår drift vekker internasjonal oppsikt, og registrene er garantisten for et velfungerende samfunn"

 

Så hvorfor skal du kaste dette og lage noe nytt?

 

Fordi alderen på teknologien gjør at systemene risikerer å stoppe opp.

Og fordi samfunnet stiller nye krav som det gamle ikke oppfyller, vil jeg tro. Ganske vanlig fenomen ...

[quantum]

 

Men å lage dette som ETT eneste system, slik deres noe vage illustrasjon i den første artikkelen viste, det tror jeg er et stort feilsteg.

Kommer jo veldig an på hva en definerer som "ett eneste system". Siden BRreg ser på k8s baserte PaaS løsninger regner jeg med monolitt er lite naturlig, kanskje heller et sett av (mikro)tjenster.

 

 

 

Det er forøvrig fullt mulig å implementere et rigid frys-regime oppå enhver modulær (mikro)tjenestestruktur ... 

[Geir Amsjø]

Det har aldri vært nødvendig å lage software-systemer på denne måten. Aldri særlig smart heller. Antagelig kommer det av ideen om at Prosjektstyring er et selvstendig fag, uavhengig av hva slags prosjekt som skal styres.

Men digre, langvarige prosjekter blir stadig mindre smart! Den aksellererende utviklingen vi står oppe i nå gjør det særdeles viktig å levere gradvis og å bare innse at 6-års planer ikke holder mål. Skrev om det her: https://www.linkedin.com/pulse/samfunnsutviklingen-og-digitalisering-geir-amsj%C3%B8?published=u

Sovjetunionen baserte seg på 5-årsplaner for mange titalls år siden. Det kan jo fungere i et diktatur, men er selvsagt fånyttes i den markedsdrevne virkeligheten vi har i da. BRREG lager 6-årsplaner. Just sayin´.