Verouderde software moderniseren zonder een grote big-bang herbouw

Bijna elk gevestigd bedrijf heeft er een: een stuk software waar iedereen stilletjes een hekel aan heeft. Het is traag, het is lelijk, de helft van het team kent een omweg voor de bug die nooit is opgelost, en de ene persoon die het begreep vertrok in 2019. De impuls is altijd dezelfde — alles platgooien en iets nieuws bouwen. En precies die impuls is, vaker wel dan niet, hoe goede bedrijven een jaar en een klein fortuin voor niets verliezen.

Ik heb de grote herbouw vaak genoeg fout zien gaan om er een reflex over te hebben. Een ondernemer laat me zijn krakende ordersysteem of zijn aftandse planningstool zien, zucht, en zegt een variant van “we moeten gewoon het hele ding vervangen.” En misschien doet u dat ooit ook. Maar de volledige herbouw — het oude systeem eruit rukken, er parallel een glanzend nieuw bouwen, en dan een knop omzetten — is een van de meest riskante zetten in heel de softwarewereld. Het is duur, het duurt veel langer dan beloofd, en de hele tijd vliegt u blind, hopend dat het nieuwe ding elk vreemd randgeval dekt dat het oude vijftien jaar lang stilletjes afhandelde.

Het goede nieuws is dat de big-bang herbouw bijna nooit de enige optie is, en zelden de beste. Er is een rustigere manier om te moderniseren — incrementeel, omkeerbaar, en mild voor de onderneming die ondertussen nog steeds geld moet verdienen. Dit is een gids voor die manier: hoe u herkent wat echt gerepareerd moet worden, hoe u de pijnlijke delen vervangt zonder het hele systeem plat te leggen, en hoe u weet wanneer een volledige herbouw werkelijk de juiste keuze is.

Waarom de big-bang herbouw zo verleidelijk is — en zo gevaarlijk

De volledige herbouw is verleidelijk omdat hij een schone lei belooft. Geen legacy-rommel meer, geen compromissen meer, een verse codebase die op de juiste manier is gebouwd met moderne tools. Op een whiteboard ziet het er vanzelfsprekend uit. In werkelijkheid tekent u in om jaren aan opgebouwde bedrijfslogica opnieuw te bouwen — veel ervan niet gedocumenteerd, een deel alleen levend in de hoofden van mensen die vertrokken zijn — terwijl de klok tikt en de rekeningen binnenkomen.

De diepere valkuil is het parallelle-universum-probleem. Gedurende de maanden of jaren die de vervanger kost, heeft u twee systemen: het oude, dat de onderneming nog steeds moet laten draaien, en het nieuwe, dat nog niet klaar is. Elke verandering die het bedrijf nodig heeft, moet twee keer worden gemaakt, anders raakt het nieuwe systeem achter op de werkelijkheid voordat het ooit live gaat. Teams branden op door beide in leven te houden. En omdat niemand mag overstappen totdat het nieuwe systeem alles doet, is er geen vroege winst, geen feedback, geen bewijs dat het werkt — alleen een lang, gespannen wachten op één enorme alles-of-niets-lanceringsdag.

Er bestaat hier een bekende industrie-overlevering, en die is verdiend: het tweede systeem, de grootse herbouw, heeft de neiging drie keer zo lang te duren als geschat en aan te komen met minder functies dan het ding dat het verving. De schatting klopt niet, niet omdat mensen slordig zijn. Hij klopt niet omdat niemand bij de start alle kleine dingen kan zien die het oude systeem stil en goed doet.

Wat 'legacy' eigenlijk betekent (het gaat niet om leeftijd)

We gooien het woord legacy rond alsof het gewoon oud betekent. Dat is niet zo. Heel wat software die al tien jaar draait is prima — saai, stabiel, betaald, en doet zijn werk. Leeftijd alleen is geen reden om iets aan te raken. De duurste fout in dit hele vakgebied is iets moderniseren dat stilletjes werkte, alleen maar omdat het er gedateerd uitzag.

Software verdient het legacy-label wanneer ze u actief in de weg zit. Wanneer u ze niet veilig kunt veranderen omdat niemand ze helemaal begrijpt. Wanneer ze niet kan koppelen aan de tools waarvan u nu afhankelijk bent. Wanneer één persoon de enige is die ze in leven kan houden. Wanneer ze zo traag of broos is dat uw team er een hele folklore van omwegen omheen heeft gebouwd. Dat is de echte definitie — niet het jaar waarin ze geschreven werd, maar de kosten die ze u vandaag oplegt en het risico dat ze meeneemt naar morgen.

