Het reduceren van de total cost of ownership (tco) van it-systemen is nog steeds een belangrijk thema voor organisaties. Helemaal als je beseft dat ongeveer driekwart van de it-resources worden gebruikt om legacy-applicaties te onderhouden.
Het alloceren van een deel van dit onderhoudsbudget aan moderniseringsprojecten kan de toekomstige onderhoudskosten echter enorm verlagen, zodat er meer kan worden besteed aan innovaties die een bijdrage leveren aan wat alleen maar belangrijker wordt: het behalen van concurrentievoordeel.
Dit betekent in toenemende mate dat applicaties die voorheen alleen intern beschikbaar waren, ook worden opengesteld in een ‘consumerized’ vorm. Gebruikers hebben veel hogere verwachtingen van de gebruiksvriendelijkheid, omdat ze de zakelijke applicaties vergelijken met de laagdrempelige apps en games die ze privé gebruiken. Deze eisen, en de druk van concurrentie beïnvloeden in grote mate de keuze voor wat er wanneer gemoderniseerd moet worden.
Het uitgangspunt van moderniseren is dat je de huidige systemen aanpast aan nieuwe technologieën. Uit onderzoek blijkt dat bijna alle it-managers (98 procent) geloven dat het toevoegen van nieuwe functionaliteiten aan (mainframe)applicaties zorgt voor een stijging van de productiviteit. Desondanks staat bij it-managers het moderniseren van dergelijke legacy-applicaties niet hoog op de agenda. Als reden wordt aangevoerd dat 72 procent zegt dat de business het moderniseren van legacy-applicaties niet als innovatie beschouwt. Op de vraag wat de business dan wel aanmerkt als innovatie, antwoordde 42 procent dat innovatie wordt beoordeeld op ongebruikelijke en ‘gimmicky’ applicaties en widgets; zij verkiezen nieuwigheid boven legacy.
Waarom?
De reden dat moderniseren van applicaties weinig aandacht krijgt, heeft te maken met de onwetendheid over de kosten en de directe voordelen die het gaat opleveren. Moderne applicaties moeten natuurlijk op elk platform kunnen draaien (Windows, web, mobile, et cetera.), en 24×7 beschikbaar, en schaalbaar zijn. Een belangrijke voorwaarde is dan ook dat het mogelijk is om data met andere systemen te delen. Applicaties moeten makkelijk te onderhouden en te verbeteren zijn zodat je als organisatie snel kunt inspelen op veranderende omstandigheden.
In tegenstelling tot wat vaak wordt gedacht, hoeft een legacy systeem niet compleet opnieuw te worden gebouwd. Met de juiste benadering is het mogelijk de sterkste elementen van je applicatie te behouden en het overige aan te passen. Ook wordt het toevoegen van nieuwe functionaliteit veel makkelijker als je applicaties bestaan uit makkelijk te gebruiken onderdelen. Het op deze manier verpakken van je applicaties is een van de belangrijkste doelstellingen van modernisering.
Window dressing
Ook zakelijke applicaties moeten er dus goed uit zien en makkelijk te gebruiken zijn. Het gevaar dat op de loer ligt, is dat er te veel focus ligt op het moderniseren van de front-end zonder naar een duurzaam doel toe te werken, waardoor de voordelen die te behalen zijn door modernisering, onvoldoende of helemaal niet zullen worden behaald.
Bij het starten van een moderniseringsprogramma moet de aandacht dan ook niet alleen uit gaan naar die ene specifieke applicatie, maar ook de omgeving worden meegenomen en een aantal vragen worden gesteld. Wat wordt er van ons verwacht en met welke andere tools en licenties hebben we nog meer te maken? Door de applicatie in samenhang te zien met andere systemen ontstaat een volledig beeld, dat altijd het uitgangspunt zou moeten zijn voor het moderniseringsprogramma.
Welke applicaties moderniseren?
Moderniseren kan worden overwogen wanneer een legacy-applicatie voldoet aan een of meerdere kenmerken:
- Het is al een aantal jaar in productie.
- De architectuur is gedateerd, hetgeen onderhouden ervan moeilijk/kostbaar maakt.
- De front end architectuur is achterhaald (zoals bijvoorbeeld character UI of 1e generatie GUI interfaces).
- De back-end architectuur bevat geen integratie mogelijkheden en ondersteunt SOA niet.
- Het operating systeem en de database worden niet meer ondersteund, en werken met uitgefaseerde hardware.
- Belangrijke functionaliteit ontbreekt, zoals bijvoorbeeld integratie met Google Maps en social media.
- Verloop van medewerkers, waardoor cruciale kennis van de applicaties verloren is gegaan.
One size does not fit all
Het moderniseringsproces zal per organisatie verschillen en is onder meer afhankelijk van tijd, budget en draagvlak van het management. Ongeacht hoe ver je de modernisering wilt doorvoeren, is het aan te raden om te denken aan de hand van drie moderniseringsprogramma’s: ‘Nieuwe Windows GUI’, ‘SOA-implementatie’ en ‘C/S to Web’.
1) Nieuwe Windows GUI
De afgelopen jaren is de gebruikerservaring voor zakelijke applicaties drastisch verbeterd. De nieuwe generatie eindgebruikers verwacht echter dat ook zakelijke applicaties intuïtief en efficiënt(er) te gebruiken zijn.
Voor ontwikkelaars betekent dit dat zij geen nieuwe frameworks moeten hoeven leren of dikke manuals moeten lezen (achthonderd pagina’s is geen uitzondering). Als de nieuwe functionaliteit out of the box gebruikt kan worden, dan kunnen ontwikkelaars snel beschikken over de nieuwe mogelijkheden van het product.
2) SOA implementeren
Deze vorm van modernisering wordt meestal gekozen als men er zeker van wil zijn dat de applicatie architectuur of delen daarvan, ‘future-proof’ zijn, makkelijker te integreren met andere apps en diensten, en gereed is om als web app uit te rollen. Als eerste stap, verdient het aanbeveling de legacy applicatie op te schonen. Veel applicaties hebben namelijk ongebruikte code, en/of code die bestaat uit verouderde constructies of op een andere manier afwijken van de gangbare standaard. Deze kunnen fouten veroorzaken die pas na de migratie aan het licht komen, en daardoor het onderhoud en verbeteringen veel tijdrovender en dus kostbaarder maken dan nodig, en daarnaast ook veel gevoeliger voor fouten.
De meeste succesvolle SOA-initiatieven beginnen klein, waarbij één business proces tegelijk wordt getransformeerd naar een service. De ‘services functionaliteit’ kan beschikbaar worden gesteld in de vorm van web of andere services via een ‘enterprise service bus’. Dit is een software laag die functionaliteit biedt in de vorm van business logica. Deze laag zou altijd onderdeel van de applicatie architectuur moeten zijn, maar dit is niet altijd het geval omdat het vaak vergeten wordt wanneer organisaties de stap maken van C/S naar web. En dat is jammer, want dit heeft gevolgen voor de beveiliging en schaalbaarheid van de applicaties. Zodra legacy services door deze ‘laag’ zijn verpakt, kunnen ze worden gebruikt om nieuwe systemen te bouwen of direct te integreren met andere systemen.
Deze aanpak heeft de volgende voordelen:
• Voor alle applicaties (client server, web of mobile) kan dezelfde back-end worden gebruikt
• Als de functionaliteit wordt hergebruikt, kan tot 80 procent van de code worden hergebruikt
• High-level beveiliging kan worden toegevoegd
• Ondersteuning van complexe web services
• Mogelijkheid om beveiliging te introduceren of te verbeteren door gebruik van de beschikbaar gestelde richtlijnen
• De webservices kunnen makkelijk worden gebruikt door systemen van derde partijen zonder kostbare vertalingen in verschillende talen
Het resultaat is dat de organisatie sneller kan inspelen op veranderingen. Door deze flexibiliteit kunnen meerdere projecten tegelijkertijd worden gedraaid, omdat het mogelijk is het werk pas later te integreren. SOA-services kunnen hergebruikt en gecombineerd worden, waardoor zeer snel ontwikkelen van nieuwe functionaliteit mogelijk wordt. SOA-implementatie heeft vele voordelen en is een ideale manier om toe te werken naar een compleet gemoderniseerde omgeving.
3) C/S naar Web
Zakelijke applicaties maken een verschuiving door van traditionele client server naar het volledig uitrollen via een browser. Het naar het web en in de cloud brengen van applicaties stelt eindgebruikers in staat hun applicaties overal en altijd te gebruiken en is daarom een populaire zakelijke beslissing. Als je applicaties groeien, dan kun je waar nodig opslag, RAM en CPU capaciteit toevoegen. Dit betekent dat je kunt volstaan met de aanschaf van ‘precies genoeg’, en kunt schalen zodra de applicatie eisen groeien.
Webapplicaties kunnen ook draaien op mobiele devices zonder dat er verschillende versies van de applicaties ontwikkeld en onderhouden moeten worden voor de diverse platforms. Alhoewel het moderniseren van applicaties klinkt als veel werk, is het door het gebruik van de juiste tools goed mogelijk delen hiervan te automatiseren. Zo is het bijvoorbeeld handig als Windows-applicaties direct in de browser kunnen worden uitgerold zonder dat er delen van de applicatie opnieuw gecodeerd moeten worden.
Concurrentievoordeel
Ook moderniseren moet gezien worden als een innovatieproject. Het levert namelijk wel degelijk concurrentievoordeel. De uitdaging ligt in het voorbereid zijn op de toekomst. En dan gaat het over het innoveren met bestaande applicaties.
Om je huis te onderhouden doe je ook af toe kleine, maar ook grotere projecten zoals de badkamer of de keuken. Maar intussen heb je ook schilderwerk verricht. Moderniseren biedt je ook die mogelijkheid om soms alleen te werken aan de schil eromheen, of een groter project aan te pakken waarbij je aan de slag gaat met de architectuur van de applicatie. Neem altijd de technologische context, de zakelijke doelen, en je visie als uitgangspunt om te bepalen wat er nodig is om onder de moderniseringskapstok te hangen.
In het huidige economische klimaat worden it-budgetten vooral gericht op de meest urgente behoeften. Het gevaar is dat dit leidt tot een backlog van applicaties die nu, meer dan ooit, aangepast moeten worden aan de benodigde zakelijke doelstellingen. De toekomst is nu. Innoveeer door te moderniseren.
Veel plezier met moderniseren.
Een belangrijke reden om applicaties te moderniseren wordt helaas in dit artikel niet genoemd. Misschien zou deze reden wel als nummer 1 in het rijtje moeten staan: Security. Met name legacy applicaties zijn in het verre verleden niet ontwikkeld met security requirements in het achterhoofd. Veel van deze oude applicaties zijn vervolgens voorzien van een “web-interface” waardoor de applicatie ook via Internet te gebruiken is. Dergelijke applicaties zijn zeer kwetsbaar. Hackers weten dit ook en hebben de afgelopen jaren hun focus daarom verschoven naar het inbreken in applicaties en websites. Gebruikte hack-methodes als SQL injection en Cross Site Scripting zijn populair en zéér eenvoudig uit te voeren. Bedrijven lopen daarbij grote risico’s op security incidenten. Wij voeren security scans uit op software en het aantal kwetsbaarheden wat wij aantreffen is bedroevend. Neem daarom de Security mee als overweging als je denkt aan modernisering van de gebruikte applicaties. Vraag ook aan je software developer of hij wil aantonen dat de software veilig is! Wij horen nog veel te vaak “De software is ontwikkeld door XYZ en we gaan ervan uit dat het veilig is”. Veilige software in combinatie met veilig gedrag van de medewerkers zal het aantal security incidenten verlagen en duurzame weerbaarheid van de organisatie creëren. Met vriendelijke groet, Rob Koch (Sebyde BV)
“Gebruikers hebben veel hogere verwachtingen van de gebruiksvriendelijkheid, omdat ze de zakelijke applicaties vergelijken met de laagdrempelige apps en games die ze privé gebruiken.”
Innovatie, moderniseren, opinie?
Of gewoon elkaar namauwen en iets verkopen?
Ergens… in de buurt van cijfers en percentages…. raak ik het spoor een beetje bijster.
TCO
De total cost of ownership en de wijze waarop het hier word gepresenteerd, is wat mij betreft een louter commerciële excercitie. Wie, welke managers, van waar? Het zijn een beetje dooddoeners die met regelmaat worden opgevoerd om iets te onderstrepen maar helemaal helderder word het daarom weer niet.
In de IT kun je TCO 100% inzichtelijk maken en voorspelbaar. (Ja ja ik hoor sommigen alweer iets denken, soit) De ROI is dan weer een ietwat andere zaak en van andere factoren afhankelijk.
Als managers TCO nu nog niet op hun netvlies hebben ben ik geneigd te zeggen, vervang die dan.
Hijgerig Hypen
Wat ik vooral zie is dat leveranciers van software een oude trck in nieuwe kledinglijnen hebben gestoken want de wetmatigheden en de redenen van automatiseren zijn in ht geheel niet veranderd. Die kun je allerlei nieuwe verfjes en namel geven, meteen daaronder is het gewoon zoals het altijd al was.
Leveranciers halen een tweede truc uit de kast. Die heet namelijk ‘ LockTite’. Er voor zorgen dat in mum van tijd je afnemer igenlijk niet meer zonder jou kan, althans, niet zonder zeer hoge conversiekosten. Oh rollback? Neehee…. dat doen we allang niet meer. Nergens voor nodig.
Point of no return
Na het verstrijken van die doodgezwegen ‘oint of no Return’, begint het gelazer. De portemonnee kan worden geopend want heel vaak begint het gezeik daarna namelijk. Allemaal onder de noemer dat ‘ wij zaken zijn tegengekomen die wij niet hebben kunnen voorzien…. of ‘ Legacy’.
Wel mijn beste auteur, met alle Respect….
Als je namelijk zogenaamd wordt verrast door onvoorziene omstandigheden of te maken krijgt met Legacy, dan spelen er twee zaken. 1. Goede inventarisatie inclusief upgraden en completeren van betreffende documentatie, en twee de vraag of je nou wel zo nodig zou moeten ‘ upgraden’… omdat.
Ik weet het, laatste is weinig commercieel, maar hé, door de bak genomen is vehikel IT dit eigenlijk ook niet. In tegendeel.
Beste NumoQuest,
Met betrekking tot de “onvoorziene omstandigheden” denk ik dit verwijst naar hoe de legacy applicaties zijn ontworpen, wat was het uitgangspunt destijds. Applicaties zijn er als het goed is voor de business. Als legacy applicaties nog worden gebruikt, dan is dit omdat dit een doel dient. En dan kan modernisering nodig zijn om de ‘business benefit’ te behouden. En dat is ook innovatie.
Monderniseren, prima, maar dan moet er wel een reden zijn. Wat is de huidige kwaliteit van de applicatie? Voldoet de functionaliteit? Sluit de documentatie aan? Is de code goed inderhoudbaar? Het inventariseren van de huidige situatie (IST) en de gewenste situatie (SOL) geeft inzicht. Voldoet de techniek om functionele wensen te implementeren. Voldoet de functionaliteit. Mijn visie;
is de documentatie verouderd, de bron code een puinhoop, breng dan eerst de documentatie op order. Je kan vervolgens bepalen welk standaardpakket het beste aansluit op je huidige functionaliteit. Vaak is moderniseren met behulp van een goed uitgewerkt frame-work goedkoper. Het model (de entiteiten en hun relaties) opschonen is relatief eenvoudig. Het herbouwen (assembleren met behulp van sjablonen) is geen kunst. Kosten besparen wel.