Hva er et legacy-system?

Legacy-system er et uttrykk som ofte blir sagt med et sukk. Det forbindes med støvete, eldgamle systemer som burde ha vært pensjonert for lenge siden. Men det bildet bommer på poenget og kan føre til gale beslutninger. Her ser vi på hva et legacy-system faktisk er, hvordan du kjenner det igjen, og hva du kan gjøre med det.

Legacy betyr vanskelig å endre, ikke gammelt

Den vanligste misforståelsen er at legacy er det samme som gammelt. Det stemmer ikke. Et legacy-system er et system som fortsatt bærer virksomheten (det gjør nytte for seg hver dag), men som er bygd på teknologi eller kunnskap som har blitt vanskelig å vedlikeholde og endre.

Alderen er underordnet. Et tjue år gammelt system som er godt vedlikeholdt, dokumentert og holdt i live, trenger ikke å være legacy. Samtidig kan et system som ble bygd for fem år siden, allerede være legacy hvis det ble utviklet uryddig, hvis de som bygde det, er borte, og hvis ingen lenger tør å røre det. Det avgjørende er om systemet lar seg endre, ikke antall år.

Med den definisjonen blir legacy et spørsmål om risiko og handlingsevne, ikke om teknologiens fødselsår.

Varselsignalene

Legacy sniker seg som regel inn. Det finnes sjelden en bestemt dag da et system «blir» legacy, men det finnes tydelige tegn på at det har skjedd:

• Én person kjenner systemet. Kunnskapen sitter i hodet på én eneste medarbeider, og alle vet at ingenting får skje med akkurat den personen. Det er kanskje det sterkeste signalet av alle.
• Ingen tør å oppgradere. Hvert forslag om å oppdatere en komponent eller endre noe møtes med bekymring for hva som kan gå i stykker, så man lar det være og drar med seg gammel teknologi og sikkerhetshull.
• Dokumentasjonen mangler eller stemmer ikke. Det som en gang ble skrevet ned, er utdatert, og sannheten finnes bare i koden og i hukommelsen til noen få.
• Alt tar uforholdsmessig lang tid. Selv små endringer blir dyre og trege fordi ingen egentlig har oversikt over konsekvensene.

Kjenner du igjen flere enn ett av disse, har dere med stor sannsynlighet et legacy-system, uansett hvor nytt det føles.

Et konkret scenario

Et selskap har ordrehåndteringen sin i et system som ble utviklet internt for åtte år siden. Det fungerer, men bare én av de opprinnelige utviklerne er igjen, og det er vedkommende som fikser alt når noe krøller seg. Det finnes ingen dokumentasjon verdt navnet. Når utvikleren tar ut en lengre permisjon, tør selskapet knapt å røre systemet. En ny integrasjon som burde ta to uker, tar i stedet flere måneder fordi ingen andre forstår hvordan delene henger sammen.

Systemet er ikke gammelt regnet i år, men det er i aller høyeste grad legacy: Virksomheten avhenger av noe ingen lenger behersker, og frykten for å røre det bremser forretningen.

Tre veier videre

Når dere først har identifisert et legacy-system, finnes det i bunn og grunn tre strategier, med ulik risiko og kostnad:

• Kapsle inn. La systemet bli stående, men bygg et beskyttende lag rundt det slik at nye deler kan kobles på uten å røre kjernen. Raskt og med lav risiko, men det løser ikke grunnproblemet.
• Modernisere trinnvis. Bytt ut én del om gangen mens systemet fortsetter å kjøre, til det gamle gradvis er erstattet. Det tar lengre tid, men holder risikoen lav og virksomheten i gang.
• Erstatte. Bygg et nytt system og gå over. Det gir en ren start, men er den mest risikofylte og kostbare veien, særlig hvis alt skal byttes på én gang.

Hvilken vei som er riktig, avhenger av hvor forretningskritisk systemet er, hvor stor risikoen er, og hva budsjettet tillater. For de fleste systemer som virkelig bærer virksomheten, er trinnvis modernisering den tryggeste linjen.

Slik tar du neste steg

Begynn med en ærlig kartlegging: Hva avhenger av systemet, hvem kjenner det, og hva skjer hvis det faller ut? Det bildet avgjør hvor mye det haster, og hvilken vei som passer. Vil dere ha hjelp til å vurdere et legacy-system og velge riktig strategi, gjør vi i Weapp gjerne gjennomgangen sammen med dere før dere binder dere til én vei.