|
Back to the Future!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 honderden COBOL applicaties die bestaan uit ruim 1 miljard COBOL coderegels. 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. 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 objectgeoriënteerde Cobol-2000 versie geïntroduceerd. 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 kinderschoenen 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. De volgende ICT kwesties zijn anno 2004 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 wer Sarbanes-Oxley. De nieuwe, scherpere IFRS richtlijnen hebben in eerste instantie (m.i.v 2005) op alle beursgenoteerde bedrijven invloed, waarbij de financiële systemen ingrijpend dienen te worden aangepast. Daarna (2007) 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 verlies- en 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 zullen worden geïmplementeerd. Actueel is tevens de herziening van het Nederlandse ziekteverzekeringsstelsel dat in 2006 in zal moeten gaan. 2) De opmars van ERP systemen. De bekendste ERP systemen zijn: SAP, Oracle, Peoplesoft 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 geïntroduceerde 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. 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 informerende 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 (bijvoorbeeld die van en naar het GBA) 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 2 randvoorwaarden een grote rol moeten spelen : interoperabiliteit en 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 systeemontwikkeling in feite nog in de kinderschoenen en was die nog volop aan het evolueren vanuit het ponskaartentijdperk. De programmeur die in het verleden uitsluitend met coderen bezig was, moet nu veel meer in architectuurvraagstukken thuis zijn, concepten kunnen interpreteren en materiekennis bezitten, wil hij een toegevoegde waarde in het systeemontwikkelingsproces kunnen leveren. Zoals eerder genoemd is adaptief en correctief onderhoud uit het verleden bij COBOL systemen vaak ad-hoc opgelost zonder deugdelijke documentatie, zodat het ook in dit opzicht gewoonweg complexer wordt. 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. 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 exact 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 aantal 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. 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. Artikel, tevens gepubliceerd in Automatisering Gids d.d. 28-5-2004, is geschreven door Randolph Nuis, Business Development Manager bij MFSW Software en Detachering uit Gouda. Reacties op dit artikel? Ga naar www.mfsw.nl of Mailto:info@MFSW.nl |
|
|
