Vad är ett legacy-system?

Legacy-system är ett uttryck som ofta sägs med en suck. Det förknippas med dammiga, urgamla system som borde ha pensionerats för länge sedan. Men den bilden missar poängen, och kan leda till fel beslut. Här är vad ett legacy-system faktiskt är, hur du känner igen det och vad du kan göra åt det.

Legacy betyder svårförändrat, inte gammalt

Den vanligaste missuppfattningen är att legacy är synonymt med gammalt. Det stämmer inte. Ett legacy-system är ett system som fortfarande bär verksamheten – det gör nytta varje dag – men som byggts på teknik eller kunskap som blivit svår att underhålla och förändra.

Åldern är underordnad. Ett tjugo år gammalt system som skötts väl, dokumenterats och hållits vid liv behöver inte vara legacy. Samtidigt kan ett system som byggdes för fem år sedan redan vara legacy om det gjordes rörigt, om personerna som byggde det är borta och om ingen längre vågar röra det. Det är förändringsbarheten som avgör, inte antalet år.

Med den definitionen blir legacy en fråga om risk och arbetsförmåga, inte om teknikens födelseår.

Varningssignalerna

Legacy smyger sig oftast på. Det finns sällan en dag då ett system “blir” legacy, men det finns tydliga tecken på att det har hänt:

• En person kan systemet. Kunskapen sitter i huvudet på en enda medarbetare, och alla vet att inget får hända just den personen. Det är kanske den starkaste signalen av alla.
• Ingen vågar uppgradera. Varje förslag att uppdatera en komponent eller ändra något möts av oro för vad som kan gå sönder, så man låter bli – och släpar på gammal teknik och osäkra hål.
• Dokumentationen saknas eller stämmer inte. Det som en gång skrevs ned är inaktuellt, och sanningen finns bara i koden och i minnet hos några få.
• Allt tar oproportionerligt lång tid. Även små ändringar blir dyra och långsamma, eftersom ingen riktigt överblickar konsekvenserna.

Känner du igen fler än ett av dessa, har ni med stor sannolikhet ett legacy-system – oavsett hur nytt det känns.

Ett konkret scenario

Ett bolag driver sin orderhantering i ett system som byggdes internt för åtta år sedan. Det fungerar, men bara en av de ursprungliga utvecklarna är kvar, och det är hen som lagar allt när det krånglar. Ingen dokumentation finns värd namnet. När hen tar ut en längre ledighet vågar företaget knappt röra systemet. En ny integration som borde ta två veckor drar ut på månader, eftersom ingen annan förstår hur delarna hänger ihop.

Systemet är inte gammalt i år räknat, men det är i allra högsta grad legacy: verksamheten hänger på något ingen längre behärskar, och rädslan för att röra det bromsar affären.

Tre vägar framåt

När ni väl identifierat ett legacy-system finns i grunden tre strategier, med olika risk och kostnad:

• Kapsla in. Låt systemet vara kvar, men bygg ett skyddande lager runt det så att nya delar kan kopplas på utan att röra kärnan. Snabbt och lågrisk, men löser inte grundproblemet.
• Modernisera stegvis. Byt ut en del i taget medan systemet fortsätter köra, tills det gamla successivt ersatts. Tar längre tid men håller risken låg och verksamheten igång.
• Ersätta. Bygg ett nytt system och gå över. Ger en ren start men är den mest riskfyllda och kostsamma vägen, särskilt om allt ska bytas på en gång.

Vilken väg som är rätt beror på hur affärskritiskt systemet är, hur stor risken är och vad budgeten tillåter. För det mesta som verkligen bär verksamheten är stegvis modernisering den tryggaste linjen.

Så tar du nästa steg

Börja med en ärlig kartläggning: vad hänger på systemet, vem kan det, vad händer om det faller? Den bilden avgör hur bråttom det är och vilken väg som passar. Vill ni ha hjälp att bedöma ett arvssystem och välja rätt strategi, gör vi på Weapp gärna genomlysningen tillsammans innan ni binder upp er vid en väg.