Laat uw oude degelijke Cobol gewoon staan

Toch moeten we van onze oude spullen af. Dat is echter geen sinecure. De meeste systemen zijn de afgelopen jaren knap verknoopt om diensten op portalen te leveren, het bedrijf data driven te maken en ‘straight through processing’ te realiseren. Ontkoppelen, opruimen en vervangen is daardoor geen optie! Te complex, te tijdrovend en te duur.

Je kan natuurlijk altijd beginnen met snijden. Bijvoorbeeld in assembler-applicaties die slecht gedocumenteerd zijn. Exoten in Smalltalk kunnen doorgaans ook wel weg. Maar veel andere oude applicaties vragen om een genuanceerdere benadering. Dat hangt af van het onderliggende besturingssysteem, de database-technologie en de taal waarin de applicatie ontwikkeld is.

Kiezen

Er zijn verschillende keuzes: replatform (de applicatie naar een nieuwere infrastructuur als Linux brengen, rebuild (gewoon overnieuw bouwen in bijvoorbeeld .Net of Java) of replace (door een alternatieve bestaande pakket/cloud oplossing).

Uw bedrijf vraagt om lagere kosten en meer wendbaarheid. Als de run-change ratio boven de 80 komt (van elke IT-euro heeft u meer dan 80 cent nodig voor het aan de praat houden van het bestaande) dan móét er opgeruimd worden. Agile en Devops helpen daarbij ook in de wendbaarheid. Maar dat is niet genoeg, u zal moeten ingrijpen in uw IT landschap.

De vlucht naar voren kan u een tijdje redden. Dan bouw je een enorme data-bak waar alle data van de bronsystemen in gezet worden. Zo kan functioneel vaak een geweldige sprong vooruit worden gemaakt. In combinatie met een paar slimme cloud-toepassingen helpt dat zeker de dienstverlening aan klanten een impuls te geven. Maar met die bronsystemen moet ook iets gebeuren.

Nu komt de crux

De verouderde applicaties en infrastructuren moeten dus ‘lichtvoetiger’. De sprong naar iets compleet nieuws is vaak te groot en er zijn teveel pogingen die niet goed hebben uitgepakt (zie rapport commissie Elias, 2014). De vraag is dus waar je je beperkte resources op moet inzetten. En nu komt de crux: laat oude degelijke Cobol toepassingen staan en ruim eerst de code-generatoren en slecht onderhoudbare pakketoplossingen van de periode ’95-’05 op. Dáár zit de grootste winst!

Zorg daarnaast dat je applicatie- en infra-landschap ‘loosely coupled’ wordt door vaste verbindingen losser te maken. API’s, micro-services, Docker, enzovoort zodat je in afzonderlijke compartimenten kunt opruimen én vernieuwen. Dát geeft wendbaarheid en voorkomt dat je legacy-rationalisatie op de verkeerde applicaties richt. Want die Cobol programma’s uit tweede helft jaren ’80 zijn vaak goed ontworpen door mensen die nog wisten hoe je programma’s en databases vakkundig gebruikt, die kunnen nog we even mee.

Het advies is dat er maar drie opties zijn voor uw applicatie keuzes voor de komende jaren:

(1) Kies een toekomstvaste taal als C/.NET/Java of Cobol;

(2) Kies een generator of pakket waarvan u eenvoudig weer afscheid kan nemen;

(3) Kies pakketten en talen waarvan vrij zeker is dat ze over tien jaar nog massaal beschikbaar zijn en ondersteund worden.

Anders bouwt u vandaag de legacy voor de CIO die u binnen vijf jaar opvolgt en een hoop geld zal moeten uitgeven om uw ‘legacy’ op te ruimen.