Leseproben
Matthias Möser KVB

Das konkrete Vorgehen ist von der Architektur der Legacy-Anwendung abhängig, die oft eine schlechte Struktur aufweist oder wie bei einem Kaufprodukt überhaupt nicht modifizierbar ist.

Historisch gewachsene IT-Landschaften mit ihrer Vielzahl an Systemen, Schnittstellen und Technologien finden sich in vielen Unternehmen. Dabei sind es oft Legacy-Anwendungen, die als mission critical gelten und daher hohe Verfügbarkeit und Stabilität gewährleisten müssen. Wer vor der Aufgabe steht, solch eine Software abzulösen, stellt sich natürlich die Frage, wie am besten vorzugehen ist.

Legacy-Anwendungen sind meist schon viele Jahre im produktiven Einsatz. Währenddessen gab es immer wieder neue Anforderungen an die Software, die implementiert wurden. Irgendwann ist jedoch der Punkt erreicht, an dem sich neue Features nur noch schwer bzw. mit sehr großem Aufwand umsetzen lassen. Die Architektur ist dann nicht mehr tragfähig. In einer solchen Situation können die Geschäftsprozesse nicht mehr optimal bedient werden und es entsteht ein Wettbewerbsnachteil für das Unternehmen. Außerdem bindet die Erhaltung eines solchen Legacy-Systems viele Entwickler.

Als Lösung für dieses Problem bleibt oft nur noch die Migration, also die Ablösung durch eine neu entwickelte Anwendung. Häufig sprechen noch weitere Gründe für eine Migration, beispielsweise das Fehlen von Schnittstellen, die zur Automatisierung von Geschäftsprozessen benötigt werden. Oder der Technologie-Stack ist insgesamt veraltet und es finden sich nur noch schwer Mitarbeiter mit entsprechendem Know-how. Mangelnde Qualität ist keine Motivation für eine Migration, da sie am bestehenden System durch entsprechende Maßnahmen verbessert werden kann. Bei Kaufprodukten kann ein weiterer Treiber für eine Ablösung die nicht mehr vorhandene Liefer- und Leistungsfähigkeit des Herstellers sein. Doch wie kann eine Migration erfolgreich gelingen, ohne geschäftskritische Downtime und ohne Qualitätsprobleme? Und wie lassen sich die Anforderungen festlegen, wenn es nur schlechte oder gar keine Dokumentation für das Legacy-System gibt und Wissensträger nicht oder nur bedingt zur Verfügung stehen?

Ein altes Ding

Abb. 1: Beispiel einer Legacy-Anwendung

Abb. 1: Beispiel einer Legacy-Anwendung

Die konkrete Strategie zur Migration ist abhängig von der Architektur der Legacy-Anwendung und ihrer Integration in die IT-Landschaft. Wir wollen uns die grundlegenden Konzepte und ihre mögliche Verwendung anhand eines Beispiels anschauen. Dazu nehmen wir uns eine Legacy-Anwendung (Abb. 1) mit einem Delphi Fat Client und einer Oracle-Datenbank vor. Die Fachlogik ist beliebig auf beide Schichten verteilt. Bemerkenswert ist im konkreten Fall das generische und schwer verständliche Design der DB-Tabellen. Für die lesenden Clients der IT-Landschaft wird daher jede Nacht ein eigenes DB-Schema mit einer einfacheren Struktur aufbereitet. Schreibender Zugriff ist aufgrund fehlender technischer Schnittstellen ausschließlich durch die Anwender des Fat Clients möglich. Außerdem handelt es sich um ein Kaufprodukt, sodass eine Modifikation des Codes ausgeschlossen ist.

Der triviale Ansatz

Die vermeintlich einfachste Möglichkeit besteht darin, losgelöst vom Legacy-System eine komplett neue Anwendung zu entwickeln, die Daten am Ende zu migrieren und letztlich auf die neue Software umzuschalten. Das entspricht dem klassischen Big-Bang-Release mit all seinen bekannten Risiken, z. B. in Hinblick auf funktionale Vollständigkeit, Verfügbarkeit und Datenqualität. Besser ist es, ein inkrementelles Vorgehen im agilen Sinne mit regelmäßigen, überschaubaren Produktiv-Deployments zu wählen und frühes Feedback von Anwendern einzuholen, gepaart mit der Möglichkeit, gegebenenfalls auf die vorherige Version zurückrollen zu können.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 3.18 - "20 Jahre Java Magazin"

Alle Infos zum Heft
579827743Legacy-Systeme agil ersetzen
X
- Gib Deinen Standort ein -
- or -