NL2017782B1 - Gefaseerde migratie - Google Patents

Abstract

De onderhavige openbaarmaking betreft een werkwijze van gefaseerde migratie van een eerste IT platform naar een tweede IT platform van een systeem op basis van een bestand met entiteiten en bij het bestand behorende basismodules, welke bewerkingen verrichten, waaronder basisbewerkingen op of van de entiteiten in het bestand zoals store, update, delete, en read. Voor elke van ten minste een geselecteerd aantal entiteiten in het bestand creëren we een eerste kopie-entiteit op het eerste IT platform. Voor de eerste kopie-entiteiten verschaffen we bij iedere van de eerste kopie-entiteiten behorende basismodules op het eerste IT platform. Voor elke van het geselecteerd aantal entiteiten in het bestand creëren we een tweede kopie-entiteit op het tweede IT platform; Voor de tweede kopie-entiteiten verschaffen we bij iedere van de tweede kopie-entiteiten behorende basismodules op het tweede IT platform.

Description

GEFASEERDE MIGRATIE

De onderhavige openbaarmaking betreft een werkwijze van migratie. Daarbij kan het database migratie betreffen, of de migratie van een User Interface, bedrijfs- en besturings-code, en vele andere soorten migratie, op basis van een bestand op het als bron aan te merken IT platform, naar een als bestemming of doel aan te merken IT platform. Bij wijze van voorbeeld wordt hieronder veelal gerefereerd aan migratie van een database, maar de vinding volgens de onderhavige openbaarmaking is hiertoe dus niet beperkt.

Grote organisaties hebben steeds meer moeite om verouderde mainframe systemen, bijvoorbeeld voor administratieve doeleinden, operationeel te houden. Door middel van migratie kunnen nieuwe functionaliteiten op modernere platforms en in modernere hardware worden benut, en kunnen risico’ s van systeem crashes worden verminderd, die bij voorbeeld kunnen voorkomen wanneer niet-ondersteunde platforms en hardware de geest geven.

Daarbij spelen de volgende overwegingen een belangrijke rol, aangezien dit de belangrijkste hindernissen zijn voor migratie naar een moderner platform. IT specialisten met kennis van oudere talen worden steeds moeilijk te vinden en te behouden. Jongere medewerkers zijn terughoudend om zich te verdiepen in oudere talen, omdat dit wordt opgevat in een investering in achterhaalde technologie, en/of omdat dit niet past in hun carrière.

Het onderliggende platform van verouderde mainframe systemen is moeilijk te ondersteunen. Veel oudere systemen draaien op oudere hardware systemen. Producenten houden na verloop van tijd vaak op met het aanbieden van ondersteuning van oudere platforms en hardware systemen. Dergelijke hardware systemen worden daardoor duurder om te behouden, en personeel dat deze systemen kent, wordt na verloop van tijd dus ook steeds moeilijker te vinden.

Oudere software integreert slecht met andere systemen. De architectuur van de oude talen leent zich veelal niet voor het bouwen van bruggen naar andere IT-systemen binnen één-en-dezelfde organisatie.

Op dit moment zijn in essentie drie oplossingsstrategieën voor handen: 1. volledige herbouw van applicaties; 2. vervanging van applicaties door één of meer pakketten, dan wel inzet van Cloud diensten; 3. Conversie/Rehosting van de applicaties middels een “Big Bang” migratie; en

Ad 1. Herbouw is zeer kostbaar, duurt lang en geeft op functioneel vlak niet altijd voldoende toegevoegde waarde. Een voordeel van herbouw is dat de onderhoudbaarheid van het systeem beter wordt.

Ad 2. Het aanschaffen van één of meer pakketten brengt veelal aanzienlijke kosten met zich mee. Niet alleen de aanschaf zelf, maar met name ook het realiseren van koppelvlakken / interfaces is kostbaar, in termen van financiële middelen en van inzetbaarheid van IT specialisten, die hierdoor in beslag worden genomen. Voor Cloud diensten geldt ongeveer hetzelfde. Bij Cloud diensten zullen de initiële, eenmalige kosten iets lager zijn, maar vallen periodieke kosten veelal hoger uit.

