3.6 Modernisering av äldre system

Översikt och motivation

Äldre system är de system som driver världen. De centrala banksystemens huvudböcker, skatte- och bidragsmotorer, flygledningssystem och försvarssystem, försäkringarnas försäkringsadministration och myndighetsregister som samhällen är beroende av är ofta decennier gamla. Många är skrivna i COBOL (Common Business-Oriented Language) eller andra äldre tekniker, och de bearbetar fortfarande merparten av de kritiska transaktionerna. “Äldre” är ingen förolämpning. Det betyder att systemet är värdefullt nog att ha överlevt, kritiskt nog att ett fel är katastrofalt och gammalt nog att det är svårt att ändra säkert. Modernisering av äldre system är disciplinen att förbättra, migrera eller ersätta dessa system utan att bryta de väsentliga tjänster de tillhandahåller.

Det här är oproportionerligt mycket ett företags- och myndighetsproblem, och det är där de största, mest offentliga IT-misslyckandena inträffar. En stor andel av större transaktioner världen över rör fortfarande stordatorsystem. En stor andel av produktionskoden i stora institutioner är i äldre språk som underhålls av en åldrande, krympande skara specialister. Myndigheter bär den tyngsta bördan: lagstadgade skyldigheter kodade över decennier, upphandlings- och budgetcykler som överlever regeringar och medborgartjänster som inte kan avbrytas. Den dominerande risken är inte att dessa system är gamla, eftersom många körs utmärkt. Den är att kunskapen att underhålla dem går i pension, plattformarna blir allt dyrare och mer begränsade och frestelsen att “bara skriva om det” leder till några av fältets dyraste misslyckanden.

Det här kapitlet behandlar de inkrementella moderniseringsmönster som faktiskt fungerar (kvävarfikon och gren-via-abstraktion), hur man bedömer och prioriterar risk i äldre system, förvaltningen av stordators- och COBOL-egendomar, disciplinen kring datamigrering och dubbelkörning och framför allt hur man motstår frestelsen till den stora omskrivningen. Den centrala övertygelsen är att lyckad modernisering nästan alltid är inkrementell, belägg-driven och kontinuerligt levererar värde. Den är aldrig en flerårig big bang.

Nyckelprinciper

Äldre betyder värdefullt och grundläggande, inte bara gammalt. Respektera vad systemet gör innan du rör det. Det kodar decennier av hårt förvärvade affärsregler.
Inkrementellt slår storskaligt, nästan alltid. Ersätt bit för bit bakom ett stabilt gränssnitt. Leverera värde kontinuerligt och håll risken liten.
Den stora omskrivningen är standardfelläget. Fullständiga omskrivningar överskrider rutinmässigt, underlevererar och avbryts. Behandla impulsen med djup misstro.
Du kan inte modernisera det du inte förstår. Baklängeskonstruera och dokumentera beteendet (inklusive odokumenterade regler) innan du ersätter det.
Datamigrering är där projekt dör. Datan är äldre, smutsigare och mer intrasslad än någon väntar sig. Planera för den som en förstklassig insats.
Kör gammalt och nytt parallellt för att bygga tillförsikt. Dubbelkörning och jämförelse fångar avvikelser före övergången.
Prioritera efter risk och värde, inte efter ålder. Modernisera det som är riskablast och mest värdefullt först, inte det som helt enkelt är äldst.
Håll lamporna tända medan du byter motor. Tjänsten måste fortsätta köra genom hela förloppet. Det finns inget acceptabelt driftstopp för kritiska medborgar- eller finanssystem.

Rekommendationer

Modernisera inkrementellt med kvävarfikonmönstret

Kvävarfikonet (uppkallat efter vinrankan som växer runt ett träd och gradvis ersätter det) är moderniseringens arbetshäst. Placera ett routinglager (en API-gateway, fasad eller proxy) framför det äldre systemet. Bygg sedan, förmåga för förmåga, ersättningen i ett modernt system och led den biten av trafiken dit, och lämna resten på det äldre systemet. Över tid växer det nya systemet och det gamla krymper, tills det kan avvecklas. Det levererar värde kontinuerligt, håller varje ändring liten och reversibel, undviker en riskabel övergång och låter dig stoppa eller omprioritera när som helst. Det är motsatsen till big bang. Det äldre systemet fortsätter köra och förtjäna sitt uppehälle medan du ersätter det runt omkring.

