Datenmigration: Zusammenhänge statt Tabellen – ETL vs. objektorientierter Ansatz

Herausnehmen, Umwandeln und Einfügen (ETL) – nach dieser Herangehensweise werden seit den 70er-Jahren Daten migriert, als Unternehmen grössere Datenbankstrukturen anlegten. Trotz technischem Fortschritt hat sich das Prinzip nicht wesentlich verändert, es bildet bis heute einen Pfeiler der digitalen Datenverarbeitung.

Bei ETL-Migrationen stehen die Datenstrukturen im Vordergrund: Spalte X in Tabelle A muss in die Spalte Y der Tabelle B. Dazwischen können die Inhalte dieser Spalte mit beliebig vielen Arbeitsschritten transformiert werden, aber das einzelne Datenfeld bleibt dabei die zentrale Einheit. Dafür muss nicht zwingend eine Software eingekauft werden, ETL-Migrationen lassen sich auch leicht selbst programmieren.

Es ist also, als ob wir beim Zügeln eines einzelnen Büroraums das Bücherregal in eine Kiste packen, dann alle Ordner in eine zweite, die Stifte in eine dritte und so weiter. Beim Einpacken werden die Bücher, Ordner und Stifte so sortiert, dass sie in die neuen Regale und Schubladen passen. Dementsprechend einfach ist das Auspacken.

Wo ETL an seine Grenzen stösst

Was aber, wenn nicht nur ein Büroraum, sondern ein Dutzend Büroräume umziehen? Eine gemeinsame Kiste für alle Ordner, eine zweite für alle Bücher und eine dritte für Stifte zu packen würde ein Chaos verursachen. Die Bücher, Ordner und Stifte sind aus ihrem Zusammenhang gerissen und lassen sich nur mit langen Dokumentationen wieder zuordnen.

Anstatt jede Kategorie einzeln zu verpacken, sollte jeder Büroraum seine eigenen Kisten bekommen. So bleiben Bezug und Zusammenhang aller Gegenstände bestehen und müssen nach dem Umzug nicht wiederhergestellt werden. Das ist das Prinzip des objektorientierten Ansatzes. Er verpackt und verschiebt jeden Büroraum – jedes Objekt – im Zusammenhang. Jeder Raum hält sich zwar an die gleichen grundlegenden Packregeln, aber in Büro 3 tauchen alte Hängeregister auf, für die es eine eigene Regel braucht.

Für grosse Mengen einfacher Datenstrukturen ist ETL – ob eingekauft oder selbstentwickelt – also absolut sinnvoll. Denn ein grosser Vorteil von ETL gegenüber der objektorientierten Migration liegt in der Performance. Fachliche Verbindungen zwischen Datensätzen herzustellen, kostet Rechenzeit. Liegen also beispielsweise Millionen bis Milliarden von mehr oder minder unabhängigen Transaktions- oder Sensordaten vor, spielt die Leistung eine grosse Rolle. Mit anderen Worten: Das Einzelbüro kann auch eine ganze Lagerhalle sein, solange der Inhalt einfach strukturiert ist. Hier objektorientiert zu arbeiten wäre ineffizient.

Sobald aber komplexe fachliche Zusammenhänge, gewachsene Altsysteme, regulatorische Anforderungen und mehrere Zielsysteme ins Spiel kommen, stossen ETL-Lösungen an ihre Grenzen und aus ein paar Zeilen selbst geschriebenen Codes wachsen unübersichtliche, schwer wartbare Bibliotheken. Auch der rein tabellenorientierte Blick reicht dann nicht mehr aus.

Ein typisches Beispiel sind gewachsene Datenmodelle mit wiederkehrenden oder durchnummerierten Attributen. In solchen Fällen ist es oft nicht ausreichend, einzelne Spalten isoliert zu transformieren. Vielmehr muss verstanden werden, und wie sie als Objekt im Zielsystem korrekt abgebildet werden. Im Bild des Umzugs würde dies beispielsweise bedeuten, zu verstehen, dass sich Ordner A auf Handregister 1, 2 und 3 im gleichen Büro bezieht. Bei einer Versicherung wäre das etwa ein Schadensfall, der Police A, B und C betrifft, denen die Zahlungsverbindung 1 angeheftet ist.

Einfach oder komplex? Warum die Datenlage oft unterschätzt wird

Das Problem ist allerdings häufig: Datenmigrationen werden unterschätzt. Auf den ersten Blick sieht die Datenstruktur gerne einfach aus. Historien, Sonderfälle, Umsysteme und Produktvarianten machen eine Migration aber schnell zur Herausforderung. Wenn sie gar erst im Verlaufe des Projekts auftauchen, bedroht dies den Erfolg einer Legacy-Ablösung.

Die Entscheidung, ob ETL oder objektorientiertes Vorgehen, ist keine technische Geschmacksfrage, sondern eine wichtige strategische Weichenstellung: Legen wir den Fokus auf Systeme und Tabellen oder auf Fachobjekte und Domänen? Folgt die Transformation einer Feldlogik oder einer Fachlogik? Planen wir von Tabelle zu Tabelle oder von Business-Funktion zu Business-Funktion?

