Legacy-IT bei einem Merger

Legacy-Systeme sind und bleiben eine der größten Herausforderungen der digitalen Transformation deutscher Unternehmen. In der Post-Merger-Integration werden sie meist zum größten Erfolgshindernis. Einerseits bringen in der Regel beide Unternehmen Legacy-Systeme ein, was die Zahl der Altlasten quasi verdoppelt.

Andererseits erfordert der Business Case eines Mergers Kostenreduktionen und meist auch Umsatzsteigerung in einem ambitionierten Zeitraum. Damit ist Ablösung der gemeinsamen Legacy-System in der Regel die Voraussetzung für IT-Kostenreduktionen und die Umsetzung neuer Features, die vom Vertrieb dringend zur Umsatzsteigerung benötigt werden.

Alles auf einmal oder Stück für Stück

Während Legacy-Ablösungen gewöhnlich mehrere Jahre in Anspruch nehmen, ist die Erwartung nach Mergern nicht selten, dies in Monaten zu erreichen. Um diese Mammutaufgabe umzusetzen existieren verschiedliche Ansätze.

Der Greenfield-Ansatz, ein vollständiger Neubau der abzulösenden Applikationen mit modernen Mitteln, erfordert aufwändiges Design und eine meist langwierige Umsetzung.

Der Zielsystem-Ansatz erfordert die Optimierung der besten verfügbaren Anwendungen durch Abbildung hier fehlender und neuer Funktionalitäten. Da dieses System in der Regel Altlasten beinhaltet, ist auch hier mit einer langen Umsetzungsdauer zu rechnen.

Der Refactoring-Ansatz, erfreut sich in letzter Zeit zunehmender Beliebtheit. Er setzt auf eine semi-automatisierte Übersetzung des Quellcodes der Legacysysteme in moderne Programmiersprachen. Die Übersetzung selbst geht sehr schnell. Da aber dabei gewachsene Ineffizienzen in Code and Datenbankzugriffen übernommen werden, folgt meist aufwändige Problemanalyse und Optimierung. Somit dauert auch dieser Ansatz bis zur vollen Einsatzfähigkeit für Merger-Roadmaps meist zu lange.

Lesetipp: IT-Modernisierung - Legacy Apps fit für Cloud Computing machen

Legacy-Erneuerung mit Composable Apps

Eine vierte Option, mit Legacy-Systemen umzugehen, ist die sukzessive Erneuerung statt der zügigen Ablösung. Man kann dieses Vorgehen als agile Form der Legacy-Ablösung verstehen.
Ein Erneuern über einen längeren Zeitraum bedeutet zwar andauernde Legacy-Betriebskosten, überkompensiert den jährlichen Effekt jedoch deutlich, indem die Projektkosten einer Ablösung gestreckt werden. Dafür verfügt der Vertrieb - viel früher als in den drei oben genannten Ansätzen - über neue Features, um Umsatzsteigerung und Differenzierung voran zu bringen.

In diesem Ansatz werden neue Funktionalitäten mit modernen Technologie-Stacks umgesetzt, die mit den Legacy-Systemen koexistieren können. Alternativ finden auch Standardkomponenten ihre Verwendung. Der Architekturaufbau entlang dieser Logik entspricht dem aktuellen Trend einer "Composable Architecture". Statt Erweiterungen und komplexe Wartungen an den Legacy-Systemen durchzuführen, die dann weiter "altern", werden entsprechende Komponenten in der neuen Welt integriert und sukzessive in den Legacy-Systemen "verödet".

Während zu Beginn das gesamte Geschäft weiter über die Legacy-Systeme abgewickelt wird und die neuen Applikationen punktuell unterstützen, verschiebt sich dies in immer größer werdenden Schritten. Am Ende haben die Legacy-Systeme nur noch Archivfunktion und können schließlich ganz außer Betrieb genommen werden.

Ausgereifte Technologien sichern die Wirtschaftlichkeit

Die erforderliche Koexistenz von alten und neuen Systemen wird durch die inzwischen ausgereiften Service-orientierten Architekturen erst wirtschaftlich realisierbar. Während traditionelle Schnittstellen zu Legacy-Systemen gewöhnlich Millionen kosteten, erlauben sukzessive wachsende APIs den Zugang zu den Legacy-Systemen zu einem Bruchteil der Kosten.

So können über spezialisierte API-Gateways selbst Mainframe-Anwendungen genauso wie Standard-Software von modernen Microservices genutzt werden. Im Frontend merkt der Nutzer meist nicht, welche Funktionen und Daten aus modernen Microservices und welche aus den Legacy-Systemen kommen.