Använd gren-via-abstraktion för interna sömmar

Där du behöver ersätta en komponent som många delar av systemet beror på, använd gren-via-abstraktion. Inför ett abstraktionslager (ett gränssnitt) över den befintliga implementationen, migrera anropare att bero på abstraktionen, bygg den nya implementationen bakom samma abstraktion, byt över (ofta bakom en funktionsflagga, gradvis) och ta slutligen bort den gamla implementationen. Det låter en stor komponent ersättas inkrementellt på utvecklingens huvudlinje utan en långlivad gren, och håller systemet releasbart hela vägen. Det paras naturligt med kvävarfikonet: fasaden hanterar yttre sömmar, gren-via-abstraktion hanterar inre.

Bedöm och prioritera risk i äldre system medvetet

Innan du moderniserar, bygg en klarsynt inventering och riskbedömning av egendomen. Poängsätt varje system på affärskritikalitet, teknisk risk (föråldring, stödlösa plattformar, säkerhetsexponering), ändringsfrekvens och, avgörande, kunskapsrisk (hur många människor som fortfarande kan underhålla det, och hur nära pension de är). Rita in systemen på ett rutnät risk-mot-värde. Prioritera att modernisera det som är både högrisk och högvärde. Överväg att lämna stabila, lågändrings-, väl förstådda system ifred även om de är gamla, eftersom ett fungerande system ingen behöver ändra inte är ett nödläge. Den här bedömningen förvandlar “allt är gammalt och skrämmande” till en försvarbar, sekvenserad färdplan.

Förvalta stordators- och COBOL-egendomen, ersätt den inte bara

Inte varje stordators- eller COBOL-system bör, eller kan säkert, ersättas snart. Den kortsiktiga prioriteten är ofta förvaltning: fånga kunskapen innan den går i pension. Dokumentera de affärsregler koden kodar (mycket av det odokumenterat och oersättligt), investera i automatiserade tester som fastnaglar nuvarande beteende så att framtida förändring är säker, rekrytera och korsutbilda underhållare och modernisera de omgivande leveranspraxisen (källkodshantering, kontinuerlig integration (CI), automatiserad testning) även medan kärnan förblir på plats. Där du moderniserar, föredra att exponera äldre förmågor genom moderna API:er (inkapsling) som ett första steg. Behandla automatisk översättning från COBOL till modernt språk med försiktighet, eftersom den producerar kod som körs men ofta troget återger obegriplig logik. Den knappaste resursen är förståelse, inte beräkning.

Behandla datamigrering och dubbelkörning som projektets kärna

Den svåraste och mest riskfyllda delen av de flesta moderniseringsinsatser är datan. Den är omfattande, av dålig och inkonsekvent kvalitet och full av odokumenterad mening som ackumulerats över decennier. Profilera och rensa den, kartlägg gamla mot nya scheman uttryckligen och bygg repeterbar, automatiserad migrering med full avstämning (antal, kontrollsummor, affärstotaler) så att du kan bevisa att inget gick förlorat eller ändrades. Minska risken vid övergången med dubbelkörning (parallellkörning): kör det gamla och nya systemet sida vid sida på samma indata och jämför utdata tills det nya systemet matchar det gamla till din tillitströskel. Gå först då över, och behåll förmågan att rulla tillbaka. För verkligt kritiska system, migrera och gå över i bitar snarare än allt på en gång.

Hantera frestelsen till den stora omskrivningen

