Bygga om systemet eller vidareutveckla det?

När ett system börjar skava dyker alltid samma fråga upp: ska vi skriva om alltihop från grunden eller fortsätta bygga på det vi har? Få tekniska beslut är så känsloladdade. Båda lägren har goda argument – och båda har förutsägbara blinda fläckar. Här är resonemanget som hjälper dig fatta beslutet på fakta i stället för frustration.

Därför lockar en total omskrivning

Utvecklare som arbetar i en gammal kodbas ser dess sämsta sidor varje dag: rörig struktur, föråldrade beroenden, enkla ändringar som tar veckor. Tanken på att börja om med ren arkitektur och modern teknik är genuint lockande.

Men var vaksam på jämförelsen som görs. Den som föreslår en omskrivning ställer ett verkligt system, med alla dess ärr, mot ett tänkt system som ännu inte mött verkligheten. Det nya ser alltid bättre ut på whiteboarden än det gamla gör i produktion.

Därför underskattas omskrivningar systematiskt

Två mekanismer gör att omskrivningar nästan alltid blir större än planerat.

Dold affärslogik. Ett system som körts i tio år har samlat tusentals små beslut: specialregler för en viss kundtyp, hantering av udda datumfall, undantag som lades till efter en incident. Det mesta är odokumenterat och syns bara i koden. Den nya versionen måste återskapa allt detta för att verksamheten ska fungera, men i kalkylen räknas oftast bara funktionerna som syns på ytan.

Andrasystemseffekten. När teamet äntligen får bygga nytt vill man rätta alla gamla misstag och lägga till allt man saknat – samtidigt. Version två blir därför regelmässigt mer ambitiös än någon egentligen beställt: större scope, längre projekt, högre risk.

Ovanpå det kommer dubbelarbetet. Verksamheten kan sällan frysa utvecklingen i ett eller två år, så varje ny funktion måste byggas i både det gamla och det nya systemet – annars är det nya inaktuellt redan vid lansering.

Stegvis modernisering är rätt utgångspunkt

För de flesta system är grundrekommendationen därför att vidareutveckla och modernisera stegvis: förbättra koden inifrån, byt ut den mest problematiska delen först och låt resten leva vidare bakom stabila gränssnitt.

• Värdet kommer löpande. Varje utbytt del förbättrar vardagen direkt, i stället för att allt värde ligger i slutet av ett flerårigt projekt.
• Risken är avgränsad. Går ett steg fel påverkas en del av systemet – inte hela verksamheten på en gång.
• Kursen kan ändras. Prioriteringarna får justeras mellan etapperna, allteftersom verksamheten lär sig vad som ger effekt.
• Affärslogiken bevaras. Den dolda logiken flyttas bit för bit och verifieras mot det gamla systemets beteende, i stället för att återuppfinnas i ett svep.

När en total omskrivning faktiskt är motiverad

Det finns lägen där stegvis modernisering inte räcker. De är färre än man tror, men de är verkliga:

Uppfyller systemet ett eller flera av kriterierna är en omskrivning rimlig att utreda på allvar. Gör den ändå så begränsad som möjligt: återskapa det som faktiskt används, inte allt som någonsin byggts.

Bias-varningen gäller åt båda håll

Omskrivningsivern är den vanligaste fällan, men motsatsen finns också. Den som investerat år i ett system värjer sig gärna mot tanken att det spelat ut sin roll – och så lappas det vidare långt efter att kalkylen slutat gå ihop. Om underhållet äter större delen av utvecklingsbudgeten, om varje release kräver manuell akrobatik och om ingen vågar röra vissa delar av koden, då är “vi fortsätter som vanligt” inte det trygga valet. Det är bara det tysta.

Så fattar du beslutet i praktiken

Ta ett konkret exempel: ett grossistbolag med ett ordersystem byggt 2012. Systemet fungerar, men plattformen närmar sig slutet av sin livscykel och två nyckelutvecklare närmar sig pension. I stället för att välja mellan “behåll allt” och “skriv om allt” kartlägger bolaget systemet i delar. Integrationerna flyttas först till ett modernt mellanlager, därefter byts kundportalen, och kärnan – prislogiken som fungerar – får leva kvar bakom ett stabilt API tills även den kan ersättas.

Resultatet är en plan där varje etapp har egen budget, eget värde och en punkt där man kan pausa utan att stå med ett halvfärdigt bygge. Det är så du tar dig ur ett skavande system utan att satsa allt på ett kort.

Vill du ha en second opinion på ert vägval? Vi på Weapp gör den här typen av teknisk kartläggning som en del av våra tjänster – hör av dig så tittar vi på förutsättningarna tillsammans.