Systemet ingen vågar röra.

Det som gör äldre system svåra att hantera är sällan tekniken i sig. Det är kunskapen om dem — eller bristen på den. Systemen byggdes av personer som sedan länge lämnat verksamheten. Affärslogiken anpassades löpande under år utan att dokumentationen hängde med. Integrationerna mot andra system gjordes när det behövdes, utan att någon ritade en helhetsbild.

Kvar finns ett system som kör — men där förståelsen för varför det kör som det gör är koncentrerad till en eller två personers erfarenhet. Och den erfarenheten är inte nedskriven.

Det skapar en situation som de flesta IT-chefer känner igen: man gör det minsta möjliga för att undvika att röra kärnan. Varje förändring riskerar att påverka något man inte förstår fullt ut. Så man undviker, lagar, lägger till — och det gamla systemet växer vidare i periferin av vad som egentligen är rimligt att förvalta.

Det som är lätt att missa i det här samtalet är att affärslogiken i ett gammalt system faktiskt är en tillgång. Den är sällan dokumenterad och sällan elegant — men den representerar år av beslut om hur verksamheten fungerar. Regler som skapades av goda anledningar. Undantag som hanterar verkliga situationer. Beräkningar som stämmer med hur branschen fungerar.

Att "bara kasta det och börja om" ignorerar det värdet. Det är möjligt i teorin, men i praktiken innebär det att man behöver ta reda på vad systemet faktiskt gör — vilket är exakt samma arbete som att förstå det man redan har, fast utan systemet som referens.

Det är en av anledningarna till att modernisering av äldre system kräver en annan approach än ett nybygge. Målet är att bevara och synliggöra det värde som finns, inte att ersätta det med ett modernare alternativ som gör ungefär samma sak.

Returpack stod inför en version av det här när plattformen deras befintliga system byggde på nådde slutet av sin supportcykel. Det system som hanterade informationsflödena i det svenska pantsystemet — mer än 1,6 miljarder enheter per år — kunde inte bara köras vidare i oändlighet på en plattform som Microsoft inte längre underhöll.

Utmaningen var att förstå vad systemet faktiskt gjorde, koda in den affärslogiken i den nya lösningen, och göra det på ett sätt som var förvaltningsbart framåt. Inte att börja om och hoppas att man fick med sig allt viktiga — utan att metodiskt arbeta sig igenom befintlig kod, identifiera logiken och bygga upp något nytt kring den.

Det är ett annat slags arbete än att bygga något från scratch. Det kräver tålamod och en förståelse för att komplexiteten inte är ett misstag — den speglar en komplicerad verksamhet.

En sak som faktiskt har förändrats de senaste åren är möjligheten att analysera befintlig kod snabbare. AI-verktyg som Copilot och liknande kan hjälpa till att förstå vad en kodbas gör — identifiera beroenden, förklara logik, föreslå hur moduler kan separeras och refaktoriseras. Det som tog månader av kartläggningsarbete kan nu göras på kortare tid.

Det förändrar inte komplexiteten i sig. Och det ändrar inte det faktum att besluten om vad som ska bevaras, vad som ska byggas om och vad som ska fasas ut fortfarande kräver djup förståelse av verksamheten. Men det gör att det initiala analysarbetet är mer tillgängligt än det var för fem år sedan.

Det bästa sättet att börja är att vara ärlig om riskbilden. Hur många personer bär förståelsen för det här systemet? Vad händer om de slutar eller är borta? Vilka delar av systemet har förändrats senast, och av vem?

De svaren ger en bild av hur akut situationen egentligen är. Ibland är den hanterbar och modernisering kan planeras i lugn och ro. Ibland är det mer bråttom än organisationen har insett.

I båda fallen är det bättre att ha den bilden tydlig än att fortsätta undvika frågan. Tre decennier av att arbeta med äldre system har lärt oss att de sällan blir enklare med tiden.