Jarenlang hebben de legacy-applicaties dienst gedaan als core-applicatie in het landschap. Het zijn vaak grote en complexe applicaties die even complexe processen aansturen. De betrouwbaarheid is groot, de performance matig. Updaten is een heel gedoe: ingebouwd maatwerk zorgt er voor dat updates in de soep lopen of helemaal niet mogelijk zijn. We hebben het over applicaties die duidelijk in mode 1 zitten van het Gartner bi-modal IT concept. Duidelijk applicaties die geen onderdeel uitmaken van een cloudstrategie? Dat is wat snel geoordeeld.  In dit blog bespreek ik de voordelen van een cloudstrategie voor je legacy-applicaties. Want die zijn er!

Legacy-applicaties en de cloudstrategie

Als jouw organisatie een cloudstrategie heeft (misschien ben je er nu wel eentje aan het schrijven) dan staat daar vast in dat bij gelijke functionele geschiktheid de ‘as-a-service’ variant de voorkeur heeft boven eigen hardware. Zeker als het gaat over applicaties die niet bijdragen aan het onderscheidend vermogen van de organisatie, zoals marketing en sales en proces-ondersteunende applicaties, worden deze bij voorkeur als dienst afgenomen of direct in Cloud ontwikkeld. De legacy-applicaties komen (waarschijnlijk) niet voor in de cloudstrategie en daar is een goede reden voor. De eigenschappen van legacy-applicaties maken dat ze niet geschikt zijn voor Cloud. Ga je het toch proberen, dan is dit waar je (onder andere) tegenaan loopt:

Netwerkeisen: sommige legacy-applicaties maken gebruik van verouderde netwerktypologieën die niet gebruikt kunnen worden in een cloudomgeving (denk aan multicastverkeer) of client-serverapplicaties (geen webapplicaties) die niet bestand zijn tegen netwerkvertraging.


Licenties: een cloud deployment is vaak niet in het licentiemodel opgenomen, waardoor je geconfronteerd kunt worden met bizarre kosten voor laten we zeggen: je database in Cloud (ik noem geen namen).

Performance-eisen: Cloud is van nature flexibel als het gaat om de performance, deze kan per cloudserver verschillen (tenzij je kiest voor gereserveerde virtuele data centers of ‘reserved instances’).

OS-architectuur: Cloud ondersteunt uitsluitend X86 Intel architecturen. Op RISC of SPARC gebaseerde architecturen zoals HP-UX of AIX functioneren dus niet in Cloud.

Met grof geweld naar Cloud?

Je kunt proberen een applicatie die ongeschikt is voor Cloud met alle macht toch naar Cloud te brengen. Dit voelt echter een beetje als een vierkant blokje in een rond gat hameren: uiteindelijk lukt het wel, maar de vraag is wat het oplevert. De beoogde voordelen van de cloudstrategie zullen voor de legacy-applicatie niet gelden: kostenbesparingen en verhoogde wendbaarheid (door pay-per-use en self-service architectuurpatronen toe te passen) gaan niet op. Het is economisch gezien dus niet zinvol om zo’n project door te zetten. En omdat legacy-applicaties (door al dat maatwerk) vaak ook niet meer geüpdatet kunnen worden, blijft dit ook zo.

Bovengenoemde neemt niet weg dat veel bedrijven toch de behoefte hebben om hun legacy-applicaties wendbaarder te maken. Het gebrek aan flexibiliteit gaat voor organisaties een gigantisch probleem worden, als het dat nu al niet is. Zo voorspelde onderzoeksbureau Gartner dat steeds meer marktleiders hun nummer één positie moeten afstaan aan een bedrijf wat is opgericht na het jaar 2000. De reden hiervoor: een gebrek aan ‘digital business advantage’. Er moet dus toch iets gebeuren.

Legacy-applicaties en de cloudstrategie; een stappenplan

Veel bedrijven hebben dus de behoefte om hun kernapplicaties wendbaarder te maken, kosten te besparen, sneller nieuwe functies te verkrijgen en beter aan te sluiten op de buitenwereld. Vaak maakt dit onderdeel uit van de digitale strategie van een organisatie, waarschijnlijk met een lange horizon van enkele jaren.

Begin in zo’n geval met het applicatielandschap gestructureerd te bestuderen. De grote legacy-applicatie ziet er vanaf een afstandje uit als een monolithische applicatie, in tekeningen vaak weergegeven als één groot blok. In de praktijk is dit echter verre van waar: dergelijke enterprise-applicaties bestaan uit tientallen, zo niet honderden individuele modules die elk hun eigen karakteristieken hebben. Deze modules worden met elkaar verbonden door mechanismen als een Enterprise Service Bus.

Stroom 1: Ontvlechten van het applicatielandschap

