Hoe vervang je een systeem dat anderhalf miljoen informaticatransacties aankan en dagelijks ca. 25 miljoen euro aan uitkeringen voor 4,5 miljoen leden voor zijn rekening neemt? Voorzichtig, uiterst voorzichtig, zoals Alain Conrath, directeur informatica bij de Landsbond der Christelijke Mutualiteiten heeft bewezen.

Opgericht rond de kerktorens als wederzijdse bijstandskassen vormt CM (Christelijke Mutualiteit) vandaag een cruciale instelling voor velen die bij de ziekenzorg moeten aankloppen. Zo heeft CM als wettelijke opdracht “het beheer en de uitvoering van de verplichte ziekte- en invaliditeitsverzekering, de organisatie van bijkomende diensten en voordelen, evenals de verstrekking van hulp, informatie, begeleiding en bijstand.” Daarnaast heeft ze ook een breed spectrum van bijkomende diensten ontwikkeld, van het eigen verenigingsleven tot sociaal-culturele activiteiten.

Hoewel de lokale en regionale entiteiten nog heel wat bevoegdheid hebben, voorziet de Landsbond der Christelijke Mutualiteiten al sinds jaar en dag de nodige it-infrastructuur ter ondersteuning van de 5.900 werknemers in de afdelingen. Een infrastructuur die jaarlijks ca. 300 miljoen prestaties behandelt en waar je dus zeker geen risico’s mee neemt als die aan vervanging toe is. Want, “als het systeem uitvalt, wordt de massa werk snel onoverzichtelijk groot,” maakt Alain Conrath meteen duidelijk.

Toch maar wegdoen

Een cruciaal systeem veranderen doe je niet voor de fun, maar om dringende redenen, en die waren er. Door de jaren heen was niet alleen het systeem zelf gegroeid, maar rond het systeem had zich ook een veelheid aan elektronische datastromen ontwikkeld. Die lopen van en naar de overheid, en tussen personen en organisaties uit de zorgsector, het controleorganisme en zelfs de leden. Een en ander leidde tot “de nood aan een 7 dagen op 7 architectuur, bijvoorbeeld voor de communicatie met de apotheken.” Tegelijkertijd begon ook de mainframeinfrastructuur zelf – met Siemens BS2000 systemen – wat zwaar door te wegen, met een resem problemen die niet onbekend in de oren klinken: hoge kosten, verouderde concepten, problemen met het onderhoud en een groeiend gebrek aan expertise op het vlak van BS2000 en Cobol. Oorspronkelijk werd overwogen om de toepassingen te herschrijven in Java Enterprise Edition en Oracle op Unix-systemen, maar een eerste project leerde al snel dat dit een klus van veel te lange adem zou worden. Het leek er dus op dat CM nog lang aan zijn mainframe zou zijn gekluisterd, tenzij er een oplossing werd gevonden om het hele systeem naar een andere omgeving over te zetten. Die oplossing moest dan wel rekening houden met 6,5 miljoen lijnen code, een databasesysteem op eerbiedwaardige leeftijd (met eigen uitbreidingen), een transactiemonitor, systeemtoepassingen in JCL en dies meer. Niet alleen slaagde CM in de overzetting van de BS2000 naar de nieuwe ‘CosMos’ omgeving – alias CM Open systems -, maar bovendien verliep dit in een ‘OneShot’-beweging.

CosMos brengt oplossing

Het succes van CosMos heeft alles te maken met de migratieaanpak, en de uiterste voorzichtigheid die daarbij aan de dag gelegd werd. Hard- en softwarematig werden voor het doelsysteem oplossingen gekozen die hun kwaliteiten ruimschoots hadden bewezen. Het werden HP9000 SuperDome servers onder HP/UX 11.23, een vervanging van het UDS hiëarchisch databeheersysteem door Oracle (RAC uitvoering, met mirroring in de productieomgeving), het omzetten van Siemens Cobol naar MicroFocus Cobol, het recreëren van de systeemtaken en dies meer. De UTM transactiemonitor werd gewoon behouden.

