Et centralt spørgsmål: Skal vi rydde op i it-systemet eller udvikle et nyt?

Mangelfuld dokumentation, ældre teknologier og flere hundredetusinder liniers kode, som nogle steder er uigennemskuelig. Hvornår er det klogt at skrotte det gamle og starte helt forfra med udvikling af et nyt system?

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Claus Bobjerg Juul

Udvikleren skal i gang med at dokumentere systemet lige meget hvad.

Der skal dokumentation til hvis der købes et nyt system der så måske skal tilpasses.

Hvordan vil det være muligt at erstatte det gamle system med et nyt, hvis ingen ved hvad det gamle system gør og kan.

I arbejdet med dokumentation vil viksomheden/udvikleren helt sikkert opnå en viden som gør ham/hende/dem i stand til at træffe et godt valg i forhold til at enten bibeholde det gamle, udvikle nyt eller købe nyt.

  • 5
  • 0
Kjeld Flarup Christensen

Jeg har prøvet at sætte et nyt system i drift, og så alligevel ikke.
Grundlæggende skiftede vi web interface og gik fra ASP og windows til PHP og Linux.

Men database strukturen var stortset den samme og de to systemer kiggede da også ned i den samme database.

Da vi startede ud med det nye interface var ambitionerne høje om en state of art data database. Problemet er at når man skifter database, så står man overfor et point of no return. Så vi kom ned på jorden igen, og modellerede et mellemlag, som præsenterede data fornuftigt, men stadigt brugte de gamle strukturer.

Så et vigtigt sted at bruge sine kræfter er altid i data design og doumentation.

  • 2
  • 0
René Nielsen

De ”kravspecifikationer” jeg har set, er over en bred kam renset for de fordele et nyt IT-system kunne give.

Jeg vil helt uvidenskabelig påstå at hovedproblemet med ”kravspecifikationer” er at de 99% vedkommende i detaljer beskriver det ”nye system som klon af det gamle system” og derfor har jeg vanskeligt ved at se fordelene i en ”opgradering” udover at hardwaren løber hurtigere og at man kan komme over på en nyere platform.

Men hvis selve indholdet af ”løsningen”, er uændret, hvorfor så bruge penge på et nyt system?

  • 5
  • 0
Niels Henriksen

Jeg sidder selv og har arbejdet på et system i 5 år. Jeg kan se de fejl der er foretaget den gang og hvad der kan optimeres nu, men problemet er at sætte penge og tid af til at lave en ny version.

Med tiden ændre teknologien sig også men tit er det jo under motorhjelmen at ændringerne findes. Problemet er når det ikke synligt giver forbedringer for slutbrugeren.

  • 0
  • 0
Jørgen Hansen

Når der skal besluttes mellem nyt eller gammelt - er ejerforholdene vigtige at tage med i ligningen. De mange kapitalfondsovertagelser medfører at der skal vrides mange flere kroner og bonuser ud af de ældre systemer. Til det formål kommer de nye ejere ofte med en hær fra den talende klasse, da kommunikation til markedet er meget vigtigere end de tekniske løsninger og vedligehold. Det medfører på sigt at systemerne sander til, og mange af de ældre vidende teknikere fremskynder pensionen. Det kan selv de bedste agile intentioner ikke ændre på.

  • 4
  • 0
Flemming Riis

Desværre er rigtig mange lad os bygge nyt ramt at First In Never Out

Så når version 2 kommer af version 1 , forbliver v1 i drift , har set op til 4 generation af samme system online fordi man prioriterede resourcer til at bygge nye men ikke lige rydde op når man var færdig

  • 0
  • 0
Peter Harboe

Det er ejedommeligt at se denne diskussion i et/en moderne samfund/virksomhed, idet det (efter min mening) er vigtigt vide "Hvem gør hvad" (læs: har ansvaret).
I en moderne virksomhed er det vigtigt at vide, at det er systemejeren der har ansvaret, indeholdt alt hvad dertil kommer (udvikling, risikovurdering, test, dokumentation (ikke for koden, arkitektur og sammenhænge) m.m.)
Udviklere har altid og vil altid være presset (ikke de eneste i forretningen), men det er systemejer der så skal tage stilling til, hvad udviklerens tid skal bruges til.
Udvikling/nyudvikling eller dokumentation.
Jeg er ikke i tvivl om svaret.
I mange tilfælde ligger kosten (læs: tiden) også i IT afdelingen.
Så længe den ligger der, så tænker afdelingerne ikke i væsentligt grad på ovenstående.
Se hvis man nu lagde kosten (hvad end det omfatter) over til de enkelte afdelinger (systemejere), og deres budget ville blive påvirket af det de nu valgte at lægge vægt på, så er jeg sikker på, at der langt hen ad vejen vil ske andet end det der typisk gør idag.

  • 1
  • 0
