Er zullen altijd legacy-applicaties en -systemen zijn. Legacy’s zijn gewoonlijk een teken van succes in het verleden, daarom zouden we ze met respect moeten behandelen. Helaas gebeurt dat niet altijd, en sommige problemen die daarmee samenhangen, lijken te verergeren.
Het is gebruikelijk om ‘legacy’ te associëren met oude batch-applicaties die op mainframe-computers draaien. Maar in de eenentwintigste eeuw draaien veel applicaties op Unix-systemen van vele jaren oud die toe zijn aan modernisering. Enkele systemen moeten geheel worden vervangen, maar andere hebben intrinsieke waarde, met name die inherent batchgeoriënteerde zijn, zoals voor afdrukken en factureren. In de praktijk doen die applicaties het op mainframes beter dan op Unix, omdat batchverwerking altijd goed werd ondersteund door efficiënte schedulers.. Unix-systemen vertrouwden teveel op time-sharing en Unix-‘shell’-scripts. De introductie van producten van derden zoals Cybermation is inderdaad zeer welkom. Dat biedt het operationeel management overzicht over meerdere platformen, en helpt enorm bij het samenbrengen van oude en nieuwe systemen.
De legacy batchsystemen zijn makkelijk te gebruiken met nieuw ontwikkelde applicaties, eenvoudigweg door het gebruik van software voor transactieberichtgeving om de bestaande batch-inputstromen te voeden. Ook de interactieve legacy applicaties zijn te gebruiken, maar niet zo recht-toe-recht-aan.
Aangezien veel van deze systemen van enorme waarde voor de business zijn, met name de systemen die gebaseerd zijn op mainframes en tp-monitoren gebruiken (voornamelijk Cics), zijn er echter veel tools ontwikkeld om de integratie van nieuw en oud te helpen. E-handel heeft een flinke impact gehad, en de beste producten van tegenwoordig zijn met name applicatieservers die Java en J2EE gebruiken, zoals Weblogic en Websphere. Desalniettemin hebben de legacy-systemen een wisselende waarde. De systemen die in een modulaire architectuur zijn opgebouwd, hebben de meeste waarde; ontwikkelaars van nieuwe applicaties zouden dat in hun oren moeten knopen.
Hoewel er vooruitgang kan worden geboekt door nog meer waardevolle dingen uit mainframe-applicaties te extraheren, is er een grotere horde.
Helaas zijn in de afgelopen jaren veel bedrijfskritische applicaties ontwikkeld met behulp van de dikke-client-architectuur. Het merendeel van de applicatielogica wordt uitgevoerd op een pc, terwijl de database – versterkt door enkele opgeslagen procedures – op de server staat. Deze architectuur was van begin af aan ten dode opgeschreven, en is tot stand genomen omdat ontwikkelaars te weinig ervaring hadden met het bouwen van implementeerbare en onderhoudbare systemen. De generatie van Visual Basic en Power Builder wist niets van robuust systeemontwerp, had nooit gehoord van een tp-monitor, en wist niet echt het verschil tussen meerdere systemen voor één gebruiker zoals e-mail, en systemen voor meerdere gebruikers, zoals orderverwerking. Oudere professionals die beter hadden moeten weten, zwichtten en lieten toe dat de aantrekkelijke grafische gebruikersinterface ging domineren. Wij hebben de kans gemist om applicaties te bouwen die het beste van beide werelden combineerden, dunne gui-clients en robuuste servers voor transactieverwerking. IBM kon maar geen middel leveren voor een Windows-client om bijvoorbeeld de uitvoering van een cics-transactie op te roepen, waardoor een slecht ontwerp zich verspreidde.
Maar er is een groter probleem. De dikke-client-applicaties zijn ontwikkeld en geïmplementeerd in pilot-situaties. Terwijl iedereen tegenwoordig praat over ‘web-enabled’ applicaties, komt de bulk van de dikke-client-applicaties nu pas in het spel voor. En de problemen stapelen zich op, omdat deze systemen niet zijn op te schalen. Ze zijn moeilijk te installeren en zelfs nog moeilijker te onderhouden. Met als gevolg ontevredenheid bij het merendeel van de klanten. Dit resulteert in pogingen om de code te wijzigen, waarmee alleen maar meer problemen ontstaan omdat de architectuur niet deugdelijk is.
Veel organisaties wenden zich tot Citrix om dit groeiende legacy-probleem op te lossen. Hoewel dat op zich een goed idee is, wordt hierdoor alleen het onderhoud makkelijker. Het lost het probleem niet op; het is nog steeds dezelfde nachtmerrie van de dikke-client-applicatie. Citrix verwart de zaken door zijn product een ‘dunne client’ te noemen, wat het niet is. Het wijst alleen de Windows-gui toe over het netwerk, en meer niet. Er is maar een oplossing. Citrix is te gebruiken als een tool waarmee tijd kan worden gewonnen bij het herontwerp van de applicatie, en de Visual Basic-code moet zo snel mogelijk worden weggegooid. Dezelfde hardware is dan te gebruiken om de nieuw dunne-client-code te draaien, wanneer die eenmaal is ontwikkeld.
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.