Ad 3. Bij een “Big Bang” (ook wel “Cold Turkey” genoemd) wordt in een weekend volledig omgeschakeld naar het doel-platform, waarna geen weg meer terug is. Indien de nieuwe omgeving en applicaties fouten bevat kan niet meer worden teruggevallen op het oude platform. Deze “Big Bang” aanpak confronteert organisaties met zeer grote risico’s, waarbij zelfs het voortbestaan van de organisatie in het geding kan komen. Om een indicatie te geven over de belangen: onlangs heeft een gerenommeerde bank een migratie project afgeblazen kort voor de “Big Bang”. De kosten van zo’n beslissing kunnen oplopen tot wel rond de 100 miljoen euro, en meer, zonder dat de reden van de beoogde migratie is bereikt.

Een ander nadeel van reguliere “Big Bang” migraties is dat medewerkers van de organisatie een enorme testinspanning moeten leveren, hetgeen zich vertaalt naar hoge kosten. Een dergelijke testinspanning kan door IT medewerkers alleen naast hun reguliere werkzaamheden worden geleverd, hetgeen leidt tot een risico op overbelasting, terwijl het systeem functioneel niet wijzigt of wordt verbeterd. Motivatie om te testen is daarom veelal gering.

Software wordt vaak één-op-één vertaald naar een doeltaal die daar niet op ingericht is. Hierdoor neemt de kans op programmeerfouten toe, neemt onderhoudbaarheid af en worden latere aanpassingen duurder dan voorheen.

Veel liever zouden organisaties gebruik willen kunnen maken van een doelmatige gefaseerde migratie. Bij deze aanpak wordt het bron platform in delen over gezet naar het doel platform. Voordeel is dat de risico’s beperkt zijn. Daarentegen is een nadeel dat enorme inspanningen moeten worden geleverd om te migreren delen te ontkoppelen. De oorzaak hiervan is dat de verouderde systemen altijd intern zeer sterk verweven zijn als gevolg van het delen van databases/sequentiële bestanden, de user -interface en aanroepen naar andere programma’s.

Ter illustratie: wanneer een eerste programma moet migreren, dan zullen vele daarmee samenhangende programma’s ook mee moeten migreren. Maar met die met het eerste programma mee te migreren programma’s moeten ook weer daarmee samenhangende programma’s mee migreren, et cetera, en raakt het einde zoek. Uiteindelijk moeten dan alle programma’s gemigreerd worden en is alsnog sprake van een “Big Bang”.

Het isoleren van componenten van een legacy systeem vergt diepgaande analyses en vervolgens zeer veel programmeer- en test werk, waardoor de kosten van een gewenste gefaseerde aanpak - voor zover zo’n aanpak al daadwerkelijk te realiseren valt - enorm zijn.

Voor veel grote organisaties leveren herbouw, vervanging door pakketten en gefaseerde migratie geen business case op. Deze oplossingsstrategieën zijn simpelweg te duur.

De optie van de “Big Bang” wordt in de praktijk daarom met gepaste tegenzin dan toch het meest toegepast, omdat deze economisch wel enigszins interessant is, maar risico’s zijn vaak groot. Veel grote instellingen handhaven als gevolg hiervan langer de status quo, die vroeger of later doorbroken zal moeten worden.

Met de onderhavige openbaarmaking is beoogd een aanpak voor gefaseerde migratie te verschaffen, waarbij gefaseerde migratie voor het overgrote deel geautomatiseerd gerealiseerd kan worden in plaats van handmatig. Deze benadering is gedefinieerd in de geappendeerde conclusies.

Waar in de onderhavige openbaarmaking sprake is van entiteiten, zijn dit bij wijze van voorbeeld in het kader van een bankomgeving entiteiten, zoals: een entiteit “geldrekening”, een entiteit “klant” of rekening houder of een entiteit “overboekingsopdracht”, et cetera.

Het kenmerkend en onderscheidend onderliggend principe van de onderhavige openbaarmaking is het eerst ontvlechten en/of ontkoppelen van al dan niet verweven programmacode op het oude platform alvorens met de migratie te starten. Het principe is in IT ontwerp termen aan te duiden als: “Loosely coupling”. De ontvlechting en/of ontkoppeling kan in hoge mate geautomatiseerd plaats vinden.

Opgemerkt wordt dat het doel platform daarbij in eerste instantie het bron platform zelf is. Juist deze benadering is wezenlijk onderscheidend ten opzichte van alle bestaande migratie tools en biedt de sleutel naar geautomatiseerde en gefaseerde migratie.

