Et centralt spørgsmål: Skal vi rydde op i it-systemet eller udvikle et nyt?
Redaktionen modtog for nylig en mail fra en erfaren it-udvikler, der ønsker at være anonym.
Vedkommende rejser en række interessante spørgsmål, der på den ene eller anden måde relaterer sig til et centralt tema, som alle it-professionelle kender, men som der ikke er et endegyldigt svar på:
Skal vi vedligeholde de(t) gamle system(er) eller udvikle nyt?
Det relativt enkle spørgsmål dækker over en række faktorer, som Version2 gerne vil belyse sammen med vores læsere i en række kommende artikler.
Teknisk gæld
Et af dem er begrebet teknisk gæld, som blev introduceret af Howard ‘Ward’ Cunningham.
Teknisk gæld dækker over alle de hacks, genveje og ikke-optimale designbeslutninger, som findes i ethvert system. Den slags sniger sig som regel gradvist ind i et system, når en deadline skal nås, og der ikke er tid til at gøre tingene ordentligt:
»Vi kan rette op på det efterfølgende, lyder efterrationaliseringen.«
Problemet er blot, at der ofte/nogle gange ikke bliver fulgt op på det midlertidige hack, som blev kodet for at få afleveret til tiden. Der er nemlig en ny deadline, der skal nås.
Martin Fowler har yderligere specificeret, hvorfor teknisk gæld opstår, ved hjælp af sin tekniske gæld-kvadrant.
Her rubriceres årsagen til teknisk gæld efter, hvor uansvarlig eller ansvarlig man er på den ene dimension, mens den anden dimension angiver, om det sker bevidst eller ubevidst.
Uanset om man opfører sig ansvarligt eller uansvarligt og er bevidst eller uvidende om den tekniske gæld, så vil den tekniske gæld i et system vokse over tid, hvis der ikke gøres en aktiv indsats for at nedbringe den.
Som læseren formulerer det:
»Den typiske situation er, at der ikke har været afsat penge til løbende vedligehold, og at systemejer har forventet ny funktionalitet for pengene hele tiden. Det har bevirket et enormt efterslæb, som ikke er synligt for forretningen.«
Læseren foreslår at afsætte 15-20 pct. af en anskaffelsesinvestering til årligt vedligehold, men det sker ikke så tit.
Det er ikke udelukkende ydre omstændigheder, som er skyld i den tekniske gæld. Læseren peger også fingeren mod udviklerne selv.
»Samtidig har det altid været sjovere at udvikle end at rydde op og dokumentere,« som læseren formulerer det.
(Her vil Version2's journalist for egen regning tilføje, at det agile manifest nogle gange misbruges. Især formuleringen ‘Velfungerende software frem for omfattende dokumentation’. Ofte glemmes den sidste sætning i det agile manifest: ‘Der er værdi i punkterne til højre, men vi værdsætter punkterne til venstre højere.’)
Mangelfuld dokumentation
Hvis der ikke er tid til at lave ordentligt design og ordentlig kode – og udviklere desuden har en forkærlighed for kode frem for dokumentation – så er det formentlig ingen overraskelse, at dokumentationen også halter.
Selvom de fleste udviklere i dag selvfølgelig (?) skriver kommentarer i koden, så halter det måske mere med arkitekturdokumentationen.
I løbet af de seneste 10-15-20 år er det oprindelige standalone-system blevet integreret med alle mulige andre systemer, ligesom der lystigt eksporteres og importeres data i forskellige formater via forskellige protokoller.
Er der fuldstændigt overblik over de forskellige datakilder og interne/eksterne systemer, som systemet interagerer med? Er der fuldstændigt overblik over, hvad et nedbrud eller blot en mindre ændring af dataformat i et andet system vil medføre?
Folk med viden pensioneres
Der er en del systemer derude, som troligt er blevet udviklet og vedligeholdt af folk, der nærmer sig pensionsalderen. Hvad sker der med systemerne, når de går på pension?
Nyuddannede it-folk kender eksempelvis ikke til de mainframe-teknologier, som er det centrale fundament for mange fancy apps, det være sig mobilbank, Mobile Pay og andre finansielle apps.
Samtidig har it-branchen altid haft en forkærlighed for al ny teknologi, mens der rynkes lidt på næsen ad velafprøvet, men ældre teknologi.
Derfor er der prestige for både nyuddannede og ledere i at være involveret i et cloud-baseret projekt, der udvikler en blockchain-baseret løsning, hvori indgår containeriserede Docker-mikroservices som orkestreres med Kubernetes, mens IoT-devices indsamler data til en Hadoop-datalake, der anvendes til machine learning.
OK, mindre kan nok gøre det, men i realiteten kunne organisationens forretningsmæssige behov måske opfyldes af et mindre prestigefyldt website/administrativt system baseret på ældre teknologi?
Men det sker ikke, og værdifuld teknisk viden går tabt. Men det er ikke kun teknisk viden, det handler om. Som læseren formulerer det:
»Da man udviklede første generation af de administrative systemer, vidste kunden, hvilke regler de fulgte i den manuelle sagsbehandling. Det ved kunderne ikke længere – for dem, der ved det, er også på vej på pension. Der må findes mange yngre sagsbehandlere rundt omkring, som anvender it-systemerne uden at vide præcist, hvad systemet udfører. Hvordan skal de kunne specificere og teste et nyt system?«
Valget mellem modernisering og nyudvikling
Hvis et eksisterende systems tekniske gæld anses for så overvældende, at det vil være billigere at starte udviklingen af et helt nyt, hvordan sikres det så, at alle regler og særregler - samt undtagelser til reglerne og særreglerne - bliver implementeret korrekt i det nye system?
Her kan det blive nødvendigt at lave en ny kravspecifikation ved at gennemgå kildekoden for det gamle system, hvis der ikke findes en ordentlig dokumentation af reglerne i systemet.
Hvis man vælger at modernisere et eksisterende system, kræver det også en indsats, men det er noget, som læseren foretrækker:
»Hvis et eksisterende system ikke er helt håbløst, så vil man kunne genbruge komponenter – eventuelt pakket lidt pænere ind og kombineret på en ny måde. Men det forudsætter jo, at man har overblik over det gamle system. Så en løsningsmulighed er oprydning, konsolidering, dokumentation, forbedring af arkitekturen … og så kan man modernisere en del af systemet ad gangen. Det er betydelig mindre risikofyldt end big bang-projekter, hvor man smider det hele ud og starter forfra.«
Der er selvfølgelig andre faktorer, som har relevans, når valget mellem modernisering og nyudvikling skal træffes.
Version2 vil i den kommende tid i en række artikler se nærmere på det valg, og vi vil meget gerne høre om læsernes erfaringer i den forbindelse.
Har du nogle gode eller dårlige erfaringer, som du ønsker at dele – eventuelt anonymt – så kontakt gerne redaktionen på tip@version2.dk
Og som altid er debatten herunder også åben for input.