Diagnosticeer voordat u iets aanraakt

Voordat één regel wordt herschreven, heeft u een eerlijke kaart nodig van waar de pijn echt zit. Meestal is het systeem waar iedereen een hekel aan heeft voor 80% prima. De ellende is geconcentreerd op een paar specifieke plekken — één traag scherm, één kapotte koppeling, één workflow die dubbele invoer afdwingt — en die paar plekken veroorzaken bijna alle klachten. Vind ze, en u heeft uw hele project gevonden.

De manier om ze te vinden is niet eerst een technische audit — het is een gesprek. Ga zitten met de mensen die het ding elke dag gebruiken en vraag hen waar het pijn doet. Waar wachten ze? Wat typen ze opnieuw? Wat vermijden ze omdat het pijnlijk is? Waar houden ze een eigen spreadsheet bij om het officiële systeem te omzeilen? Die omwegen zijn goud waard: elk ervan is een precieze röntgenfoto van een probleem dat het oplossen waard is.

• De schermen en stappen waar mensen het meest over klagen — niet in theorie, maar in hun echte dagelijkse werk.
• Elke plek waar gegevens twee keer worden ingetypt omdat twee systemen niet met elkaar praten.
• De koppelingen die kapotgingen, of er nooit waren, en zo handmatig kopiëren-plakken tussen tools afdwingen.
• Alles wat maar één persoon kan bedienen of repareren — uw single points of failure.
• De delen die werkelijk prima zijn, zodat u ze kunt beschermen en met rust laten.
• Wat de onderneming volgend jaar nodig heeft en waar het huidige systeem simpelweg niet in mee kan groeien.

Als u dit eerlijk doet, krimpt het project meestal. De ondernemer die binnenkwam met “vervang alles” loopt buiten met het besef dat hij drie dingen moet repareren. Dat is geen teleurstelling — het is een opluchting. Drie repareerbare dingen is een project dat u dit kwartaal kunt afronden. Een volledige vervanging is een jaar dat u misschien niet overleeft.

De strangler-aanpak: vervang het stuk voor stuk

Er is een patroon om dit veilig te doen, en het heeft een wat grimmige maar gedenkwaardige naam: de strangler-aanpak, naar de wurgvijg — een liaan die rond een boom groeit en geleidelijk diens structuur overneemt totdat uiteindelijk de nieuwe groei op eigen benen staat en de oude stam verdwenen is. Toegepast op software is het idee prachtig praktisch: u vervangt het oude systeem niet in één heroïsche ruil. U laat het nieuwe eromheen groeien, stuk voor stuk, totdat er van het oude niets meer over is dat iemand nodig heeft.

In de praktijk werkt het zo. U kiest één pijnlijk stuk — bijvoorbeeld de facturatiemodule waar iedereen een hekel aan heeft. U bouwt een moderne vervanging voor alleen dat stuk. U leidt de facturatie naar de nieuwe module terwijl al het andere ongemoeid op het oude systeem blijft draaien. U houdt het een tijdje in de gaten. Als het solide is, valt dat deel van het oude systeem stil, en gaat u naar het volgende stuk. Het oude systeem krimpt geleidelijk, als een kaars, in plaats van in één keer omver te worden gegooid.

Wat dit zoveel veiliger maakt dan een herbouw, is dat elke stap klein, live en omkeerbaar is. U vliegt nooit blind. Elk nieuw stuk gaat snel in echt gebruik, dus u komt snel te weten of het echt werkt. Als er iets misgaat, heeft u maar één module geriskeerd, niet de hele onderneming — en u kunt meestal terugvallen op de oude weg terwijl u het repareert. U boekt winst onderweg in plaats van één angstaanjagende lancering aan het eind. En de onderneming blijft de hele tijd gewoon draaien.

Hoe het ritme er werkelijk uitziet

1. 1
   Kies het pijnlijkste, meest op zichzelf staande stuk

   U wilt veel pijn en schone randen — een module die flink pijn doet en geen vingers in al het andere heeft. Dat is uw eerste doelwit.
2. 2
   Zet een dunne laag voor het oude systeem

   Een kleine routeringslaag beslist welke verzoeken naar het oude systeem gaan en welke naar het nieuwe stuk. Dit is de naad die al het andere mogelijk maakt.
3. 3
   Bouw en lanceer alleen dat ene stuk

   Vervang één module, breng hem in echte handen, en leid alleen dat plakje werk ernaartoe. Weken, geen jaren — en de rest van het systeem bewoog nooit.