Instinkten att kasta det röriga gamla systemet och bygga ett rent nytt från grunden är kraftfull, och den är nästan alltid fel för stora, kritiska system. Fullständiga omskrivningar underskattar värdet som gömmer sig i den “fula” koden (kantfall, regulatoriska regler, buggkompatibla beteenden som verkliga användare är beroende av), tar långt längre tid än projicerat, levererar inget värde före slutet och avbryts ofta efter enorma utgifter. Välj inkrementell modernisering som standard. Reservera omskrivningar för fall där plattformen är genuint ohållbar och inkrementella vägar är uttömda. Även då, bryt ned omskrivningen i oberoende levererbara bitar via kvävarmönstret snarare än en enda big bang-release. När ledningen driver på för en total omskrivning, insistera på frågan: vilket värde levereras de första tre månaderna, och vad händer om programmet stoppas halvvägs?

Avvägningar: för- och nackdelar

Tillvägagångssätt	Fördelar	Nackdelar
Kvävarfikon (inkrementellt)	Kontinuerligt värde, låg risk, reversibelt, håller tjänsten igång	Längre total tidslinje, måste köra två system parallellt, integrationsoverhead
Storskalig omskrivning	Ren tavla, inga äldre begränsningar i den nya koden	Mycket hög felfrekvens, inget värde före slutet, enorm kostnad, affärsregler förloras
Kapsla in (omslut med API:er)	Snabbt, lågrisk, moderniserar åtkomst utan att röra kärnan	Kärnan förblir äldre. Skjuter upp, löser inte, den underliggande risken
Lämna som det är (förvalta)	Ingen projektrisk. Billigast på kort sikt	Kunskaps- och plattformsrisk fortsätter ackumuleras. Så småningom påtvingad åtgärd

Den grundläggande avvägningen är omvandlingens hastighet mot risken för misslyckande, och modernisering av äldre system är domänen där den affären är mest sned. Den “snabba, rena” storskaliga omskrivningen är en hägring som upprepade gånger producerar det långsammaste och dyraste utfallet av alla: ett avbrutet program och ett fortfarande omodernt system. Inkrementella ansatser känns långsammare och kräver att köra två system parallellt, men de levererar värde hela vägen, håller risken liten och reversibel och är den empiriskt pålitliga vägen. Det genuina omdömesbeslutet är mellan att förvalta ett stabilt äldre system en stund till och att påbörja inkrementell ersättning nu. Låt riskbanan driva det beslutet, särskilt kunskapsrisk, snarare än obehag med gammal teknik.

Frågor att diskutera med ditt team

