Modernisering

Att systemet är gammalt är inget skäl i sig. Ful kod som sällan ändras och gör sitt jobb kan få vara kvar. Skälen är andra: en ändring verksamheten vill ha går inte att göra utan att bryta något annat, ett beroende får inte längre säkerhetsuppdateringar, eller en enda person förstår den del allt annat hänger på. Då är det inte åldern som kostar.

Vad behöver ändras, och vad kan vara kvar?

Innan något byggs om behöver varje del ett av fyra svar: behåll, reparera på plats, ersätt eller avveckla. Det svaret kan varken vi eller koden ge. Det kräver att de som använder systemet får frågan vilka beteenden som fortfarande spelar roll. Frestelsen är att göra allt gammalt till krav på det nya. Då bygger du om även det som borde ha försvunnit, och tar kostnaden med dig.

Själva bytet gör vi hellre en avgränsad del i taget, med resten i drift bredvid, än som en omskrivning som ska vara klar innan någon får använda den. Hur det går till står under legacy-system, och följer historiken med börjar det med en provkörning.

Var vi börjar

Ibland med en kodgranskning, när du behöver en oberoende bild av vad systemet kostar att äga och var riskerna sitter. Men en granskning leder inte automatiskt till en omskrivning, och alla moderniseringar behöver inte börja med en. Vet du redan vilken ändring som fastnat börjar vi där.

Ta med den ändringen: vad du ville göra och varför det inte gick. Ta med det du vet om beroendena: vilka system som läser ur samma databas, vilka jobb som körs på natten. Och ge oss tillgång till dem som använder systemet. Målet med ett första samtal är ett prioriterat första beslut: vad som ändras först, vad som får vänta och vad som kan tas bort. Inte en plan för att byta ut allt. Hör av dig, så tar vi det därifrån.