Bygge om systemet eller videreutvikle det?

Når et system begynner å skave, dukker alltid det samme spørsmålet opp: Skal vi skrive om alt fra bunnen av eller fortsette å bygge på det vi har? Få tekniske beslutninger er så følelsesladde. Begge leirer har gode argumenter, og begge har forutsigbare blindsoner. Her er resonnementet som hjelper deg å ta beslutningen på grunnlag av fakta i stedet for frustrasjon.

Derfor frister en total omskriving

Utviklere som jobber i en gammel kodebase, ser de dårligste sidene ved den hver dag: rotete struktur, utdaterte avhengigheter og enkle endringer som tar uker. Tanken på å begynne på nytt med ren arkitektur og moderne teknologi er virkelig fristende.

Men vær oppmerksom på sammenligningen som gjøres. Den som foreslår en omskriving, stiller et system som finnes, med alle arrene det har, opp mot et tenkt system som ennå ikke har møtt virkeligheten. Det nye ser alltid bedre ut på tavlen enn det gamle gjør i produksjon.

Derfor blir omskrivinger systematisk undervurdert

To mekanismer gjør at omskrivinger nesten alltid blir større enn planlagt.

Skjult forretningslogikk. Et system som har vært i drift i ti år, har samlet tusenvis av små beslutninger: spesialregler for en bestemt kundetype, håndtering av uvanlige datotilfeller og unntak som ble lagt til etter en hendelse. Det meste er udokumentert og står bare i koden. Den nye versjonen må gjenskape alt dette for at virksomheten skal fungere, men i kalkylen regnes som regel bare funksjonene som er synlige på overflaten.

Second system-effekten. Når teamet endelig får bygge nytt, vil man rette opp alle gamle feil og legge til alt man har savnet, og det på én gang. Versjon to blir derfor som regel mer ambisiøs enn noen egentlig har bestilt: større omfang, lengre prosjekt og høyere risiko.

I tillegg kommer dobbeltarbeidet. Virksomheten kan sjelden fryse utviklingen i ett eller to år, så hver ny funksjon må bygges i både det gamle og det nye systemet. Ellers er det nye utdatert allerede ved lansering.

Trinnvis modernisering er riktig utgangspunkt

For de fleste systemer er hovedanbefalingen derfor å videreutvikle og modernisere trinnvis: forbedre koden innenfra, bytte ut den mest problematiske delen først og la resten leve videre bak stabile grensesnitt.

• Verdien kommer fortløpende. Hver del som byttes ut, gjør hverdagen bedre med en gang, i stedet for at all verdi ligger på slutten av et flerårig prosjekt.
• Risikoen er avgrenset. Går et steg galt, rammes én del av systemet, ikke hele virksomheten på én gang.
• Kursen kan endres. Prioriteringene kan justeres mellom etappene etter hvert som virksomheten lærer hva som gir effekt.
• Forretningslogikken bevares. Den skjulte logikken flyttes bit for bit og verifiseres mot hvordan det gamle systemet oppfører seg, i stedet for å bli gjenoppfunnet i én omgang.

Når en total omskriving faktisk er berettiget

Det finnes situasjoner der trinnvis modernisering ikke strekker til. De er færre enn man tror, men de er reelle:

Oppfyller systemet ett eller flere av kriteriene, er det fornuftig å utrede en omskriving for alvor. Gjør den likevel så begrenset som mulig: Gjenskap det som faktisk brukes, ikke alt som noen gang er bygget.

Tankefellene finnes på begge sider

Iveren etter å skrive om er den vanligste fellen, men det motsatte finnes også. Den som har investert år i et system, vegrer seg gjerne mot tanken på at det har utspilt sin rolle, og så lappes det videre lenge etter at regnestykket har sluttet å gå opp. Hvis vedlikeholdet spiser størstedelen av utviklingsbudsjettet, hvis hver ny versjon krever manuell akrobatikk, og hvis ingen tør å røre enkelte deler av koden, da er «vi fortsetter som før» ikke det trygge valget. Det er bare det stille valget.

Slik tar du beslutningen i praksis

Ta et konkret eksempel: en grossist med et ordresystem bygget i 2012. Systemet fungerer, men plattformen nærmer seg slutten av livssyklusen, og to nøkkelutviklere nærmer seg pensjonsalder. I stedet for å velge mellom «behold alt» og «skriv om alt» kartlegger selskapet systemet del for del. Integrasjonene flyttes først til et moderne mellomlag, deretter byttes kundeportalen, og kjernen, prislogikken som fungerer, får leve videre bak et stabilt API til også den kan erstattes.

Resultatet er en plan der hver etappe har eget budsjett, egen verdi og et punkt der man kan ta pause uten å sitte igjen med et halvferdig bygg. Slik kommer du deg ut av et system som skaver, uten å sette alt på ett kort.

Vil dere ha en second opinion på veivalget deres? Vi i Weapp gjør denne typen teknisk kartlegging som en del av tjenestene våre. Ta kontakt, så ser vi på forutsetningene sammen.