4. 4
   Stabiliseer, ga dan naar het volgende stuk

   Zodra de nieuwe module vertrouwd is, gaat het bijbehorende deel van het oude systeem slapen. Herhaal met het volgende pijnlijke stuk, lerend terwijl u gaat.
5. 5
   Trek het oude systeem terug als het leeg is

   Uiteindelijk doet het legacy-systeem niets meer waar iemand op steunt. Pas dan schakelt u het uit — geruisloos, zonder drama, omdat alles wat belangrijk was al verhuisd is.

Merk op wat hieraan anders is dan aan de herbouw: er is geen enkele lanceringsdag om te vrezen. Er is geen parallel universum om te onderhouden. Het nieuwe systeem staat vanaf week drie in productie, verdient zijn brood en leert u dingen, in plaats van in een lab te wachten op een lancering die almaar uitloopt.

Soms hoeft u het niet eens te vervangen

Voordat u überhaupt iets vervangt, is het de moeite waard u af te vragen of het oude systeem vervangen moet worden of gewoon moet stoppen een eiland te zijn. Een verrassend aantal “we hebben een nieuw systeem nodig”-problemen zijn in werkelijkheid “onze systemen praten niet met elkaar”-problemen. De oude software doet haar werk prima — ze zit alleen in een silo en dwingt mensen gegevens met de hand heen en weer te slepen.

In die gevallen is de goedkoopste, snelste oplossing geen nieuw systeem. Het is een brug. U omhult de oude software met een verbinding — een koppeling waarmee ze automatisch gegevens uitwisselt met uw andere tools — en een moderne laag erbovenop voor de delen die mensen echt aanraken. De gedateerde motor blijft eronder zoemen; het team krijgt een nette oppervlakte en een einde aan het kopiëren-plakken. Niet glamoureus, maar vaak het hoogste rendement per euro van de hele onderneming.

Wanneer een volledige herbouw werkelijk de juiste keuze is

Ik heb deze hele gids besteed aan u de grote herbouw uit het hoofd praten, dus laat ik eerlijk zijn: soms is hij echt het antwoord. Er zijn fundamenten zo verrot dat geen hoeveelheid patchen, overbruggen of stuk-voor-stuk vervangen ze zal redden, en doen alsof het anders is stelt enkel het onvermijdelijke uit terwijl u geld uitgeeft aan het overeind houden van een lijk.

De eerlijke tekenen zijn specifiek. De technologie waarop het systeem is gebouwd is dood of stervende — geen ondersteuning, geen beveiligingsupdates, niemand meer over die ermee kan werken. De onderneming is zo fundamenteel veranderd dat het oude model totaal niet meer aansluit op de werkelijkheid. Of het systeem is zo verstrengeld dat zelfs kleine wijzigingen routinematig dingen op ongerelateerde plekken kapotmaken, wat meestal betekent dat er om te beginnen geen schone naden zijn voor een strangler-aanpak. Als er twee of drie van die dingen tegelijk waar zijn, houdt incrementeel werk op de veiligere keuze te zijn.

En hier is de stille beloning van het eerst doen van het incrementele werk, zelfs als u uiteindelijk toch herbouwt: tegen de tijd dat u daar bent, begrijpt u het systeem veel beter dan aan de start. Elke module die u verving leerde u iets dat de oorspronkelijke makers nooit opschreven. Een herbouw die door die kennis is gevoed, is een compleet ander, veel veiliger beest dan een die op dag-één-optimisme werd gelanceerd.

Het deel dat niemand noemt: het draait vooral om mensen

Hier is iets dat de technische gidsen overslaan. Het moeilijkste aan het moderniseren van oude software zijn meestal niet de code — het zijn de mensen die er jaren aan hebben gewend. Ze kennen haar eigenaardigheden. Ze hebben spiergeheugen voor haar vreemde sneltoetsen. Een nieuwe module die objectief beter is, kan de eerste twee weken toch slechter aanvoelen, simpelweg omdat ze onbekend is. Als u dat negeert, kan zelfs een perfecte technische migratie mislukken.

De incrementele aanpak helpt ook hier, bijna per ongeluk. Omdat verandering stuk voor stuk aankomt, nemen mensen ze geleidelijk op in plaats van te worden gevraagd alles op één maandagochtend opnieuw te leren. Betrek de dagelijkse gebruikers vroeg. Laat hen de vervanging mee vormgeven voordat ze klaar is. Het team dat hielp het nieuwe facturatiescherm te ontwerpen zal het verdedigen; het team waar het op werd gedropt zal het verafschuwen, zelfs als het identiek is. Modernisering is een verandermanagementproject in een softwarekostuum.

Veelgestelde vragen