Ju fler år man samlar på sig i IT-branschen, desto större är risken att man förr eller senare hamnar i ett system som utan tvekan kan stämplas som legacy. Som tekniker är det lätt att fastna i lunken där varje liten ändring tar längre och längre tid. Kanske är du rentav den enda utvecklaren med både mod och mandat att röra koden?
Inga ingenjörer behöver längre hålla systemet vid liv.
Om systemet är tillräckligt bra och vi egentligen inte behöver några ändringar är den självklara strategin att frysa det. Rör ingenting. Vi fortsätter använda systemet, vi bara låtsas att det är färdigt.
Riskerna är uppenbara. Fördelen är lika uppenbar: det kostar verksamheten noll kronor. Om man bortser från eventuella säkerhetshål, vill säga. Då kan notan bli desto saftigare.
Om verksamheten klarar sig utan systemet och kostnaderna överstiger vad vi är beredda att betala, då är den självklara strategin att lägga ner. Släng det. Ingen mer utveckling, ingen mer användning. Begravning utan blommor.
Ett vanligt skäl att avveckla är att det finns ett ersättningssystem. Det innebär i praktiken att värdet systemet levererar är mindre än kostnaden för fortsatt underhåll.
En snarlik variant är att avveckla under en längre period, för att mjuka upp övergången till ett nytt system som ännu inte täcker alla användningsfall.
För oss som varit med och byggt systemet kan strategi 1 eller 2 kännas som ett slag i magen. Vi har suttit med kunderna och försökt leverera det bästa system budgeten tillåter. Vi har kanske jobbat sena kvällar med akuta kundproblem och hyllats som hjältar? Och nu döms vår surt förvärvade expertis ut som onödig. Kanske gick det extra fort utför för att vi aldrig lyckades få kunden att förstå att teknisk skuld också behöver en budget? Utvecklare som investerat hårt i gammal infrastruktur eller ett gammalt språk kan få det tufft på arbetsmarknaden. Och som kund kanske du trodde att du förhandlat fram ett riktigt bra pris per funktion, bara för att långt senare sitta med ett system som knappt någon vågar röra.
Kör på! Fortsätt betala för underhåll, nya funktioner och nya eller ändrade krav.
Om det finns lite budget och systemet är sådär lagom litet, då är det lätt att trilla i fällan…
Den här fällan är ingen ovanlig strategi. Minimalt underhåll, men ändå nya krav och funktioner i en strid ström.
Jag har själv suttit i team som jobbat så här, med en gnagande känsla av uppgivenhet, eftersom ingen verkar lyssna när vi varnar för att det bara blir värre (och sedan får leverantören skulden).
Som kund behöver du kunna lyssna på vad dina tekniker faktiskt säger. Kanske tar det månader för nya utvecklare att komma in i koden. Kanske finns det bara en enda person som klarar av merparten av jobbet…
Strategin bygger på att det ännu inte är för sent att betala av skulden. Men var inte för säker: om bussfaktorn är 1 kan du bli intvingad i en annan strategi, fortare än du anar.
En populär idé bland utvecklare är att överge den gamla koden och skriva om alltihop från grunden. The big rewrite. Släng ut det gamla och börja om på ett blankt papper. Att läsa vad någon annan har skrivit tar ju tid och energi.
Strategin brukar vara mindre populär bland affärsfolk, av det enkla skälet att den kostar tid och pengar. Har du ett legacysystem kostar det oftast ungefär lika mycket att bygga nytt som det kostade att bygga originalet.
Ibland finns det inget kvar att rädda, men du behöver fortfarande det systemet gör. Då är du helt enkelt tvingad hit.
I andra fall kan strategin fungera riktigt bra för små och medelstora systemkomponenter. Den stora vinsten är att du kan ompröva kraven och stöpa om arkitekturen betydligt mer radikalt än vid refaktorering. Kanske finns det ingen igenkännbar domänlogik alls, eller så är den skriven på ett sätt som gör den, låt oss säga, utmanande att läsa.
Men säg att det faktiskt finns bra delar i systemet. Att vi tekniker gjort ett hyfsat jobb och levererat åtminstone några bitar som går att porta till ett icke-legacysystem. Då kan vi plocka russinen ur kakan: ta med det goda och lämna det unkna. Vi återvinner kod och krav in i ett uppdaterat system.
Strategin passar bra när det finns någorlunda ren domänlogik, medan exempelvis frontend eller infrastruktur bygger på föråldrad teknik. Se ports and adapters, hexagonal arkitektur, clean architecture, vertical slice…
Ibland går det att refaktorera ett legacysystem till ett icke-legacysystem. Det är inte alltid möjligt. Du behöver tillräckligt skickliga ingenjörer. Du behöver verifiera att det ryms i budgeten jämfört med att skriva nytt. Det är ett svårt och otacksamt jobb. Men jag har sett strategin lyckas, med rätt team.
Som kund innebär det att buggfixar och nya funktioner tar längre tid under en övergångsperiod. Man saktar ner för att kunna köra fortare på sikt.
Vi behöver prata med varandra om kortsiktiga avvägningar och långsiktiga konsekvenser. Den som identifierar riskerna tidigt hinner lägga undan pengar till renovering eller ersättning.
Är du osäker på vilken strategi som passar ert system? Vi erbjuder en kostnadsfri migreringsbedömning. Läs mer om hur vi moderniserar och migrerar legacysystem.
Oskar Gewalli
Vill ni frigöra tid, förbättra arbetssätt eller göra vardagen enklare för era kunder och medarbetare? Berätta om er utmaning, så pratar vi om hur digitala lösningar kan hjälpa er vidare.
