Forskjellige problemer, samme løsning?

Vi har mange IT systemer i staten. Mange av dem er avhengige av hverandre. Mange er avhengige av samme data. Det er vanskelig å holde styr på alle sammen. For å kunne jobbe effektivt må vi forenkle systemet. Men hvordan gjør vi dette best?
La oss ta et oppdiktet eksempel med rot i virkeligheten.
Det finnes mange trygdeordninger i dag. Hvis hver eneste trygdeordning har sitt eget trygde-system, sin egen applikasjon, blir det mange applikasjoner å holde styr på. Alle trygder har en masse fellestrekk, hva om vi lager ett system som håndterer alle trygder? Først lager vi skjermbilder for inntasting av data. Så supplerer vi disse med data fra offentlige registre. Dataene blir så sendt inn i en regelmotor, der trygden blir beregnet basert på dataene vi sender inn, så må trygden vedtas av en saksbehandler, før vedtaket arkiveres og utbetales til trygdemottaker. Høres bra ut. Fra hundrevis av separate applikasjoner har vi nå kun søknads-skjermbilder -> datainnsamling -> regelverksmodul -> vedtaksmodul -> arkivmodul -> utbetalingsmodul. Høres mye enklere ut. Denne typen forenkling og sammenslåing av systemer er veldig vanlig. Den gjør livet mye lettere for de som sitter på toppen. Diagrammene blir mye enklere å forholde seg til.

Men denne fremgangsmåten har store svakheter.
La oss ta for oss to forskjellige trygdeordninger og se på konsekvensene av denne strategien.
Foreldrepenger og uføretrygd. Vi begynner med første del – søknads-skjema. Hva kan vi egentlig gjenbruke her? For å søke om foreldrepenger, må man bl.a. ha informasjon om arbeidsgiver, forventet termin, hvorvidt partner er i arbeid og hvor lang permisjon man ønsker seg. For uføretrygd trenger man helt andre ting. Helse-erklæringer og diverse andre utrednigner. Dataene som trengs, for ikke å snakke om målgruppen, er så forskjellige, at gjenbruk av skjema ikke gir noen verdi. For å få til en god brukeropplevelse er vi nødt til å lage et eget skjema for hver av tjenestene.
Videre til neste punkt. Datainnsamling. Hvilke data trenger vi samle inn fra eksterne registre? Igjen, er behovene forskjellige. For foreldrepenger må vi hente inn data om partner, for uføretrygd er dette uinteressant. For uføretrygd trenger vi helsedata og arbeidshistorikk. Dette er unødvendig med tanke på søknad om foreldrepenger. Skal vi lage et gjenbrukbart datainnsamlingssteg, vil vi enten ende opp med en omfattende innsamlingsjobb som der kun en liten brøkdel av dataene samlet inn trengs av tjenesten i bruk. Ellers må vi skrive egen logikk for å håndtere hvilke tjenester som trenger hvilke data og hvordan alt skal rutes. Gjenbruk her gir liten praktisk verdi.
Hva så med regelverk og vedtak? Er det noe som er forskjellig fra trydeordning til trygdeordning så er det regelverket. En trygd er nødvendigvis ikke lik en annen trygd, ellers hadde de vært samme trygd. Gjenbruk av regler er dermed helt meningsløst. Samlokalisering av regler har ingen verdi i praksis.
Vedtakene i forskjellige trygder vil være basert på helt forskjellige ting, og behandles av helt forskjellige saksbehandlere som legger vekt på helt forskjellige faktorer. En søknad om foreldrepenger blir sjelden avslått. Mens søknader om uføretrygd er mye mer omfattende og vedtakene må håndteres med mye mer omhu. Gjenbruk gir liten verdi.
Men utbetaling – det må være gjenbrukbart. Nei faktisk ikke. Hvor utbetales foreldrepengene? Til arbeidsgiver. Hvor utbetales trygd? Vanligvis til trydemottakeren, men kanskje også til kommunen. Selv ikke i utbetaling er det lett å gjenbruke funksjonalitet.

Vi kommer ikke unna å måtte implementere spesifikke regler som gjelder spesifikke tjenester. Ved å insistere på at all utbetalingslogikk skal i samme modul, gjør vi denne jobben mye vanskeligere. Ved å skille kode etter prosess-steg (skjema –> regler -> vedtak -> utbetaling osv) så gjør vi det mye vanskeligere å jobbe med hver enkelt trygdeordning. La oss si det kommer nye krav til søknad om foreldrepenger. I et samordnet system må man da inn og endre koden i kanskje 4 forskjellige systemer. Både skjema, regler, vedtak og utbetaling blir kanskje affektert. Ettersom hver av disse modulene også brukes av alle andre trygdeordninger, må man teste hele applikasjonsporteføljen på ny for å forsikre seg om at endringen ikke hadde negative konsekvenser for noen av de andre tjenestene. Dette er en både tidkrevende og risikabel prosess.

De eneste som tjener på en slik samlokalisering og inndeling av kode er IT-arkitektene og ledelsen, som får en tilsynelatende god oversikt. Brukeren derimot, får et system som er vanskelig å tilpasse deres behov, ettersom alle tjenester skal fungere mest mulig likt.

Hvis vi istedenfor deler inn koden etter brukerbehov, blir den mye enklere og tryggere å jobbe med. Foreldrepenger kan være en applikasjon, som integrerer med akkurat de registrene som trengs for foreldrepenger. Verken flere eller færre. Én applikasjon, med skjema, regler, vedtak, arkivering og utbetaling. Den kan bli forvaltet av ett team, som er dedikert til akkurat den brukergruppen som trenger foreldrepenger. Det blir lett å oppdatere applikasjonen, enten med nye regelverk eller tekniske forbedringer ettersom man kun trenger å forholde seg til regler som gjelder den ene tjenesten. Endringer involverer kun folk i det ene teamet – man trenger ikke koordinere med ”vedtaksmodul-teamet” og ”arkiv-teamet”. Alt skjer internt i teamet som er ansvarlig for brukeropplevelsen til de som søker om foreldrepenger. Oppdateringer i foreldrepenger-applikasjonen kan ikke ødelegge for noen andre trydeordninger, så utrulling av nye versjoner blir uproblematisk og kan skje fortløpende.

Vi må skille mellom gjenbruk av data og gjenbruk av funksjonalitet. Gjenbruk av data er fint. Det er dét vi må jobbe med. De som forvalter offentlige data er nødt til å gjøre disse dataene tilgjengelig. De som forvalter foreldrepenger-applikasjonen bli nødt til å spesifisere hvordan andre offentlige virksomheter kan hente ut informasjon om hvem som mottar foreldrepenger. Så lenge dette er godt dokumentert, er det ikke av stor praktisk betydning hvordan det gjøres rent teknisk. Ved å låse oss til en bestemt integrasjonsprotokoll, gjør vi innovasjon og tekniske fremskritt vanskeligere. Det må være opp til hvert applikasjonsteam å bestemme hvordan de best kan levere fra seg dataene.

Når f.eks. SKATE-programmet til Difi skal jobbe med å legge til rette for bedre samhandling mellom offentlige IT-tjenester er det viktig at de ikke forhindrer utviklingsteamene i å jobbe effektivt og bruker-orientert. Oversikt fra toppen og ned er mindre viktig enn gode tjenester ut mot brukeren. Brukbarhet er viktigere enn gjenbrukbarhet. Offentlige tjenester må optimaliseres for det norske folk, for brukerene, for oss, ikke IT-arkitektene.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s