Beheer

IT beheer
datacenter

Laat uw oude degelijke Cobol gewoon staan

De legacy van IT zijn de code-generatoren en slecht onderhoudbare pakketoplossingen van de periode ’95-’05. Die moeten het eerst worden opgeruimd

© CC0 - Pixabay.com ElasticComputeFarm
17 augustus 2017

CIO’s van grote organisaties hebben allemaal een IT-erfenis van decennia. De algemene gedachte is dat we van de oudste spullen af moeten. Maar niemand krijgt een freeze van twee jaar plus enkele miljoenen om zo’n massieve operatie uit te mogen voeren.

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.

Reactie toevoegen
2
Reacties
Marcel 04 september 2017 09:11

"Want die Cobol programma’s uit tweede helft jaren ’80 zijn vaak goed ontworpen ". Dit kan best wel waar zijn, maar "code rot" is niet tegen te houden. Tevens zijn vele Cobol sources nog een stuk ouder.
Het hier genoemde Containerisering en Micro-services is, volgens mij, de juiste weg. Hierdoor hak je alles in kleine, goed onderhoudbare stukjes. Er is al zeer veel op het internet te vinden over hoe je dit kan aanpakken.

Peter Steenmeijer 17 augustus 2017 21:46

Het probleem is dat het coderen als een minderwaardige taak wordt gezien binnen de ICT. Daardoor komt het coderen nooit tot volle wasdom en wordt er derhalve inferieure software opgeleverd. In plaats van het coderen tot kunst te verheffen en dan niet hoe korter hoe beter, maar hoe onderhoudbaarder hoe beter, wordt er telkens voor gekozen om nieuwe methodes te implementeren, die de onderhoudbaarheid zouden moeten verbeteren. Gevolg is een wirwar aan methodes, waardoor de beschikbare codeercapaciteit wordt versplinterd en dus ook nog slechter wordt. Ik heb vanaf 1968 tot 2011 Cobol gecodeerd, waarvan vanaf 1977 tot 2011 voor o.a. dezelfde toepassing en in de lifetime van die toepassing 5 keer gemigreerd naar steeds nieuwere hardware en operating systems. De ICT-markt laat zijn oren hangen naar de commercie en waar je als ICT-manager mee kunt scoren. Heel veel van wat kan, werkt niet en dan valt er weer een ICT-projekt in duigen. Maar wat werkt is ouderwets en smoelt niet op e.o.a. manier.