Wie isst man einen Elefanten? Im Tranchieren liegt das Geheimnis einer inkrementellen Datenmigration

Gelegentlich sind Unternehmen gezwungen, auf eine neue IT-Anwendung umzusteigen. Gründe hierfür können veraltete Technologien, die Digitale Transformation oder eine Unternehmensfusion oder -übernahme sein. Und, oh Schreck! Die Daten müssen umziehen.

Anbieter zum Thema

Rosenberger-OSI GmbH & Co. OHG

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

adesso AG

adesso SE

Zu den größten Herausforderungen einer Datenmigration gehören oft unterschiedliche Datenmodelle der Systeme, schlechte Datenqualität im Altsystem und starke Restriktionen des Zielsystems. Soll eine größere Datenmenge migriert werden, sind die Analysten gezwungen, die Daten in unabhängige Tranchen zu zerlegen und in der vorgegebenen Systemausfallzeit zu migrieren. Die Kombination aus dieser erforderlichen Datenzerlegung und komplexen Abhängigkeiten innerhalb der Datenstruktur stellt eine zentrale Herausforderung dar.

In diesem Artikel wird ein neuer Datendekompositionsansatz vorgestellt, der sich diesen Herausforderungen stellt. Dieser Ansatz ermöglicht es, in einem inkrementellen Datenmigrationsprojekt das gesamte Datenvolumen flexibel in unabhängige Datenmigrationstranchen aufzuteilen und die Tranchenvolumina Datenvolumen an die verfügbaren Ausfallzeiten des Systems anzupassen. Diese Datenmigrationstranchen können dann unabhängig voneinander in das Zielsystem migriert werden.

Man fängt mit dem Strukturieren der Daten an

In größeren Datenmigrationsprojekten müssen die IT- und Fachbereichs-Experten Tausende beziehungsweise Millionen von Datensätzen aus dem Altsystem in das Zielsystem migrieren. Jeder Datensatz besteht aus mehreren Feldern mit Daten in unterschiedlichen Formaten. Die Beziehungen zwischen den Datensätzen sind oft sehr komplex und nicht sofort ersichtlich.

Aus diesem Grund ist eine einfache Aufteilung der Daten auf Tabellenebene oder Datensätze nicht optimal. Stattdessen sollten die Daten entlang von Geschäftsobjekten und weiterhin entlang von Geschäftsobjekt-Netzwerken aufgeteilt werden.

Eine Geschäftsklasse (GK) ist eine abstrakte Vorlage für identische Geschäftsobjekte (GO). Diese Vorlage beschreibt die Struktur und die Attribute, die in einer Geschäftsdomäne von Bedeutung und mit der Geschäftslogik verknüpft sind. Beispiele für Geschäftsklassen sind „Kunde", „Bestellung" und „Produkt". Diesen Geschäftsklassen wiederum würden Geschäftsobjekte wie „Max Smith", „Bestellung Nr. 45721" und „Zahnbehandlungen" entsprechen.

