Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Maak legacy klaar voor de toekomst

 

Computable Expert

Arie Timmerman
Information Security Consultant, Capgemini. Expert van Computable voor het topic Security.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4775468). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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")

@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!).

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×