In een specifieke uitvoeringsvorm met een aantal optionele aspecten / stappen, kan de onderhavige openbaarmaking worden onderverdeeld in enkele fasen, te weten “ontkoppeling”, daadwerkelijke “migratie”, en “testen”, elke met diverse of slechts een enkele stap. Testen kan op meerdere momenten worden uitgevoerd.

Deze fasen worden hieronder uiteengezet, in stappen en aan de hand van de in de geappendeerde tekening weergegeven processen, waarbij geen aspecten uit de beschrijving onder als beperking op de beschermingsomvang voor de onderhavige openbaarmaking kan of mag worden aangemerkt, als die aspecten of stappen niet als zodanige beperking zijn gedefinieerd in de geappendeerde hoofdconclusie(s), terwijl de in alle van de geappendeerde conclusies gedefinieerde eigenschappen kunnen worden verwezenlijkt met alternatieven, in het bijzonder voor de hand liggende alternatieven, zonder af te wijken van de in die conclusies gedefinieerde beschermingsomvang. De geappendeerde tekening toont in:

Figuren 1-8 voor migratie voorbereidende stappen op een eerste bron IT platform;

Figuren 9-19 stappen op het eerste bron ΓΓ platform en op een tweede doel IT platform.

Hieronder worden twee benaderingen gevolgd om uitvoeringsvormen te openbaren, te weten een stappenbeschrijving en een daarmee samenhangende figuurbeschrijving, die als aanvulling op of afzonderlijk van de stappenbeschrijving kan worden gezien.

In de fase “Ontkoppeling” worden de volgende stappen doorlopen: 1. Maak op het bron platform een bestand aan met daarin alle programmacode van het bron systeem. 2. Lees deze programmacode in met een daarvoor gecreëerde parser. De parser levert datastructuren op van de programmatuur die gebruikt worden voor analyse, het genereren van modules, het aanpassen van programmatuur en waar nodig conversies. 3. Analyseer met de datastructuren van de parser welke entiteiten / databasefiles in de programmatuur gebruikt worden. 4. Selecteer op basis van de analyse een van de entiteiten uit de beschikbare entiteiten. Dergelijke entiteiten kunnen een tabel zijn in een relationele Database. Geanalyseerd wordt welke entiteiten gebruikt worden en wat hun samenhang is, bijvoorbeeld in een technisch datamodel, en hoeveel gebruik gemaakt wordt van die entiteit, bijvoorbeeld door het tellen van aantallen records dat geschreven/gelezen wordt. Op basis daarvan mag verwacht worden dat de organisatie dat het systeem gebruikt uitspraken kan doen over die entiteiten, in het bijzonder hoe belangrijk de betreffende entiteiten zijn en wat hun functionele betekenis is.