Har ni en plats att sätta ett routinglager framför ert äldre system, och om inte, vad skulle det krävas för att skapa en? Kvävarfikonet beror på en söm: en API-gateway, fasad eller proxy genom vilken ni kan leda om en förmåga i taget till en ny implementation. Många gamla system har ingen sådan söm, så det första moderniseringssteget är ofta bara att bygga avlyssningspunkten, och det arbetet är lätt att underskatta. Ta med den nuvarande integrationskartan och fråga var trafik kunde avlyssnas per förmåga utan en storskalig övergång. Om det inte finns någonstans kan gren-via-abstraktion på en intern söm vara startdraget i stället. Utan ett routinglager har ni ingen inkrementell väg, vilket är precis hur organisationer drivs tillbaka mot omskrivningen som vanligen misslyckas.
Har ni faktiskt ritat in er egendom på ett rutnät risk-mot-värde, eller drivs er färdplan av vilket system som känns äldst? Kapitlet insisterar på att ni moderniserar det som är högrisk och högvärde först, och medvetet lämnar stabila, lågändrings-, väl förstådda system ifred även när de är uråldriga. Utan ett uttryckligt rutnät flödar uppmärksamheten till det högljuddaste klagomålet eller den minst moderna tekniken, och genuina tidsinställda bomber (ett kritiskt system med två underhållare nära pension) väntar. Poängsätt varje system på affärskritikalitet, teknisk risk, ändringsfrekvens och kunskapsrisk, och sekvensera sedan från övre högra hörnet. Ta med det rutnätet till mötet som den gemensamma kartan. Kunskapsrisk förtjänar den tyngsta vikten, eftersom den är den enda indata som bara blir värre och inte kan köpas tillbaka när människorna väl lämnat.
När ni går över, hur ska ni bevisa att inte en enda post gick förlorad eller ändrades, och vem godkänner det beläggen? Datamigrering är där dessa projekt dör, och tillförsikt kommer av avstämning: radantal, kontrollsummor och affärskontrolltotaler som stämmer mellan gammalt och nytt, plus dubbelkörning som jämför utdata på samma indata tills de stämmer överens till en hög tröskel. För ett bidrags- eller huvudboksystem är en avvikelse en medborgare som underbetalats eller ett öre som förlorats, så beläggen måste tillfredsställa en revisor, inte bara en ingenjör. Besluta nu vilka totaler ni ska stämma av, vilken tillitströskel som utlöser övergång och hur länge ni ska köra gammalt och nytt parallellt. Behåll återrullning tillgänglig hela vägen och gå över i bitar snarare än allt på en gång. Avvikelserna ni hittar under dubbelkörning är vanligen odokumenterade äldre regler ni måste bevara, så behandla var och en som en upptäckt, inte bara en defekt.
Vilka av era äldre system förvaltar ni jämfört med att aktivt ersätta, och vem avgjorde vilket som är vilket? Kapitlet drar en medveten linje mellan system värda att stabilisera på plats (dokumentera regler, lägga till karakteriseringstester, korsutbilda underhållare) och system värda att inkrementellt ersätta, och de två kräver mycket olika finansiering och bemanning. För en stor organisation är faran drift: ett system märkt “förvalta för nu” blir i det tysta “förvalta för alltid” tills den sista underhållaren går i pension och valet görs åt er under kris. De motstridiga hänsynen är förvaltningskostnad och plattformsföråldring å ena sidan mot risken och störningen av ersättning å den andra, och kunskapsrisk bör luta vågen eftersom den bara förvärras. Ta med rutnätet risk-mot-värde, antalet underhållare och pensionshorisonten för varje system och en uttrycklig ägare för beslutet förvalta-eller-ersätt. I företags- och myndighetsegendomar, namnge en granskningstakt och en ansvarig tjänsteman för varje system, för en klassificering ingen omprövar är ett beslut ingen fattar.
När ledningen ber om en fullständig omskrivning, vilket är ert stående svar, och kan ni visa vad en inkrementell väg levererar de första tre månaderna? Den storskaliga omskrivningen är standardfelläget, men den fortsätter att finansieras eftersom en ren tavla är lätt att sälja och ett kvävarfikon inte är det. Ett stort team behöver ett repeterat svar så att argumentet vinns på belägg snarare än av den som är mest senior i rummet. Den genuina spänningen är att vissa plattformar verkligen är ohållbara och en omskrivning är motiverad, så svaret kan inte vara ett generellt vägrande: det måste väga om inkrementella sömmar fortfarande finns mot den verkliga kostnaden för att hålla den gamla plattformen vid liv. Ta med det värde ett inkrementellt första steg skulle leverera, den historiska felfrekvensen för jämförbara omskrivningar och en nedbrytning av varje föreslagen omskrivning i oberoende levererbara bitar. I myndigheter, där ett avbrutet flerårigt program bränner offentliga pengar i full syn, insistera på att varje omskrivning levererar värde tidigt och överlever att stoppas halvvägs utan total förlust.
Hur ska ni fånga de affärsregler som är inlåsta i er äldsta kod innan de människor som förstår dem är borta? Mycket av värdet i ett äldre system är odokumenterat beteende som decennier av kantfall, regler och buggkompatibla rättelser har samlat, och det bor i en krympande skara pensionerande specialister snarare än i något skrivet register. För en stor organisation är detta den enda risk som inte kan köpas tillbaka när människorna väl lämnat, så den förtjänar finansiering före det mer synliga plattformsarbetet. Det motstridiga draget är att kunskapsfångst (dokumentation, karakteriseringstester, baklängeskonstruktion, korsutbildning) känns som overhead som inte levererar något, vilket är exakt därför den skjuts upp. Ta med en inventering av vem som håller kritisk kunskap, hur nära de är att lämna och vilken testtäckning som fastnaglar nuvarande beteende i dag. I reglerade och offentliga miljöer, behandla de lagstadgade regler som är kodade i gammal kod som en regelefterlevnadstillgång: att förlora dem i tysthet är ingen teknisk skuld, det är en rättslig exponering.

