Recent onderzoek van Gartner onder ruim 2300 cio’s laat zien dat Legacy Modernization één van hun prioriteiten is. Helaas komt deze modernisatie niet zelden zonder problemen. Toch is vernieuwing belangrijk om legacy systemen met de nieuwste technologieën te integreren, de kosten van het onderhoud te verlagen en een veilige werking te garanderen. Bovenal blijft belangrijk dat elk systeem voortdurend wordt aangepast aan een veranderende business.
We kunnen kiezen om met een big-bang methodologie snel met legacy af te rekenen, maar dit is risicovol omdat legacy ook voordelen bied; bijvoorbeeld een vertrouwde werkomgeving en tevreden medewerkers. Gelukkig bestaan er betere oplossingen die helpen te profiteren van de voordelen van verouderde systemen maar tegelijkertijd zorgen dat aan nieuwe wensen tegemoet wordt gekomen.
Een voorbeeld. Pas geleden heb ik een nieuwe auto besteld die helaas niet in de door mij gewenste kleurencombinatie leverbaar was. Daarom besloot de dealer om een zwarte auto te bestellen om vervolgens zelf het dak van de auto rood te maken. Hij kwam tegemoet aan mijn wens, en tegelijkertijd profiteerde ik van de voordelen die dit ‘legacy’ model met zich meebracht.
Of het nu gaat om een nieuwe kleurlaag op een auto, een laag kleding tegen de kou, een wrap als laag om ons eten: gelaagdheid is niet uit onze samenleving weg te denken en komt terug als oplossing voor uiteenlopende problemen. Vergezocht of wat abstract? Misschien. Maar ook voor it bied deze denkwijze oplossingen.
Gelaagde architectuur
Gelaagdheid bied mogelijkheden om te voldoen aan zowel functionele als niet-functionele eisen. Door een extra laag bovenop een bestaand systeem te introduceren kunnen aanpassingen in de interface gerealiseerd worden en kan nieuwe functionaliteit worden toegevoegd. Dat een toevoeging van een extra component zorgt voor een eenvoudiger systeem is paradoxaal maar gaat op in veel situaties.
Een gelaagde architectuur is in het bijzonder relevant voor legacy systemen. Sterk verouderde systemen zoals mainframes en Cobol-programmatuur zijn nog altijd in gebruik, maar ook meer recente systemen zijn vaak moeilijk onderhoudbaar; bijvoorbeeld omdat de programmeur is vertrokken of de ontwikkeling is uitbesteed aan een nieuwe partij. Zeker als het systeem slecht gedocumenteerd is en niet gebouwd volgens bekende standaarden, kan de wens om een kleine functionele aanpassing leiden tot tijdrovende projecten.
Het is ook mogelijk om te kiezen voor een andere insteek, gebaseerd op een gelaagde architectuur. Bijvoorbeeld door de introductie van een stukje middleware: een laag die transparant tussen de client en de server opereert en die communicatie daartussen afvangt. Aan de hand van ontvangen berichten kan dit stukje middleware besluiten om het legacy systeem aan te spreken zoals vanouds, of juist om een andere operatie toe te passen zodat nieuwe functionaliteit geboden kan worden. Ook kan de nieuwe laag onderlinge communicatie bewerken om informatie anders te presenteren of juist om verdachte communicatie onschadelijk te maken.
Concreet kan een nieuwe laag helpen om traditionele desktopapplicaties naar het web te verschuiven. Bijvoorbeeld door een http-verzoek te vertalen naar shell commands of zelfs naar een simulatie van muisbewegingen en muisklikken op een grafische interface. Een extra laag kan de bereikbaarheid van applicaties vergroten. Het maakt het mogelijk om nieuwe infrastructuren aan te spreken en stapsgewijs systemen aan te passen aan de laatste ontwikkelingen.
Voor toepassingen met security is gelaagdheid een bewezen concept. Deze gelaagdheid is nu al duidelijk zichtbaar in security architecturen. Niet alleen wordt het netwerk zelf binnen een lagenstructuur gemodelleerd, zoals in het bekende OSI-model, ook de beveiligingstoepassingen die daarboven functioneren passen in dit lagenmodel. Bijvoorbeeld de in populariteit groeiende application firewalls. Deze vormen een extra schil bovenop de eigenlijke applicaties. Voor de eerder genoemde legacy systemen kan dit type laag de veiligheid aanmerkelijk vergroten. Andere voorbeelden van oplossingen die als laag werken zijn Intrusion Detection System, Virtual Private Network en Secure Sockets Layer.
Combineer oud met nieuw
Sommige concepten bieden oplossingen in verschillende domeinen. Gelaagdheid is daar een mooi voorbeeld van. In de it heeft de introductie van een laag veel voordelen tegenover het aanpassen van het eigenlijke systeem. De introductie van een nieuwe schil verbetert de onderhoudbaarheid van vaak organisch gegroeide systemen. Ook kan één laag om meerdere systemen gelegd worden zodat de voordelen van één laag doorwerken op alle systemen die hieronder geplaatst zijn.
Ontwikkel- en migratieprocessen zijn te vaak gericht om het volledige legacy systeem in één keer te vervangen door een nieuw systeem. Door toepassing van een gelaagde architectuur kan het migratieproces geleidelijk verlopen. Uiteindelijk zou de binnenste kern – de legacy applicatie – op den duur relatief eenvoudig vervangen kunnen worden.
Maak legacy klaar voor de toekomst. Zet Cobol in de cloud! Breng mainframes naar het web. En ga mobile met dos-applicaties. Legacy Modernization blijft lastig, maar toepassing van een gelaagde architectuur helpt om de voordelen van verouderde systemen te benutten en tegelijkertijd te werken aan een innoverende business.
@PaVaKe: Ik wist dat je iets zou zeggen over embedded 🙂 Dit zijn inderdaad gevallen waarin je niet gaat vervangen.
Legacy is in mijn ogen een systeem van waarde dat verouderd is.
Sexy software is als een sales persoon het kan demonstreren en als iedereen er van gecharmeerd is omdat het zo lekker uit ziet en clean of flashy is. Tijdens verkoop is functioneel echt ondergeschikt aan look & feel. Het wordt gewoon verkocht als “in potentie kan het alles”.
En wat betreft de “verouderd mainframe”. In deze valkuil stapte ik bij een klus bij de Rabobank. Toen werd er op Yammer een discussie gestart over cloud en trok ik de vergelijking door te zeggen wat een mainframe allemaal niet was. How little did I know. Nu zijn er nog steeds sterk verouderde mainframes in gebruik en wellicht dat Arie hierop doelde, maar de moderne mainframe is “cloud computing uit het doosje”. Nu moeten ze die mainframes alleen wat meer slijten als snel, goedkoop en cloud, dan komt het helemaal goed 🙂
@Henri
je begint me te kennen 🙂
Maar “Legacy is in mijn ogen een systeem van waarde dat verouderd is” is ook nog steeds hoe je het wil zien.
Als jij 3 jaar geleden een apparaat van 1 miljoen euro gekocht hebt, en dat apparaat draait op windows XP, is dit dan legacy ?
Vanuit XP gezien misschien wel, maar vanuit de investering van de klant uit misschien niet, die heeft een duur apparaat gekocht waar hij 10 jaar mee wil kunnen doen.
Of, om terug te gaan naar de auto uit het voorbeeld: als de firmware van de cruisecontrol niet meer ondersteund wordt (maar nog wel gewoon goed werkt), ruil je dan je auto al in voor een nieuwe?
Die opmerking over de verouderde mainframe was niet zo slim. Ik meende dat mainframes vooral iets van vroeger was. Hoewel mainframe vaak nog steeds synoniem voor legacy is bestaan er inderdaad ook moderne mainframes. Dit voorbeeld had ik weg moeten laten.
Blijkbaar snij ik een onderwerp aan waar nogal wat discussie over bestaat. Mijn verhaal komt vooral voort uit het feit dat grote IT projecten vaak falen. Door met lagen te werken kun je a la Scrum snel resultaten boeken in korte tijd.
Henri. Ik ben het met je eens dat de oudste componenten uiteindelijk uitgefaseerd moeten worden. Maar als je bijvoorbeeld eerst een nieuwe user interface bouwt bovenop een legacy systeem, dan kun je daarna alsnog prima het legacy systeem vervangen voor een nieuw systeem. Of als je eerst een application firewall voor een legacy applicatie plaatst, kun je daarna alsnog de vulnerabilities in het oude systeem verhelpen.
En omdat veranderingen inderdaad zo snel gaan – zoals Frans Nevels zegt – dan is het onmogelijk om telkens oude systemen volledig uit te faseren.
Uiteindelijk is het balanceren tussen twee uitersten: voortbouwen op legacy of legacy uitfaseren en volledig vervangen.
Arie, in mijn ogen zit er een groot verschil tussen software die al een tijd bestaat en legacy! Al is dit wellicht geen algemeen standpunt en zit het vooral in mijn hoofd.
Een eigenschap van legacy (systems) is dat het verouderd is. Niet alle software die al een tijd draait is ook daadwerkelijk verouderd. In 2001 heb ik een Workflow management systeem gemaakt welke nog steeds draait op basis van (het toen nieuwe) .NET en MS SQL Server. De database kant is heeft 2 upgrades gehad en draait nu op SQL Server 2008. De .NET kant is blijven steken op 2.0 welke momenteel in mijn ogen nog geen legacy is al zat dit niet lang meer duren. Het onderliggende datamodel is echter opgezet om een hele lang tijd mee te gaan.
Dat systeem leent zich dus uitstekend voor een nieuw jasje (laagje) en opnieuw bouwen is dan een nodeloos dure investering. Het systeem is echter wat meer een eilandje geworden wat steeds minder past binnen de organisatie die ook andere software is gaan adopteren.
Maar goed, om te proberen de lengte van mijn reactie te beperken.
Het kan prima zijn om laagjes te bouwen, mits die keuze maar bewust genomen word en dat men beseft dat het een diepte investering is en dat de applicatie life cycle in acht genomen wordt. Mijn ervaring is, dat dit vaak niet gebeurd, men bang is de echt belangrijke stappen te ondernemen en dat de leverancier dit allemaal wel best vind.
Men bespaard steeds vaker op consultants, dat is vaak een dure fout al besef ik me dat de term consultant de laatste jaren erg verwaterd is.
Niettemin leuk artikel en goede reacties. Keep them coming.
Pa Va Ke & Henri
Legacy is de keus van gisteren die wringt met de wens van morgen. Bijvoorbeeld omdat zoals Henri het zegt de ‘eye candy’ belangrijker is geworden dan het proces. En met het aan elkaar knopen van allerlei oplossingen (lagen) is beveiliging een punt waar niet altijd goed over nagedacht wordt. Een embedded (windows XP) systeem aan het internet hangen heeft nu eenmaal een risico omdat de ‘known errors’ niet meer opgelost worden en dus te ‘exploiteren’ zijn.
Arie
Dat je opmerking over mainframes: “een beetje dom was” lijkt me duidelijk dat je echter blijft volharden in je visie om eerst een firewall te plaatsen en dan te gaan patchen is gewoon gevaarlijk.
Informatiesysteem: Een samenhangende gegevensverwerkende functionaliteit voor de besturing of ondersteuning van één of meer bedrijfsprocessen Functionaliteit in dit verband betreft de bewerkingen die het informatiesysteem kan uitvoeren. Informatiesystemen bestaan uit mensen, processen en producten.
Een (IT)systeem maakt deel uit van het informatiesysteem en betreft een object, of verzameling objecten met een specifieke functionaliteit of werking. Een systeem kan worden gedefinieerd in hardware, systeemprogrammatuur en netwerken. (bron: De ISM methode, Versie 3).
Persoonlijk vind ik deze definities al zeer verhelderend, maar ze werpen wel een ander licht op de bovenstaande discussie.
Als we het over “een systeem” of “een legacy systeem” hebben, dan is de grote vraag of we het informatiesysteem bedoelen of een specifieke functionaliteit die daar deel van uitmaakt en die tot functioneren komt via hardware, programmatuur en netwerk. Ik denk het laatste, waarbij elk van de drie delen legacy kan zijn. Maar ik geloof dat veel mensen vooral het eerste denken. En dat maakt een discussie als hierboven nogal ondoorzichtig.
Ik begrijp dat de auteur inmiddels meer op het spoor van bovenstaande definitie zit, want inderdaad: het mainframe concept is allesbehalve legacy, maar de invulling met IT systemen kan hier en daar heel goed verbeterd worden.
Misschien moet hij zijn stuk dan (gedeeltelijk) herschrijven en in zijn verhandeling duidelijk onderscheid maken tussen informatiesystemen, IT systemen, en systeem- en applicatieprogrammatuur.
Overigens blijf ik van mening dat veel zogenaamde legacy niet goed op waarde wordt geschat. Met de hardware en netwerken van nu kan veel oudere programmatuur die op zichzelf de juiste functionaliteit levert nog jarenlang uitstekend functioneren.
Een mooi, relevant opiniestuk met dito reacties.
Het artikel hinkt wel op 2 gedachten: enerzijds de legacy intact houden door er een extra laag overheen te leggen; anderzijds het migratieproces “door toepassing van een gelaagde architectuur” geleidelijk laten verlopen naar…. een gelaagde architectuur.
Eerst nog even de kenmerken van legacy waardoor migratie naar een gelaagde architectuur op den duur noodzakelijk is:
1. Dataredundantie:
hetzelfde gegeven is in meerdere applicaties vastgelegd, waardoor het mogelijk is dat een klant op meerdere adressen tegelijk woont.
2. Functionaliteitredundatie:
dezelfde functionaliteit komt op meerdere plaatsen in dezelfde en/of andere applicaties voor, wat de gevolgen van aanpassingen steeds ondoorzichtiger maakt.
3. Verwevenheid van functionaliteit en data:
functionaliteit is geprogrammeerd in 3GL of 4GL in combinatie met platformafhankelijke databasetechnologie.
4. Verwevenheid van functionaliteit en flow:
functionaliteit bevat instructies voor de afwikkeling van de workflow, bijvoorbeeld de status verwerking van een bepaalde entiteit, waardoor hergebruik van deze functionaliteit sterk wordt bemoeilijkt.
5. Verwevenheid van applicaties:
door veel 1-op-1 koppelingen tussen applicaties hebben wijzigingen een sneeuwbaleffect in een oerwoud van processen.
6. Batchverwerking:
Legacy is vaak volledig batchgeorienteerd, hetgeen haaks staat op het realtime willen afhandelen van klantwensen door middel van selfservice.
Als gevolg van deze kenmerken is legacy steeds moeilijker aan te passen aan veranderende bedrijfsomstandigheden, zoals veranderingen in de markt, de wetgeving en de technologie.
Daarnaast hebben eindgebruikers nauwelijks invloed op de volgorde waarin bedrijfsfuncties worden afgewikkeld.
In de markt is al enige tijd een probaat middel voor deze legacy-problematiek beschikbaar en die heet: Service Oriented Architecture. SOA maakt een ontkoppeling van data, functionaliteit, flow en presentatie mogelijk, hetgeen dus zeer basaal leidt tot een 4-lagen architectuur.
En daarmee kom ik op een volgende dubbelzinnigheid in het artikel:
duidt de term ‘middleware’ nu op de infrastructurele voorziening die SOA (en dus ook een lagen-architectuur) mogelijk maakt, en wel bekend staat als enterprise service bus (ESB) of duidt deze term specifiek op de laag “die transparant tussen client en server opereert en die communicatie daartussen afvangt”?
Het laatste is het geval als de auteur vervolgt:
Aan de hand van de ontvangen berichten kan dit stukje middleware besluiten om het legacy systeem aan te spreken zoals vanouds, of juist om een andere operatie toe te passen zodat nieuwe functionaliteit geboden kan worden.
Dit is beslist een mooie aanwijzing hoe legacy geleidelijk onder architectuur gemigreerd kan worden naar een gelaagde architectuur.
De hamvraag blijft echter hoe de laag die transparant tussen client en server opereert moet worden vormgegeven. In de markt is hiervoor ook al enige tijd een oplossing beschikbaar en die heet: Business Process Management (BPM).
In mijn optiek gaat het met BPM (en overigens procesdenken in het algemeen) niet lukken.
Het verdient dan ook aanbeveling om de flowchart-spaghetti die BPM met zich meebrengt te vervangen door beslissingstabellen in combinatie met kunstmatig intelligente, dus doelgerichte redeneertechnieken (en dat is dus beslist niet BRM!).