Mangelfull dokumentasjon, eldre teknologier og flere hundre tusen linjer med kode som noen steder er ugjennomskuelig. Når er det klokt å skrote det gamle, og starte helt forfra med utvikling av et nytt system?
Redaksjonen i danske Version2.dk mottok nylig en e-post fra en erfaren it-utvikler som ønsker å være anonym.
Rekke faktorer
Vedkommende stiller en rekke interessante spørsmål, som på den ene eller andre måten relaterer seg til et sentralt tema som alle it-profesjonelle kjenner til, men som det ikke finnes et entydig svar på:
_logo.svg.png){kind=logo}
Skal vi vedlikeholde de(t) gamle system(ene), eller utvikle nytt?
Dette relativt enkle spørsmålet berører en rekke faktorer som Version2 gjerne vil belyse sammen med leserne framover.
Teknisk gjeld
Et av dem er begrepet teknisk gjeld, som ble introdusert av Howard ‘Ward’ Cunningham.
Teknisk gjeld dekker over alle de hackinger, snarveier og ikke-optimale designbeslutninger som finnes i alle systemer. Slike ting sniker seg som regel gradvis inn i et system når en deadline skal holdes, og det ikke er tid til å gjøre tingene ordentlig:
Splitter ny stormaskin får innebygd sikkerhet og compliance
«Vi får rette det opp litt senere», heter det under etterrasjonaliseringen.
Problemet er bare at det ofte/noen ganger at de midlertidige løsningene som ble kodet for å få levert i tide, ikke blir fulgt opp. Det er nemlig en ny deadline som må holdes.
Martin Fowler har i tillegg spesifisert hvorfor teknisk gjeld oppstår ved hjelp av sin tekniske gjeld-kvadrant.
Vokser med tiden
Her rubriseres årsaken til teknisk gjeld etter hvor uansvarlig eller ansvarlig man er på den ene dimensjonen, mens den andre dimensjonen angir om det skjer bevisst eller ubevisst.
Uansett om man oppfører seg ansvarlig eller uansvarlig og er bevisst eller uvitende om den tekniske gjelden, vil den tekniske gjelden i et system vokse over tid, hvis det ikke gjøres en aktiv innsats for å redusere den.
Slik formulerer leseren dette:
«Den typiske situasjonen er at det ikke har vært satt av penger til løpende vedlikehold, og at systemeieren har forventet ny funksjonalitet for pengene hele tiden. Det har medført et enormt etterslep som ikke er synlig for bedriften».
20 prosent til vedlikehold
Leseren foreslår å sette av 15–20 prosent av en anskaffelsesinvestering til årlig vedlikehold, men det skjer ikke så ofte.
Det er ikke utelukkende ytre omstendigheter som er skyld i den tekniske gjelden. Leseren peker også på utviklerne selv.
Hvordan balansere KI-investeringer med bærekraftsmål?
«Samtidig har det alltid vært morsommere å utvikle enn å rydde opp og dokumentere», som leseren formulerer det.
(Her vil Version2's journalist for egen regning legge til at det agile manifest noen ganger misbrukes. Spesielt formuleringen «Velfungerende programvare framfor omfattende dokumentasjon». Ofte glemmes den siste setningen i det agile manifestet: «Det er verdi i punktene til høyre, men vi verdsetter punktene til venstre høyere».)
Mangelfull dokumentasjon
Hvis det ikke er tid til å lage en skikkelig design og ordentlig kode – og utviklerne dessuten har en forkjærlighet for kode framfor dokumentasjon – er det antagelig ingen overraskelse at dokumentasjonen også halter.
Selv om de fleste utviklere i dag selvfølgelig (?) skriver kommentarer i koden, skorter det kanskje mer på arkitekturdokumentasjonen.
I løpet av de siste 10–15–20 årene har det opprinnelige standalone-systemet blitt integrert med alle mulige andre systemer, i tillegg til at det villig vekk eksporteres og importeres data i forskjellige formater via forskjellige protokoller.
Finnes det fullstendig oversikt over de forskjellige datakildene og de interne/eksterne systemene som systemet samhandler med? Finnes det en full oversikt over hva et avbrudd eller bare en mindre endring av dataformatet i et annet system vil medføre?
Folk med kunnskap pensjoneres
Det er en del systemer der ute som trolig har blitt utviklet og vedlikeholdt av folk som nærmer seg pensjonsalderen. Hva skjer med systemene når disse går av med pensjon?
Nyutdannede it-folk kjenner for eksempel ikke til de stormaskin-teknologiene som er det sentrale fundamentet for mange fancy apper; det være seg mobilbank, Mobile Pay og andre finansielle apper.
.jpg)
Nkom åpner tilsyn etter trøbbel med politiets nødnummer
Samtidig har it-bransjen alltid hatt en forkjærlighet for all ny teknologi, mens det rynkes litt på nesa over velprøvd, men eldre teknologi.
Derfor er det prestisje for både nyutdannede og ledere i å være involvert i et skybasert prosjekt som utvikler en blockchain-basert løsning, som også inkluderer containeriserte Docker-mikrotjenester som orkestreres med Kubernetes, mens IoT-innretninger samler inn data til en Hadoop-datasjø som benyttes til maskinlæring.
Overdrivelse
Greit, dette er kanskje å overdrive litt, men i realiteten kunne organisasjonens forretningsmessige behov kanskje dekkes av et mindre prestisjefylt nettsted/administrativt system basert på eldre teknologi?
Men det skjer ikke, og verdifull teknisk kunnskap går tapt. Men det er ikke bare teknisk kunnskap dette handler om. Som leseren formulerer det:
«Da man utviklet første generasjon av de administrative systemene, visste kunden hvilke regler de fulgte i den manuelle saksbehandlingen. Det vet ikke kundene lenger – for de som vet dette, er også på vei mot pensjon.»
«Det må finnes mange yngre saksbehandlere rundt omkring som bruker it-systemene uten å vite nøyaktig hva systemet utfører. Hvordan skal de kunne spesifisere og teste et nytt system?».
Valget mellom modernisering og nyutvikling
Hvis den tekniske gjelden til et eksisterende system anses for å være så overveldende at det vil være billigere å starte utviklingen av et helt nytt, hvordan sikres det så at alle regler og særregler – samt unntak fra reglene og særreglene – blir implementert korrekt i det nye systemet?
Her kan det bli nødvendig å gjennomføre en ny kravspesifikasjon ved å gjennomgå kildekoden til det gamle systemet, hvis det ikke finnes en skikkelig dokumentasjon av reglene i systemet.
Hvis man velger å modernisere et eksisterende system, krever også det en innsats, men dette er noe som leseren foretrekker:
Gjør endringer etter sviende tap: – Dessverre en del useriøse bedrifter
«Hvis et eksisterende system ikke er helt håpløst, vil man kunne gjenbruke komponenter – eventuelt pakket litt penere inn og kombinert på en ny måte. Men det forutsetter jo at man har oversikt over det gamle systemet.
Så en løsningsmulighet er opprydding, konsolidering, dokumentasjon, forbedring av arkitekturen … og så kan man modernisere én del av systemet av gangen. Det er betydelig mindre risikofylt enn big bang-prosjekter hvor man kaster ut alt sammen og begynner forfra.»
Men det er selvfølgelig også andre faktorer som har relevans når valget mellom modernisering og nyutvikling skal foretas.
Artikkelen er levert av vår samarbeidspartner Version2.dk, en del av Teknologiens Mediehus.
