Pressmeddelande -

​Vägen ut ur legacy-djungeln

Legacy-system. Detta sammanvävda virrvarr av kod, som tiden har gjort operationellt instabilt, är en potentiell bomb under många verksamheter. Alla vet att något ska göras men konsekvenserna kan tyckas så oöverskådliga att det kan vara svårt att veta var man ska börja.

Joost Visser är teknisk direktör hos Software Improvement Group (SIG) och professor i Large-scale Software Systems på Radboud University. Han och SIG har rådgivit hundratals verksamheter om deras legacy-system och hjälpt dem med att navigera säkert genom konverteringar och avvecklingar. Enligt Joost Visser är det en farbar väg ut ur legacy-djungeln, men stigen är snäv och skiljer sig åt från system till system.

Det börjar hos din ledning

Det är frestande att tro att legacy-problem uteslutande är en sak för it-avdelningen. Men innan it-avdelningen överhuvudtaget kan börja med deras uppröjningsarbete ska ledningen identifiera vilka strategiska mål som är hotade av legacy-system, och därefter är det ledningens uppgift att ge it-avdelningen full uppbackning när de påbörjar uppdraget med att konfrontera utmaningen.

Theis Eichel, som är skandinavisk direktör för Software Improvement Group (SIG), menar att när ledningen har tagit ställning till de strategiska målen, och it-avdelningen har skapat sig en gedigen överblick, så kan man börja fundera över vilken väg man ska ta ut ur djungeln.

– Samtidigt har it-avdelningen två uppgifter. Först och främst ska de skapa en fullständig överblick över verksamhetens it-landskap, inklusive detaljerade tekniska fotspår och olika systems beroende av varandra. Därefter ska de kartlägga ekonomi angående resurser, ROI och risker i verksamhetens legacy-system, förklarar Theis Eichel.

Avkastning och risker

Vägen ut ur legacy-djungeln är en stig som balanserar på en knivsegg mellan risker och avkastning. Därför är det viktigt att skapa sig en bild av situationen som är så precis som det är möjligt.

– Varje förändring innebär en risk. Och risken stiger i takt med kodens komplexitet, och de inbördes beroenderelationer som finns mellan olika delar av koden i systemet. Samtidigt utgör varje ändring en investering med en potentiell möjlighet till avkastning i form av de framtida fördelar som kommer av ändringen. Det kan handla om att verksamhetens styrförmåga förbättras, att operationella omkostnader och risker reduceras eller helt enkelt om att leva upp till gällande lagstiftning, förklarar Theis.

När både avkastning och risk är osäkra variabler, så är utmaningen att kvalificera varje enskild ändring, så att de kan hållas upp och jämföras. När risk och avkastning för varje potentiell ändring är kvalificerad kan de delas upp i fyra faser beroende på deras potentiella avkastning och den förväntade risken.

De fyra faser som leder ut ur legacy-djungeln

När alla legacy-system i verksamheten är uppdelade efter risk och avkastning kan vi dra machete-kniven och börja hugga oss en väg ut ur djungeln. Theis förklarar:

– Vi börjar alltid med att öva oss. Vi börjar med de system som har låg risk och låg avkastning. Syftet är att skaffa erfarenhet. Det är också i denna fas som vi bygger upp våra processer och tekniska lösningar. När vi är färdiga med första fasen förflyttar vi oss till system med hög avkastning, men fortfarande med låg risk. Här kan vi börja definiera processer och team. Därefter kan vi ta all den erfarenhet vi har samlat på oss och bege oss in i den tredje fasen, där både avkastningen och risken är hög. I denna fas är det därför viktigt att i högre grad stämma av användarnas förväntningar; den ökade risken innebär att det kommer att uppstå fler fel.

Efter den tredje fasen är det frestande att stanna. Varför ödsla tid och resurser på system med låg avkastning och hög risk? Men man ska inte vila på lagrarna ännu, förklarar Theis Eichel:

– Det är viktigt att avsluta uppgiften. Om ni hoppar över den fjärde fasen så bäddar ni för att legacy-systemen kan växa, och skapa problemen i framtiden. Det ni tjänar på den fjärde fasen är att tavlan blir ren, inte att själva uppgiften i sig blir löst, avslutar Theis Eichel.

Läs mer om hur du får bukt med verksamhetens legacy-system i vår e-bok: ”Escape From Legacy Mountain” eller läs Joost Vissers artikel: ”A 4-Step Path to Escape from Legacy Mountain” 

Ämnen

  • Ekonomi, finans

SIG (Software Improvement Group) löser och förebygger problem med programvaror hos verksamheter genom att skapa transparens i deras programvaruinfrastruktur. Genom väldokumenterade metoder och årtionden av expertis hjälper vi verksamheter att grundläggande förbättra och förstärka säkerheten och effektiviteten i deras enterprise-programvaror – i alla led av verksamheten.

SIG utför riskvärderingar och portfolioanalyser av verksamhetens programvaror, riskvärderingar av programvaruprojekt, riskvärderingar av programvarusäkerhet och certifiering av programvaruunderhåll (i samarbete med TÜViT).

SIG har huvudkvarter i Amsterdam och har 150 anställda i Danmark, Belgien, Tyskland och Holland, varifrån vi betjänar våra kunder i Europa, USA och Asien. SIG grundades år 2000.

Som de enda i världen är SIG certifierat av TÜViT. (https://www.tuvit.de/en/home/) för Trusted Product Maintainability.

Kontakter

Theis Eichel

Presskontakt Adm. Direktør +45 28 60 22 06