Klavs Klavsen

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, særregler - samt undtagelser til reglerne og særreglerne - bliver implementeret korrekt i det nye system?

Det er jo så her, man skriver TESTS - der tester at ting også fungerer som de skal. Dermed fungerer disse tests også som dokumentation af hvordan ting BURDE virke - og man kan med langt større sindsro forsøge at modernisere dele af ens system af gangen - da et godt test system fanger problemer.
Her vil man så oftest måtte udvikle "time-travel" support - så man hurtigt kan teste, hvad der sker "på x tid" osv... Men det er det hele værd.

  • 2
  • 0
Povl H. Pedersen

Ofte er opgradering den forkerte vej.
Se på ERP systemer, her er et væsentligt mål med udskiftningen at få ændret (kaldet moderniseret) sine arbejdsprocesser. Og i samme omgang høste en række rationaliseringsgevinster. Man tilpasser sin organisation til det nye mindset.

Så der er meget mere i det end bare at opgradere et system, udskiftning af større systemer er et forandringsledelsesprojekt.

Jeg er delvis enig med den person der skrev at kravspecs ofte bliver en klon af det gamle system. Men det er IKKE det en virksomhed ønsker. De ønsker noget der er bedre når de skifter.

Interne legacy systemer har ofte en masse funktionalitet som et nyt system ikke har. Fordi virksomheden har fået en masse viden og udviklet videre på det i mange år. Nye systemer har den ulempe, at de også er blevet fast moving, fast changing. Så der bliver man nødt til at være med i forandringsprojektet, for konsulenthusene kan ikke finde dyre drenge der vil lave det gamle fra sidste år.

  • 1
  • 0
Ole Laursen

Medmindre man skifter platform, programmeringssprog eller i virkeligheden vil noget helt andet, så gå i gang med at rydde op. Så kan man dele risikoen op i små bidder. Start med det er værst.

Det peger også i retning af den rigtige kultur - her i huset passer vi på det vi laver, vi laver ikke skrald.

Det er et laaaangt sejt træk, og kræver buy-in.

Her er et godt gammelt svar fra Joel Spolsky

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-par...

  • 4
  • 0
Anders Andersen

Svaret kan ligge et sted midt imellem alt nyt og forbedre gammelt.

Det kan være tillokkende at lave alt nyt. Det tager bare sin tid, og mens man gør det bidrager man ikke til forretningen.
De, der lavede det gamle system er jo "de dygtigste" --> de skal også lave det nye system, jo så er problemet bare hvor nyt det bliver.

Alternativet at bevare de gode gamle cobol programmer, og bare forbedre. Nja, udviklere bliver sværer at skaffe. Så det er måske heller ikke den fedeste ide.

Processiden...
Man kan starte et andet sted. Man kan dokumentere processerne med en fornuftig processmoter, først som dokumentation og i næste stadie med BPR lader man det nye system overtage processer 'en for 'en samtidig med at man tilfører forretningsværdi ved at den aktuelle nye proces laver en lille forbedring.

Data siden...
Datamodellen i det eksisterende system vil alt andet lige svare til de krav der var en gang. Ved at anvende eventSourc ing vil man kunne bygge nye virkeligheder ved siden af de eksisterende systemer og udfase områder af systemerne stille og roligt.

  • 0
  • 0
Niels Grove-Rasmussen

Enig. Undervejs er det også fastholde hvorfor systemer gør som det gør. Og hvad der undervejs er fravalgt, igen med motivationen for valget. Det er ikke bare belejligt for udvikleren der genbesøger et komponent efter 42 dage og skal have genopfrisket hukommelsen, men også for hurtigere og mere præcist kunne diskutere nye idéer i forhold til det eksisterende system.

  • 0
  • 0
Per Dalgas Jakobsen

Som yngre, havde jeg næsten altid den holdning at <some-system> var noget skrammel, og burde skiftes helt ud. Nu tager jeg det som en udfordring: "hvis jeg kan forestå at rette op på <some-other-system>, så kan jeg alt" :-)

