Vad händer när den som kan systemet slutar?

“Han har jobbat här sedan 1996. Nästa år går han i pension. Vi vet att vi borde ha dokumenterat systemet. Men när skulle vi ha hunnit?”

Vi hör varianter av den meningen ganska ofta. Den handlar sällan om ett system i största allmänhet. Den handlar om ett särskilt system, en särskild person och en tidpunkt som länge känts avlägsen men som plötsligt står i kalendern.

Lars, låt oss kalla honom det, är 62 år. Han vet hur beräkningslogiken fungerar i ett system som började byggas i COBOL på 80-talet och sedan byggts vidare och anpassats i flera omgångar. Han vet varför en viss parameter har just det värdet. Han minns undantagen som aldrig skrevs ner, eftersom alla ändå visste hur det fungerade då. Han vet vilka integrationer man ska vara försiktig med och vilka delar av koden som ser enkla ut, men inte är det.

Och han vet att han slutar om femton månader.

När kunskapen försvinner före systemet

Många äldre system fungerar fortfarande bra. De gör sitt jobb, dag efter dag, och hanterar affärskritiska processer, beräkningar, integrationer och regelverk.

Problemet är inte alltid systemet i sig, utan att kunskapen runt det håller på att försvinna. De som kan systemen på djupet närmar sig pension, medan nya utvecklare utbildas i andra tekniker. Det som en gång var självklar kunskap finns i dag i gamla mejltrådar, muntliga överenskommelser, specialfall i produktion och minnet hos ett fåtal personer.

Systemet fortsätter fungera. Men förmågan att förändra det, felsöka det och anpassa det till nya krav blir svagare för varje år.

Den dolda kostnaden

Innan Lars går i pension kostar hans kunskap mer än hans lön. Det märks kanske inte på en egen rad i budgeten, men det märks i vardagen.

Nya initiativ bromsas eftersom någon måste “kolla med Lars först”. Migrationsplaner skjuts fram. Dokumentationsarbetet blir något man ska ta tag i senare. Och när något går fel finns det ett nummer man ringer.

Det är tryggt, på ett sätt. Men det är också en risk. Ett personberoende utan redundans gör organisationen långsammare och varje förändring lite mer osäker än den hade behövt vara.

Risken sitter inte bara i servern. Den sitter i en persons huvud.

Modernisering börjar med att minska beroendet

Ett naturligt svar är att försöka hitta någon ny. En konsult. En senior specialist. En ny Lars. Men även om ni hittar rätt teknisk kompetens räcker det sällan.

Det här handlar också om historik, verksamhetslogik och gamla beslut som aldrig dokumenterades. Om undantag som någon en gång löste snabbt och som sedan blev permanenta. Om integrationer som fungerar, men som ingen längre riktigt vågar röra.

Därför behöver modernisering av legacy-kod inte börja med att allt gammalt kastas ut och ersätts. Ett bättre första steg är ofta att förstå vad ni faktiskt har. Vilka delar är mest kritiska? Var finns de största personberoendena? Vilken kunskap finns bara hos Lars?

När den bilden finns går det att prioritera, skriva tester där risken är störst, dokumentera det som faktiskt används och bygga en väg framåt som inte kräver ett stort, riskfyllt språng.

Det handlar inte om att ersätta Lars. Det handlar om att ta vara på hans kunskap medan ni fortfarande kan, och se till att den börjar leva i koden, testerna och dokumentationen. Inte bara i honom.

En fråga att ställa nu

Vilket system skulle bli svårt att förvalta om er mest erfarna person försvann?

Om svaret är tydligt har ni redan hittat ett bra ställe att börja. Inte för att allt behöver moderniseras på en gång, utan för att kunskap som försvinner är svår att återskapa i efterhand.

Femton månader går fortare än man tror.

Läs vidare: Så kartlägger ni ett system som bara finns i huvudet på en person.