FloraHolland, de grootste producent en handelaar van snijbloemen ter wereld, worstelde met een erfenis uit het verleden. Verschillende Cobol-systemen op een oude infrastructuur kostten FloraHolland veel geld aan onderhoud en beheer. Bovendien werd de technische kennis bij FloraHolland steeds schaarser om het onderhoud en beheer adequaat uit te voeren. FloraHolland koos ervoor om het hart van haar IT te moderniseren door de Cobol-systemen geautomatiseerd te laten migreren naar C# op een moderne infrastructuur.
FloraHolland koos ervoor om het hart van haar IT te moderniseren door de Cobol-systemen geautomatiseerd te laten migreren naar C# op een moderne infrastructuur
FloraHolland had diverse bedrijfskritische Cobol-maatwerksystemen op een oude infrastructuur (VAX/VMS) draaien ter ondersteuning van haar logistieke en financiële processen, waaronder de facturatie. De continuïteit van de IT-ondersteuning van deze processen dreigde ernstig in gevaar te komen door een oplopende schaarste aan Cobol-expertise binnen de eigen organisatie.
Hiernaast was FloraHolland zich ook bewust van het feit dat de operationele kosten van hun oude infrastructuur factoren hoger lagen dan die van een moderne infrastructuur, zoals Windows. Ook was het voor FloraHolland duidelijk dat de productiviteit van het onderhoud op hun Cobol-systemen door migratie naar een nieuwe technologie kon worden verbeterd.
Migratie naar een moderne technologie was voor FloraHolland dan ook een logische keuze. Ook de keuze van de doeltechnologie kostte FloraHolland geen moeite. De standaard architectuur binnen FloraHolland is geënt op Microsoft C#. Deze expertise heeft FloraHolland al ruimschoots beschikbaar. FloraHolland koos in eerste instantie ervoor om zijn Cobol-systemen zelf te converteren naar C#, en wel handmatig. In deze conversie zou meteen de platformmigratie van de oude infrastructuur naar Windows worden meegenomen.
Uitdagingen
Vanwege grote technische verschillen tussen Cobol en C# verliep de handmatige conversie door FloraHolland moeizaam. Statements van de bron- en doeltaal leken op het eerste gezicht dezelfde werking te hebben, maar bleken uiteindelijk heel verschillend te zijn.
Een concreet voorbeeld hiervan is de toekenning van waarden. In bepaalde gevallen zal Cobol de toegekende waarde afkappen, terwijl dat in C# niet gebeurt, waardoor een verschillende functionele werking van de programma’s optreedt. Zonder diepgaande kennis van zowel bron- als doeltaal kunnen statements dus onjuist worden vertaald.
Statements van de bron- en doeltaal leken op het eerste gezicht dezelfde werking te hebben, maar bleken uiteindelijk heel verschillend te zijn
Ook de platformmigratie bood de nodige uitdagingen. Diverse utilities op de oude infrastructuur, zoals sorteringroutines met filterfunctionaliteit, vereisen nabootsing op Windows. Bovendien verschillen de karaktersets op de oude infrastructuur en onder Windows van elkaar, hetgeen de nodige problemen tijdens de conversie en het testen oplevert, zoals extra benodigde conversie van testbestanden. Hoe heeft FloraHolland deze uitdagingen opgepakt en tot een goed einde gebracht zonder haar businessprocessen te verstoren?
Diverse utilities op de oude infrastructuur, zoals sorteringroutines met filterfunctionaliteit, vereisen nabootsing op Windows
Investering
Het handmatig nabouwen van de Cobol-programma’s is een te lastige en langdurige opdracht. En meestal accepteert de Business niet wanneer gedurende een lange migratieperiode géén productiewijzigingen mogelijk zijn: de zogenaamde freeze-periode. Daarom is voor het succesvol uitvoeren van complexe migraties automatisering van de conversie essentiëel.
FloraHolland ging op zoek naar leveranciers die ervaring hebben met migraties en hier geschikte tools voor hebben. Een grotendeels geautomatiseerde conversie van Cobol naar C# bleek echter nog nooit eerder te zijn uitgevoerd.
De keuze van FloraHolland viel op de G4-tool van Cornerstone vanwege de goede basis die deze tool biedt voor de ontwikkeling van een geautomatiseerde conversie van Cobol naar C#. Vanuit Sogeti werd de migratiemethodiek Mikado™, integratiecapaciteit en ruimschootse ervaring met migraties ingezet. Voor de toolontwikkeling stelde Sogeti de conversieregels op, die Cornerstone in zijn conversietool implementeerde.
Mikado™
Mikado™ is een door Sogeti ontwikkelde migratieaanpak, gebaseerd op vele jaren ervaring. Mikado™ is ontwikkeld om migratieprojecten beheerst en gecontroleerd uit te voeren. Migraties worden daarbij gezien als een projectmatig proces, waarbij middels een één-op-één transformatie de functionaliteit van de bestaande (bron-) naar een nieuwe (doel)omgeving wordt overgezet en waarbij de continuïteit in de bedrijfsvoering wordt gegarandeerd. Vaak is er sprake van systemen die zijn ontwikkeld met ‘verouderde’ of achterhaalde technologie, die uiteindelijk niet meer voldoen aan de eisen en wensen van deze tijd en die vaak hoge kosten met zich meebrengen. Hierdoor ontstaat de noodzaak om de systemen en/of data over te zetten naar een modernere omgeving, eventueel met architectuurvernieuwing, en met behulp van analyse- en conversietooling.
Eerste helft
Sogeti initieerde het migratieproject en startte het volgens Mikado™ op: na een migratiescan (in Mikado-termen “Scenario analyse”) vond de projectinrichting plaats en startte het opstellen van de conversieregels en het parallel implementeren van de conversieregels in de G4-tool van Cornerstone. Het opstellen van de conversieregels bleek een lastig en langdurig proces te zijn, met veel iteraties en veel uitzonderingen. Met name het vertalen van de dataopslagstructuur in Cobol naar een object-oriented opslagstructuur in C# was te geïsoleerd, per programmadeel, opgepakt en niet als totaalconcept uitgewerkt. Na een lang traject was het nog steeds niet mogelijk om vanuit een automatische conversie een programma te compileren, terwijl de verzameling conversieregels al flinke proporties aannam.
Door het niet kunnen compileren was er ook geen zicht op de kwaliteit van de conversie qua functionaliteit: is de output van de geconverteerde programma’s wel identiek aan die van de oorspronkelijke?
Wisselen van spoor
Voor de ontwikkeling van een conversietool is het aan te raden om eerst een representatief programma volledig handmatig te converteren. Hieruit kunnen vervolgens de conversieregels worden afgeleid. Dit spoor is ook initieel bewandeld, maar vanwege tijdsdruk losgelaten. Het terugwisselen naar deze aanpak, maar met als uitgangspunt de al voor meer dan 90% automatisch geconverteerde programma’s, doorbrak deze impasse. De resterende 10% van enkele representatieve programma’s werd handmatig afgebouwd, totdat ze compileerbaar waren.
Vóór het handmatig afbouwen zijn afspraken gemaakt over de vertaling van de data-opslagstructuur en over de vertaling van de utilities op de oude infrastructuur, zodat deze meteen in het handmatig afbouwen meegenomen konden worden.
Het resultaat was enkele compileerbare en testbare representatieve programma’s. Door middel van een functionele test werd de kwaliteit van de conversie aangetoond. Dit was tevens het punt waarop gewisseld kon worden naar het opstellen en implementeren van de ontbrekende conversieregels op basis van de handmatige afbouw. Hierdoor is de conversietool gecompleteerd en kon de hoofdconversie op een beheerste manier worden uitgevoerd.
Het blijkt dus essentiëel te zijn om een Proof of Concept uit te voeren op een representatief deel van de te migreren systemen, om zodoende de complexiteit naar voren te halen, en daarmee de risico’s van het migratieproject te minimaliseren.
Het blijkt dus essentiëel te zijn om een Proof of Concept uit te voeren op een representatief deel van de te migreren systemen, om zodoende de complexiteit naar voren te halen, en daarmee de risico’s van het migratieproject te minimaliseren
Tweede helft
De gewijzigde aanpak maakte de resterende projectinspanning meteen meetbaar. Er konden goede schattingen worden gemaakt voor het implementeren van de resterende conversieregels, het testen en het bugfixen. Ook het kleine restant aan handmatige acties om de uitzonderingen in de geconverteerde programma’s te coderen werd direct inzichtelijk. De gewijzigde projectplanning werd in één klap realistisch en dus voorspelbaar. Na enkele kleine overschrijdingen van tussenmijlpalen vond de eindoplevering enkele werkdagen voor de geplande datum plaats.
Het realiseren van de vereiste functionaliteit en performance staat echter altijd op de eerste plaats. Uit het beperkte aantal bevindingen (minder dan één per geconverteerd programma) blijkt dat zowel de proces- als productkwaliteit van de tweede helft van het project dik in orde waren. FloraHolland heeft op basis van de acceptatietest en na het oplossen van de bevindingen de migratie geaccepteerd. De in productie name van de geconverteerde programma’s verliep zonder noemenswaardige problemen.
Ná de finish
Het FloraHolland migratieproject leverde een aantal waardevolle ervaringen op die in Mikado™ zijn geïntegreerd. De opgerichte unit Migratie Services is verantwoordelijk voor de integratie van deze migratieleerpunten. Doordat elke projectmanager van een migratieproject verplicht is om zijn ervaringen aan te leveren en omdat alle migratieprojecten waarin Sogeti betrokken is volgens de Mikado™ methode worden aangepakt, zorgt de borging van deze ervaringen ervoor dat niet opnieuw dezelfde knelpunten kunnen ontstaan.