Migratiestrategieën (informatietechnologie)

Vereisten voor een migratie

Om succesvol te zijn, moet een migratie ten minste aan de volgende vereisten voldoen:

• • Zorgen voor een ononderbroken, veilige en betrouwbare werking: storingen in centrale systemen zoals bedrijfsinformatiesystemen kunnen een bedrijf niet over een langere periode aankunnen, zelfs de kortste mislukkingen leiden tot (financiële) verliezen.

• Voer zoveel mogelijk wijzigingen uit om de huidige en toekomstige verwachte vereisten te dekken: dit zorgt ervoor dat het nieuwe systeem niet hoeft te worden aangepast kort nadat de migratie is voltooid en dat een verdere migratie vereist kan zijn.
• Maak zo min mogelijk wijzigingen om de omvang en het risico van migratie te verkleinen: hoe complexer een migratie, hoe groter het risico op fouten, hoe complexer een migratie zal zijn met het aantal gemaakte wijzigingen.
• Verander oude code zo min mogelijk om risico’s te minimaliseren: zolang de code werkt en geen nieuwe functionaliteit nodig is, moet deze worden toegepast zoals deze is of minimale wijzigingen worden aangebracht, omdat wijzigingen onvermijdelijk fouten in de implementatie zullen omvatten om zichzelf te trekken. Dit principe wordt echter meestal niet toegepast, omdat het hele systeem wordt herontwikkeld zonder dat er code is aangenomen.
• Wijzig de oude code om de migratie te ondersteunen: als er wijzigingen worden aangebracht in de code met een redelijke inspanning om de migratie te vergemakkelijken, moet dit worden gedaan.
• Neem de grootst mogelijke flexibiliteit op om toekomstige wijzigingen te vergemakkelijken: door functies te encapsuleren en een API (Application Programming Interface) aan te bieden, kunnen toekomstige ontwikkelingen en aanpassingen worden gefaciliteerd.
• minimaliseer mogelijke negatieve effecten van de veranderingen: bij alle wijzigingen aan het systeem moet worden gecontroleerd of deze wijzigingen nog steeds compatibel zijn met het systeem om foutieve ontwikkelingen in een vroeg stadium te voorkomen.
• Maximaliseer de voordelen van moderne technologieën en methoden: dit maakt het eenvoudiger om aan te passen aan de toekomst, en het laat ook toe dat systeemwaarden positief worden beïnvloed bij het beslissen over een migratie, zoals prestaties, datadoorvoer.

“Chicken Little” -strategie

Deze migratiestrategie bestaat uit elf “kleine stappen”, die incrementeel worden uitgevoerd, waardoor de migratie beheersbaar wordt, omdat de daadwerkelijke migratie wordt opgesplitst in kleinere delen (principe ” Divide & Conquer “). Niettemin betekent “Chicken Little” een compleet herontwerp van het systeem.

1. Analyse van het oude systeem: voor een succesvolle migratie is het essentieel om eerst te begrijpen hoe het oude systeem werkt. Dit zal worden geholpen door een hopelijk bestaande documentatie, anders reverse-engineering .
2. Demontage van het legacy-systeem: het legacy-systeem moet zo worden gewijzigd dat er gedefinieerde interfaces zijn tussen de afzonderlijke modules en de backends van de database.
3. Ontwikkel de interfaces van het doelsysteem.
4. Ontwikkeling van de doeltoepassingen: afweging, of de functionaliteit van de toepassing van het oude systeem opnieuw moet worden gemaakt of dat de oude toepassing alleen zo dicht mogelijk bij benadering moet worden benaderd.
5. De database-backend ontwikkelen: het bevat de resultaten van de voorgaande stappen en beveelt aan om te ontwikkelen met een relationele database op basis van SQL .
6. Installeer de doelomgeving: bouw een testomgeving en test die omgeving.
7. Ontwikkeling en installatie van gateways : de gateways zijn verantwoordelijk voor het extraheren van de gegevens uit het legacy-systeem en ze overbrengen naar het doelsysteem.
8. Migratie van de database van het oude systeem: installatie van het nieuwe databasesysteem, vervolgens migratie van de gegevens tussen het oude en het doelsysteem.
9. Migratie van legacy-applicaties: het geleidelijk vervangen van de afzonderlijke modules van oudere applicaties en hun integratie in het totale systeem.
10. Migratie van de gebruikersinterface
11. Overschakelen van het oude systeem naar het doelsysteem: het nieuwe systeem activeren en het oude systeem uitschakelen

Database eerst

Ten eerste wordt het databasesysteem gemigreerd naar een modern systeem voordat toepassingen en gebruikersinterfaces worden gemigreerd. Zogenaamde forward gateways worden gebruikt om toegang te krijgen tot de componenten van het legacy-systeem naar het nieuwe databasesysteem. Na volledige migratie van applicaties en interfaces kan de Forward Gateway worden uitgeschakeld.