Nicht die bevorzugte Software oder die Eigenentwicklung sollte das Migrationsprinzip vorgeben – sondern die Datenlage: «Sind die Daten einfach genug, sodass ETL genügt oder nicht?» Und: «Sind wir uns sicher, dass die Daten nicht doch komplexer sind?» In der Realität unserer Kunden, insbesondere im Finanz- und Versicherungsumfeld, sind die Datenbestände selten einfach.

Eine belastbare Einschätzung der Datenlage bedingt auch eine saubere Trennung von Analyse, fachlicher Regeldefinition und technischer Ausführung. Hier haben ETL-Lösungen unserer Erfahrung nach ihre Tücken. Besonders in selbst entwickelten ETL-Skriptlösungen vermischen sich diese Ebenen schnell und erschweren eine objektive Analyse. Mehr noch: Durch diese Vermischung werden Wertelisten und Sonderregeln verteilt gepflegt und fachliche Überprüfungen plötzlich zu Code Reviews. Es erschwert später die Zusammenarbeit zwischen Fachbereich, Migrationsteam und IT.

Warum wir auf den objektorientierten Ansatz setzen

Warum also setzen wir bei nag seit Jahrzehnten erfolgreich auf den objektorientierten Ansatz? Weil unsere Erfahrung zeigt, dass komplexe Migrationen nicht an der reinen Datenbewegung scheitern, sondern an fehlender Transparenz, unklaren Regeln, übersehenen Sonderfällen und mangelnder Nachvollziehbarkeit. Ein objektorientierter Ansatz zwingt dazu, fachliche Zusammenhänge früh sichtbar zu machen. Er unterstützt eine strukturierte Datenanalyse, erlaubt die Wiederverwendung von Regeln und Validierungen und schafft eine gemeinsame Arbeitsbasis für Fach und IT.

Auch beim Testing und bei der Qualitätssicherung bietet der objektorientierte Ansatz klare Vorteile. Wenn ganze Objekte migriert werden, lassen sich Testfälle, Coverage, Reconciliation und fachliche Prüfungen gezielter aufbauen. Es geht nicht nur darum, ob eine Anzahl Datensätze geladen wurde, sondern ob die migrierten Objekte im Zielsystem vollständig, konsistent und nutzbar sind. Genau diese Sicht ist für Geschäftsvorfalltests, Generalproben und die spätere Abnahme entscheidend.

Migrationstool für objektorientiertes Vorgehen

Für diese Vorgehensweise haben wir unser eigenes, jahrzehntelang weiterentwickeltes Migrationstool nag nxT optimiert. Es ermöglicht uns, Analyse, Regeldefinition und Ausführung sauber zu trennen, objektorientiert zu migrieren und nachvollziehbar vorzugehen. Letzteres deshalb, weil die Strukturen, Mappings, Transformationsregeln, Validierungen und Steuerungslogiken im zentralen Repository verwaltet werden. So bleibt – auch ohne den Code zu lesen – verständlich, welche Regel warum existiert, wer sie verändert hat und welche Version Grundlage eines bestimmten Migrationslaufs war.

Das ist besonders wichtig, weil Datenmigrationen oft einmalige, aber geschäftskritische Vorhaben sind. Man hat in der produktiven Migration nicht beliebig viele Versuche. Das Verfahren muss präzise, reproduzierbar und jederzeit überprüfbar sein.

Datenbestände mit wiederkehrenden oder durchnummerierten Attributen, zusammengehörenden Feldern und fachlichen Bedeutungen lassen sich mit nag nxT durch generierte Klassen, zentrale Regeln und projektspezifisch erweiterbare Logik sauber abgrenzen. Das reduziert die Gefahr, dass die Behandlung von Sonderfällen auf viele Stellen im Code verteilt wird und später schwer nachvollziehbare Seiteneffekte entstehen.

Nochmals in Kürze

Zusammenfassend lässt sich festhalten: ETL überträgt Daten streng tabellarisch zwischen zwei Datenbanken. Der objektorientierte Ansatz überführt fachliche Zusammenhänge, Inhalte und Bedeutungen von einem Kernsystem ins nächste. Genau dieser Unterschied ist entscheidend, wenn aus einem technischen Datenumzug eine erfolgreiche fachliche Transformation werden soll.

ETL ist nicht grundsätzlich falsch. Für klar abgegrenzte Datenmengen mit wenigen Abhängigkeiten, wenigen Sonderfällen und geringen Compliance-Anforderungen – also für ein kleines Einzelbüro – ist ein schlanker Skriptansatz durchaus sinnvoll. Ebenso, wenn riesige Mengen von Datensätzen mit wenigen Abhängigkeiten bewegt werden müssen. Sobald jedoch mehrere Büroräume ins Spiel kommen – das heisst fachliche Konsistenz, Nachvollziehbarkeit, Wiederverwendbarkeit und Revisionssicherheit – ist der objektorientierte Ansatz bedeutend sicherer.

Der alles entscheidende Arbeitsschritt ist die belastbare Einschätzung der Datenstruktur. Sonst muss sich nach dem Umzug jedes Büro seine Bücher, Ordner und Stifte mühsam aus Sammelkisten zusammensuchen.