De selectie in stappen drie en vier zal onder andere afhangen van de risico’s (kans x impact) en de samenhang met andere entiteiten. Door met de eenvoudigste en minst risicovolle te beginnen zal ervaring opgedaan worden met de specifieke situatie / configuratie. Hierdoor zal elke volgende slag een betrouwbaarder resultaat opleveren. Later kunnen entiteiten eventueel in samenhang (bijv. klant met bijbehorende rekeningnummers) worden overgezet. Enkelvoudig kan ook, maar dan zal met name voor de “commit” / “transaction handling” extra code gegenereerd moeten worden (two-phase commit, zoals bij voorbeeld geopenbaard op https://en.wikipedïa.org/’wiki/f\vo·· phase commit protocol 5. Creëer een kopie van de entiteit op hetzelfde bron platform, waarbij structuur en inhoud hiervan bij voorkeur beide gelijk zijn aan de entiteit in het bestand op het eerste of bron ΓΓ platform, waarop ook de kopie wordt gezet. 6. Genereer voor het bron platform een losse “toevoeg” / store module die het toevoegen van database records aan de kopie entiteit als functie heeft. Het genereren van de store module kan op basis van de informatie die beschikbaar is in de ingelezen programmatuur aangevuld met informatie uit de data dictionary. 7. Bepaal waar in de programmatuur database records aan de gekozen entiteit toegevoegd worden. 8. Genereer in de programma’s die het database record toevoegen direct onder het betreffende statement een aanroep naar de store module. 9. Vergelijk de resultaten van het oorspronkelijke statement en de aanroep van de module. Hiermee test het systeem zichzelf. Bij verschillen wordt een signaleringslijst aangemaakt. 10. Vergelijk periodiek de inhoud van de originele entiteit en de kopie entiteit. Deze vergelijking is een extra controle op de werking van de store module. 11. Herhaal bovenstaande stappen voor het wijzigen, verwijderen en lezen van records. 12. Als alle modules aantoonbaar goed werken dan kunnen stapsgewijs de oorspronkelijke statements die records toevoegen daadwerkelijk worden vervangen door aanroepen van de store module. 13. Nadien kan hetzelfde worden gedaan voor de wijzig- en verwijder- en lees-statements. 14. Als alle betreffende statements zijn vervangen door aanroepen naar modules, dan zijn de geraakte programma’s ontkoppeld wat betreft database benadering. De data-access is hiermee centraal beheersbaar. 15. Soortgelijke stappen worden genomen voor aanroepen naar andere programma’s alsmede de User Interface zijnde lijsten en scherm in- en uitvoer.

Telkens worden de betreffende statements stapsgewijs vervangen door aanroepen naar gegenereerde modules met dezelfde functie. Ook hier test het systeem zo veel mogelijk zichzelf, bij voorkeur door vergelijking van de kopie entiteiten en het bestand met de entiteiten.

De gegenereerde modules belichamen de ontkoppeling en zijn tevens een “man in the middle”. Door deze aanpak wordt de controle over hetgeen plaats vindt gecentraliseerd en beheersbaar gemaakt.

Als de data-access en User Interface zijn gecentraliseerd dan bevat de resterende programmatuur de besturings- en bedrijfs-code. Ook deze twee onderdelen kunnen geautomatiseerd afgescheiden worden voor zover dat nog noodzakelijk/gewenst is.

Pas als de voorgaande stappen zijn doorlopen kan begonnen worden met de daadwerkelijke migratie met bijbehorende conversie van statements. Ook hier vindt een stapsgewijze, risico mijdende benadering plaats.

In de fase “Migratie” vinden de volgende stappen plaats: 16. Creëer een kopie van de entiteit op het nieuwe doel platform(tweede IT platform). Hierbij zal onder andere data conversie nodig zijn. Deze stap kan worden uitgevoerd met bestaande tools in de markt. 17. Genereer voor het nieuwe doel platform (tweede IT platform) modules, die de tegenhanger zijn van of equivalent zijn aan de modules op het bron systeem. 18. Roep vanuit de bron modules de modules aan op het nieuwe platform en vergelijk de resultaten. Indien verschillen worden gedetecteerd, dan wordt een signaleringslijst aangemaakt. 19. Vergelijk periodiek de inhoud van de entiteit op het bron platform met de kopie entiteit op het nieuwe platform. Deze vergelijking is een extra controle op de werking van de modules op het nieuwe platform. 20. Als alle modules aantoonbaar goed werken dan kunnen stapsgewijs de modules op het bron platform worden vervangen door de modules op het nieuwe platform.

Op het moment dat alle modules op het bron platform vervangen zijn door de nieuwe modules dan kan de programmatuur van het bron systeem in stappen geconverteerd en overgezet worden. Voor conversies zijn tools in de markt. Het betreft hier de “Big Bang” tools. Alleen met de beschreven gefaseerde aanpak/voorbereiding zijn kleine stappen met deze tools ook mogelijk.

Ten behoeve van de fase “testen”, worden de volgende stappen doorlopen:

Zoals beschreven testen de modules zoveel mogelijk zichzelf. Voor de besturings- en bedrijfscode kan de handmatige test-inspanning als volgt aanmerkelijk verminderd worden: 21. Splits de besturingscode af. Deze besturingscode is de basis structuur van een programma (mainline). 22. Bouw geautomatiseerd in de te migreren delen tellers in die bijhouden hoe vaak de takken in een programma geraakt worden. 23. Laat de oude en de nieuwe bedrijfscode gelijktijdig draaien op beide platformen onder aansturing van debesturingscode. Het gaat hier om “live” schaduw draaien. In deze fase is de oude bedrijfscode operationeel en dus leidend. 24. Vergelijk de resultaten. Bij verschillen wordt een signaleringslijst aangemaakt met bevindingen. 25. Rapporteer over een gegeven periode welke takken niet geraakt zijn (en dus nog niet getest zijn) 26. Doe eventueel suggesties voor testgevallen op basis van hetgeen verwerkt is. 27. Plaats die concrete testgevallen (database records) in een aparte test-omgeving in samenhang met andere databaserecords/files. 28. Verwerk de gegenereerde testgevallen in de testomgeving door ook daar schaduw te draaien. 29. Vergelijk de resultaten en rapporteer bevindingen. 30. Alleen voor die situaties die aantoonbaar niet getest zijn zullen nog testsets gemaakt moeten worden. Naar schatting is dit maximaal slechts 20% van een reguliere testinspanning. 31. Herhaal het bovenstaande voor debesturingscode.

Wanneer al het bovenstaande is uitgevoerd kan een volgende entiteit opgepakt worden. Dit betekent een iteratief proces voor de beschikbare entiteiten, en dat selectie daarvan uit een steeds kleiner wordende populatie geschiedt, en progressief moeilijkere entiteiten kunnen worden opgepakt, maar waarbij de voorgaande behandeling van simpelere entiteiten bij draagt aan vereenvoudiging van analyse en verwerking van de moeilijkere entiteiten.

Naar wens kunnen stappen worden samengevoegd, tests verkort en/of entiteiten parallel uitgevoerd worden ten einde het tempo te verhogen.

Hieronder is een en ander nader uitgewerkt, onder verwijzing naar de geappendeerde figuren van de tekening.

In figuur 1 is de uitgangssituatie op het bron platform getoond.

De cilinder met de tekst DB representeert het database bestand en meer in het bijzonder een entiteit in de database. De bolletjes zijn programma’s, hier aangemerkt als basismodules, die ergens in de code respectievelijk een record toevoegen, wijzigen, verwijderen en lezen. De pijlen geven de request en response naar de database weer. De basismodules verrichten basisbewerkingen op of van de entiteiten in het bestand, zoals store, update, delete, en read.

In figuur 2 is een volgende stap weergegeven. De functie daarvan is: genereer store module.

Toelichting: de store module wordt gegenereerd op basis van de informatie uit de data dictionary én het programma dat records toevoegt. De store module heeft uitsluitend als functie het opslaan van records van de geselecteerde entiteit.

In figuur 3 is de functie weergegeven van het koppelen van de store module aan programma.

Toelichting: in de programma’s die records toevoegen aan de geselecteerde entiteit wordt de store module geautomatiseerd toegevoegd direct na het statement dat de toevoeging doet. Het betreft in deze fase nog een aanroep naar een loze store module die altijd een return code nul terug geeft.

In figuur 4 is de functie weergegeven dat de database entiteit wordt gekopieerd.

Toelichting: op hetzelfde Bron platform (het eerste IT platform) wordt bij voorbeeld in een maintenance window een entiteit aangemaakt met dezelfde structuur en inhoud als de te migreren entiteit. De kopie database entiteit wordt direct daarna gekoppeld aan de store module.

In figuur 5 is een functie weergegeven dat de database entiteit wordt gekoppeld.

Toelichting: de kopie database entiteit wordt direct na het kopiëren gekoppeld aan de store module.

De werking van de store module kan gecontroleerd worden door op run-time de pre- en post condities te vergelijken, bijvoorbeeld returncodes. Deze zelfcontrole / autocheck wordt aangevuld met een periodieke controle op toegevoegde records in de databases.

Indien fouten geconstateerd worden dan zal de oorzaak weggenomen moeten worden alvorens naar de volgende stap te gaan.

In figuur 6 is een functie weergegeven dat overige modules worden gegenereerd en gekoppeld.

Toelichting: voor alle programma’s die de database entiteit raken worden dezelfde stappen genomen voor de update-, delete- en read. Bij de uitrol van de update en delete stappen wordt de database entiteit opnieuw gekopieerd ten einde de twee entiteiten synchroon te laten blijven.

Als het bovenstaande gerealiseerd is dan zullen de databases dezelfde data blijven bevatten. Dat kan worden onderworpen aan een controle op basis van vergelijking.

Na een periode schaduw draaien met zelfcontroles/autochecks kan gestart worden met het ontkoppelen van de oorspronkelijke, verweven database benaderingen.

In figuur 7 is een functie weergegeven van het verwijderen de oorspronkelijke lees acties.

Toelichting: voor alle programma’s, die de database entiteit lezen, worden stuk voor stuk de oorspronkelijke lees-acties uit het betreffende programma verwijderd.

In figuur 8 is een functie weergegeven voor het verwijderen van de oorspronkelijke store-update en delete acties.

Toelichting: voor alle programma’s die de database entiteit muteren worden stuk voor stuk de oorspronkelijke muteer-acties uit het betreffende programma verwijderd.

Na afronding van deze fase is de ontkoppeling van de database entiteit een feit en kan worden over gegaan naar de migratie.

In figuur 9 is een eerste stap weergegeven die betrekking heft op het doel platform, ook wel aangeduid als het bestemmingsplatform.

De functie is het genereren van de store module op het nieuwe, tweede IT platform.

Toelichting: vanaf hier worden in grote lijnen dezelfde stappen genomen als op het bron platform (het eerste IT platform), maar dan op het tweede IT platform, dat als bestemming of doel aan te merken is.

De store module wordt gegenereerd op basis van de informatie uit de data dictionary én het programma dat records toevoegt.

Een verschil met de eerste stap op het bron platform is dat de store module is gegenereerd in de taal van het doel platform én is aangepast op de database die bij dat platform hoort. Vanwege dat laatste is de store module op het doel platform nooit een geconverteerde versie van het bron platform.

In figuur 10 is een vervolgstap weergegeven. De functie daarvan is het koppelen van een nieuwe store module aan de store module op het bron platform

Toelichting: in de oorspronkelijke store module wordt een aanroep geactiveerd naar de store module op het doel platform. De aanroep vindt plaats na de benadering van de kopie database entiteit op het bron platform. Het betreft in deze fase nog een aanroep naar een loze store module die altijd een return code nul terug geeft.

In figuur 11 is de functie weergegeven dat de database entiteit wordt gekopieerd.

Toelichting: op hetzelfde doel platform wordt een entiteit aangemaakt met een soortgelijke structuur en inhoud als de te migreren entiteit. Deze stap kan uitgevoerd worden met bestaande database migratie tools.

Met de genereerde store module op het doelplatform kunnen verschillen in opslagstructuur (bijvoorbeeld hiërarchisch versus relationeel) opgelost worden door de data om te vormen in het gewenste formaat.

De kopie database entiteit wordt direct daarna gekoppeld aan de store module.

In figuur 12 is een functie weergegeven dan het koppelen van de database entiteit.

Toelichting: de kopie database entiteit wordt direct na het kopiëren gekoppeld aan de store module.

De werking van de nieuwe store module kan gecontroleerd worden door op run-time de pre- en post condities te vergelijken, bijvoorbeeld returncodes. Deze zelfcontrole / autocheck wordt aangevuld met een periodieke controle op de inhoud van de databases.

Indien fouten geconstateerd worden dan zal de oorzaak weggenomen moeten worden alvorens naar de volgende stap te gaan.

In figuur 13 is de functie weergegeven dat overige modules worden gegenereerd en gekoppeld.

Toelichting: voor alle modules op het bron platform worden dezelfde stappen genomen.

Bij de uitrol van de update en delete stappen wordt de database entiteit opnieuw gekopieerd ten einde de twee entiteiten synchroon te laten blijven.

Als het bovenstaande gerealiseerd is dan zullen de databases dezelfde data blijven bevatten. Middels schaduw draaien met zelfcontroles/autochecks wordt de werking van de modules op het doel platform bewezen.

In figuur 14 is de functie weergegeven dat programma’s met store acties worden geconverteerd.

Toelichting: elk programma dat store acties uitvoert op de geselecteerde entiteit kan nu geconverteerd worden, naar wens per programma of groepen programma’s tegehjk. Het converteren kan met behulp van bestaande conversie tools of door het hier beschreven tooi zelf.

De geconverteerde programma’s worden uitgerold op het doel platform.

In figuur 15 is een verder functie weergegeven van het activeren van het store programma.

Toelichting: elk geconverteerd programma dat store acties gaat uitvoeren op het doel platform wordt gekoppeld aan de bijbehorende store module op het doel platform. De store module op het doel platform geeft de store verzoeken door aan de database alsook aan de store module op het bron platform. Hiermee blijft het bron platform synchroon lopen en kan op ieder moment een fall back worden gegarandeerd.

Het geconverteerde programma wordt gestart door de tegenhanger op het bron platform zodat het programma’s op dezelfde momenten blijft draaien. De start instructie wordt geautomatiseerd ingebouwd in de programma’s op het bron platform.

De werking van het geconverteerde programma kan gecontroleerd worden door op runtime de pre- en post condities te vergelijken, bijvoorbeeld returncodes. Deze zelfcontrole / autocheck wordt aangevuld met een periodieke controle op toegevoegde records in de databases.

Indien fouten geconstateerd worden dan zal de oorzaak weggenomen moeten worden alvorens naar de volgende stap te gaan.

In figuur 16 is een functie weergegeven dat de overige programma’s worden geconverteerd en geactiveerd.

Toelichting: voor de resterende programma’s wordt gefaseerd dezelfde stappen genomen als bij de store.

Als alle programma’s zijn overgezet en geactiveerd dan kan gecontroleerd worden hoe het systeem op het nieuwe platform zich gedraagt (zie uitleg vorige stap). Waar nodig kunnen niet geraakte takken worden gesignaleerd. Afhankelijk van de situatie kunnen extra tests worden uitgevoerd.

In figuur 17 is een functie weergegeven dat het nieuwe store programma leidend wordt gemaakt.

Toelichting: de geconverteerde programma’s met store acties worden stuk voor stuk daadwerkelijk operationeel op het doel platform.

Het starten van de geconverteerde programma’s vindt nog wel plaats vanuit het bron platform. Op het bron platform wordt de store module niet meer aangeroepen door het oorspronkelijke programma met store acties.

De store module op het doel platform geeft de store verzoeken door aan de database alsook aan de store module op het bron platform. Hiermee blijft het bron platform synchroon lopen en kan op ieder moment een fall back worden gegarandeerd.

In figuur 18 is een functie weergegeven waarbij overige programma’s leidend worden gemaakt op het doel platform.

Toelichting: alle geconverteerde programma’s worden stuk voor stuk daadwerkelijk operationeel op het doel platform conform de vorige stap. De update en delete gaan als eerste, pas als laatste de programma’s met lees acties.

Bij het operationeel/leidend maken van de programma’s met een update en delete actie zal telkens de database entiteit op het doel platform moeten worden overschreven (restore) met de inhoud van de database op het bron platform.

In figuur 19 is een stap weergegeven dat verbinding met bron database entiteit wordt verwijderd of ontkoppeld.

Toelichting: als het systeem stabiel draait en een fall back niet meer nodig is, dan kan de verbinding tussen de store-, update en delete-modules verbroken worden.

Op de aansturing na zijn de platformen ontkoppeld. Voor de aansturing/ scheduling bestaan in de migratie markt oplossingen. Deze kunnen incrementeel ingezet worden.

Na het volledig loskoppelen van de platformen kan gestart worden met re-factoring op het doel platform. Ook hiervoor zijn tools in de markt verkrijgbaar.

Op basis van de voorgaande beschrijvingen van uitvoeringsvormen van de onderhavige openbaarmaking, is de openbaarmaking volledig en compleet. Desalniettemin dekt de onderhavige openbaarmaking ook aanvullende en alternatieve uitvoeringsvormen, ten opzichte van die in deze openbaarmaking. Dergelijke al dan niet openbaar gemaakte uitvoeringsvormen vallen binnen de beschermingsomvang van de onderhavige openbaarmaking, tenzij deze indruisen tegen de diepere gedachte van de oplossingen voor problemen met systemen volgens de stand der techniek, en omvatten ook alternatieven voor de in de figuurbeschrijving geopenbaarde en in de geappendeerde conclusies gedefinieerde uitvoeringsvormen.

Claims (14)

1. Werkwijze van gefaseerde migratie van een eerste IT platform naar een tweede ΓΓ platform van een systeem op basis van een bestand met entiteiten en bij het bestand behorende basismodules, welke bewerkingen verrichten, waaronder basisbewerkingen op of van de entiteiten in het bestand zoals store, update, delete, en read, omvattende: - het voor elke van ten minste een geselecteerd aantal entiteiten in het bestand creëren van een eerste kopie-entiteit op het eerste IT platform; - het voor de eerste kopie-entiteiten verschaffen van bij iedere van de eerste kopie-entiteiten behorende basismodules op het eerste IT platform, welke bij de eerste kopie-entiteiten behorende basismodules dezelfde basisbewerkingen verrichten op de eerste kopie-entiteiten als die welke de bij het bestand behorende basismodules verrichten op de entiteiten in het bestand; - het voor elke van het geselecteerd aantal entiteiten in het bestand creëren van een tweede kopie-entiteit op het tweede IT platform; - het voor de tweede kopie-entiteiten verschaffen van bij iedere van de tweede kopie-entiteiten behorende basismodules op het tweede IT platform, welke bij de tweede kopie-entiteiten behorende basismodules dezelfde basisbewerkingen verrichten op de tweede kopie-entiteiten als die welke de bij het bestand behorende basismodules verrichten op de entiteiten in het bestand.

2. Werkwijze volgens conclusie 1, waarbij de bij de eerste kopie-entiteiten behorende basismodules dezelfde basisbewerkingen verrichten op de eerste kopie-entiteiten als die welke de bij het bestand behorende basismodules verrichten op de entiteiten in het bestand, in reactie op aanroep van de bij het bestand behorende basismodules.

3. Werkwijze volgens conclusie 1 of 2, verder omvattende: het van de bij het bestand behorende basismodules ontkoppelen van het bestand, in samenhang met en bij voorkeur voorafgaand aan het creëren van een tweede kopie-entiteit op het tweede IT platform.

4. Werkwijze volgens conclusie 3, verder omvattende het gedurende een periode op inhoud vergelijken van de eerste kopie-entiteiten en de entiteiten in het bestand, voorafgaand aan het ontkoppelen.

5. Werkwijze volgens een willekeurige of meer dan één van de voorgaande conclusies, waarbij het voor elke van het geselecteerd aantal entiteiten in het bestand creëren van een tweede kopie-entiteit op het tweede IT platform omvat: het verschaffen van de tweede kopie-entiteiten op het tweede IT platform in een van het tweede IT platform afhankelijk format, met een ten minste in hoofdzaak zelfde inhoud als overeenkomstige entiteiten in het bestand.

6. Werkwijze volgens een willekeurige of meer dan één van de voorgaande conclusies, waarbij de bij de tweede kopie-entiteiten behorende basismodules dezelfde basisbewerkingen verrichten op de tweede kopie-entiteiten als die welke de bij het bestand behorende basismodules verrichten op de entiteiten in het bestand.

7. Werkwijze volgens een willekeurige of meer dan één van de voorgaande conclusies,, waarbij de bij de tweede kopie-entiteiten behorende basismodules dezelfde basisbewerkingen verrichten op de tweede kopie-entiteiten als die welke de bij de eerste kopie-entiteiten behorende basismodules verrichten op de eerste kopie-entiteiten in reactie op aanroep van de bij de eerste kopie-entiteiten behorende basismodules.

8. Werkwijze volgens een willekeurige of meer dan één van de voorgaande conclusies, in het bijzonder conclusie 6, waarbij het verschaffen van bij de tweede kopie-entiteiten behorende basismodules omvat: het genereren van de bij de tweede kopie-entiteiten behorende basismodules in een met het tweede ΓΓ platform samenhangende programmeertaal.

9. Werkwijze volgens een willekeurige of meer dan één van de voorgaande conclusies, verder omvattende: het van de bij de eerste kopie-entiteiten behorende basismodules ontkoppelen van de eerste kopie-entiteiten, in samenhang met en bij voorkeur nadat de tweede kopie-entiteiten en de bij iedere van de tweede kopie-entiteiten behorende basismodules zijn gecreëerd, dan wel verschaft, en werkzaam met elkaar in samenhang zijn gebracht.

10. Werkwijze volgens conclusie 9, verder omvattende het gedurende een periode op inhoud vergelijken van de tweede kopie-entiteiten en de eerste kopie-entiteiten, voorafgaand aan het ontkoppelen.

11. Werkwijze volgens een willekeurige of meer dan één van de voorgaande conclusies, verder omvattende: het uiteindelijk ontkoppelen van aanroepen in het eerste IT platform.

12. Werkwijze volgens een willekeurige of meer dan één van de voorgaande conclusies, verder omvattende: het afzonderlijk naar het tweede IT platform converteren van op het eerste IT platform draaiende programma’s.

13. Werkwijze volgens conclusie 12, verder omvattende: het genereren van op de geconverteerde programma’s gebaseerde basismodules, en het daaropvolgend toestaan van aanroepen van de op de geconverteerde programma’s gebaseerde basismodules voor basisbewerkingen op of van de tweede kopie-entiteiten.

14. Informatiedrager met een daarop opgeslagen programma voor het in een op een computer geladen toestand ten uitvoer brengen van de werkwijze volgens ten minste één van de voorgaande conclusies.