Het belangrijkste voordeel van deze methode is dat aan het einde van de migratie de ontwikkelde toepassing en de database met elkaar overeenkomen, omdat de ontwikkeling van de toepassing pas begint nadat de migratie van de database is voltooid. De nieuwe database kan dus al worden gebruikt voor tests van de nog te ontwikkelen applicatie. Het is ook voordelig dat door de conversie naar de nieuwe database onmiddellijke verbeteringen in de rapportage door de huidige programmeertalen kunnen worden bereikt. Elke toepassing kan vervolgens een voor een worden gemigreerd zonder de functie van het systeem te beïnvloeden.

Het belangrijkste nadeel van deze aanpak is dat deze alleen van toepassing is op systemen met een gedefinieerde interface naar de databases, dwz een strikte scheiding tussen applicatie en databases. Bovendien moet de databasestructuur worden ontwikkeld voordat de migratie wordt gestart. De te ontwikkelen voorwaartse gateway kan ook zo ingewikkeld zijn dat het soms niet mogelijk is om een ​​gateway te maken.

Database laden

Deze aanpak is het tegenovergestelde van Database First en kan ook alleen worden toegepast op systemen met een gedefinieerde interface voor gegevens-backend.

Geleidelijk aan worden de toepassingen van het legacy-systeem gemigreerd, voor de gelijktijdige toegang van componenten van het oude en nieuwe systeem tot de database, moeten alle componenten van het nieuwe systeem de toegang via omgekeerde gateways afhandelen. De laatste stap van deze migratiemethode is de migratie van het databasesysteem naar het nieuwe platform.

Samengestelde databaseaanpak

Daarbij wordt het nieuwe applicatiesysteem geleidelijk ontwikkeld en geïmplementeerd terwijl het oude systeem nog steeds in bedrijf is. Beide systemen vormen dus een samengesteld systeem dat blijft bestaan ​​totdat de migratie is voltooid. De basis voor dit netwerk is een coördinatielaag waarin gateways naar de individuele databases van het oude en nieuwe systeem worden gevormd. Met behulp van toewijzingstabellen kunnen de individuele relaties worden gemigreerd. Het kan worden toegepast op volledig demonteerbare, semi-demontabele en niet demontabele beensystemen.

“Koud Turkije” / “Big Bang”

Net als bij “Chicken Little” is “Cold Turkey” een volledig nieuwe ontwikkeling van het oude systeem met behulp van moderne ontwikkelingsmethoden. Het nieuwe systeem zal parallel aan het oude systeem worden ontwikkeld en getest. Als het nieuwe systeem alle noodzakelijke tests heeft doorstaan, in een laatste stap, de “Big Bang”, wordt het legacy-systeem gedeactiveerd en neemt het nieuwe systeem het over. Dit resulteert echter in hoge risico’s voor een functionerende migratie:

• Een compleet nieuwe ontwikkeling kost tijd. Naarmate de tijd verstrijkt, vereist ontwikkeling echter wijzigingen in het oude systeem om aan de huidige behoeften van het bedrijf te voldoen. Dit creëert een algemeen probleem omdat deze wijzigingen in het oude systeem ook moeten worden opgenomen in reeds voltooide delen van het nieuwe systeem. Dit is foutgevoelig en kostbaar.
• Meestal is er geen documentatie voor de oude systemen behalve het systeem zelf, bijvoorbeeld de broncode . Er is nu het probleem dat de oorspronkelijke ontwikkelaars van het systeem meestal niet langer beschikbaar zijn en dat het systeem en de werking ervan dus moeten worden begrepen op basis van de broncode. Bovendien veroorzaken bepaalde programmeertechnieken, zoals zelfmodificerende code, migratieproblemen.
• Er zijn vaak ongedocumenteerde afhankelijkheden tussen het verouderde systeem en andere systemen. Deze afhankelijkheden kunnen zich uitstrekken over het gehele spectrum van niet-kritieke afhankelijkheden tot bedrijfskritieke afhankelijkheden. In de ontwikkelingscyclus van het legacy-systeem blijft het aantal afhankelijkheden toenemen en het bestaan ​​van deze afhankelijkheden is vaak onbekend vanwege het gebrek aan documentatie.
• De enorme hoeveelheid gegevens is een ander probleem voor deze aanpak. Zelfs als het doelsysteem volledig beschikbaar is, zou het in sommige gevallen weken duren om de gegevens van het oude systeem naar het nieuwe systeem over te zetten. Gedurende deze tijd zijn geen wijzigingen in de gegevens mogelijk en kan het systeem dus niet worden gebruikt. Dit is nauwelijks een haalbare optie voor een bedrijf. Ook wordt in een migratie meestal het gegevensschema gewijzigd, wat ook moet worden overwogen tijdens de gegevensmigratie.
• Het beheren van dergelijke grote projecten is buitengewoon moeilijk.
• De bovenstaande punten betekenen dat het ontwikkelingsplan nauwelijks kan worden aangehouden en dat de voltooiing van het systeem steeds verder wordt vertraagd.

Butterfly

De Butterfly Migration-aanpak is een strategie die, in tegenstelling tot Chicken Little, geen gebruik van gateways vereist. De methode is gebaseerd op een aanvankelijke migratie van gegevens achtereinden: het oude systeem blijft werken tijdens een testomgeving kan worden ontwikkeld en getest het nieuwe systeem al, zonder dat de normale werking of storend.