Sektorsperspektiv

Startup. Ditt äldre system är din egen brådskande MVP, inte en stordator: en prototyp som nu bär intäkter och som alla fruktar att röra. Skriv inte om den. Omslut den mest skrämmande modulen bakom ett rent gränssnitt, lägg till karakteriseringstester för att fastnagla dess beteende och skär ut funktionalitet inkrementellt så att varje liten release levererar värde och krymper risken. Du har ingen löptid för en ombyggnad från grunden, så valfrihet spelar större roll än elegans.

Småföretag. Du har inget moderniseringsteam och en snäv budget, så det praktiska draget är vanligen att hålla ett fungerande system fungerande: fånga vad den enda person som förstår det vet, få in det i källkodshantering med några automatiska tester och lita på en leverantör eller en paketerad produkt snarare än en skräddarsydd ombyggnad. Rama in beslutet som köp mot bygg och föredra köp när förmågan är en standardvara. Lägg din begränsade insats på det enda system vars fel skulle stoppa verksamheten, inte på det som bara ser äldst ut.

Storföretag. Problemet är portföljskala: dussintals system, många team och kunskapsrisk över hela egendomen. Kör en gemensam riskbedömning risk-mot-värde, standardisera på inkrementella mönster (kvävarfikon och gren-via-abstraktion) och behandla datamigrering och dubbelkörning som förstklassiga discipliner med avstämning alla litar på. Styr modernisering som en kontinuerlig portfölj mot riskbana snarare än en spridning av heroiska projekt, och budgetera förvaltning och kunskapsfångst uttryckligen så att inget kritiskt system beror på en enda pensionerande underhållare.

Offentlig sektor. Lagstadgade skyldigheter kodade över decennier, upphandlingsregler och medborgartjänster som inte kan avbrytas gör storskalig ersättning särskilt farlig. Föredra inkrementell kvävarfikonmigrering med övergång bit för bit, bevisa genom avstämning och lång parallellkörning att inte en enda medborgarpost gick förlorad eller felberäknades och behåll återrullning tillgänglig hela vägen. Upphandling bör kräva dataportabilitet och redovisning av affärsregler snarare än ogenomskinlig översättning, och varje flerårigt program måste leverera granskningsbart värde tidigt och överleva offentlig granskning om det stoppas halvvägs.

Exempel

Startup. MVP:n hos en treårig startup har blivit sitt eget slags äldre system: en brådskande prototyp som nu hanterar verkliga intäkter och som alla är rädda att röra. I stället för en omskrivning omsluter teamet den värsta modulen bakom ett rent gränssnitt, lägger till karakteriseringstester för att fastnagla dess nuvarande beteende och flyttar funktionalitet ut ur den bit för bit under några månader. Varje liten release levererar värde och krymper den skrämmande delen, så att startupen får ett underhållbart system utan att satsa företaget på en ombyggnad från grunden den inte har råd med.

Storföretag. Ett stort försäkringsbolag kör försäkringsadministration på ett stordators-COBOL-system som är pålitligt men dyrt att ändra och underhålls av en handfull ingenjörer nära pension. I stället för en omskrivning omsluter försäkringsbolaget stordatorn med moderna API:er och tillämpar kvävarfikonet: nya offert-och-köp- och självbetjäningsförmågor byggs på en modern plattform och leds genom en fasad, medan kärnregistren för försäkringar stannar på stordatorn. Parallellt dokumenterar teamet affärsregler och lägger till karakteriseringstester runt COBOL-koden. Under flera år flyttar förmåga efter förmåga bort från stordatorn, varje release levererar värde, tills den återstående kärnan kan avvecklas på försäkringsbolagets villkor snarare än under kris.

