Back to the Future 2007!
Zeker nog 10 jaar werk voor de
Cobol Programmeur.
Wanneer COBOL genoemd wordt,
denk je niet direct aan de meest
spannende ICT oplossingen.
Waar je echter niet snel bij stil staat
is het feit dat veel programmatuur
die de bedrijfskritische processen
ondersteunt bij zowel overheidsinstellingen
als in het bedrijfsleven,
nog steeds COBOL programmatuur
betreft, die nu al tientallen jaren
dienst doet. Naar een voorzichtige
schatting zijn er alleen al in Nederland
nu nog duizenden COBOL
applicaties die bestaan uit ruim
1 miljard COBOL coderegels.Dit aantal groeit nog steeds jaarlijks
als gevolg van de introductie van
nieuwe functionaliteit.
Met name de back office processen
van veel financiële instellingen worden
nog steeds ondersteund door COBOL
programma?s. Grote Nederlandse
banken en verzekeringsmaatschappijen
gebruiken bijvoorbeeld nog COBOL
programmatuur voor dagelijkse
productiebatches die o.a. voor onze
miljoenen bankafschriften en polissen
zorgen. Eén grote verzekeraar heeft al
gauw 1500 in COBOL geschreven
programma?s en deelsystemen die ook
nog beheerd en onderhouden moeten
worden.
COBOL staat voor Common
Business Oriented Language en is in
de jaren ?60 ontwikkeld. In de loop
der decennia is de taal verder uitgebreid
en aangepast, telkens vastgelegd
in nieuwe standaards, zoals Cobol-
68 en Cobol-74. Na Cobol 85 is in
2002 zelfs de object georienteerde
Cobol-2000 versie geïntroduceerd.
Daarnaast is ook COBOL .Net
beschikbaar gekomen, waarbij op
eenvoudige wijze user interfaces
gebouwd kunnen worden in de
modernste Microsoft omgevingen.
Desondanks wordt COBOL in de
wandelgangen van de ICT doorgaans
als verouderd beschouwd en
derhalve nauwelijks meer onderwezen
op de Informatica opleidingen.
Maar is dit uitgangspunt terecht ?
Er zijn in de afgelopen jaren enkele
pieken geweest in de vraag naar
COBOL expertise: voor het millennium
probleem en voor de introductie van
de Euro. Tijdens het oplossen van de genoemde
kwesties zijn vele programma?s
aangepast die toen reeds tientallen jaren
draaiden. Veel programmatuur stamt
nog uit de 70?er en 80?er jaren waarbij
tijdens de ontwikkeling ervan niet gedacht werd dat die nog tientallen
jaren in productie zouden zijn en in
de loop van de tijd zijn dan ook veel
?tijdelijke, quick and dirty? oplossingen
bedacht en zogenaamde ?spaghetti?
programmatuur geschreven met
vaak een onlogische structuur.
Daarbij stond de ICT toen nog in
de kinder-schoenen waarbij er nog
geen kwaliteitssystemen gehanteerd
werden en er geen eenduidige
functionele en/of technische
documentatie bestond. Ook recente
veranderingen zoals de introductie
van 10-cijferige bankrekeningnummers,
waarop de zogenaamde
11-proef van toepassing is, zorgde
voor aanpassingen waarbij wederom
COBOL expertise nodig was.
Je zou je af kunnen vragen waarom
deze ?oude? COBOL programmatuur
eigenlijk nog steeds in productie is en
niet al lang vervangen door moderne
programmeertalen op nieuwe platforms?
In het kort gezegd was hier
geen noodzaak toe: Alles draaide in
principe en de bugs die er waren zijn
in de loop van de tijd verdwenen.
Op de welbekende, betrouwbare mainframes
draait deze programmatuur
snel en is de 3GL code in principe
transparant en leesbaar. Bovendien
betreffen het, zoals eerder gezegd,
inhoudelijk complexe informatiesystemen,
die niet zo snel te vervangen
zijn door maatwerk of een standaard
pakket. Eventuele aanpassingen moeten
vaak met de grootst mogelijke voorzichtigheid
aangebracht worden omdat
functionaliteit vaak over meerdere
plaatsen binnen de systemen verdeeld
was. Voorts wordt bij deze organisaties
vaak het uitgangspunt gehanteerd dat
je een systeem dat goed, betrouwbaar
en snel draait niet hoeft te vervangen.
De volgende ICT kwesties zijn
zeer actueel en hebben gevolgen voor
veel COBOL legacy systemen:
1) Wettelijke wijzigingen, w.o. de
International Financial Reporting
Standards (IFRS).
Wijzigingen vanuit de wettelijke richtlijnen
vormen reeds decennia een
werkvoorraad voor informatici.
De introductie van de nieuwe IFRS
(International Financial Reporting
Standards) richtlijnen houdt momenteel
financieel Nederland bezig,
evenals de wet Sarbanes-Oxley (SOX).
De nieuwe, scherpere IFRS richtlijnen
hebben op alle beursgenoteerde
bedrijven invloed, waarbij de financiële
systemen ingrijpend dienen te worden
aangepast. Daarna zullen deze richtlijnen
gaan gelden voor alle overige
publicatieplichtige ondernemingen.
In tegenstelling tot het millenniumprobleem
en de introductie van de
EURO zal er op functioneel vlak veel
veranderen in de informatiesystemen
van financiële dienstverleners zoals
banken en verzekeringsmaatschappijen.
Een van de voorbeelden van de IFRS
richtlijnen is dat de waarde van de
assets een zogenaamde ?fair value? moet
gaan weergeven, waarbij de waardefluctuaties
van o.a. effectenportefeuilles
en onroerend goed over de verliesen
winstrekening zullen gaan lopen in
tegenstelling tot de huidige situatie
waarbij dit jaarlijks op de balans geactiveerd
dan wel gepassiveerd mag
worden. De impact van de vorige zin
alleen al heeft de komende jaren in
Nederland honderdduizenden uren
werk tot gevolg voor managers,
analisten, accountants, programmeurs,
testers en ontwerpers, waarbij de
legacy systemen zullen moeten worden
aangepast.
Hetzelfde geldt voor wettelijke
wijzigingen op de pensioenenmarkt,
waarbij o.a. de bevindingen van
de commissie Witteveen en de
levensloopregeling worden geïmplementeerd.
Recentelijk is tevens de herziening van het Nederlandse
ziekteverzekeringsstelsel afgerond
inzake de basisverzekering, welke
ook veel werk heeft opgeleverd.
2) De opmars van ERP systemen.
De bekendste ERP systemen zijn: SAP,
Oracle en JD Edwards. In omvangrijke
implementatietrajecten wordt deze
standaardsoftware geïmplementeerd
bij grotere organisaties.
Waarom winnen deze ERP systemen
eigenlijk marktterrein ? Het antwoord
ligt in de eerste plaats in het feit dat
de genoemde ERP systemen een
volwassenheidsfase hebben bereikt
waarbij, in tegenstelling tot de eerst
geintrodu-ceerde versies, tegenwoordig
75 tot 80 % van de vereiste functionaliteit
gedekt kan worden door de
genoemde ERP systemen. Daarnaast
speelt het kostenoogpunt mee: hoewel
deze pakketten en de implementatie
ervan kostbaar zijn, is maatwerksoftware
doorgaans duurder indien
je de totale kosten (total cost of
ownership) in ogenschouw neemt
over de economische levensduur.
Overigens blijkt de resterende 20-25%
van de functionaliteit, die specifiek
op de betreffende organisatie van
toepassing is, opgelost te moeten
worden middels maatwerk omdat
dit niet of niet volledig door de
gekozen ERP oplossing kan worden
opgelost. Het gaat hierbij specifiek
om de complexe bedrijfslogica die
uitsluitend op de betreffende organisatie
van toepassing is. Ook hierbij
dienen vele koppelingen (interfaces)
tussen front office en back office
legacy systemen te worden ontworpen,
ontwikkeld en/of aangepast.
ERP systemen zouden de reeds
lang bestaande legacy systemen kunnen
vervangen, of althans grote delen ervan.
Dit zou opgaan voor met name front
end oplossingen. Invoer- en raadpleegschermen laten
zich relatief eenvoudig standaardiseren
en parametriseren en middels
generatoren worden de Graphical
User Interfaces opgebouwd. Ook de
eenvoudige tot redelijk complexe
validaties en standaard overzichten
kunnen binnen de ERP implementaties
gerealiseerd worden. Voor de back end
functionaliteit echter, waarin bijvoorbeeld
complexe batchverwerkingen
plaatsvinden, is dit echter veel minder
snel te doen. Hoewel ERP leveranciers
tegenwoordig veel branche specifieke
oplossingen bieden, weerhouden de
complexiteit van het geheel en de grote
risico?s van een volledige ERP implementatie
veel potentiële klanten hiertoe
over te gaan.
Klaas Kok van Corus onderschrijft
dat de laatste jaren deelfunctionaliteiten
zijn ondergebracht in SAP, meer stelt
tevens dat er daarnaast veel aanvullende
functionaliteit is ontwikkeld in COBOL.
3) Web-ontsluiting, extranet omgevingen
en integratie.
De ontwikkeling van de afgelopen jaren
op internet gebied zijn snel gegaan en
hadden in de beginfase geen impact op
de back office systemen. In die periode,
midden jaren negentig, volstond het
voor een bedrijf wanneer het een eigen
website had met voornamelijk een infor-
merende functionaliteit.
Gaandeweg is dit uitgegroeid tot een
wezenlijk voorportaal van elk bedrijf
dat naast communicatiemedium
tevens een wervende en/of commerciële
functie heeft voor potentiële klanten,
sollicitanten en overige relaties.
Daarbij is het extranet portal niet
meer weg te denken, waarbij klanten
en andere relaties direct in kunnen
loggen en hun mutaties door kunnen
geven. Extranet portals dienen tevens
gekoppeld te worden met de back
office legacy systemen door middel
van interfaces.
De aanpassingen die uit voorgenoemde
punten voortvloeien, komen
boven op het reguliere onderhoud en
de reeds bestaande interfacing van
en naar COBOL systemen en zullen
in de nabije toekomst een forse
werkvoorraad gaan vormen.
Gevolgen
De gevolgen van de genoemde ontwikkelingen
zijn in het kort:
Informatiesystemen worden complexer,
behoefte aan flexibiliteit wordt hoger.
Dit lijkt wellicht een open deur: in
de afgelopen decennia zijn informatiesystemen
alleen maar complexer
geworden en niet eenvoudiger.
Ook ICT-organisaties lijken te leren
van het verleden, waarin men de
wijzigingen in bijvoorbeeld wet- en
regelgeving moet implementeren.
Ook wordt een steeds kortere time
to market verwacht door de klanten
van de betrokken organisaties.
De genoemde ontwikkelingen hebben
gemeen dat ze de behoefte aan flexibele
informatiesystemen vergroten, waarbij
je van tevoren niet weet wat er exact
gaat veranderen, maar wel dat er gaat
veranderen. Deze behoefte wordt
doorgaans verwerkt in een integraal
informatieplan waarin het informatiebeleid
voor de komende jaren wordt
verwoord. Hierbij zouden twee randvoorwaarden
een grote rol moeten
spelen :
1) Interoperabiliteit , dit wil zeggen:
modulaire opzet van informatiesystemen,
waarbij de afzonderlijke
bouwstenen afzonderlijk onderhoudbaar
dan wel vervangbaar
zijn.
2) de mogelijkheid tot ontkoppeling
van de deelsystemen. Dit vereist
een andere manier van denken,
ontwerpen en programmeren dan
voorheen. Waarom dat met name
voor COBOL systemen veel gevolgen
heeft, komt omdat deze in feite uit het stenen ICT-tijdperk afkomstig
zijn. De toenmalige eisen die aan
deze systemen werden gesteld,
liggen op een geheel ander vlak dan
tegenwoordig. Een voorbeeld: aan
een slimme, flexibele architectuur
werd nauwelijks aandacht besteed,
maar aan gebruikte geheugen- en
schijfruimte des te meer, waarbij
elke byte telde. Tegenwoordig zijn
de kosten van opslagmedia en
processors een fractie van toen
en worden dus gemakkelijker
?bijgeprikt?. Daarnaast stond de
systeem-ontwikkeling in feite nog
in de kinderschoenen en was die
nog volop aan het evolueren
vanuit het pons-kaartentijdperk.
De programmeur die in het verleden uitsluitend met coderen
bezig was, moet nu veel meer in
architectuurvraagstukken thuis
zijn, zoals Service Oriented
Architecture (SOA), concepten
kunnen interpreteren en materiekennis
bezitten, wil hij een
toegevoegde waarde in het systeemontwikkelingsproces
kunnen
leveren. Zoals eerder genoemd is
adaptief en correc-tief onderhoud
uit het verleden bij COBOL
systemen vaak ad-hoc opgelost
zonder deugdelijke documentatie,
zodat het ook in dit opzicht
gewoonweg complexer wordt.
1Een duidelijk herkenbaar voorbeeld vormen interfaces
van en naar het GBA of financiële pakketten.
Grotere afhankelijkheid van
informatiesystemen.
Samenhangend met het vorige punt
kan gesteld worden dat de informatiesystemen
steeds bedrijfskritischer
worden, aangezien steeds meer
bedrijfsprocessen door de informatiesystemen
worden ondersteund.
Tegenwoordig zien steeds meer grote
organisaties de noodzaak voor een
deugdelijk risk management en wordt
in het contingency plan veel aandacht
besteed aan vooral betrouwbaarheid,
beheersbaarheid, continuïteit en
beveiliging van hun ICT platforms.
Waarom dit specifiek voor de COBOL
systemen van toepassing is, komt
omdat die voornamelijk in financiële
omgevingen draaien waarin direct de core-business wordt ondersteund op
een centraal mainframe; uitval betekent
altijd kostbaar productiviteitsverlies.
Werkelijk alle transacties bij financiële
instellingen worden tegenwoordig in
een informatiesysteem vastgelegd en
bij een eventuele productieverstoring
ligt in feite het hele bedrijf ?plat?.
Hogere ICT kosten.
Dat het implementeren van de
bovengenoemde kwesties veel tijd,
inspanningen en (dus) veel geld
gaan kosten behoeft geen betoog.
Hoeveel dit exact gaat kosten, verschilt
nogal per organisatie. Opvallend is
dat veel organisaties dit niet eens
grofweg in kunnen schatten, omdat
zij simpelweg nog niet weten wat
voor (wets)wijzigingen op hun af zal
komen in de komende jaren. Middels
impact analyses zal steeds bepaald
moeten worden wat er gewijzigd moet
worden. COBOL systemen draaien
veelal op mainframes; platforms die
in vergelijking tot andere hardware
alternatieven niet echt goedkoop zijn.
Aanpassingen in hard- en software
zullen voor COBOL systemen derhalve
doorgaans duurder uitpakken
dan andere, modernere systemen,
mede omdat er geen case-tools en
codegeneratoren beschikbaar zijn ,
zoals bij 4GL systemen. De betrokken
organisaties hebben geen keus bij
wetswijzigingen: ze moeten wel blijven
investeren in de informatiesystemen.
De huidige technologische vooruitgang
op het gebied van webontsluiting
wordt bij commerciële organisaties
als een push factor beschouwd, mede
omdat zij de concurrentie hiermee een
stap voor kunnen zijn (of blijven).
Uitstervende COBOL expertise:
risico of kans ?
De echte COBOL programmeur
?sterft? uit en degenen die de bestaande
programmatuur geschreven
hebben, hebben zich tijdens de dalen
in vraag naar COBOL expertise laten
omscholen of gaan zo langzamerhand
met pensioen.
Hierbij komt nog dat het dalende
aan-tal startende, programmerende
ICT?ers liever voor iets sexier kiest
als .NET, Java, Oracle of SAP.
Ook de in de afgelopen decennia
geschreven spaghetti programmatuur
dient echter nog te worden onderhouden,
waarbij het uitgangspunt
blijft dat deze bedrijfskritische
programmatuur betrouwbaar moet
blijven draaien. Volgens ingewijden
vormt dit een wezenlijk risico, omdat
de continuïteit in het beheer hiermee
gevaar kan komen. De functionele
en technische kennisborging omtrent
COBOL systemen is derhalve een
groot attentiepunt.
"Ronald Vervenne, Unitmanager
Mainframe Services bij Sogeti onderschrijft
de stelling dat er de komende
jaren nog veel werk ligt in het COBOL
vak: 'Wij zien dat grote klanten voor de
continuïteit en beschikbaarheid kiezen
van het Mainframe in combinatie met
COBOL. Daarom investeren wij in
kennis en leiden wij tevens nieuwe
COBOL programmeurs op om aan
de vraag te kunnen blijven voldoen'."
Nog steeds is de combinatie van
COBOL op het Mainframe bijzonder
snel, robuust en betrouwbaar.
Daarnaast is de code zeer goed leesbaar,
wat de onderhoudbaarheid
ten goede komt.
De hierboven beschreven ontwikkelingen
geven aan dat er in de COBOL
wereld, ondanks het wellicht stoffige
imago, nog steeds veel te doen is en
dat zal in de komende jaren naar
verwachting nog wel zo blijven.
Dit kan ook een kans blijken voor al
de IT?ers die op dit moment zoekende
zijn naar een nieuwe uitdaging.
Reacties op dit artikel ?
Ga naar http://www.mfsw.nl
en geef je opmerking of reactie!
Een e-mailbericht sturen kan
natuurlijk ook naar:
Randolph.Nuis@MFSW.nl
Randolph Nuis is Business
Development Manager bij MFSW
Software en Detachering.
|
