Legacy-systemen leggen een enorme druk op IT-budgetten. Grote bedragen en forse inspanningen moeten worden gestoken in het onderhouden van oude en slecht gedocumenteerde applicaties. Analyse-methoden kunnen aan het licht brengen welke toepassingen aan vervanging toe zijn en welke – na weliswaar flink onder handen te zijn genomen – nog een hele tijd mee kunnen. Volgens consultants Klaas Stuijt en Laurens van der Stok leiden dergelijke methoden tot produktiviteitsverbeteringen van circa 35 procent.
Tegenwoordig spreekt men over ‘legacy-systemen’. Het probleem van het onderhouden van deze grote, veelal in Cobol geschreven applicaties is echter al zo oud als er mainframes in gebruik zijn. De problematiek heeft zo langzamerhand enorme proporties aangenomen. Zo publiceerde het Engelse vakblad Computer Weekly onlangs nogal onthutsende cijfers. Het gaat inmiddels om toepassingen die in totaal 150 miljard (!) regels code tellen en die een investering van 2300 miljard dollar hebben gevergd. Wereldwijd wordt per jaar maar liefst 300 miljard dollar uitgegeven aan software-onderhoud.
Gemiddeld zijn legacy-systemen twaalf jaar oud; dat doet het ergste vrezen ten aanzien van de documentatie. Uit een door de IBM-gebruikersvereniging Guide gepubliceerd onderzoek getiteld ‘Study on Legacy Management’ blijkt die vrees niet ongegrond. Maar liefst 50 procent van de onderhoudsinspanningen gaat zitten in het analyseren van de wijze waarop de code eigenlijk in elkaar zit, zie figuur 1.
Vervolgens wordt nog eens een kwart van de inspanningen besteed aan het testen of de aangepaste toepassing wel naar behoren functioneert. Nog eens 20 procent is nodig voor het plannen en documenteren van veranderingen. Van elke 100 gulden die we in Nederland uitgeven aan onderhoud, wordt dus slechts 5 gulden gestoken in het daadwerkelijk uitbreiden of verbeteren van de functionaliteit van de applicatie. Het onderhouden van legacy-systemen is dan ook een weinig efficiënte aangelegenheid.
Maar er is meer. De bekende uitspraak dat tot wel 80 procent van het IT-budget op gaat aan onderhoud wordt ieder jaar opnieuw bevestigd. Duidelijk is inmiddels ook dat het voortdurend geld uitgeven aan het corrigeren van software-fouten, het voorkomen van ‘crashes’ en het aanbrengen van kleine verbeteringen uiteindelijk weinig zin heeft. De kwaliteit van het te onderhouden produkt is veelal dusdanig, dat iedere nieuwe gulden die in de programmatuur wordt geïnvesteerd steeds minder voordeel oplevert. Als we niet oppassen, zijn we in veel gevallen eigenlijk alleen maar bezig met het in leven houden van achterhaalde systemen die gebouwd zijn met verouderde technologieën en gebaseerd zijn op oude structuren. Met andere woorden, we creëren vandaag de legacy-systemen van morgen.
Legacy heeft waarde
De kwalificatie ‘legacy-systeem’ impliceert voor veel mensen dat het systeem waardeloos is en niet langer te gebruiken. Je kunt echter ook anders tegen dit soort applicaties aankijken. Veel legacy-systemen ondersteunen immers nog dagelijks op uitstekende wijze allerhande bedrijfsprocessen en bevatten bovendien een schat aan ‘business rules’. Het is daarom beter om het begrip ‘legacy’ anders te definiëren en wel als ‘een oud informatiesysteem – wat betreft gebruikte technologie en applicatiestructuur – dat echter wel een duidelijk aanwijsbare waarde heeft voor de gebruikersorganisatie’. Het is dus de kunst om vast te stellen wat er met deze oude, maar wel degelijk waardevolle informatiesystemen dient te gebeuren zodat enerzijds de waarde van de applicaties voor de ondersteuning van de bedrijfsvoering behouden blijft en anderzijds de onderhoudskosten omlaag kunnen. Hiervoor is een beoordelingsmethode beschikbaar – de zogenaamde ‘4R analysis’ – die niet alleen kijkt naar de applicaties zelf, maar ook naar de technische infrastructuur en naar de wijze waarop het beheer en onderhoud zijn geregeld.
De methode geeft een oordeel op drie punten: de waarde van de applicatie voor de organisatie (business value), de technische kwaliteit van de toepassing (technical value) en de exploitatiekosten (beheer en onderhoud) van de programmatuur.
De ‘business value’ wordt ondermeer vastgesteld aan de hand van een vragenlijst waarin onder andere de volgende punten aan de orde komen.
Aard van gebruik. Hoe diep grijpt de toepassing in de organisatie in? Is de programmatuur bijvoorbeeld van vitaal belang voor het realiseren van omzet? Of zijn er contractuele verplichtingen richting klanten? In welke mate ondersteunt de software de bedrijfsprocessen van de organisatie?
Hergebruik. Kan de programmatuur ook op andere plaatsen binnen de organisatie worden toegepast? Kan een andere divisie of business- unit de applicatie zonder veel problemen ‘kopiëren’ en gebruiken? Impact. Hoe belangrijk is de programmatuur voor het functioneren van produkten, klanten of afdelingen?
Volledigheid. Is de toepassing compleet? Ondersteunt het bepaalde bedrijfsprocessen volledig of zijn daar nog andere applicaties voor nodig?
Betrouwbaarheid. Hoe betrouwbaar is de toepassing? Is de informatie die het de gebruiker verschaft eenduidig, betrouwbaar, accuraat? Gebruiksgemak. Is de software eenvoudig te gebruiken? Voldoen de help-functies aan de eisen en wensen? Kan een gebruiker er snel en gemakkelijk mee uit de voeten?
Technische staat
Voor het beoordelen van de technische staat waarin een applicatie zich bevindt, kan men ondermeer gebruik maken van hulpmiddelen als de McCabe Toolset. Hiermee is bijvoorbeeld de complexiteit van een applicatie te meten. Bij het vaststellen van de ’technical value’ wordt onder andere getoetst op de volgende punten. Architectuur. Is de structuur van de applicatie consistent met de architectuur waar de organisatie voor heeft gekozen? In welke mate wordt gebruik gemaakt van relationele database-managementsystemen, client/server-technologie, vierde-generatie talen, object-georiënteerde technieken, standaarden?
Aanpassingsvermogen. Is de programmatuur complex, modulair of gestructureerd opgezet? Zijn zaken als naamgevingsconventies en de integratie met het voor de gehele organisatie geldende enterprise-datamodel goed geregeld?
Kennis over applicatie. Is de functionele, technische en gebruikersdocumentatie aanwezig en in orde? Hoe goed is de onderhoudsafdeling op zijn taak berekend?
Stabiliteit. Hoe zit het met het aantal fouten dat optreedt? En de beschikbaarheid van de toepassing?
De ‘business value’ en de ’technical value’ worden vervolgens aan de hand van rekenregels gekwantificeerd en in een matrix uitgezet, zie figuur 2.
De positie van een applicatie binnen de vier kwadranten geeft een beoordeling en bepaalt in belangrijke mate de te volgen strategie.
Beoordelingen maken
Als een applicatie in de matrix een positie in het kwadrant retire inneemt, dan zou de applicatie in feite moeten verdwijnen. Er is sprake van zowel een lage economische als technische waarde. Het gaat hier in de regel om ongeveer een kwart van de legacy-systemen. Zijn er dwingende redenen om een dergelijke toepassing toch ‘in de lucht te houden’ dan kan gekozen worden voor min of meer cosmetische acties. Denk aan het onder een grafische gebruikersinterface brengen van een van oorsprong alfanumerieke applicatie.
Valt een applicatie in het reassess-gebied, dan betekent dit een lage economische, maar een hoge technische waarde. Deze score komt bij ongeveer 5 procent van de toepassingen voor. Veelal is dat een gevolg van devaluatie van de economische waarde door veranderingen in de markt, waardoor de applicatie de bedrijfsprocessen niet goed meer ondersteunt. Het toevoegen van nieuwe functionaliteit kan het bestaansrecht van de toepassing vergroten. Soms kan de programmatuur echter toch beter van het systeem worden gehaald.
Ongeveer de helft van de legacy-systemen valt in de categorie redevelop (hoge economische en lage technische score). Dit betekent dat veel geld wordt besteed aan onderhoud, omdat de organisatie nu eenmaal sterk van deze toepassingen afhankelijk is. Het is zaak voor dergelijke systemen de economische waarde te behouden, terwijl tegelijkertijd de kosten worden verlaagd. Het laatste kwadrant heet renew en kenmerkt zich door hoge scores ten aanzien van zowel de economische als de technische waarde. Een vijfde deel van de systemen valt in deze groep. Ze zijn belangrijk en technisch in goede staat en dienen dus behouden en ‘up-to-date’ te blijven. Om dat ook op langere termijn te laten gelden, moeten eveneens ten aanzien van deze systemen maatregelen genomen worden. Bijvoorbeeld door stukken code onder te brengen in een object-georiënteerde omgeving. In ieder geval kan functionele redundantie of ‘dode code’ worden verwijderd. Verder kan de applicatie in een meer-lagen-structuur worden gebracht.
Verbeteren onderhoudbaarheid
Het in kaart brengen van de legacy-systemen is slechts het beginpunt, zie figuur 3.
Het geeft een overzicht van de functionele, technische en economische staat van de diverse applicaties. Per geval dient men te bekijken hoe verder moet worden gegaan. In de figuur zijn hiervoor een aantal technische mogelijkheden op een rij gezet. De doelstellingen daarbij zijn dat de ‘business value’ van legacy-systemen moet worden gemaximaliseerd, terwijl de exploitatiekosten tot een minimum moeten worden teruggebracht. Daarnaast dient het risico dat een legacy-systeem door zijn hoge leeftijd kan opleveren, te verminderen door de betrouwbaarheid en de onderhoudbaarheid te vergroten. Ook wordt een betere integratie van de diverse applicaties nagestreefd en worden – waar mogelijk – toepassingen of modules daarvan hergebruikt.
Om beter zicht te krijgen op de concrete resultaten die met dit soort evaluatieprocessen bereikt kunnen worden, heeft het Software Engineering Institute (SEI), een organisatie die zich bezig houdt met ‘software process improvement’, onderzoek verricht onder dertien organisaties. De resultaten liegen er niet om: gemiddeld behalen organisaties als gevolg van een dergelijke analyse een produktiviteitsverbetering van maar liefst 35 procent. Die stijging ontstaat echter niet zomaar: een gemiddeld verbeteringsprogramma vergt 3,5 jaar en een jaarlijkse investering van gemiddeld een kwart miljoen dollar. Tegenover elke dollar die men investeert staat echter een gewin van 5 dollar, terwijl de ’time-to-market’ voor een applicatie met gemiddeld 19 procent kan worden bekort. Het aantal foutmeldingen na het operationeel worden van een applicatie daalt bovendien met gemiddeld 39 procent.
Dit soort cijfers maken duidelijk dat het verbeteren van de onderhoudbaarheid van legacy-systemen een zinvolle en lucratieve bezigheid kan zijn. Het risico voor een organisatie dat een oude applicatie met zich meebrengt, wordt verminderd terwijl de aangebrachte technische en organisatorische verbeteringen tot een aanzienlijke verlaging van de onderhoudskosten kunnen leiden.
Klaas Stuijt en Laurens van der Stok zijn senior consultants bij CSC Computer Sciences in Amsterdam.
Toekomst voor legacy-systemen
Grofweg kan men het functioneren – en daarmee de toekomst – van legacy-systemen aan de hand van de in dit artikel beschreven analyse-methode indelen in vier scores: retire, reassess, redevelop of renew. De vraag is welke actie op deze beoordeling dient te volgen. Daarvoor is een aantal technieken beschikbaar. Rationalisatie en herstructurering. De bestaande programma’s worden geschoond door eliminatie van redundantie en ‘dode code’, het toepassen van programmeerstandaarden, het verbeteren van de structuur van de applicatie en het opnieuw documenteren van de programmatuur.
Verdelen in componenten. De applicatie wordt in kleine componenten verdeeld waardoor deze beter onderhoudbaar wordt en eventuele vervanging component voor component kan plaatsvinden. Surrounding. Nieuwe of gewijzigde functionaliteit en data worden buiten de applicatie toegevoegd. Het legacy-systeem wordt daarmee ‘geïsoleerd’ en toekomstige wijzigingen worden tot een minimum beperkt.
Wrappering. Applicaties of delen hiervan worden ingekapseld waardoor objecten ontstaan. Hierdoor kunnen oude code en pakketten bestaan naast en communiceren met nieuwe objectgeoriënteerde programmatuur. Architectural layering. Applicaties of delen hiervan worden verdeeld over lagen die met behulp van standaard interfaces met elkaar communiceren. Denk aan een indeling in bijvoorbeeld een presentatie-, een functie- en een data-laag. Ook nieuw te bouwen toepassingen dienen de gekozen indeling aan te houden. Reverse engineering. In dit geval worden de oorspronkelijke ontwerpspecificaties afgeleid uit de bestaande programma-code. Dit leidt tot specificaties op een hoger abstractieniveau. Deze aanpak kan gebruikt worden om niet-gedocumenteerde code te leren begrijpen en biedt de mogelijkheid de stap naar forward engineering te maken. Forward engineering and regeneration. De code wordt met behulp van tools gegenereerd uit specificaties op een hoger abstractie-niveau. Daarbij worden handmatig geen modificaties in de code aangebracht. Conversie of rehosting. Een applicatie wordt naar een technologisch ander platform gemigreerd. Ook kan een informatiesysteem geïmplementeerd worden in een andere omgeving (programmeertaal of database).
Vervangen door standaardpakketten. Dit kan bij algemene toepassingen. Sommige pakketten kunnen ook worden toegepast in een surrounding- of wrappering-operatie.
Outsourcing. Bij outsourcing wordt een duidelijk te definiëren en af te bakenen taak geïdentificeerd en uitbesteed. Dit kan financiële voordelen opleveren bij het ontwikkelen, vervangen of in produktie houden van informatiesystemen.
