Modernisér gammel software uden en stor omskrivning

Næsten enhver etableret virksomhed har et: et stykke software, som alle stille og roligt afskyr. Det er langsomt, det er grimt, halvdelen af teamet kender en omvej til den fejl, ingen nogensinde rettede, og den ene person, der forstod det, stoppede i 2019. Instinktet er altid det samme — brænd det ned og byg et nyt. Og det instinkt er, oftere end ikke, præcis sådan gode virksomheder mister et år og en lille formue på ingenting.

Jeg har set den store omskrivning gå galt nok gange til at have en refleks omkring det. En stifter viser mig sit knirkende ordresystem eller sit ældgamle planlægningsværktøj, sukker og siger en version af ”vi skal bare udskifte det hele”. Og måske gør I det en dag. Men den fulde omskrivning — riv det gamle system ud, byg et skinnende nyt parallelt, vend en kontakt — er et af de mest risikable træk i hele softwareverdenen. Det er dyrt, det tager langt længere end lovet, og hele tiden kører I i blinde og håber, at det nye dækker hvert mærkeligt grænsetilfælde, som det gamle stille håndterede i femten år.

Den gode nyhed er, at den store omskrivning næsten aldrig er den eneste mulighed, og sjældent den bedste. Der findes en roligere måde at modernisere på — trinvis, omstødelig og skånsom mod forretningen, der stadig skal tjene penge, mens I arbejder. Dette er en guide til den måde: hvordan du afgør, hvad der faktisk skal rettes, hvordan du udskifter de smertefulde dele uden at tage hele systemet ned, og hvordan du ved, hvornår en fuld omskrivning virkelig er det rigtige valg.

Hvorfor den store omskrivning er så fristende — og så farlig

Den fulde omskrivning er forførende, fordi den lover et rent bord. Ikke mere ældre rod, ingen flere kompromiser, en frisk kodebase bygget rigtigt med moderne værktøjer. På en tavle ser det indlysende ud. I virkeligheden skriver du under på at genopbygge års akkumuleret forretningslogik — meget af den udokumenteret, noget lever kun i hovedet på folk, der er holdt op — mens uret tikker og regningerne kommer ind.

Den dybere fælde er paralleluniverset-problemet. I de måneder eller år, det tager at bygge afløseren, har du to systemer: det gamle, der stadig skal drive forretningen, og det nye, der ikke er klar endnu. Hver ændring, forretningen har brug for, skal laves to gange, ellers sakker det nye system bagud i forhold til virkeligheden, før det overhovedet lanceres. Teams brænder ud på at holde begge i live. Og fordi ingen må skifte over, før det nye system gør alt, er der ingen tidlig sejr, ingen feedback, intet bevis på, at det virker — kun en lang, ængstelig venten på én enorm alt-eller-intet-lanceringsdag.

Der er en velkendt branchefortælling her, og den er fortjent: det andet system, den store omskrivning, har for vane at tage tre gange så lang tid som anslået og ankomme med færre funktioner end det, det erstatter. Estimatet er ikke forkert, fordi folk er skødesløse. Det er forkert, fordi ingen ved starten kan se alle de små ting, som det gamle system stille gør rigtigt.

Hvad ”ældre” faktisk betyder (det handler ikke om alder)

Vi smider om os med ordet ældre, som om det bare betyder gammelt. Det gør det ikke. Masser af software, der har kørt i et årti, er helt fint — kedeligt, stabilt, betalt, gør sit arbejde. Alder alene er ingen grund til at røre ved noget. Den dyreste fejl i hele dette felt er at modernisere noget, der stille virkede, bare fordi det så forældet ud.

Software fortjener mærkatet ældre, når den aktivt står i vejen for dig. Når du ikke trygt kan ændre den, fordi ingen forstår den fuldt ud. Når den ikke kan forbinde til de værktøjer, du nu afhænger af. Når én enkelt person er den eneste, der kan holde den i live. Når den er så langsom eller skrøbelig, at dit team har bygget en hel folklore af omveje op omkring den. Det er den rigtige definition — ikke året, den blev skrevet, men den pris, den pålægger dig i dag, og den risiko, den bærer ind i morgendagen.

Stil diagnosen, før du rører ved noget