Neue Funktionalitäten lassen sich als moderne Microservices mit eigener Benutzeroberfläche, als "Composable Apps", schnell und günstig umsetzen. Diese werden entweder direkt vom User aufgerufen oder es erfolgt ein Absprung aus den Legacy Systemen.

Lesetipp: Was Sie über Microservices wissen müssen

Entgegen des Paradigmas, dass moderne Services keine eigene Datenhaltung haben sollten, werden neue Datenobjekte nur in der modernen Architektur abgebildet. Alte Datenobjekte werden über ein API-Gateway, zum Beispiel einen Servicebus, mit den Legacy-Systemen ausgetauscht. Falls aus Performance- oder Security-Gründen nötig, können solche Altdaten auch in der neuen Architektur gespiegelt werden.

So koexistieren neue und alte Welt so lange, bis alte Funktionen und Datenbasen vollständig durch neue ersetzt sind. Dieser Prozess dauert länger bis zur vollständigen Ablösung. Er ermöglicht es aber, sukzessive Kompetenz aufzubauen und die Risiken eines komplexen Modernisierungsprojekts zu beherrschen. Dringliche Architekturanforderungen, zum Beispiel die IT-Security, können natürlich frühzeitig umgesetzt werden.

Auswirkungen auf Vertrieb und Finanzen

Statt neue Produkte und Services vollständig umzusetzen, bevor der Kunde sie das erste Mal sieht, lassen sich mit Composable Apps auch leicht und schnell Minimal Viable Products (MVP) implementieren. Dieses Vorgehen ermöglicht reales Kunden-Feedback, mit dem sich sowohl das Marktpotenzial als auch die nötige Feature Pipeline besser bestimmen lassen.

Eine extrem langgezogene Legacy-Ablösung ist normalerweise mit hohen Kosten verbunden. Mit Composable Apps wird auch dieses Paradigma gebrochen. Die Umsetzung neuer Funktionen löst alte Funktionen sukzessive ab - mit geringfügigem Mehraufwand für das geordnete "veröden" von Applikationsteilen und Tabellen der Legacy-Welt.

Der Aufwand für Design und Testing verteilt sich auf Neuentwicklung und Migration. Somit sind die Migrationskosten in Summe in der Regel sogar geringer als bei einem Greenfield-Ansatz. Stellt der CIO mittels Domain-driven Design zusätzlich noch sicher, dass pro Release nicht mehr Altfunktionalität als nötig erneuert wird, belasten die jährlichen Kosten auch den Cash Flow weniger als bei anderen Ansätzen.

Lesetipp: IT-Modernisierung - Universitätsmedizin Mainz migriert 570 IT-Systeme

Praxisbeispiel für Composable App Architecture

Ein Anbieter von Apothekensoftware gehört zu den erfolgreichen Anwendern einer Composable-App-Architektur. Nach drei Mergern begann das Unternehmen einen Greenfield-Ansatz, der vierte Merger brauchte ein vermeidlich modernes Zielsystem mit sich.

Somit gab es fünf nahezu redundante Systeme mit jeweils einem beträchtlichen Kundenstamm. Nahezu keines der beteiligten Unternehmen war bereit, signifikante Migrationsaufwände auf sich zu nehmen und gleichzeitig gab es hohen Veränderungsdruck durch eine stetig fortschreitende Regulierung und Digitalisierung im Gesundheitsmarkt. Dadurch waren die Software-Entwicklungskapazitäten durch die dringende Notwendigkeit, neue Funktionalitäten und Preismodelle abzubilden, voll ausgelastet.

Über die nächsten Jahre wurden dann Composable Apps, speziell für Domänen mit besonders deutlichem Veränderungsbedarf, entwickelt. Ein Beispiel dafür ist die Kommunikation im Medizinwesen (KIM). Dank der modularen Bauweise konnten gesetzlich notwendige Module zur Ergänzung der Legacy-Systeme auch leicht von Komfort-Modulen separiert werden, die zusätzlich vergütet werden. Nach Abschluss der Architekturphase mit MVP werden für Wartung und Weiterentwicklung der Systemlandschaft bereits geringere Kosten erwartet, als ohne die Composable-App-Architektur.

Egal ob im Rahmen einer Post-Merger-Integration oder im Zuge der regulären Legacy-Modernisierung - Deutsche Unternehmen sollten die Chancen moderner Architekturoptionen, wie den Composable Apps, zumindest eingehend prüfen, bevor sie weiter mit klassischen Methoden mit hohem Zeit- und Investitionsbedarf die eigene IT-Architektur modernisieren.