Een onderdeel van je cloudstrategie kan zijn om modules die veel aandacht vragen (in de zin van mensen of systeemcapaciteit) naar Cloud te brengen als daar een volwaardig alternatief voor is. Sommige van deze modules vervullen functies die ook als clouddiensten worden aangeboden. Denk hierbij aan CRM, Identity & Access Management, e-mail, sms-functionaliteit, enz. Het applicatielandschap moet dus ontward worden. Dit “ontvlechten” van modules is soms heel eenvoudig, maar kan ook gecompliceerd zijn.

Modules selecteren en naar Cloud brengen

Om te kunnen bepalen of het zinvol is een bepaalde module uit het applicatielandschap te trekken en naar Cloud te brengen, wil je bepalen of dit modules zijn waar de beheerorganisatie veel werk aan heeft of die veel resources vragen of anderszins problemen veroorzaken.

Ik geef een voorbeeld: bij één van onze klanten troffen we een module aan die verantwoordelijk was voor ruim 80% van de database-omvang en 10% van het aantal storingstickets en dus een groot aantal beheeruren. Het betrof een module die de klant in staat stelde om opgemaakte e-mailtemplates aan te roepen en te versturen. De verzonden e-mails werden netjes in de database opgeslagen en oneindig lang bewaard waardoor de database van het ERP-pakket onhandelbaar groot was geworden. Daarnaast was deze module zeer storingsgevoelig. Een korte analyse leerde dat deze functionaliteit ook geboden werd door het online e-mailpakket MailChimp en dat deze met wat integratiewerk middels de API’s (mandrill) volledig kon worden geïntegreerd.

Een ander voorbeeld: een module om geautomatiseerd SMS berichten te versturen bleek zeer foutgevoelig, gebruikte daardoor heel veel CPU en memory resources en genereerde 20% van het aantal storingstickets. Deze functionaliteit wordt ook geboden door online messagingdiensten zoals messagebird en kon dus prima worden vervangen.

Door op deze manier het landschap te analyseren en probleemgevallen te adresseren, wordt de grote monolithische applicatie langzaamaan een stuk lichter. Soms kan zelfs meer functionaliteit worden geboden, zoals het voorbeeld van MailChimp laat zien.

Stroom 2: Vervang maatwerk door nieuwe software

We hebben gezien dat ingewikkeld maatwerk in een ERP-pakket de updates naar nieuwe versies van de applicatie lastig of zelfs onmogelijk kan maken. Ik ken voorbeelden van bedrijven die daardoor soms tientallen versies achter liepen met hun ERP-pakket. Dat is niet alleen een probleem voor de IT operations afdeling, maar hierdoor staat de hele innovatie van een bedrijf stil.

Herbouw is vaak de enige optie. Door het maatwerk opnieuw te ontwikkelen in een modern, cloud-gebaseerd Enterprise PaaS platform wordt langzaamaan de complexiteit van de legacy-applicatie gereduceerd tot proporties waarbinnen het normale life-cycle-management proces weer opgepikt kan worden. De overgang naar een cloud-geschikte versie is het eenvoudigst als zo veel mogelijk de standaard ERP software gebruikt wordt.

Legacy-applicaties naar Cloud brengen

We hebben nu twee stromen besproken die prima naast elkaar in één programma kunnen lopen:

1. Modules ontvlechten en vervangen door SaaS
2. Maatwerk vervangen door nieuwe modules op een (Enterprise)PaaS platform

Dit is een programma dat, afhankelijk van de complexiteit, enkele jaren zal duren. Hiermee breng je de legacy-applicatie weer terug tot een omvang en complexiteit die de IT-organisatie in staat stelt deze weer als een reguliere applicatie te beheren. De kans is groot dat nieuwe versies van de software wel in staat zijn om op standaard X86-Intel te draaien en dat er door de leverancier flinke stappen gezet zijn om de applicatie cloud-waardig te maken.

Verplaats de ontwikkel-, test- en acceptatieomgeving naar Cloud

Zodra de legacy-applicatie is afgeslankt tot een handelbaar niveau en life-cycle-management weer actief is, kan je een begin maken met het in de Cloud plaatsen van de legacy-applicatie. Begin hierbij met de niet-kritische omgevingen: de ontwikkel-, test- en misschien de acceptatieomgeving. Zodra hier ervaring mee is opgedaan, kan je overwegen de productieomgeving naar Cloud te migreren. Dit scheelt veel geld aan licentiekosten voor databases, maar ook dure supportcontracten op niet-standaard hardware kun je zo opzeggen.

Legacy-applicaties en cloud: een lange horizon

Eindoordeel?

Met een paar aanpassingen en een plan hebben legacy-systemen dus wel degelijk baat bij een cloudstrategie. Het vergt alleen wat extra werk. En hoewel ik me sexyer projecten kan voorstellen om aan te werken, is het cloudwaardig maken van je oudere, loggere systemen wel iets dat je organisatie enorme voordelen (waaronder besparingen) kan opleveren. Serveer zowel de legacy-systemen als de combinatie legacy-Cloud dus niet meteen af en kijk per module wat je kunt verbeteren.

Wil je meer weten over de weg naar een gedegen cloudaanpak en hoe je de selectie en verhuizing van applicaties regelt? Download dan ons gratis e-book.