We horen weinig meer over legacy. Op het hijgerige af stond dit onderwerp in de belangstelling tijdens de millenniumwisseling. Maar de Y2K-ziekte bleek mee te vallen: geldautomaten, telefoonverkeer en andere computergestuurde maatschappelijke voorzieningen bleven gewoon werken. Sindsdien komen we 'legacy transformation' niet meer in trendlijstjes tegen.

Is legacy nu weg? Nee, het bestaat nog steeds. Het zijn verouderde applicaties die nog wel functioneren en waarvan je dus wel nog afhankelijk bent. Maar je wilt er eigenlijk niet meer in investeren, omdat er allang nieuwere, verbeterde en efficiëntere technologieën beschikbaar zijn. Liefst laat je ze daarom 'slapen'. Legacy bestaat uit miljoenen slecht gedocumenteerde lines of code. Daardoor is het een raadsel wat het effect is van een verandering. Je drukt hier en vervolgens ontstaan op tal van andere plaatsen bulten. Je wilt er dus van nature zo min mogelijk aankomen.

De crisis heeft hierop een ongewenst effect. Bedrijven hebben weinig trek in miljoenenverslindende projecten voor nieuwbouw. Door de huidige cashflowdruk is dit te duur. Dus wordt er weer gesleuteld aan legacy. Back to the future? Ja, want we worden er niet minder maar juist weer meer afhankelijk van.

De vraag is wie er straks eerder met pensioen gaat: de legacy of de laatste medewerkers met essentiële kennis van dit verouderde systeem. De AOW-leeftijd mag dan wel worden opgetrokken, maar ik weet zeker dat wanneer de laatste generatie ervaringsdeskundigen gaat genieten van hun oude dag er nog steeds veel legacy zal bestaan. We kunnen natuurlijk Indiërs opleiden en een pool moderne kennisgastarbeiders aannemen om deze erfenis te onderhouden. Maar dat is een lapmiddel, het lost de oorzaak van het probleem niet op. Net als met de scheepsbouw in de jaren zeventig zul je moeten accepteren dat legacy als Cobol en PL/1 een 'laatste levensfase-industrie' is.

Flexibiliteit en wendbaarheid is dan ook vandaag de dag nodig: simpelweg veranderen, testen, toevoegen en 'gaan met die banaan'. Maar dat wordt door de spaghetti aan oude code een bijna onmogelijke taak. De impactanalyse, het testen en de integratie kosten soms wel negentig procent van de tijd en het geld dat je besteedt aan changes. Dat is het echte probleem, niet legacy an sich. Hoe kom je nu van de probleemlegacy af? In 'big bangs' geloof ik niet meer. Waarom zou je vandaag de dag nog een bedrijfsbrede implementatie van ERP op je hals halen? Zo'n muur-tot-muur inrichting kost miljoenen euro's. En ben je daarna wel flexibel? Bedrijven zullen stap voor stap verouderde systemen moeten afschakelen en selectief nieuwbouwen.

Er is ook een ander te overwegen alternatief, dat van het geautomatiseerd omzetten van oude code in nieuwere talen als J2EE of .Net. Waarom kiezen voor omzetten? Bedrijfsprocessen veranderen niet drastisch. Rekenregels blijven voor vijfennegentig procent hetzelfde bij dure migraties. 'Wegmigreren' is dus kapitaalvernietiging. Wanneer omzetten geen optie blijkt, dan is het zeker zinvol om een geautomatiseerd repository te bouwen waarin alle verwijzingen in de codelijnen staan, ofwel de software-brei aan when, else en go to-statements. Bij gebrek aan goede documentatie is een repository een minimale stap om niet afhankelijk te zijn van het vergrijzende kenniswerkers. De waarheid zit in de code. Die moet je boven tafel krijgen.

Steve Van Wyk, CIO van ING, stelde laatst in een vlammende presentatie voor CIO's: "Cobol is not cool". Dat speelt dus ook mee, want je wilt nieuw talent niet oud werk laten doen. Er komt een generatie CIO's aan die jonger is dan de oudste systemen in hun bedrijf. Niemand wil over tien jaar écht in de problemen zitten na de afscheidsborrel van een laatste Cobol-crack. Dat is misschien wel de beste reden om nu echt iets aan legacy te gaan doen.