Verzand in het legacy-moeras

30-01-2013 13:46 | Door Ben Ootjers | Lees meer artikelen over: Legacy, Mainframes, Testing, Agile | Er zijn 13 reacties op dit artikel | Permalink
Computable Expert
Ben Ootjers
Ben Ootjers

IT Architect Unisys

Expert van Computable voor het topic Development

Meer

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.

Reacties op dit artikel
De redactie vindt deze reactie: OKJan van Leeuwen, 30-01-2013 15:36
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".
De redactie vindt deze reactie: OKsprinter, 30-01-2013 16:00
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.
De redactie vindt deze reactie: OKFrank, 30-01-2013 18:18
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.
De redactie vindt deze reactie: OKmauwerd, 30-01-2013 21:37
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 :-)
De redactie vindt deze reactie: OKHenri Koppen, 31-01-2013 9:32
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.
 
De redactie vindt deze reactie: OKWibo ten Have, 31-01-2013 9:49
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.
De redactie vindt deze reactie: OKBen Ootjers, 31-01-2013 10:42
@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.
De redactie vindt deze reactie: OKJan van Leeuwen, 31-01-2013 11:22
@Ben
 
Wat noem je eigenlijk een mainframe? In vele artikelen zie ik zelfs VMS-systemen als mainframe betitelt en die zijn dat niet.
De redactie vindt deze reactie: OKBen Ootjers, 31-01-2013 16:30
@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.
De redactie vindt deze reactie: OKJan van Leeuwen, 31-01-2013 23:24
@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.
De redactie vindt deze reactie: OKLeen Blom, 01-02-2013 14:30
@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.
De redactie vindt deze reactie: OKJurgen Prins, 04-02-2013 11:05
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.
 
De redactie vindt deze reactie: OKPatrick de Brabander, 21-02-2013 11:50
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.
101 vacatures
Web Developer ASP.NET C# (Medior / Senior)

NiDiDo BV , Barneveld

PHP Programmeur

BWSS B.V. , Deventer

.NET (C#) Programmeur

Let's build IT , Hoorn NH

Pielen in PHP, of on Rails in Ruby?

ForecastXL (via Quoratio BV) , Groningen

Senior SAP BW Specialist - Tilburg

Achmea , Tilburg

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1560 6.2
Klik voor meer info2 1293 6.0
Klik voor meer info3 1266 6.2
Klik voor meer info4 1066 6.2
Klik voor meer info5 976 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 519 6.1
Klik voor meer info9 394 6.0
Klik voor meer info10 391 6.2