Belangrijk voor deze migratietechniek is de basisveronderstelling dat het allemaal om pure datamigratie gaat en dat samenwerking tussen legacy- en doelsystemen niet nodig is.

Aan het begin van het migratieproces worden naast de database van het oude systeem meerdere tijdelijke herinneringen ingesteld en de database tegen schrijven beveiligd. Door de Data Access Allocator de toegangen worden omgeleid: niet toegankelijk informatie wordt opgehaald uit de database, worden veranderingen beginnen in het tijdelijke geheugen TS ₁ geschreven. Als gewijzigde informatie moet worden opgehaald, wordt deze opgehaald uit TS ₁ .

Dan kunt u veilig, zonder verlies van gegevens en het verlies van kwaliteit van de dienstverlening van het systeem, de database van het oude systeem, genaamd over. “Chrysalizer”, een component die de gegevens overdraagt uit de gegevens schema van het oude systeem naar de nieuwe gegevens schema en ze op te nemen in de nieuwe gegevens terug in de nieuwe Systeem wordt overgedragen. Tijdens deze migratie worden alle gegevenswijzigingen, zoals hierboven beschreven, niet langer opgeslagen in de oudere gegevensbackend, maar in het tijdelijke geheugen TS ₁ .

Als de migratie van de oude database is voltooid, moet de informatie die in de tussentijd in TS ₁ is opgeslagen , ook worden gemigreerd. Voor dit doel is TS ₁ geblokkeerd voor schrijftoegang en wordt het nieuwe geheugen TS ₂ geopend. Wijzigingen in de database worden niet meer opgeslagen in TS ₁ , maar in TS ₂ . Elke keer dat nu een tijdelijke opslag TS _n van “Chrysaliser” is gemigreerd, het geheugen TS is _{n + 1}gesloten voor schrijftoegang, de opslag TS _{n + 2} geopend voor schrijftoegang van het oude systeem en het geheugen TS _{n + 1}overgedragen aan de “Chrysaliser”. U kunt sneller de inhoud van een tijdelijk geheugen wanneer het nieuwe geheugen wordt gemaakt op basis van het oude systeem te migreren, dat wil zeggen tijdens de migratie van een tijdelijk geheugen TS _n geen schrijftoegang het oude systeem te laten plaatsvinden, de grootte van het tijdelijke geheugen TS is _{n + 2} gereduceerd in de volgende stap. De grootte van het geheugen heeft voor{\ displaystyle n \ rightarrow \ infty}mathematisch de limiet nul.

Gehele migratie gaat het systeem normaal zolang de grootte van de laatste tijdelijke geheugen onder een bepaalde drempelwaarde, zodat de tijd vereist voor de migratie van deze laatste geheugen, uiterst kort. Daarna, in de laatste stap het oude systeem, de laatste tijdelijke opslag kan worden gestopt, worden overgezet naar het nieuwe systeem en het nieuwe systeem zal in werking worden gesteld, zoals nu is bereikt tussen de database van de oude en Neusystemes consistentie.

De voordelen van de vlindercorrectie zijn duidelijk: ten eerste is het gehele systeem, behalve de laatste stap van de omschakeling naar het nieuwe systeem kan de duur ervan verder worden geminimaliseerd door de oordeelkundige keuze van de drempelwaarde op elk moment. Ook kan de migratie op elk moment voor het schakelen van de systemen worden geannuleerd omdat de migratie is zolang omkeerbaar zolang alle gegevens op de Data Access Allocator liep. Als de migratie moet worden afgebroken, moeten de temp-geheugens die begint bij TS ₁ slechts één voor één in het datageheugen worden geïntegreerd.

Het nadeel van deze strategie is dat, afhankelijk van de activiteit in het oude systeem, een extreem groot aantal tijdelijke opslagplaatsen nodig kan zijn, die allemaal niet mogen worden overschreven, bijvoorbeeld in een round-robin-procedure , om een ​​mogelijke beëindiging van de migratie mogelijk te maken . In extreme gevallen kan een hoog niveau van hardwaregebruik vereist zijn voor geheugenbackends tijdens migratie. Een ander probleem is de ontwikkeling van de Data Access Allocator: het bespaart de ontwikkeling van gateways tussen de systemen, in tegenstelling tot “Chicken Little”, maar de Data Access Allocator is ook een zeer complexe component die veel ontwikkelingsinspanning kan vergen.

Zie ook

• legacy systeem
• Migratie (informatietechnologie)
• Elektronische archivering
• Informatie lifecycle management

Literatuur

• Brodie, Stonebraker: migratie van verouderde systemen; Morgan Kaufmann Publishers Inc., 1995
• Bisbal, et al.: Een onderzoek naar onderzoek naar legacy systeemmigratie
• Harry M. Sneed et al.: Softwaremigratie in de praktijk: oude softwaresystemen overbrengen naar een moderne omgeving. dpunkt.verlag, Heidelberg 2010, ISBN 3898645649 .