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.
Leuk en logisch stuk, koren op de molen van de integrators, want nu kan er blijvend omzet gescoord worden op legacy en bouwen we vrolijk verder zodat afscheid van legacy nog moelijker en duurder wordt.
Het probleem van lagen over een bestaand systeem is deze: Op de korte termijn heb je een oplossing en het is goedkoper dan opnieuw beginnen met alle risico’s van dien. Op de lange termijn echter maak je het “gewicht” van de oplossing alleen maar zwaarder, elke wijziging duurder en kun je deze nieuwigheid niet meenemen c.q. migreren. Of kun je dat wel, maar heb je nog steeds een mindere goede architectuur voor je nieuwe oplossing. Je doet in feite nog meer diepte investeringen. In het begin is dat niet erg, je krijgt er namelijk wat voor terug en je doet ervaring op. Op de langere termijn is het een doodlopende weg en wordt migreren alleen maar nog moeilijker.
Als je zonodig geen afstand kan nemen van je legacy, zorg ervoor dat je een gewenste architectuur bouwt met dito database als fundament en beweeg je in allerlei bochten om dat model te vullen (liefst 1 richting op) vanuit je legacy database. Dit is duur, lastig en onhandig. Maar zodra dat nieuwe systeem goed is, kun je afscheid nemen van je legacy.
Naar mijn mening moet je dus altijd bouwen voor afscheid en waken dat je niet verder bouwt op je legacy. Dit is echter een strategische beslissing, duurder dan even doorbouwen, maar dit betaald zich op de lange termijn uit.
Dit model noem ik het greenfield model. Bouw een simpel nieuw systeem (evt. door het te vullen vanuit het oude systeem) en hang klanten over op dit nieuwe systeem. Daarna kun je het oude systeem laten afzinken zodra het grootste gedeelte over is, het gedeelte wat niet over gaat of wil overgaan betalen langzaamaan de hoofdprijs (prikkel om over te gaan) en daar neem je gewoon afscheid van door het oude systeem met klanten te verkopen.
Kortom de manier waarop je omgaat met bovenstaand artikel bepaald of je goed of niet goed bezig bent. Als je niet bewust bent van de keuze maak je automatisch de verkeerde, want die is namelijk het gemakkelijkst op de korte termijn.
Rationaliseren van je legacy is pittig en vergt leiderschap en visie. Maak de juiste keuze…
@Henri. Lange termijn denken, dat is toch iets voor idealisten? Crisis of niet, als er snel geld verdiend kan worden door te besparen dan zal men dat niet laten. Korte termijn denken dus. En dat maakt het verhaal van Arie zeer plausibel, ook al deel ik je idealisme.
@Henri
Helaas moet ik het (nagenoeg) volledig met je oneens zijn.
Het grootste probleem van legacy applicaties is dat medewerkers deze niet sexy vinden. Een oud karakter-gebaseerd CICS-scherm oogt nu eenmaal niet zo mooi als een web-scherm met plaatjes. Maar de onderliggende functionaliteit is vaak heel stabiel en snel.
Het is een prima model om functionaliteit waar jaren werk in zit gewoon heel te laten en een nieuwe presentatielaag erom heen te bouwen. De oude presentatielaag kan dan verwijderd worden.
Natuurlijk kun je besluiten om je kernapplicatie in zijn geheel te vervangen. Je maximaliseert alleen wel je bedrijfsrisico op deze manier.
Als je COBOL applicatie prima voldoet maar eigenlijk alleen maar een nieuwe presentatielaag nodig heeft, kan het voorstel van Arie een economische en technisch correcte oplossing zijn.
Je breekt toch ook je huis niet af en bouwt het opnieuw alleen maar omdat je een schuifpui wilt hebben?
Arie,
Legacy is vaak een erfenis uit het verleden, oplossingen die toen heel valide waren met de geldende requirements. Dat deze systemen en oplossingen nog steeds gebruikt worden wil dus ook wat zeggen. Dat er nu nieuwe requirements toegevoegd worden zoals bijvoorbeeld privacy zorgt ervoor dat de cloud zoals we deze nu kennen mogelijk de legacy van morgen is.
Maar dat is een andere discussie en waar het hier nu om gaat is dat we met het toevoegen van extra lagen wel de legacy systemen/code kunnen ontsluiten voor het web maar daarmee ook richting ‘security through obscurity’ gaan. Want twintig jaar geleden waren er andere requirements waardoor veel legacy code kwetsbaar is:
“Little thought was given to security, and SQL injection as a exploit did not exist in most developers’ minds. As such, these systems were not developed to take a variety of what are now very well-known attack vectors.”
Als we in 1999 de code niet alleen voor de eeuwwisseling en Euro hadden aangepast dan hadden we nu misschien niet zoveel problemen gehad maar wie wist toen welke het op ging met het Internet;-)
Ik opteer net als Henri toch voor de uitfasering van legacy-systemen. Ik heb al vaak meegemaakt dat de beheerkosten van zo’n oude applicatie volledig uit de hand lopen. Helaas zitten de bedrijven dan gevangen want die oude applicatie is zo vreselijk complex dat niemand zijn handen durft te branden. Een nieuw front-end laagje erop zetten neemt die kosten en complexiteit niet weg. Extra lagen erop bouwen kan handig zijn zoals Arie zegt, maar het verlengt ook je keten waardoor iedere interface aanpassing op meerdere plekken gedaan moet worden.
Mooi voorbeeld trouwens van Legacy Modernization in de echte wereld: Een bedrijf had een mainframesysteem met beheerkosten van ongeveer 3 miljoen. Dit is via een standaard oplossing geconverteerd (cobol naar java) en geoptimaliseerd naar een AIX-server oplossing. Beheerkosten nu: 250.000 euro. Batches die van 6 uur naar 2 uur gingen. Bizar hoeveel er bespaard kan worden door van het mainframe af te stappen. Toen ik het hoorde kon ik mijn oren niet geloven, maar het was echt zo. Hier zitten de betere besparingen i.p.v. front-end vervanging en lagen toevoegen.
Ik lees dit verhaal als Manager ICT, eindverantwoordelijk om mijn business (en externe klanten) zo goed als mogelijk met ICT te bedienen, zowel vandaag, morgen, als volgend jaar. Met nieuwe systemen en nieuwe technologie en met het onderhoud en beheer van de bestaande systemen.
Ontwikkelingen binnen ICT gaan razendsnel. Wat vandaag nieuw is, is volgend jaar legacy. Dat zal altijd zo blijven.
Om uit de “legacy-trap” zo veel mogelijk weg te blijven is er maar 1 oplossing: maak systemem zo basic en simpel mogelijk, waarbij ze net voldoen aan basic klant requirements en wet-/regelgeving. Waardoor het geinvesteerd vermogen relatief beperkt blijft en het migreren van systemen naar iets nieuws, betrekkelijk weinig pijn doet.
De investering in ICT zal altijd terugverdiend moeten worden!!! ICT is een hulpmiddel, geen doel.
De gebruiker voelt de pijn van het migreren beperkt (afgezien dat het lang duurt voordat ze iets nieuws opgeleverd krijgen), de afdeling ICT des te meer. Dus, gebruikers en managers, hou jullie requirements beperkt tot het minimaal noodzakelijke, des te lager zijn de kosten en inspanningen van het in de toekomst migreren naar iets nieuws. En des te sneller kan er geschakeld worden op nieuwe ontwikkelingen.
Sorry, maar je verhaal viel in elkaar toen je begon over “Sterk verouderde systemen zoals mainframes”. Er zijn weinig bedrijven die op “sterk verouderde mainframes” draaien en als je naar de nieuwe generaties kijkt (waar dus bijna iedereen op draait) zijn die qua technologie andere platformen ver vooruit. Misschien dat je je eens zou moeten verdiepen in mainframes, het is zulk mooi spul 😉
Als je het hebt over applicaties die draaien op een mainframe, ja, daar zit inderdaad oud spul tussen, maar ook op mainframes draaien veel moderne applicaties, middleware en open source OS’en, dus is het wel heel simpel om te stellen dat je als je van legacy af wil, je op een ander platform moet gaan draaien … dan gaan er opeens heel andere zaken spelen als RAS, licensing per core, environmentals etc etc
Gisteren op webwereld een toepasselijk bericht:
http://webwereld.nl/it-beheer/78488-cobol-legacy-veroorzaakt-problemen-leger-vs-
@Brombeer, we zijn het inderdaad vrijwel oneens 🙂
Eerst waar ik het wel over eens ben is dat inderdaad het bedrijfsrisico groot is. Iets wat maar al te vaak waar is gebleken.
Ik ken ook veel systemen die opgebouwd zijn uit ASCII. Wellicht doen die systemen een paar dingen heel goed en robuust. Dit betekend echter de het proces wat ze faciliteren goed is. Functioneel schort er vaak van alles aan. Het is vaak beperkt in zijn functionaliteit en flexibiliteit. Door er een grafische schil overheen te leggen los je dit niet op. Mijn ervaring is vaak dat de key gebruikers juist terug willen naar de oude schermen omdat de sneltoetsen zo goed werkten, maar als je iets verder kijkt is het gewoon de weerstand tegen verandering.
Door verder te investeren maak je het afscheid van legacy alleen maar moeilijker, maar legacy is door de tijd ook veel duurder geworden. Een quick fix lijkt dus leuk en is economisch op korte termijn ook aantrekkelijk, maar ik ben er van overtuigd dat het op de langere termijn een slechte beslissing blijkt te zijn. Je overhead loopt alleen maar op, je wendbaarheid neemt af en veranderen wordt een steeds groter struikelblok.
Als je kernapplicaties niet opnieuw kunt bouwen dan ben je als organisatie dus “vergeten” wat de fundamentele principes van je processen zijn. Je bent de kennis die je ooit als organisatie had kwijtgeraakt. Door je processen heel goed te bestuderen (niet als manager, maar op detail) kun je dit fundament wel weer boven water toveren.
Wat betreft je analogie van de schuifpui. Voor een schuifpui ga je geen nieuw huis bouwen, maar als je van je huis een pakhuis wilt maken dan is het toch echt beter om iets nieuws te bouwen of vanaf de grond af opnieuw beginnen. Daarin falen betekent een lange en dure les: Een huis leent zich niet voor pakhuis en is niet schaalbaar.
Overigens hoef je niet altijd zelf te bouwen. Zeker als IT geen core competentie is. Beter pas je de organisatie aan de nieuwe standaard software aan…
Ik weet even niet wat ik met het artikel (ook bij mij gingen er wat nekharen omhoog staan bij de woorden “sterk verouderd mainframe”), maar vooral ook niet wat ik met de reacties moet.
Wanneer praten we nu eigenlijk over legacy ??? Als iemand de interface niet meer “sexy” vind? Als de gebruikte taal al meer dan X jaar bestaat? Als je niemand meer in je organisatie hebt om het te onderhouden?
Als je iets ontwikkeld moet je keuzes maken over de levensduur hiervan. Je kunt, zoals Henri aangeeft, bouwen voor afscheid. Maar je kunt ook kiezen voor onderhoudbaarheid of duurzaamheid. In de embedded sector wordt deze keuze vaak bewust gemaakt omdat “even vervangen” een kostbare aangelegenheid is.
Ik geloof ook niet zo in de “laagjes” oplossing. Als je je autodak telkens opnieuw afschuurt en een ander kleurtje geeft, is na een tijdje het dak lelijk geworden door “broddelwerk”, of je hebt nog steeds een prachtig dak maar de rest is verouderd. Uitstel van executie wat mij betreft!
(overigens heb ik nog steeds moeite met “sexy software”. Volgens moet software in beginsel vooral functioneel zijn. Of, zoals ze vroeger bij ons thuis zeiden “van een mooie tafel kun je niet eten”)