Før en eneste linje skrives om, har du brug for et ærligt kort over, hvor smerten faktisk bor. Som regel er systemet, alle hader, 80 procent fint. Problemet er koncentreret få bestemte steder — én langsom skærm, én ødelagt integration, ét arbejdsflow, der tvinger til dobbelt dataindtastning — og de få steder genererer næsten alle klagerne. Find dem, og du har fundet hele dit projekt.

Måden at finde dem på er ikke en teknisk gennemgang først — det er en samtale. Sæt dig sammen med de folk, der bruger tingen hver dag, og spørg, hvor det gør ondt. Hvor venter de? Hvad indtaster de igen? Hvad undgår de, fordi det er besværligt? Hvor holder de et privat regneark for at omgå det officielle system? De omveje er guld: hver enkelt er et præcist røntgenbillede af et problem, der er værd at rette.

• De skærme og trin, folk klager mest over — ikke i teorien, men i deres faktiske daglige arbejde.
• Hvert sted, hvor data indtastes to gange, fordi to systemer ikke taler sammen.
• Integrationerne, der gik i stykker, eller aldrig fandtes, og tvinger til manuel kopiering mellem værktøjer.
• Alt, som kun én person ved, hvordan man betjener eller retter — dine enkelte fejlkilder.
• De dele, der faktisk er fine, så du kan beskytte dem og lade dem være.
• Hvad forretningen får brug for næste år, som det nuværende system simpelthen ikke kan vokse ind i.

Når du gør det ærligt, skrumper projektet som regel. Ejeren, der trådte ind og sagde ”udskift det hele”, går ud og indser, at de skal rette tre ting. Det er ingen skuffelse — det er en lettelse. Tre ting, der kan rettes, er et projekt, du kan afslutte dette kvartal. En fuld udskiftning er et år, du måske ikke overlever.

Strangler-metoden: udskift det ét stykke ad gangen

Der findes et mønster til at gøre dette trygt, og det har et lidt dystert, men mindeværdigt navn: strangler-metoden, efter kvælerfignen — en slyngplante, der vokser om et træ og gradvist overtager dets struktur, indtil den nye vækst til sidst står på egne ben, og den gamle stamme er væk. Anvendt på software er idéen smukt praktisk: du udskifter ikke det gamle system i ét heroisk skift. Du dyrker det nye op omkring det, ét stykke ad gangen, indtil der ikke er noget tilbage af det gamle, nogen har brug for.

I praksis fungerer det sådan her. Du vælger ét smertefuldt stykke — sig faktureringsmodulet, alle hader. Du bygger en moderne afløser til kun det stykke. Du dirigerer faktureringen til det nye modul, mens alt andet kører videre på det gamle system, urørt. Du holder øje med det et stykke tid. Når det er solidt, falder den del af det gamle system til ro, og du går videre til næste stykke. Det gamle system skrumper gradvist, som et stearinlys, i stedet for at blive revet ned på én gang.

Det, der gør dette så meget tryggere end en omskrivning, er, at hvert trin er lille, levende og omstødeligt. Du kører aldrig i blinde. Hvert nyt stykke kommer hurtigt i reel brug, så du finder hurtigt ud af, om det faktisk virker. Hvis noget går galt, har du kun risikeret ét modul, ikke hele forretningen — og du kan som regel falde tilbage til den gamle vej, mens du retter det. Du får sejre undervejs i stedet for én skræmmende lancering til sidst. Og forretningen kører videre, normalt, hele tiden.

Hvordan rytmen faktisk ser ud

1. 1
   Vælg det mest smertefulde, mest selvstændige stykke

   Du vil have høj smerte og rene kanter — et modul, der gør meget ondt og ikke har fingrene i alt andet. Det er dit første mål.
2. 2
   Læg et tyndt lag foran det gamle system

   Et lille dirigeringslag afgør, hvilke forespørgsler der går til det gamle system, og hvilke der går til det nye stykke. Det er sømmen, der gør alt andet muligt.
3. 3
   Byg og lancér kun det ene stykke

   Udskift ét modul, få det ud i rigtige hænder, og dirigér kun den skive af arbejdet til det. Uger, ikke år — og resten af systemet flyttede sig aldrig.
