Testgetriebene Datenmigration

Agile Ansätze für komplexe Migrationsszenarien

Martin Wagner und Thomas Scherm

Im Zuge mehrerer Fusionen hatte die M-net Telekommunikations GmbH eine heterogene IT-Infrastruktur zu integrieren. Das wurde in den letzten Jahren eher halbherzig versucht, da die Anforderungen aus der aktuellen Produktentwicklung dominierten. So betrieb M-net mehrere System-Stacks parallel und litt zunehmend an sich verstetigenden „Interimsschnittstellen“. Als neuer IT-Leiter war einer der Autoren dieses Artikels, Thomas Scherm, nun damit konfrontiert, eine sinnvolle – und vor allem erfolgreiche – Konsolidierungsstrategie zu finden. Die Erfahrungen sind Thema dieses Artikels.

Ausgangspunkt für die heterogene IT-Infrastruktur war ein Zusammenschluss von City Carriern in München, Augsburg und Nürnberg. Die schon früher definierte Zielsystemlandschaft konnten wir schnell als die am erfolgversprechendste bestätigen, auch da es sich hierbei recht homogen um Java-basierende Systeme handelt und damit die Vielzahl der Technologien aus der Java-Community wirtschaftlich in Reichweite waren.

Der Nürnberger Stack basiert auf einem mittelständischen ERP-Produkt, war jedoch nicht ausreichend skalierbar und wir erkannten, dass eine Big-Bang-Migration notwendig war. Diese setze allerdings eine annähernd vollständige Funktionsabdeckung der Ziellandschaft voraus, die nicht gegeben war. So konnten wir hier nicht ansetzen.

In München war ein Teil der Arbeit schon geleistet, jedoch blieb ein zentrales System zu migrieren: die „Kunden und Ports“ (KuP). Das System KuP wurde eingesetzt, um die technische Auftragsabwicklung durchzuführen, d. h. Kundenverträge auf ein Netz abzubilden, von der Rufnummernkonfiguration über die Beauftragung von Servicetechnikern bis hin zur Provisionierung verschiedenster Netzelemente. Technisch handelte es sich dabei um ein gewachsenes, kaum dokumentiertes System, das mit einem Microsoft Access Frontend direkt auf eine Oracle-Datenbank aufsetzte. Die Implementierung der Businesslogik in einer großen Zahl von Views und PL/SQL-Skripten prägte das System. Dazu kam eine kaum übersehbare Anzahl an teils unbekannten Schnittstellen in verschiedenste Unternehmensteile, die durch direktes Ansprechen beliebiger Datenbankobjekte realisiert wurden. Das System war jedoch funktional weit entwickelt und konnte weitgehend auf das designierte Zielsystem „Hurrican“ abgebildet werden. Ein wesentliches Problem stellten zahlreiche Sonderfälle dar, die im Lauf der Jahre explizit in der Anwendungslogik oder implizit durch Wissen der Sachbearbeiter über kontextspezifische Semantiken von Datenfeldern realisiert wurden. Die Ablösung der KuP wurde schon jahrelang immer wieder in Betracht gezogen, jedoch immer wieder als nicht durchführbar bezeichnet und gestoppt. Im Unternehmen waren große Ängste damit verbunden.

M-net fertigte zunächst intern eine Vorstudie an, bei der mit radikalen Annahmen, zunächst ohne Berücksichtigung der Bedürfnisse der Fachbereiche, untersucht wurde, wie eine Migration prinzipiell durchgeführt werden könnte. Auf der Basis dieser Liste von „Zumutungen“ baten wir die betroffenen Fachbereiche, ihre speziellen Anforderungen zu definieren.

Aufgrund der hochgradig unklaren Anforderungsdefinition und der im Projektverlauf absehbaren kontinuierlichen Änderungen sowohl am Quellsystem KuP als auch am Zielsystem Hurrican war schnell klar, dass das Projekt nur mit agilen Entwicklungsansätzen und einer stark automatisierten Testumgebung erfolgreich sein konnte. Allerdings waren im Haus weder Erfahrungen mit agilen Vorgehensweisen noch mit automatisierten Testumgebungen vorhanden. Zudem war es für die Fachbereiche ungewohnt, intensiv in IT-Projekte eingebunden zu sein. Deshalb beauftragte man einen auf Scrum und testautomatisierte Java-Entwicklung spezialisierten Dienstleister.

In einem Vorprojekt betrachteten wir zunächst vertieft Chancen und Risiken und definierten und bewerteten Rahmenbedingungen, Risikomanagement sowie Meilensteine für eine Migration. Parallel zum Vorprojekt bereiteten wir den Start des eigentlichen Projekts vor, bei dem ein gemischtes Team aus internen und externen Projektmitarbeitern dem externen Projektleiter unterstellt wurde.

Migrationsframework

Um die Gesamtmigration beherrschbar zu machen, teilten wir die Daten in zahlreiche Partitionen auf, die sich am Zielsystem orientierten. So wurden beispielsweise zunächst Stammdaten migriert, anschließend Basisdaten von Aufträgen und zuletzt Kontaktdaten von technischen Ansprechpartnern zu einem Auftrag. Technisch gesehen wurden somit zahlreiche Einzelmigrationen sequenziell ausgeführt, die in so genannten Suites logisch gruppiert wurden. Um einen hohen Grad an Wiederverwendung der technischen Details dieser Einzelmigrationen zu erzielen, entwickelten wir sukzessive ein hochspezialisiertes Migrationsframework, das prinzipiell nach dem ETL-Paradigma (Extract, Transform, Load [1]) arbeitet. Das grundlegende Vorgehen ist damit für jede Einzelmigration gleich und besteht aus folgenden Schritten (Abb. 1):

Abb. 1: Architektur unseres Migrationsframeworks. Abbildungen, die in SQL effizienter erledigt werden können, sind in speziellen Views gekapselt. Sonstige Migrationslogik steckt in den parallelen Migrationsprozessoren als Java-Code. Vor dem Schreiben in das Zielsystem erfolgt eine Validierung der Daten durch die vorhandene Applikationslogik
  • Eine spezielle View auf der Datenbank des Quellsystems bereitet die Daten derart auf, dass genau ein vollständiger Datensatz pro Zeile der View gezogen wird.
  • Die View wird, wenn möglich, parallelisiert in mehreren Blöcken eingelesen.
  • Für jeden Datensatz werden nötige Transformationen per Java-Code durchgeführt und dann per direktem Java-Aufruf der Servicelogik des Zielsystems geschrieben. Soweit möglich und sinnvoll, werden auch die Transformationen und das Schreiben ins Zielsystem parallel durch mehrere Threads erledigt.
Geschrieben von
Martin Wagner und Thomas Scherm
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.