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.
Volgende opmerking is toch wel erg dubieus:
“naar een open omgeving, zoals een Windows-omgeving”
MS Windows is geen “open” platform, dat weet iedere “specialist”.
In het artikel wordt over de agile beweging gesproken en even later wordt aangegeven dat er al met testen begonnen kan worden zodra de ontwikkeling voor 80 af is.
Testen is volgens mij een integraal onderdeel van de agile methodiek en er wordt continue getest.
Ook is het niet duidelijk of er 80 procent van een “kleine sprint” of juist van het geheel wordt bedoeld.
Een legacy systeem is per definitie een succesvol systeem. Anders was het nooit zo lang in productie gebleven… Waarom een goed werkend systeem migreren naar een Windows-omgeving wat inherent onveilig is en in 80% van de projecten mislukt?
Never change a winning team!
Er zijn genoeg beheerders en programmeurs te vinden die 30 jaar oude systemen kunnen beheren en onderhouden. Ze zijn alleen geen 20 jaar oud en komen evenmin net van school af, ze zijn ervaren en kennen het klappen van de zweep.
Misschien is in een mainframe omgeving MS Windows al best open en Agile alleen een raar woord..
maar goed, des te meer bewondering voor de schrijver van het artikel 🙂
Leuk artikel waar ik het grosso modo wel eens ben.
Het enige is dat je in mijn ogen Legacy niet in kleine stapjes kunt migreren. Als je een groot ERP pakket hebt, dat ook nog eens verbonden is met van alles, kun je hier geen “hapjes” uitnemen die je over hevelt naar een nieuw systeem. Daar zit altijd minstens één grote stap tussen waar het in de essentie om draait.
Wat je wel kunt doen is het applicatie landschap rationaliseren in kleine stapjes. Dus afscheid nemen van sateliet applicaties of de ontwikkeling ervan stilleggen. Integratie ontvlooien zodat alles niet meer verweven is met alles en er langzaam grip komt op alle lijken in alle kasten. Rationalisatie levert voor het oog echter weinig op. Het uitelkaar trekken van alle afhankelijkheden levert niets op anders dan dat je er beter afscheid van kunt nemen.
Uiteraard die je eerste een visie en strategie te hebben voordat je begint. Het gevaar met agile is dat je in sprints en kleine stapjes ergens uitkomt waar je niet wilt zijn. Dan als laatste wil ik leiderschap aanstippen als een welhaast noodzakelijk ingrediënt. Het is nagenoeg onmogelijk om van legacy af te stappen zonder dat het op bepaalde momenten pijn doet of dat politieke spelletjes de kop op steken. Als er geen leider is die draagvlak kan realiseren, dan is de kans op mislukking groot.
Mooi artikel over legacy. Het is software die werkt.
Herkenbaar wat je aandraagt over de legacy systemen die er zijn. Niet voor niets draaien vele systemen tientallen jaren en passeren vele vernieuwingsplannen de revue, en verdwijnen in de la. Het risico van het aanpassen of migreren van een systeem wordt vaak als groot ervaren. Het risico van de afhankelijkheid van een afnemend aantal specialisten en afnemende aanpasbaarheid, dus misfit met business, wordt voor lief genomen.
Bij Omnext hebben we al vele klanten geholpen met het analyseren en beschrijven van de werking en herdocumenteren van legacy systemen. Wij zijn een van die specialisten: onderzoekers die je kunnen vertellen wat je nu eigenlijk in huis hebt.Een gedegen source code analyse is een goede basis om beslissingen over de toekomst van een applicatie te nemen en goed door te ontwikkelen of verantwoord af te bouwen.
@Jan, ik heb bewust Windows toch een open omgeving genoemd, omdat het in vergelijking met een mainframe omgeving al erg open is.
@sprinter, de 80% geldt niet voor het totaal, maar meer voor losse onderdelen. Meer voor als een document voor 80% af is, dan geef je het door. Als iets wat ontwikkeld is, binnen 1 sprint, voor 80% af is dan geeft je het door. Ja 80% is dan een getal dat vragen zal oproepen, want in een sprint wil ik ook niet pas na 80% van de tijd iets doorzetten naar een tester, maar begrijp het Pareto-principe goed: 80% van het werk wordt gedaan in 20% van de tijd. Je hebt dus al heel snel een product dat getest wordt.
@Henri, goede aanvullingen, zo kunnen er nog vele artikelen worden geschreven zie ik alweer. Ja er is op een moment een grote klapper te maken. Toch kan de voorbereiding vaak echt goed in kleine stappen worden ingedeeld en dus ook prima in een Agile aanpak worden gedaan. Visie en strategie is zeker belangrijk, ook bij Agile projecten. Het is juiste de kunst om continu het eindbeeld in gedachte te hebben, maar toch kleine stappen te zetten. Te grote stappen leidt te vaak tot verzanden in het moeras.
@Ben
Wat noem je eigenlijk een mainframe? In vele artikelen zie ik zelfs VMS-systemen als mainframe betitelt en die zijn dat niet.
@Jan, goede vraag. Doorgaans zou ik die aanduiden met de maker, zoals IBM of Unisys niet zozeer een OS, maar dat is voor dit artikel niet zo relevant. Het is voor dit artikel eigenlijk vooral een kwestie van hoe gesloten een systeem is en een mainframe systeem associeer ik dan ook met gesloten en gespecialiseerde kennis die nodig is om wijzigingen op aan te brengen. Zodoende is een Windows omgeving open. Hiervoor is in de markt veel aanbod van specialisten.
@Ben,
Windows en VaxVMS, nu OpenVMS, zijn gesloten systemen, net als AS400 met OS400.
Bij grote mainframesystemen zoals die met MVS is de opbouw dermate verschillend van een Windowsomgeving dat ik me niet voor kan stellen dat een migratie mogelijk is. Daar wordt het nieuwbouw en dan betwijfel ik of windows een oplossing is, een linuxcluster biedt meer mogelijkheden vooral i.c.m. virtualisatie.
Meest belangrijke vraag is natuurlijk welke software, dat gaat bepalen wat mogelijk is.