Für die Zwecke des Ansatzes wird eine Gruppe von fachlich zusammenhängenden Geschäftsobjekten als Geschäftsobjekt-Netzwerke bezeichnen, wenn sie der folgenden Definition entspricht: „Ein Geschäftsobjekt-Netzwerk ist eine Gruppe von verbundenen Geschäftsobjekten, die sich auf genau ein gemeinsames Schlüssel-Geschäftsobjekt (SGO) beziehen, das ebenfalls zur Gruppe gehört.“ (siehe Abbildung 1: Sie zeigt ein GON um das Schlüssel-Geschäftsobjekt Kunde „k1“.

Ein SGO ist eine Instanz der Schlüssel-Geschäftsklasse (SGK), die einmalig für die gesamte Unternehmensanwendung definiert wurde. Aus geschäftlicher Sicht sollte die SGK für das Unternehmen hoch priorisierte und voneinander unabhängige GO wie zum Beispiel „Kunde" darstellen.

Diese Objekte kommen typischerweise in einer hohen Anzahl vor und haben in der Regel umfangreiche Geschäftsobjekt-Netzwerke. Diese Eigenschaften ergeben Vorteile: Das Risiko, bei der Migration einige wichtige Objekte zu vergessen, ist sehr gering, da wir die SGO und alle davon abhängigen Objekte migrieren. Die Unabhängigkeit der SGO führt zu unabhängigen GONs, die unabhängig voneinander migriert werden können.

Der Aufbau unabhängiger Geschäftsobjekt-Netzwerke bedeutet, dass jedes GON seine eigenen klaren Grenzen haben muss und von dem restlichen Datenbestand abgekoppelt werden kann. Deshalb werden in diesem Ansatz die Grenzen eines GON wie folgt definiert: „Das GON des SGO X enthält alle GO der Anwendung, die direkt oder indirekt ausschließlich mit diesem SGO X verbunden sind.“ (siehe: Andreas Martens, Matthias Book, and Volker Gruhn. 2018. A data decomposition method for stepwise migration of complex legacy data. In Proceedings of the 40th In-ternational Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP '18). ACM, New York, NY, USA, 33-42)

Das bedeutet, dass alle GO, die direkt oder indirekt mit mehreren SGO verbunden sein können, zum Beispiel GO p1 in Abbildung 2, nicht als Teil eines GON betrachtet werden sollten.

Die auf diese Art gebildeten GON werden als Primärdaten, alle anderen Geschäftsobjekte außerhalb der GON als Sekundärdaten bezeichnet. Sekundärdaten sind in der Regel weit verbreitete Geschäftsdaten, wie zum Beispiel Konfigurationsdaten, die nicht GON-spezifisch sind.

Primär- und Sekundärdaten dienen in einer Anwendung unterschiedlichen Zwecken und werden daher während der Migration deutlich anders behandelt. Primärdaten stellen den größten Teil der in einem Datenmigrationsprojekt migrierten Daten dar. Primärdaten haben auch hohe Anforderungen an die Datenqualität. Das Unternehmen sollte die Kritikalität jedes Fehlers analysieren, der bei Testmigrationen auftritt. Unerwartete und kritische Fehler, die während der realen Migration auftreten, können dazu führen, dass die Migration des gesamten betroffenen GON zurückgerollt wird.

Einen Gegensatz dazu bilden relativ statische Sekundärdaten, die normalerweise für die Verarbeitung von Primärdaten in bestimmten Geschäftsprozessen unterstützend benötigt werden. Die falsche Migration von Sekundärdaten ist für das Projekt weniger kritisch. Ein Teil dieser Daten stammt aus externen Quellen, so dass sie im Fehlerfall viel einfacher rekonstruiert werden können und mit vergleichsweise geringem Auf-wand über definierte Schnittstellen in das neue System importiert werden können. Auch eine manuelle Korrektur von Daten im Fehlerfall kann eine akzeptable Lösung sein.

Die entsprechend dieses Vorgehens aufgebauten GON können unterschiedliche Strukturen aufweisen: Während einige SGO nicht mit anderen GO verbunden sind, wie Kunden, für die nur Kerndaten verfügbar sind, kann das GON eines anderen SGO hunderte von GO enthalten, die Instanzen verschiedener GK sind. Dies bedeutet, dass sich die GON in ihrer Heterogenität unterscheiden.

Die Definition dieser Eigenschaft dient vor allem dazu, Unternehmen in die Lage zu versetzen, zwischen „einfachen" und „komplexen" GON zu unterscheiden. Einfache GON sollten zuerst migriert werden, gefolgt von komplexen – möglicherweise in verschiedenen Datenmigrationstranchen.

Inkrementelle Migration der Daten

Die im vorherigen Abschnitt beschriebenen GON können bereits unabhängig voneinander in das Zielsystem migriert werden. Aufgrund des hohen Organisationsauf-wands, der durch den Migrationsprozess entsteht, ist es jedoch sinnvoll, mehrere GON zu größeren Datenmigrationstranchen (DMT) zu bündeln.

Datenmigrationstranchen sind Gruppen von kompletten GON, das heißt, sie bestehen ausschließlich aus Primärdaten. Obwohl die Anzahl der GON in einer DMT beliebig gewählt werden kann, hängt das anzustrebende DMT-Volumen von den Bedingungen des Datenmigrationsprojekts und den Bedingungen des zugehörigen Datenmigrations-schrittes ab. DMT sollten weder zu groß, noch zu klein geschnitten werden. Der Vorteil dieses Ansatzes besteht darin, dass das Volumen jeder Tranche an die geplanten Aus-fallzeiten der Anwendung angepasst werden kann.

Eine Best Practice beim Bündeln von GON in DMT ist, dass alle identifizierten Ge-schäftsobjekt-Netzwerke zuerst nach ihrer Heterogenität in aufsteigender Reihenfolge sortiert werden. Nach dieser Sortierung betrachtet man zunächst die einfacheren GON und anschließend die immer komplexere GON mit größerer Heterogenität. Diese Reihenfolge bietet eine gute Grundlage für Aufbau unabhängiger Datentranchen.

Ohne die beschriebene Sortierung wären die Analysten gezwungen, alle für die Migration erforderlichen ETL-Programme vollständig zu konzipieren, zu entwickeln und zu testen, bevor der erste Migrationsschritt angestoßen werden kann. Dies bedeutet, dass ein Großteil der Artefakte des Projektes noch vor Beginn des ersten Migrationsschritts erstellt werden müssten.

Lediglich die Datenmigration selbst wäre iterativ durchführbar. Die Aufteilung von GON in DMT mit wachsender Komplexität ermöglicht es hingegen, den Fokus der ETL-Entwicklung an die erwartete Komplexität anzupassen und so Aufwand und Risiko der Migrationsschritte besser zu steuern.

Jedes Geschäftsobjekt eines ins Zielsystem migrierten GON muss nach der Migration für jegliche Manipulation im Altsystem gesperrt werden. Alternativ können diese auch in ein externes Data Warehouse verschoben werden. Ab der Migration eines GON ist nur noch das Zielsystem für die Verarbeitung der migrierten Daten verantwortlich. Das bedeutet auch, dass alle ausgehenden Nachrichten für die migrierten GO im Zielsystem generiert werden und alle eingehenden Nachrichten, die sich auf die migrierten GO beziehen, an das Zielsystem weitergeleitet werden müssen.

Bisher wurden nur die Primärdaten betrachtet. Diese Primärdaten sind allerdings von dem gesamten Datenbestand nicht isoliert. Sie enthalten Referenzen zu Sekundärdaten. Alle Referenzen zwischen Primär- und Sekundärdaten müssen, um einzelne GON aus dem Datenbestand herauszulösen, im Projektverlauf temporär geschnitten werden.

Während der Migration werden die Geschäftsobjekt-Netzwerke in die Zielanwendung kopiert und mit den jeweiligen bereits im Zielsystem vorhandenen Sekundärdaten wieder verbunden. Um dies zu ermöglichen, müssen alle erforderlichen Sekundärdaten noch vor Beginn der Migration der Primärdaten in das neue System migriert werden.

Inkrementelle Datenmigration ist nicht zu unterschätzen

Eine Datenmigration wird manchmal stiefmütterlich behandelt und wird sehr oft unterschätzt. Besonders herausfordernd sind große Datenmigrationsprojekte, in denen der gesamte Datenbestand in Tranchen aufgeteilt und inkrementell in das Zielsystem migriert werden soll.

Dies war auch in einem der größten Migrationsprojekte im europäischen Gesundheitswesen mit über 5.000 DB2-Datenbanktabellen und Millionen von Kunden der Fall. Mit Hilfe des hier beschriebenen Datendekompositionsansatzes waren wir allerdings in der Lage, im Projekt die Risiken zu minimieren und die Aufwände für die Integration der Systeme auf einem sehr geringen Niveau zu halten. Die Komplexität blieb beherrschbar, die Flexibilität hoch. Am Ende konnte das Projekt in drei Migrationsstufen erfolgreich durchgeführt werden.

* Dr. Andreas Martens ist Teamleiter für Requirements & Software Engineering, LoB Health bei der Adesso AG, Hamburg, Professor Dr. Matthias Book lehrt an der University of Iceland in Reykjavík und Professor Dr. Volker Gruhn ist Mitgründer und Aufsichtsratsvorsitzender der Adesso AG.

(ID:46052390)