Een dergelijke migratie manueel uitvoeren dreigde een eeuwigheid te duren (om nog te zwijgen over het acute gevaar voor fouten) maar het Belgische Anubex leverde de gedroomde oplossing. Ooit begonnen met het migreren van Wang systemen, heeft Anubex zijn aanpak en werkwijze samengebracht in sterk ‘geautomatiseerde conversietools’ – absolute topexpertise die weinig andere bedrijven kunnen bieden op een veelheid aan systemen. Daardoor moest code slechts in beperkte mate met de hand worden overgezet. De migratie kon echter pas echt als geslaagd bestempeld worden als het nieuwe systeem ook zonder noemenswaardige kleerscheuren in productie ging. CM heeft daarom ruim de tijd genomen om alles bijzonder grondig te testen – wellicht langer dan eigenlijk nodig was, geeft Alain Conrath toe. Maar iedereen besefte dan ook dat er geen weg terug meer was na de overschakeling. De planning startte begin 2005. Parallel met de normale productieomgeving werden de nodige migratie-testomgevingen opgezet, eerst voor technische testen, vervolgens functionele testen, en dat zowel voor de online- als de batchverwerking. Er werd telkens weer een dataset van een dag verwerkt tot er geen discrepanties in de resultaten meer waren tussen de bestaande en de nieuwe omgeving. Ook werd voorzien in stresstesting, door het systeem bvb. open te stellen voor een grote groep CM-werknemers.

Vanaf het tweede kwartaal in 2007 werden bijkomende omgevingen uitgebouwd, zodat vandaag op het Unix-platform naast een productieomgeving ook een pre-productieomgeving (voor acceptatietesten, met disaster recovery-rol), een testomgeving (met een kopie van de productietoepassingen en -data, bestemd voor functionele testen) en een ‘devdev’ testomgeving (voor ontwikkeling en unit testen) draaien. De ontwikkelingsomgeving zelf draait op Windows. Begin november vorig jaar werden dan alle technische verantwoordelijken bij elkaar geroepen om te oordelen of het systeem rijp was voor een definitieve overschakeling. Er werd uiteindelijk een datum geprikt: begin 2008, met tussen 28 december en 4 januari dan ook écht de overstap.

Van risico’s en voordelen

Tijdens het hele proces diende Alain Conrath ook een reeks risico’s te counteren. Zo moest hij onder meer de nieuwe procedures voor back-up en restore en voor disaster recovery uitwerken. Die zijn van cruciaal belang, omdat “als een batchverwerking fout gaat, we altijd moeten kunnen terugvallen op de oorspronkelijke gegevens.”Daarnaast waren er ook menselijke risico’s, want de overstap had een grote impact op de organisatie en met name de ict-afdeling. Voor de mainframemensen was er de overstap naar Unix, en tegelijk ging het ook het beheer van manueel naar meer geautomatiseerde procedures over. “Mensen moesten zichzelf in vraag stellen, er was een leerproces en het vergde een grote mate van flexibiliteit,” stelt Conrath, die vaststelde dat sommigen het echt wel moeilijk kregen, wat bijkomend change management vergde. Voor de ontwikkelaars was de overstap naar MicroFocus Cobol niet zo’n probleem, maar ook zij moesten leren omgaan met een nieuwe ontwikkelingsomgeving en meer procedures (o.a. inzake testen) vooraleer nieuwe elementen in productie gaan. Dat neemt wat meer tijd, maar “de kwaliteit is beter, met dan ook minder problemen in de productie wat iedereen ten goede komt,” aldus Conrath. Met het nieuwe systeem bespaart CM bijna 1 miljoen euro per jaar, waardoor het op ca. 4,5 jaar zal zijn terugverdiend. Tegelijk beschikt de organisatie nu ook over krachtiger en meer flexibele systemen in een gestandaardiseerde infra-structuur, inclusief een grotere onafhankelijkheid ten opzichte van de leveranciers. De infrastructuur biedt voorts wel dezelfde ‘RAS’-kenmerken (reliability, availability, servicability) als een mainframe, beklemtoont Alain Conrath. Voor de eindgebruiker bracht de overstap geen veranderingen mee, want hij beschikt nog steeds over dezelfde functionaliteit als voordien. Wel werkt hij nu op een stabieler systeem, met een forse daling van het aantal servicecalls in de categorie ‘incident’ tot gevolg. En ‘last but not least’ kan CM nu op een rustig en aanvaardbaar ritme oude soft herschrijven en nieuwe toepassingen creëren, dank zij de mogelijkheid om oud en nieuw te integreren.

Guy Kindermans