Het onderhoud van een legacy it-systeem is vaak uitbesteed aan de 'oude zakken'. Dit zijn de ervaren krachten die het it-systeem vooral draaiende houden, maar echte vernieuwing doorvoeren is er vaak niet bij.
Hier volgt waarschijnlijk een herkenbaar verhaal over een legacy it-systeem. Oorspronkelijk is het legacy systeem tientallen jaren geleden aangeschaft door de business. Er was een sterke vraag naar een innovatief systeem en de beste is geselecteerd en aangeschaft of zelf gemaakt. In het begin werden er nog veel wijzigingen aangebracht, maar gaandeweg steeds minder. Het applicatiebeheer is langzaam verschoven van vernieuwen naar in de lucht houden. Ook is de sturende rol van de business langzaam verschoven naar it-beheer. Bij grote aanpassingen is dan niet altijd duidelijk wie de verantwoordelijkheid heeft of de eigenaar is van het systeem. De verantwoordelijke is immers ook vaak diegene die de rekening krijgt en dan begint het touwtrekken. De voordelen zijn als het goed is voor de business, maar het systeem is van it, want die beheert het. Toch?
Zo moet het it-systeem bijvoorbeeld worden gemigreerd van de mainframe-omgeving naar een open omgeving, zoals een Windows-omgeving. Er worden verschillende aanpakken bedacht, maar verder dan de tekentafel komt het eigenlijk niet. Er is vooral onduidelijkheid en met iedere nieuwe aanpak zijn er weer nieuwe uitdagingen. De organisatie komt als het ware niet los van het praten over de migratie en de uitdagingen.
Tegelijkertijd worden nieuwe investeringen en aanpassingen voor het systeem uitgesteld. Je gaat immers geen geld investeren als je niet weet hoe lang je hier nog gebruik van kunt maken. Kleine aanpassingen worden nog wel gedaan, maar kosten doorgaans veel geld door de overhead van change-management, configuratie-management, release-management of welk management dan ook.
Signalen
Deze situatie is eenvoudig te herkennen. Het duidelijkste signaal is dat er al meer dan een jaar wordt gesproken over een mogelijke migratie zonder echt actie te ondernemen. Talloze overleggen zijn er reeds geweest en diverse modellen gemaakt, maar een keuze is er nog niet gemaakt. Telkens moest er nog iets nieuws uitgezocht worden.
Andere signalen dat het mainframe zijn langste tijd gehad heeft is het opeten van budget zonder dat er merkbare voortgang is. De beweging hoort zichtbaar te zijn in het aantal vragen en veranderingen en de omvang hiervan. Vaak wordt er veel tijd aan besteed, maar worden er slechts minimale veranderingen doorgevoerd.
Het laatste signaal is het zien van enorme hoeveelheden beren op de weg. Telkens komt er weer een nieuwe verrassing naar boven. Het lijkt alsof het totaalbeeld ontbreekt en er erg fragmentarisch wordt gewerkt. Tevens duidt dit op koudwatervrees. Deze twee versterken elkaar omdat iemand met een gedeeltelijk beeld grote problemen voorziet in het deel dat hij zelf niet in behandeling heeft.
Maatregel 1: Kleine behapbare stapjes
In de afgelopen tijd is de berg aan werk alleen maar groter geworden. Ook de energie om te beginnen is gedaald. Hoe begin je nu aan zoiets?
De Agile-beweging heeft ons geleerd dat het goed is om werk in kleine sprints op te delen. Het is het gedachtegoed van beginnen en snel resultaat laten zien in plaats van plannen blijven maken. Aantonen dat stukken werken en omgezet kunnen worden geeft vertrouwen aan zowel het team als aan de klant. Dit is niet nieuw want iedereen heeft er al een eigen naam voor bedacht: previews, demo’s of kitchen reviews. Het is echter ook heel goed toepasbaar in migratie trajecten. Lastige onderdelen kunnen afgesplitst worden en in een sprint gemigreerd en getest worden. Op die manier kunnen risico’s worden afgedekt terwijl steeds zichtbaar is of het einddoel nog wel haalbaar is.
Maatregel 2: 80 procent en dan weer verder
Hoewel niet volledig van Agile afkomstig, is het Pareto-principe prachtig van toepassing in combinatie met het Agile gedachtegoed en legacy-migratie. Het principe zegt dat je 80 procent van het resultaat bereikt met 20 procent van het werk. Van Agile leren we vervolgens dat een volgende activiteit kan starten als de vorige nog niet voor 100 procent af is. De activiteiten lopen dan in elkaar over. Zo kan de ontwikkeling starten als de specificaties voor 80 procent helder zijn en kan worden gestart met testen zodra de ontwikkeling voor 80 procent af is.
Het parallel lopen van de activiteiten verhoogt de kwaliteit en snelheid doordat de specificaties nog iets kunnen worden verfijnd tijdens de start van de ontwikkeling of doordat eerste problemen tijdens de test snel opgelost kunnen worden omdat de ontwikkeling nog bezig is.
Maatregel 3: Schakel specialisten in
Heb jij ook bewondering voor mensen die een oud huis opknappen? Als je geen verstand hebt van bouwen, zoals ik, dan lijkt het alsof het een klus is die niet te doen valt, maar voor de mensen die het doen lijkt het allemaal geen probleem. Natuurlijk kennen zij tegenslagen en duurt het langer dan verwacht, maar de grote beren die een buitenstaander ziet, zijn er helemaal niet. Kortom zorg er altijd voor dat je de juiste specialisten hebt om de migratie uit te voeren. Als deze intern niet aanwezig zijn, dan zal inhuren noodzakelijk zijn.
Bovenal vraagt een migratie ook gewoon om durf en vertrouwen dat het gaat lukken. Er ontstaan altijd nieuwe verrassingen, maar met de juiste specialisten en aanpak is het goed te doen.
@Jan: da’s lang geleden dat ik iets over VAX/VMS hoor! Ik neem aan dat er nog wel wat legacy systemen op dat OS draaien (OpenVMS dan natuurlijk). Is dat trouwens niet te emuleren op andere hardware met Linux: SIMH dacht ik? Daarmee verleng je de levensduur ook zonder dure herbouw.
Onderstaande is wat ik ervan weet…
– VM/CMS: dat zijn mainframes van IBM
– VMS een VAX computer is van Digital Equipment Corperation (DEC)
– Cray is een supercomputer
Maar goed, ben reeds geen 20 meer, derhalve zal deze info wellicht verouderd zijn.
Heb overigens nog wel met diverse OS/2 gekoppeld aan een paar AS400’n gewerkt, mooi werk was dat – met name het tikken met IBM toetsenborden staat mij bij als zeer prettig – die dingen wogen 1 kg.
Mooi artikel en zeker een actueel topic. Legacy systemen zijn vaak zeer succesvol, maar begint de applicatie zijn fit te verliezen in de veranderde organisaties. In mijn ogen is migratie dan ook niet altijd noodzakelijk. Waarom zou je risico lopen met iets wat goed werkt zonder dat er een directe noodzaak toe is? Migreren waar naar toe? Naar nieuwe legacy? In mijn ogen zit de kracht in het rationaliseren en niet in het migreren. Ontsluit de data, vernieuw functionaliteiten, innoveer en maak uiteindelijk de legacy applicatie overbodig.