Het probleem bij het integreren van legacy-systemen en nieuwe applicaties is het identificeren van zaken die de moeite van het integreren waard zijn. Dit is niet alleen een functioneel, maar ook een technisch probleem. De verwachtingen zijn vaak te hoog gespannen. Het is voor managers niet altijd gemakkelijk te begrijpen dat er substantiële technische problemen overwonnen moeten worden.
Om een legacy-applicatie te integreren, is het noodzakelijk dat je aanwijst welke functies opnieuw gebruikt moeten worden. Daarna moet de desbetreffende code worden geïsoleerd en beschikbaar worden gesteld ten behoeve van nieuwe applicaties aan het front-end.
Het koppelen van oude systemen aan nieuwe levert vaak technische problemen op, die alleen kunnen worden opgelost met een flinke dosis technische kennis op het gebied van communicatienetwerken en bijbehorende software. Bij legacy-problemen zijn vaak verschillende besturingssystemen en netwerken (hardware en protocollen) betrokken. Veel organisaties beschikken wel over de benodigde expertise, die is opgebouwd toen PC-netwerken op oudere systemen werden aangesloten, maar voor een aantal organisaties zullen wel problemen ontstaan.
De herbruikbare functies in de legacy-code hangen nauw samen met de zakelijke functies, maar zijn niet identiek. Een applicatie biedt een bepaalde zakelijke functionaliteit, maar deze bestaat in de software uit combinaties van kleine stukjes code. Deze modules zijn niet zo eenvoudig tot zakelijke functies te herleiden. In een ideale wereld zouden alle modules goed gedocumenteerd zijn, waardoor het in theorie eenvoudig zou moeten zijn om uit te vinden hoe je ze in een nieuwe applicatie zou kunnen gebruiken. Helaas is dit meestal niet het geval. Het is niet voldoende ongeveer te weten wat er is; het is essentieel om prec�es te weten wat álle modules doen.
Het gemak waarmee modules kunnen worden geïdentificeerd, gedocumenteerd en geëxtraheerd wordt mede beïnvloed door de manier waarop de code is ontwikkeld en daarna is onderhouden. Als er ontwerptools zijn gebruikt is dit een groot voordeel, maar dat komt niet zo vaak voor. In elk geval bestaat een aanzienlijk percentage van alle software uit pakketten, oude pakketten wel te verstaan, die niet gemakkelijk in modules kunnen worden opgesplitst. Het zou commercieel aantrekkelijk kunnen zijn voor leveranciers van applicatiepakketten om upgrades aan te bieden inclusief modularisatie, maar de meeste leveranciers hebben dezelfde problemen met hun code als de ontwikkelaars van hun klanten.
Het doel is dus de elementaire modules in de legacy-code op te sporen en zodanig aan te passen dat er een verzameling gedocumenteerde herbruikbare componenten ontstaat. Systemen die zijn gebaseerd op een TP-monitor (zoals Cics-applicaties) zijn veel gemakkelijker te modulariseren dan code die voor een timesharing-omgeving als Unix geschreven is. Daartegenover staat dat de Unix-applicaties nieuwer zijn en zich dus in een betere staat zullen bevinden. In elk geval is het zo dat transactiemodules als Cics-routines om historische performance-redenen zeer omvangrijk zijn. Dus als de code wordt gemodulariseerd, moeten de grote modules in een aantal kleinere worden opgesplitst. Het is waarschijnlijk de moeite waard om te investeren in onderhoudstools waarmee de code in kleine modules kan worden opgesplitst, waarbij automatische controles op de logische consistentie worden uitgevoerd. Deze tools werken vaak beter voor Cobol-broncode dan voor andere talen. Ze zijn duur, maar bieden wel waar voor hun geld.
Tenslotte moet er een methode worden geïmplementeerd waarmee de nieuwe, herbruikbare code-modules vanuit de Application Server aangeroepen kunnen worden. Als aan de legacy-kant een TP-monitor is gebruikt, biedt deze een faciliteit voor het aanroepen van de modules, maar anders moeten er specifieke oplossingen zoals Odbc en varianten worden geïmplementeerd. Er zijn specialistische middleware-producten waarmee een breed scala aan ‘remote procedure calls’ kan worden geïmplementeerd. In veel gevallen is het zinvol naar ’transaction messaging’-systemen te kijken, maar ook naar interactieve interfaces.
De interfaces van de interne modules van de meeste legacy-applicaties zijn niet vrij beschikbaar, maar de meeste legacy-systemen beschikken wel over een terminal-interface. Het is relatief eenvoudig om hier andere software op aan te sluiten en vereist geen aanpassing van de bestaande code. Omdat hiermee het legacy-systeem op een hoog niveau wordt aangesproken in plaats van op component-niveau is deze techniek niet zo krachtig, maar zeker de moeite van het bekijken waard, al is het alleen maar als tijdelijke oplossing. Moderne ‘screen scrapping’-producten ondersteunen Windows gui’s (Windows Terminal Server), evenals Ascii-, 3270- en 5250-terminals.
Het converteren van legacy-code naar een verzameling herbruikbare componenten is een uitstekend idee, maar is zeker geen sinecure!
Martin Healey, pionier ontwikkeling van op Intel gebaseerde computers en c/s-architectuur. Directeur van een aantal IT-bedrijven en professor aan de Universiteit van Wales.
