De huidige ‘installed base’ aan informatie-systemen bestaat nog steeds voor het merendeel uit mainframes. Trends van de laatste jaren zoals downsizing en client/server zetten niet zo stormachtig door als werd verwacht. De reden is dat de kosten voor het compleet vernieuwen van de systemen te hoog zijn. Volgens consultant Frans Tolen is het belangrijkste probleem van legacy- systemen de onduidelijkheid over de betekenis van de data. Het werken met gegevenspakhuizen is een oplossing.
Grote problemen met legacy-systemen (verouderde systemen) zijn altijd de slechte toegankelijkheid van de gegevens en de inflexibiliteit van de gebruikte talen geweest. Tot op heden worden deze problemen opgelost met tools die in staat zijn de gegevens los van de legacy-systemen te benaderen. Voorbeelden hiervan zijn SAS en Focus. Dit soort tools maakt geen gebruik van metagegevens. Hierdoor kan het gebeuren dat in het ene rapport een variabele met de naam ‘geslacht’ aangeeft dat het een man of een vrouw betreft, terwijl in een ander rapport de variabele met dezelfde naam een code representeert die aangeeft of een rekening op naam van een man of een vrouw staat of een en/of-rekening betreft. Deze situatie zal bekend voorkomen en als niet gewenst worden ervaren.
In de loop van de tijd zijn er zeer veel pogingen gedaan om tot betere oplossingen te komen. Soms waren ze succesvol, maar meestal liepen ze uit op fiasco’s. Al deze oplossingen hebben geen eenduidig en afdoend antwoord kunnen geven op de vraag waar het allemaal om begonnen is: inzicht in de gegevens van de legacy-systemen.
De pogingen hebben wel geleid tot een steeds beter begrip van de problemen en een beter inzicht in de oplossingen. Eigenlijk is er sprake van een ‘natuurlijk’ evolutieproces op weg naar volwassenheid op het gebied van automatisering en informatisering. De lessen die men heeft geleerd bij het ondernemen van al deze pogingen zijn zeker niet voor niets geweest. Het helpt bij het reduceren van de inspanningen die vereist zijn voor het bereiken van een volgend stadium.
De volgende stadia zijn te onderkennen:
– Creatie/rapportage-legacy-systemen ;
– Computergebruik door de eindgebruiker (end user computing);
– modellering van bedrijfsgegevens;
– reverse engineering;
– client/server en object-oriëntatie;
– werken met gegevenspakhuizen;
– global client/virtual machines.
De diverse belangengroepen binnen één organisatie bevinden zich in diverse stadia. Alle stadia lossen slechts een deel van het echte probleem op. Met betrekking tot het ontwikkelproces van een gegevenspakhuis is het van belang aan te geven waaraan een bepaald stadium te herkennen is, welke problemen hiermee zijn opgelost en welke juist ontstaan.
De problemen met de legacy-systemen nemen toe en de roep om een oplossing wordt steeds luider. Als we aannemen dat de huidige in produktie zijnde programma’s en gegevensbewaarplaatsen de nu geldende bedrijfsregels representeren, zou het mogelijk zijn deze regels van hieruit te reconstrueren en te herbouwen in modernere omgevingen. De huidige trends zoals het opslaan van gegevens in gegevenspakhuizen en het raadplegen ervan (datawarehousing en datamining) kunnen een grote rol spelen in het verkrijgen van dit inzicht. Belangrijk resultaat hiervan is het opbouwen van kennis over de legacy-systemen. Deze kennis kan opnieuw gebruikt worden voor herbouw-doeleinden.
Creatie/rapportage
Legacy-systemen zijn in het verleden gebouwd om de operationele processen te ondersteunen, uitgaande van een levensduur van maximaal tien jaar. Ze bestaan echter nog steeds en keer op keer worden er nieuwe rapportage-programma’s geschreven. Zolang er geen herbouw volgens een nieuwe applicatie-structuur heeft plaatsgevonden, zal dat noodzakelijk blijven.
Aangezien de rapportage-programma’s net zo slecht zijn gedocumenteerd als de legacy-systemen zelf, genereren ze ook dezelfde problemen. Hierdoor gaan programma’s op zich weer een legacy-systeem vormen. Met de rapportage-systemen werden de legacy-systemen bruikbaar voor meerdere doeleinden. Dit vormde het begin van computergebruik door de eindgebruiker (end user computing).
Eindgebruiker
Met de komst van PC’s gingen eindgebruikers zelf programma’s ontwikkelen. Door betere kennis van de materie was succes verzekerd. Eindgebruikers hielden echter geen rekening met zaken als beheersbaarheid en onderhoudbaarheid; dit werden de grootste nadelen. Als korte-termijn oplossing werd decentralisatie van de centrale automatiseringsafdeling een geliefd instrument. Hiermee werd automatiseringskennis naar de eindgebruikers gebracht, die steeds professioneler werden.
Het inzicht in de legacy-systemen werd hiermee niet vergroot. Integendeel. Het werd alleen nog maar slechter omdat afdelingen konden functioneren zonder controle van de centrale automatiseringsafdeling. Onder invloed van een aantal vooraanstaande organisatie-adviesbureaus en met de introductie van i-case-tools streefde men vervolgens naar een model van bedrijfsgegevens.
Model bedrijfsgegevens
Het bedrijfsgegevens-model (corporate data model) gold ooit als de oplossing voor interpretatieproblemen van data. Door de hele organisatie dezelfde bedrijfsregels te laten hanteren werden alle inconsistentie-problemen opgelost. Het bedrijfsgegevens-model maakte hergebruik van kennis, programma’s en data mogelijk. Door het gebruik van i-case-tools konden de IT-kosten drastisch verminderen.
De praktische uitvoerbaarheid werd echter uit het oog verloren. De resources die benodigd waren voor het implementeren van een bedrijfsgegevens-model in een corporate database, waren toen al te groot. Daardoor heeft men getracht het bedrijfsgegevens-model te vullen vanuit de reguliere projecten. Binnen een project wordt de optiek van de informatie-analist op de data echter bepaald door het deel van de organisatie waar hij bezig is. Deze optiek hoeft niet overeen te komen met andere delen van de organisatie. Die besluiten dan tot het implementeren van een eigen variant op de data. Binnen de grotere organisaties leverde dit op zijn minst twintig personeelstabellen op, hetgeen niet resulteerde in een oplossing van de problemen van de legacy-systemen.
Reverse engineering
Vervolgens heeft men geprobeerd de programma’s van deze legacy-systemen te onderzoeken. Vanwege het grote aantal regels broncode van de legacy-systemen zijn goede hulpmiddelen vereist. De huidige hulpmiddelen zijn goed in staat een beeld te geven van gebruikte databases; het boven water krijgen van de bedrijfsregels in programma’s gaat echter zeer moeizaam.
De oudere legacy-systemen maken vaak geen gebruik van een database. Van programma’s zijn soms alleen executable programma’s beschikbaar. Reverse engineering is dan een moeilijke zaak. Deze methode levert wel wat inzicht in de legacy-systemen. Hergebruik van dit inzicht voor andere doeleinden dan het ondersteunen van de operationele processen zoals DSS-support, management-informatie en database- marketing is nog niet mogelijk.
Downsizing
De start van downsizing-processen is met name ingegeven door het kostenaspect. Veel decentrale ontwikkel-afdelingen beschikken inmiddels over midrange-systemen. Met de invoering van kleinere, moderne machines (in vergelijking met een mainframe) werd ineens een andere applicatie-architectuur mogelijk en – vanuit dezelfde technische mogelijkheden – ook object-oriëntatie.
Midrange-systemen zijn op het gebied van beveiliging, betrouwbaarheid, autorisatie en robuustheid nog niet op het niveau van de mainframes beland. Met name de zware beveiligingsaspecten en beheerseisen kunnen niet worden waargemaakt. Het is daarom noodzakelijk de ervaring met mainframes in te brengen in de midrange-systemen. Zonder deze inbreng worden er geen kosten bespaard en is het downsizing-traject bij voorbaat tot mislukken gedoemd.
Tot op heden houden de client/server-applicaties veelal niets anders in dan het positioneren van de database – met al zijn logica – op een server en het implementeren van een applicatie – met de daarbij behorende logica – op een client. Dit is een scheiding tussen database-logica en andere logica waardoor de programma’s wel kleiner kunnen worden.
Een client/server-architectuur waarbij een client iets vraagt aan een server, die autonoom zijn taak verricht en bericht teruggeeft aan zijn cliënt, kan met recht object-georiënteerd genoemd worden. Het aantal echte object-georiënteerde applicaties dat geïmplementeerd is, is nog zeer gering.
Downsizing-processen dragen niets bij aan het verkrijgen van meer inzicht in de legacy-systemen omdat juist deze systemen niet ge-downsized kunnen worden zonder het plegen van herbouw.
Gegevenspakhuis
Een operationeel gegevenspakhuis verenigt de goede elementen van rapportage-legacy-systemen, computergebruik door eindgebruikers, reverse engineering, modellering van bedrijfsgegevens en client/server object-oriëntatie in zich. Wel moet er gewaakt worden voor het begaan van dezelfde fouten.
Rapportage-legacy-systemen moeten het gegegevenspakhuis voeden. Computergebruik door eindgebruikers levert de ervaring en kennis van de gebruikers van het gegevenspakhuis en de vrijheid die ze hebben om het pakhuis te raadplegen.
Reverse engineering is noodzakelijk om achter de oorsprong van data en logica te komen, zoals nodig is in de voedingsprogramma’s van het gegevenspakhuis.
Modellering van bedrijfsgegevens zorgt voor overeenstemming over de betekenis van data, en ervaring in het gebruik van case-tools.
Client/server, object-oriëntatie, en downsizing bieden de bouwstenen voor de implementatie.
Juist deze bundeling van krachten uit het verleden zorgt voor inzicht in de legacy-systemen. Het gegevenspakhuis zorgt immers voor een stabiele situatie waarin – naast data – juist kennis over de data is vastgelegd. Deze kennis is dan weer te gebruiken voor de herbouw van de legacy-systemen.
Door de enorme complexiteit van de legacy-systemen en de hoge bedrijfswaarde is een complete vervanging van deze systemen een zeer risicovolle zaak. De risico’s zijn eigenlijk te groot om in een keer te nemen. Vanuit de gestabiliseerde situatie kan teruggewerkt worden naar de aanleverende systemen. Bij het herstructureren van de legacy-systemen vanuit het gegevenspakhuis worden de risico’s gespreid en makkelijker beheerst.
Doordat aanpassingen in de legacy-systemen doorwerken in het gegevenspakhuis is een flexibele ontwikkel-omgeving voor het gegevenspakhuis noodzakelijk. De transformatieprogramma’s moeten gegenereerd worden vanuit procesmodellen om het transformatie-proces van legacy-systeem naar gegevenspakhuis consistent en controleerbaar te maken. De repository van de i-case moet ook toegankelijk zijn voor eindgebruikers zonder daarvoor het i-case-tool te gebruiken. Beide voorwaarden zijn nieuw te stellen eisen aan i-casetools.
Als men zich realiseert dat het gegevenspakhuis een tussenstap is op weg naar een gedistribueerde omgeving, dient men de keuze voor de componenten van het gegevenspakhuis hierop af te stemmen. Dit houdt in dat men moet kiezen voor een i-case-tool dat code genereert die overdraagbaar is, voor een database die transparant kan communiceren met andere databases, en voor hardware die via standaard netwerkprotocollen met elkaar kan communiceren. Daarnaast moeten de ontwikkelingen op het gebied van open en gedistribueerde systemen nauwlettend gevolgd, en waar mogelijk toegepast worden.
Implementatie
Het implementeren van gegevenspakhuizen zal leiden tot meer inzicht in de legacy-systemen van de organisatie. Als men daarnaast beseft dat de implementatie van gedistribueerde systemen een zeer complexe zaak is vanwege het benodigde inzicht in de legacy-systemen, is het duidelijk dat een gegevenspakhuis een nuttige stap is op weg naar een gedistribueerde omgeving. Globalisering zal leiden tot de noodzaak van gedistribueerde systemen, zodat de ontwikkeling van een gegevenspakhuis noodzakelijk is voor iedere grote onderneming.
Door het verkregen inzicht in de legacy-systemen is het duidelijk geworden welke onderdelen daarvan niet bijdragen aan de ondersteuning van de operationele processen. De functionaliteit van deze onderdelen dient als eerste te worden vervangen door herbouw via het gegevenspakhuis. Daarna volgt verwijdering uit de legacy-systemen. Hierdoor blijft alleen de functionaliteit over die benodigd is voor het ondersteunen van de operationele systemen.
Global client/virtual machines
Globalisering zal een sterke invloed gaan uitoefenen op de eisen van gebruikers van geautomatiseerde systemen. Van gebruikers kan men niet verwachten dat ze weten waar ze hun data kunnen vinden. Dit dient ondervangen te worden door een intelligente database waarin exact bijgehouden wordt welke data en welke programma’s zich waar bevinden. De gebruikelijke oplossing met een mainframe als centrale bewaarplaats resulteert in overbelasting van de mainframes en van de netwerken. Dit vergroot de noodzaak van gedistribueerd werken en zal leiden tot zogeheten global clients van één virtuele machine.
De enorme verscheidenheid aan hardware en software vereist standaardisatie. Alleen hierdoor kan zeker gesteld worden dat uitwisseling tussen al deze systemen mogelijk is.
Strategisch belang
Organisaties en mensen die zich in het verleden hebben beziggehouden met zaken als het modelleren van bedrijfsgegevens, i-case-tools, downsizing en rapportage, moeten beseffen dat dit waardevolle zaken zijn geweest die de implementatie van het gegevenspakhuis-concept vergemakkelijken. Vanuit die optiek is een beeld te geven van de positie van de organisatie op haar weg naar het werken met gegevenspakhuizen.
Daarnaast moet een organisatie weten wat de toekomst van de legacy-systemen is. Indien men tot de conclusie komt dat herbouw van de systemen in de toekomst noodzakelijk is, wordt de keuze voor het gegevenspakhuis van strategisch belang en dient men de componenten ervan hierop af te stemmen. Deze keuze moet gemaakt worden alvorens men tot definitieve oplossingen komt voor de realisatie van het gegevenspakhuis.
Frans Tolen is consultant datawarehousing bij CMG Finance.
