Liker du høye skuldre, stress og potensiale for store økonomiske tap og runder med slakt i media før du får sparken? Da er det bare å kjøre på med å lage- eller kjøpe inn nye store IT-systemer for så å rulle ut alt sammen samtidig. Har du heller lyst til å migrere til nyere systemer uten stress og mas? Ja, da har jeg noen tips her.
¶Migrering
Det er mange dårlige og gamle IT-systemer rundt omkring. Når vi programmerere jobber med nye IT-systemer, er det ofte ikke fordi det mangler en IT-løsning, men fordi dagens løsning er utdatert. Migrerings-prosjekter kalles slikt. Man ønsker å migrere seg bort fra noe gammelt og over til noe nytt og bedre.
Her er det flere veier til flere mål. De prosjektene man hører om er gjerne de som ender i katastrofer med påfølgende mediestorm. Helseplattformen er et godt eksempel. Prosjektene som går bra hører man ikke så mye om. Dette er et forsøk på å fortelle litt om hvordan de kan foregå.
¶Målbildet
For det første må vi snakke om hva målbildet er. Hvordan fungerer den perfekte løsningen vi ønsker at skal erstatte det gamle? I software endres ting hele tiden. Så målbildet innen software må være å lage systemer som er endringsdyktige. Men hva betyr det i praksis? Jo det betyr at man kontinuerlig endrer produktet. Altså, at man aldri blir ferdig. Det er alltid noe som må utvides, byttes ut eller endres. Software bør dermed ikke utvikles som et “prosjekt”. For prosjekter har per definisjon en slutt-dato. De blir ferdige. Men god software blir man aldri ferdig med.
Er det gamle systemet du ønsker å erstatte i aktiv forvaltning i egen organisasjon? Eller er det et innkjøpt produkt som noen andre er ansvarlige for å forvalte? I målbildet må man ha det klart for seg hvem det er som har forvaltningsansvaret. Pass på at noen har ansvar for kontinuerlig utvikling. Ikke invester i noe, med mindre det finnes en aktiv forvaltningsorganisasjon som kommer til å jobbe med løsningen så lenge den er i bruk.
¶Eksternt system som skal byttes
Hvis det gamle systemet er kjøpt inn av en ekstern organisasjon, og man ønsker at det nye også skal leveres av en ekstern organisasjon så må man ha god “innkjøpskompetanse”. Man må klare å se gjennom salgs-pitcher og forstå hva det er man kjøper. Alle som har noe å selge vil fremstille deres løsning som den beste i verden. Her gjelder det å ikke la seg blende av de med mest fancy power point, eller de mest sjarmerende selgerne. Mange migreringsprosjekter er nettopp et resultat av at man har kjøpt inn dårlige produkter i utgangspunktet. Igjen fremstår Helseplattformen som et godt eksempel. I Midt-Norge vil man nå måtte bruke tid og penger på å migrere seg vekk ifra Epic (Som Helseplattformen er bygget på) i tiden fremover.
¶Tilpasning av hyllevare - det er skreddersøm
Når man skal kjøpe inn et ferdig system, så må man kjøpe noe som fungerer som det er. Microsoft Office kan man kjøpe. Slack kan man kjøpe. Der det finnes hyllevare man bare kan ta i bruk, så bør man gjøre det. Fungerer ikke produktet slik man vil ut av boksen, må man være villige til å endre sin egen drift til å passe til IT-systemet som kjøpes inn. Er man ikke villige til å endre egen organisasjon på grunn av IT-systemet, så må man lage et IT-system som passer egen drift.
Enten kjøp hyllevare - eller lag skreddersøm. Ikke prøv på noe midt i mellom. “Hyllevare som kan tilpasses” må man passe seg for. Dette er det mange som prøver å selge inn. “Kjøp vår hyllevare, så kan du tilpasse den til ditt bruk etterpå”. Tilpasning av hyllevare - det ér jo skreddersøm. Bare at utgangspunktet for suksess gjerne er dårligere. Skal du bruke en skredder, er det bedre å la dem jobbe med stoff på rull, enn å ta utgangspunkt i en dress i feil farge som er for liten. Mindre justeringer kan være greit, men vær varsom. Har jeg nevnt Helseplattformen? Her har man måtte investere milliarder og flere år på å tilpasse et amerikansk produkt til norske forhold. Etter 6,3 milliarder kroner(!!!) har man fortsatt ikke noe som fungerer slik man vil.
¶Lavkode
For å understøtte behov for tilpasningsdyktighet, er det mange som selger inn “lavkode”-løsninger som svaret. Disse gir tilsynelatende muligheter til å tilpasse funksjonaliteten enkelt ved behov. “Helt uten programmerere”. Varianter av dette begrepet kommer og går. 4.generasjons-programmering - AKA “4GL” het det på 90-tallet. “Model driven development” prøvde noen seg på på 2000-tallet og nå er det altså lavkode det kalles. Det er samme idé igjen og igjen. Man prøver å selge inn at man kan “kode” uten å bruke “kode”. Igjen må man være veldig varsomme. De som selger slike løsninger viser gjerne demonstrasjoner på hvordan noen omtrent uten erfaring kan gå fra ingenting til en fungerende løsning på kort tid. Det de ikke sier, er at dette er fullt mulig med helt vanlig kode også. Det er faktisk ikke så vanskelig å skrive software. Det finnes utallige instruksjonsvideoer og artikler på hvordan komme raskt igang med hva det måtte være av teknologi. Ikke la dere lure av slike demonstrasjoner.
Med lavkode-plattformer så binder man seg til akkurat den plattformen. Hvis de som utvikler den går konk, eller lager en ny versjon som ikke er bakoverkompatibel, så får du et problem. I tillegg er nødvendigvis slike plattformer mye mer begrensede i hva slags funksjonalitet som støttes. Du kjøper deg begrensninger og bindinger. Ikke gjør dette uten å tenke dere nøye om. Programmering er kunsten å gi instruksjoner til en datamaskin, slik at den gjør en spesifik jobb. Det går ikke an å lage et IT-system uten programmerere. Konfigurering av en lavkode-plattform, det er programmering det. Det er programmering med et begrenset sett av instruksjoner tilgjengelig. Det er programmering i et “språk” veldig få folk kan. Det er lettere å finne folk med kompetanse, og det er lettere å finne hjelp på internett om hvordan løse IT-utfordringer med et kjent programmeringspråk og kjente vanlige programmeringsverktøy.
¶Stordriftsulemper
Et siste tips når det gjelder innkjøp er å ikke prøve å kjøpe inn alt i ett system fra en leverandør. (Med mindre du har veldig små behov). IT-systemer består av mange deler uansett. Skal du se på og analysere en pasient sine prøvesvar, så gjøres dette i et eget brukergrensesnitt uansett. Det er vanskelig å lage visning for å både analysere prøvesvar, se på sykehusbesøkshistorikk og lese journalnotater i samme bilde. Vil du ha alt oppe samtidig, må du åpne dem i parallell uansett - som om det var flere forskjellige systemer. Dette med å se forskjellige ting i sammenheng samtidig er interessant nok ofte enklere hvis man har flere systemer, enn kun ett. Da et enkelt system ikke nødvendigvis lar deg se på to “vinduer” samtidig. Mens med to applikasjoner kan du posisjonere dem og åpne dem som du vil.
Foretrekk flere mindre løsninger som gjør hver sin ting godt, fremfor en stor løsning der alt blir sånn halvbra. God brukeropplevelse er viktigere enn enhetlig brukeropplevelse. Hver gang. Alltid. Det er brukeren man skal optimalisere opplevelsen for, ikke innkjøpsavdelingen. Innkjøper vil kanskje foretrekke én kontrakt med én leverandør. Leverandører av store software-suiter har dessuten større budsjetter for å imponere innkjøperne. Men brukeren vil takke deg for å heller kjøpe inn løsninger som er godt tilpasset spesifikke brukerbehov.
¶Hva folk mener når de sier de ikke vil ha mange systemer
Når folk sier de ikke vil ha så mange systemer, så mener de at de ikke vil måtte logge seg inn igjen og igjen. De vil ikke måtte copy-paste store mengder data hit og dit. Men disse problemene kan løses helt uavhengig av hvor mange IT-systemer som er involvert. Du trenger ikke kjøpe alt fra en leverandør for å få systemer som snakker sammen. “Single sign-on” (SSO)-løsninger gjør at man kan logge seg inn en gang, og forbli innlogget på tvers av systener. APIer for data kan gjøre at systemer henter og lagrer info fra samme sted, så bruker slipper å kopiere ting frem og tilbake. Små systemer er enklere å bytte ut enn store. Hvis du synes migreringsprosjekter er slitsomme, så ikke kjøp inn store systemer det blir vanskelig å migrere seg vekk ifra. Kjøp mindre deler.
¶Internt system som skal byttes ut
Men hva om systemet som skal byttes ut er laget og forvaltet av egen organisasjon? Bør man gradvis utvikle dagens løsning til å bli slik man ønsker, eller skal man begynne på nytt? Ja takk, begge deler. Som nevnt allerede, et sunt IT-system er ett som kontinuerlig endres, der komponenter byttes ut stadig vekk. Som en bil - der man stadig vekk tar den inn på verksted og bytter ting. Eller som kroppen vår - der hver eneste celle i kroppen er byttet ut iløpet av en 7-års-periode.
Skal man “begynne på nytt” må man uansett ta en del av gangen. Fas nye deler inn gradvis til det gamle er byttet ut.
¶Ny og gammel i parallel
I et migreringsløp bør man lage nye løsninger som kan kjøres i parallel med den eksisterende løsningen. Første steg i en migreringsstrategi, er å finne ut hvordan man skal passe på at data fra den gamle løsningen er tilgjengelig i den nye og motsatt kontinuerlig iløpet av prosessen. Hvordan dette rent teknisk løses, vil variere fra system til system. Det viktige er å passe på at en slik mekanisme er på plass. Når det er hipp som happ om man bruker ny eller gammel løsning for å gjøre jobben sin, da kan man i ro og mak justere den nye til den er å foretrekke fremfor den gamle. Når brukerne er fornøyde, kan man da skru av den gamle med lave skuldre. Det er dette som er nøkkelen til en god migreringsprosess.
¶Få det i prod
For at det skal være hipp som happ om man bruker den nye løsningen eller den gamle, må den nye være i et produksjonsmiljø. Få funksjonalitet ut til reelle brukere i reelle brukssituasjoner så tidlig som mulig. Man får alltid overraskelser når det skjer. Man kan ikke vente til man “er ferdig” før man ruller noe ut i prod. Det er først når det kommer i produksjon at du begynner å få ordentlig feedback på hvordan løsningen fungerer - eller ikke fungerer. Helseplattformen er igjen et godt eksempel. Man trodde man var ferdig da det ble rullet ut på St. Olav, men selvfølgelig kom det rennende inn med feil og mangler. Det er helt unødvendig, og innen helse direkte farlig, å utsette seg selv for denne typen “overraskelser”. Det er ekstra unødvendig å utsette seg for overraskelser i alle deler av et kjempestort system samtidig. Rull ut en og en ting kontrollert. Ikke ta alt på en gang.
¶“Men brukerne vil jo ikke ha noe som ikke er ferdig”
Nei, det vil de ikke. Men de vil heller ikke bli servert en “ferdig” løsning som ikke fungerer. Her må vi være ærlige å si at dersom brukere ikke ønsker seg systemer som er ubrukelige - så er de helt nødt til å bidra inn i utviklingen. Det vil ta tid, det må prioriteres, det er slitsomt. Men det er den eneste måten å være sikre på at det man lager faktisk fungerer.
¶Tilgangsstyring
I tillegg til å finne mekanismer for å holde data i synk, må man tenke på tilgangsstyring og personvern. Har man ikke dette på plass så vil man ikke (bør man ikke) kunne rulle ut ny funksjonalitet i et produksjonsmiljø. Hvis data er tilgjengelig i både ny og gammel løsning, og ny løsning ikke gir tilgang til data eller funksjonalitet til uvedkomne, da kan man trygt begynne å jobbe med den nye løsningen med relle data, med reelle brukere, og få nødvendig feedback på hvordan løsningen fungerer i praksis. Dette må være på plass fra dag en. Altfor ofte venter man til slutt med å legge på denne typen ting, eller man tenker at tilgangsstyring er en egen del som kan løses av et eget team på utsiden. Dette er en oppskrift på store forsinkelser og problemer. Hvem som skal ha tilgang til hva varierer veldig på tvers av forskjellige typer data og arbeidssituasjoner. Det å skulle legge på tilgangsstyring til slutt, eller det å prøve å lage tilgangsstyringsmekanismer som fungerer for alle deler av et stort komplekst system som en egen felleskomponent er en oppskrift på en stor kompleks flaskehals det er vanskelig å ha oversikt over. I en slik komponent er det både lett å introdusere feil, og feil som introduseres kan ha alvorlige konsekvenser. Dessuten kan det være vanskelig å tilpasse tilgangsstyringen til forskjellige typer behov uten at det blir for stor kompleksitet. La tilgangsstyring heller ligge sammen med tjenestene som leverer ut data. Der man lagrer og tilgjengeliggjør data, må man ha et forhold til hvem det er som skal ha tilgang til de dataene. Forholder man seg til hver type data for seg, er det mye enklere og tryggere å gi tilgang til brukerne som trenger dem, og man kan lett tilpasse tilgangsstyringen til reelle behov som oppstår, uten at det innfører noen ekstra kompleksitet i andre deler av systemt sin tilganggstyring.
¶Trenger du nytt system?
Avslutningsvis må jeg få si at jeg både har opplevd og hørt om altfor mange migrerings- og omskrivningsprosjekter som blir startet på tvilsomt grunnlag. Det er lett å slenge dritt om et eksisterende system man kjenner alle mangler på. Det er vanskeligere å se feilene og manglene i det nye systemet man bare har tenkt på inni hodet sitt, eller kun har design-skisser for. Det å lage gode IT-systemer er vanskelig, og mest sannsynligvis blir det nye også problematisk på mange forskjellige måter. Det er lett å kaste babyen ut med badevannet.
¶Lykke til!
Lykke til med din neste migrering! Måtte den bringe både lave skuldre og god stemning!