4. 4
   Stabilisér, gå så videre til næste stykke

   Når det nye modul er betroet, går den matchende del af det gamle system i dvale. Gentag med det næste smertefulde stykke, og lær undervejs.
5. 5
   Pensionér det gamle system, når det er tomt

   Til sidst gør det ældre system intet, nogen forlader sig på. Først da slukker du for det — stille, uden dramatik, fordi alt vigtigt allerede er flyttet.

Læg mærke til, hvad der er anderledes end ved omskrivningen: der er ingen enkelt lanceringsdag at frygte. Der er intet paralleluniverse at vedligeholde. Det nye system er i produktion fra uge tre, tjener sit eget og lærer dig ting, i stedet for at vente i et laboratorium på en lancering, der bliver ved med at skride.

Nogle gange behøver du slet ikke at udskifte det

Før du udskifter noget som helst, er det værd at spørge, om det gamle system skal udskiftes, eller blot skal holde op med at være en ø. Et overraskende antal ”vi har brug for et nyt system”-problemer er i virkeligheden ”vores systemer taler ikke sammen”-problemer. Den gamle software er fin til sit job — den sidder bare i en silo og tvinger folk til at fragte data ind og ud i hånden.

I de tilfælde er den billigste, hurtigste løsning ikke et nyt system. Det er en bro. Du pakker den gamle software ind i en forbindelse — en integration, der lader den udveksle data med dine andre værktøjer automatisk — og et moderne lag ovenpå til de dele, folk faktisk rører ved. Den forældede motor brummer videre nedenunder; teamet får en ren overflade og en ende på kopier-indsæt. Det er ikke prangende, men det er ofte det højeste afkast pr. euro i hele indsatsen.

Hvornår en fuld omskrivning virkelig er det rigtige valg

Jeg har brugt hele denne guide på at tale dig fra den store omskrivning, så lad mig være fair: nogle gange er den faktisk svaret. Der findes fundamenter, der er så rådne, at ingen mængde lapning, broer eller stykke-for-stykke-udskiftning redder dem, og at lade som om andet udskyder blot det uundgåelige, mens du bruger penge på at støtte et lig.

De ærlige tegn er specifikke. Teknologien, systemet er bygget på, er død eller døende — ingen support, ingen sikkerhedsopdateringer, ingen tilbage, der kan arbejde på den. Forretningen har ændret sig så grundlæggende, at den gamle model slet ikke længere passer til virkeligheden. Eller systemet er så sammenfiltret, at selv små ændringer rutinemæssigt ødelægger ting urelaterede steder, hvilket som regel betyder, at der slet ikke er rene sømme at lave en strangler-metode i fra start. Når to eller tre af disse er sande på én gang, holder det trinvise arbejde op med at være det tryggere valg.

Og her er den stille gevinst ved at gøre det trinvise arbejde først, selv hvis du til sidst genopbygger: når du når dertil, forstår du systemet langt bedre, end du gjorde i starten. Hvert modul, du udskiftede, lærte dig noget, de oprindelige forfattere aldrig skrev ned. En omskrivning informeret af den viden er et helt andet, langt tryggere dyr end den, der blev lanceret på dag-ét-optimisme.

Den del ingen nævner: det handler mest om mennesker

Her er noget, de tekniske guides springer over. Den sværeste del af at modernisere gammel software er som regel ikke koden — det er de mennesker, der har brugt år på at tilpasse sig den. De kender dens særheder. De har muskelhukommelse for dens mærkelige genveje. Et nyt modul, der objektivt er bedre, kan stadig føles værre de første to uger, simpelthen fordi det er ukendt. Hvis du ignorerer det, kan selv en perfekt teknisk migrering slå fejl.

Den trinvise metode hjælper også her, næsten ved et tilfælde. Fordi forandringen kommer ét lille stykke ad gangen, optager folk den gradvist i stedet for at blive bedt om at lære alt om på én enkelt mandag morgen. Tag de daglige brugere ind tidligt. Lad dem forme afløseren, før den er færdig. Teamet, der var med til at designe den nye fakturerings­skærm, vil kæmpe for den; teamet, der fik den smidt i hovedet, vil afsky den, selv hvis den er identisk. Modernisering er et forandringsledelsesprojekt klædt ud som software.

Almindelige spørgsmål