Erkendelser: Jeg kunne ikke på egen hånd lave et nyt system med dokumentation, plus alt det andet der følger med. Det gamle system holder faktisk noget i drift i dag, omend med en del support og meget besværlige udvikling.

Hvad så?:

1) Find ud af hvor kodekvaliten skal forbedres: Kodestil, dubleret kode, cyklomatisk kompleksitet, coverage, etc. Og mål den eksisterende kode. Lav commit-hooks så ændrede kode-filer ikke accepteres hvis de har dårligere metrikker (op til et vist niveau). Start tidsserier med metrikkerne så man senere kan se og henvise til effekten.

2) Etablér infrastruktur til automatiserede tests. - Det skal være nemt for de andre at begynde at lave tests. Og teamet skal hjælpes til at huske at lave tests, f.eks. ved at hjælpe dem til at få startet på deres næste supportsag.

3) Ret kun i kode, hvorpå der er en support-sag (så er der nogen til at betale for rettelserne).

4) Er der nogle gennemgående problemer med den eksisterende kode, så lav softwaremønstre til at løse de pågældende problemer, og stil dem til rådighed for dem der får fat i problematisk kode, så de ved hvordan den type problemer skal løses. Start f.eks. med den type problemer der er flest supportsager på.

Og så ellers bare igang med at vedligeholde, vejlede, forbedre, og jævnligt forbedre selve processen. Et +30 år +1MSLOC system tog under to år at forbedre fra "håbløst" til "ikke så tosset endda".

Tanken om den "ideelle arkitektur" kan man jo passende bruge som guide for de ændringer man planlægger.

Bare det at teamet kan mærke at systemet løbende bliver bedre, giver ekstra motivation, energi og ikke mindst arbejdsglæde.

  • 1
  • 0
Claus Nedergaard Jacobsen

Som gammel softwareudvikler (25+ år) ved jeg alt om, hvor træls det er at skulle videreudvikle på gamle skrammelsystemer, hvor de oprindelige udviklere er ovre alle bjerge. Men her i tråden taler vi om "dokumentation", "arkitektur" og "kodekvalitet". Det er midler, ikke mål, og dem der skal bevilge tid og penge fatter ikke, hvad det er for problemer, de skal udbedre.

Men det er ret enkelt. Konsekvenserne er:
* Det bliver dyrere og dyrere at foretage rettelser
* Personafhængigheden øges og øges
* Fejlhyppigheden i releases stiger og stiger
* Risiko for sikkerhedsbrist stiger (fx. overtrædelse af persondataloven)

De ord, forstår forretningen faktisk, for det er også deres problem.

Jeg mener, at der allerede ved de første overspringshandlinger ("springe over, hvor gærdet er lavest aht. deadline el.a.) skal gøres opmærksom på konsekvenserne - og det skal ske på skrift. Så har man noget at holde forretningen oppe på, når konsekvenserne bliver synlige.

EU GDPR modellen med at gøre topledelsen ansvarlig for brud på loven er et godt skridt i retning af at gøre forretningen ansvarlig for konsekvenser af lav kvalitet.

  • 2
  • 0
Egon Sørensen

Jeg ser det som symptombehandling vs. årsagsbehandling. Det kræver mod og mandshjerte at ændre!

De fleste komplekse IT systemer er ikke lavet af én person, men af en stor gruppe bestående af forskellige personer/faggrupper. Personer ofte med MEGET forskellige synspunkter, og værdier.

Spørgsmålet om det kan svare sig at lave et nyt system, eller opdatere/vedligeholde, skal komme fra 'toppen af pyramiden' og ikke bunden som jeg ser det her. Det er i øvrigt ikke den basale behovspyramide jeg mener - men pengepyramiden (det er herfra den 'gyldne ledelse' uddelegerer penge og ressourcer) der bestemmer.

"Vi skal løfte i samlet flok" lyder det ofte oppefra, hvorefter dem med pengeansvaret er forduftet.
Ansvar belønnes, tror jeg nok. I mellemtiden kan det anbefales herfra at kigge i pungen og vurdere om det kan betale sig at skifte pind, eller om det er tid til at der skal skiftes platform/moduler/.kode

Penge har magt, og mange er villige til at sælge sig selv for hån/ører.
En person med denne indstilling burde være udelukket af enhver beslutningsproces pga. inkompetence - men, det er desværre ofte set at grådighed og kammateri er årsagen til de skrantede systemer - og naturligvis prøver de være med i al evighed, de har jo magten.
At få overblik over det hele - tjaaa. Hvem bestemmer, betaler og belønnes?

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize