Modernisering av fagsystemer for offentlig sektor
Et gammelt fagsystem er sjelden ett problem. Det er en samling avhengigheter som er blitt usynlige fordi de har fungert lenge. Modernisering handler først om å finne dem, og deretter om å bytte ut én om gangen mens alt annet fortsetter å virke.
Hva er et fagsystem, og når må det moderniseres?
Et fagsystem bærer fagreglene og dataene for én type sak. Flere signaler pleier å dukke opp samtidig når det er på tide å modernisere det. Systemet har samlet teknisk gjeld som gjør vedlikehold og videreutvikling tyngre for hvert år. Det mangler et API, og alt som går inn og ut, må gjennom databasen, en fil eller en eksportjobb, som beskrevet i fagsystem uten API. Det klarer ikke å koble seg til de nasjonale komponentene det skal snakke med, som Altinn 3. Arkiveringen er limt på i etterkant i stedet for bygget inn i datamodellen fra start. Og systemet lever lenger enn rammeverkene det ble bygget med.
Hvorfor store omskrivinger feiler
Den vanligste planen er å bygge det nye ved siden av det gamle og bytte på en gitt dato. Den datoen kommer sjelden, fordi det gamle systemet gjør flere ting enn noen husker, og fordi alt må være ferdig samtidig. Risikoen samles på ett punkt i stedet for å fordeles.
Slik gjør vi det
Fasade først
En fasade foran det gamle systemet gjør at klienter slutter å kalle det direkte. Etter det kan innmaten byttes uten at noen merker det.
Start med lesing
Rapporter og oppslag kan flyttes uten å endre hvordan data oppstår. Det gir en reell produksjonstest før noe kritisk står på spill.
Følg dataene
Hvor kommer de inn, hvor går de ut, og hvem oppdager det hvis de stopper. Svaret på det siste peker på integrasjonene ingen har dokumentert.
Én modul om gangen
Hver modul gir noe som virker, og gjør estimatet på den neste mer realistisk.
Anskaffelsen må tåle etapper
En modulvis leveranse passer dårlig med én stor fastpriskontrakt, og bedre med en avtale der omfanget avtales per leveranse.
Funksjonalitet
- Kartlegging av avhengigheter og dataflyt
- Fasade foran eksisterende system
- Modulvis migrasjon med produksjon i drift
- Flytting fra lokal drift til Azure
- Datamigrasjon med avstemming
- Parallellkjøring og sammenligning av resultater, testet automatisk
- Rullende utrulling med mulighet for tilbakerulling
- Dokumentasjon og overlevering underveis
Vi har gjort dette før
Ofte stilte spørsmål
- Hva er et fagsystem?
- Et fagsystem bærer fagreglene og dataene for én type sak.
- Når bør et fagsystem moderniseres?
- Når det har samlet teknisk gjeld som gjør vedlikehold tyngre, mangler et API, ikke klarer å koble seg til nasjonale komponenter, har arkivering limt på i etterkant, eller lever lenger enn rammeverkene det ble bygget med.
- Kan systemet være i drift mens dere jobber?
- Ja, det er hele poenget med metoden. Vi bytter modul for modul bak en fasade i stedet for å erstatte alt på én dato.
- Hvor begynner dere?
- Med lesing framfor skriving. Rapporter og visninger kan flyttes uten å endre hvordan data oppstår, og gir en test i produksjon tidlig.
- Hva om vi ikke vet hva systemet gjør?
- Det er det vanlige. Vi følger dataene inn og ut og kartlegger avhengighetene før noe røres. Kartleggingen er ofte den mest verdifulle leveransen i seg selv.
- Kan dere flytte fagsystemet fra lokal drift til Azure?
- Ja. Flytting fra lokal drift til Azure gjøres modul for modul som resten av arbeidet, uten én stor overgangsdato.
- Hvilken kontraktsform passer?
- En avtale som gir rom for etapper, for eksempel SSA-S eller en smidig utviklingsavtale. Da finansierer de første modulene læringen som gjør estimatene på de neste realistiske.
Les mer om dette
Står dere i dette nå?
Fortell oss hva dere har i dag, så sier vi hva vi ville gjort først og hva vi ville ventet med.