Offentlig sektor. En socialförsäkringsmyndighet måste modernisera ett decennier gammalt bidragsberäkningssystem som betalar miljontals medborgare och inte kan avbrytas eller betala fel. Den avvisar en storskalig ersättning efter att ha studerat jämförbara misslyckade program. I stället profilerar och rensar den datan, bygger automatiserad migrering med full avstämning mot kontrolltotaler och kör den nya bidragsmotorn parallellt med den gamla i många månader, matar båda med samma ansökningar och jämför varje beräkning och utreder varje avvikelse (som ofta avslöjar odokumenterade äldre regler som måste bevaras). Först när det nya systemet matchar det gamla till en mycket hög tillit går den över bidragstyp för bidragstyp och behåller återrullning hela vägen. Kvävarfasaden låter medborgare se en sammanhängande tjänst genom övergången.

Affärsnytta: motiv, ROI och TCO

Modernisering av äldre system har ett ovanligt affärsärende, eftersom den största kostnaden ofta är kostnaden för passivitet och den största risken är själva moderniseringsprojektet. De växande kostnaderna för att inte modernisera är konkreta: stigande underhåll och licensiering på föråldrade plattformar, en alltmer knapp och dyr specialistarbetsstyrka, oförmåga att snabbt möta nya regulatoriska eller tjänstekrav och växande exponering för ett katastrofalt fel utan att någon är kvar som förstår systemet. Mot det är kostnaden för modernisering hög, och gjord som en big bang bär den en genuint hög sannolikhet för misslyckande. Det är precis därför den inkrementella ansatsen spelar roll för ROI: den omvandlar ett enda stort vad till en serie små som var och en ger värde tillbaka och kan stoppas.

Driv ärendet inför ledningen genom att omformulera valet. Frågan är inte “modernisera eller inte”. Den är “modernisera inkrementellt nu, eller betala stigande förvaltningskostnader och möta en påtvingad, högrisk-modernisering senare under kris”. Kvantifiera TCO för status quo (plattforms- och licenskostnader, premien för knappa färdigheter, den riskviktade kostnaden för ett oåterkalleligt avbrott) och jämför den med ett stegvist program som minskar risk och kostnad med varje steg medan tjänsten förblir igång. Avgörande, insistera på att varje föreslagen omskrivning struktureras för att leverera värde tidigt och ofta. Ett program som inte levererar något på tre år och kan avbrytas med total förlust är inte en investering. Det är ett hasardspel. Det starkaste ROI-argumentet för kvävaransatsen är valfrihet: värde levereras kontinuerligt och organisationen kan justera kurs när som helst.

Antimönster och fallgropar

Den storskaliga omskrivningen. Flerårig, allt-eller-inget-ersättning som inte levererar något värde före slutet och ofta avbryts med stor kostnad.
Att skriva om utan att förstå. Att ersätta kod vars affärsregler aldrig dokumenterats och tyst släppa kantfall verkliga användare och lagar är beroende av.
Att underskatta datan. Att behandla datamigrering som en eftertanke när den är projektets svåraste, mest riskfyllda del.
Att hoppa över dubbelkörning. Att gå över till det nya systemet utan parallell jämförelse och upptäcka avvikelser först efter att de påverkat verkliga människor.
Automatisk översättning som lösning. Att maskinöversätta COBOL till ett modernt språk och tro att jobbet är gjort, vilket producerar obegriplig kod som återger den gamla logiken ordagrant.
Att modernisera efter ålder, inte risk. Att lägga insats på gamla men stabila system medan högrisk-, högändringssystem väntar.
Att förlora kunskapen. Att låta de sista underhållarna gå i pension utan att fånga affärsreglerna och lägga till karakteriseringstester.
Ingen återrullning. Att gå över utan väg tillbaka när det nya systemet beter sig fel under verklig belastning och verkliga data.

Mognadsmodell

Nivå 1: Initiera. Äldre system fruktas och är frusna. Förändring undviks. Ingen inventering eller riskbedömning finns. Modernisering, när den alls försöks, är en ad hoc allt-eller-inget-omskrivning driven av frustration. Kunskap bor i några få pensionerande huvuden utan något nedskrivet.
Nivå 2: Utveckla. Vissa team har en inventering och en grov känsla för risk, och några äldre system är omslutna med API:er för åtkomst. Inkrementella mönster är kända men tillämpade ojämnt, och tänkandet driver fortfarande mot storskaliga omskrivningar. Datamigrering försöks men underskattas, och praxis varierar vitt från team till team.
Nivå 3: Standardisera. System prioriteras efter risk och värde enligt en dokumenterad metod för hela organisationen. Inkrementella mönster (kvävarfikon, gren-via-abstraktion) är den upprätthållna standarden, och varje modernisering följer en standardspelbok. Datamigrering är en planerad, avstämd insats med dubbelkörning före övergång, och kunskapsfångst och karakteriseringstester är krävd praxis snarare än valfria.
Nivå 4: Hantera. Modernisering mäts och styrs med data. Egendomen bär utgångslägen: antal underhållare och pensionshorisont per system, täckning av karakteriseringstester, avstämningsframgångsfrekvens för migrering, antal avvikelser vid dubbelkörning och levererat värde per steg, allt följt mot mål. Beslut om förvalta-eller-ersätt och övergång-eller-inte fattas på det beläggen, och ett system som driver förbi sin kunskapsrisktröskel utlöser åtgärd i stället för att vänta på en kris.
Nivå 5: Orkestrera. Modernisering är kontinuerlig, integrerad med affärs- och riskplanering och adaptiv. Portföljen omfördelas mot riskbana (särskilt kunskapsrisk) när den förskjuts, inkrementell ersättning är rutin och lågdramatisk, varje steg levererar värde och är reversibelt, och organisationen styr takten medvetet. Lärdomar från varje migrering matas tillbaka till den gemensamma spelboken så att hela egendomen förbättras över tid.

Idéer för diskussion

För ert mest kritiska äldre system, hur många människor kan fortfarande underhålla det, och hur nära är de att lämna?
Var frestas ni av en storskalig omskrivning, och vilket värde kunde en inkrementell ansats leverera de första tre månaderna i stället?
Hur väl är affärsreglerna i era äldsta system dokumenterade, och vad händer med dem om koden ersätts?
Har ni profilerat den data ni skulle behöva migrera, och vet ni hur smutsig och intrasslad den verkligen är?
Vilka gamla-men-stabila system lägger ni moderniseringsenergi på som ni säkert kunde lämna ifred?
Kunde ni köra ert nya system parallellt med det gamla och bevisa att de är överens innan ni går över?

Viktigaste punkter

Äldre betyder värdefullt och grundläggande. Respektera och förstå ett system innan du ändrar det.
Modernisera inkrementellt med kvävarfikon och gren-via-abstraktion, leverera värde kontinuerligt och håll varje ändring liten och reversibel.
Behandla den storskaliga omskrivningen som standardfelläget. Reservera den för genuint ohållbara plattformar och bryt även då ned den.
Prioritera efter risk och värde (särskilt kunskapsrisk), inte efter ålder. Vissa gamla system förvaltas bäst, ersätts inte.
Datamigrering och dubbelkörning är kärnan i insatsen: profilera, stäm av, kör parallellt och behåll återrullning.
Det starkaste affärsärendet är valfrihet: inkrementell modernisering omvandlar ett stort, riskfyllt vad till många små, värdeskapande.

Referenser och vidare läsning

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, “StranglerFigApplication” and “BranchByAbstraction”
Sam Newman, Monolith to Microservices
Nicholas Carr / industry studies on mainframe and COBOL dependency (context on the scale of legacy estates)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (anti-corruption layer)
Gregor Hohpe, Enterprise Integration Patterns and The Software Architect Elevator
Standish Group CHAOS Report (evidence on large project and rewrite failure rates)