Erblast oder Teil der Zukunft Was genau ist Legacy Software?

Monolithische Softwaresysteme sind unflexibel und sicherheitsmäßig bedenklich, andererseits enthalten sie oft immer noch zentrale geschäftliche Assets. Insofern ist die Migration von so genannter Legacy in Service-orientierte Architekturen ein Spiel mit vielen Puzzle-Stücken.

Anbieter zum Thema

VMware Global Inc Zweigndl. Deutschland

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

Legate, also Vermächtnisse, sind für die damit Bedachten nicht immer eine Freude, sondern oft eine kostspielige, erdrückende Last; man denke nur an alte, zugige Schlösser mit 100 Zimmern, ohne Heizung und Wärmedämmung. Mit Legacy Software ist es nicht viel anders, und oft werden entsprechende Softwarevermächtnisse in den Unternehmen auch mit dem Wort „Altlast“ ins Deutsche übersetzt. Die alte Architektur ist oftmals starr, schwach strukturiert, mangelhaft gesichert und programmtechnisch schwer durchdringbar.

Die damaligen Programmierer:innen sind längst in Rente, die verfügbare Dokumentation ist lückenhaft und, wie es der Teufel will, ist der Teil, der besser dokumentiert ist, womöglich längst geändert oder ganz entfernt. Auch Testszenarien sind eher schwierig zu entwickeln. Da wird dann die kernige Aussage „Das haben wir immer schon so gemacht“ schnell zur verzweifelten Frage „Wie haben wir es eigentlich damals gemacht?“

Monolithen in der Welt der Plattform-Ökonomie

Es ist schwer vorstellbar, wie man mit einer solchen Software-Architektur die neuen, flexibel und schnell änderbaren Geschäftsmodelle der Plattform-Ökonomie abbilden will. Traditionelle Banken beispielsweise spüren dies schon seit Jahren und lavieren zwischen (partiellem) Migrieren ihrer Anwendungen und Daten, dem Parallelbetrieb von alten und neuen Systemen, sowie steigender Ratlosigkeit hin und her.

Sollte man nicht doch gleich ein Fintech kaufen (sofern man es sich finanziell noch leisten kann), dessen „Plattform-Bank“ nicht aus teuren Gebäuden, einer kostspieligen Geldautomaten-Struktur und vielen altgedienten Mitarbeiter:innen besteht? Selbst wenn ein solcher Zukauf eine Option wäre – was er aus unterschiedlichen Gründen meist nicht ist – wird man nicht umhin können, Daten und Anwendungen aus der alten monolithischen Architektur in moderne Service-orientierte Architekturen und Richtung Cloud zu überführen.

eBook: Legacy-Modernisierung

Kein Grund zur Langeweile oder zum Verzweifeln

Auch in der Unternehmens-IT ist es an der Zeit, alte Zöpfe abzuschneiden und #neustartklar zu wagen. - Die Pandemie hat die Dringlichkeitsstufe von IT/OT-Modernisierungsprojekten der digitalen Transformation plötzlich angehoben. In dem neuen wirtschaftlichen Umfeld sind selbst jene Legacy-Anwendungen mit unternehmenskritischer Geschäftslogik zum teuren Bremsklotz geworden; der Mehrwert der Bestandsdaten, die in diesen Arbeitslasten eingefangen wurde, will entdeckt werden.

So beschreibt das eBook:

Beständig statt rückständig - Einleitung

Mainframes - "tiefer legen"

Intelligente Ressourcenzuteilung

Tools, Frameworks und das Know-how der Spezialisten

>>> eBook „Legacy-Modernisierung“ zum Download

Und eine solche Transformation ist kompliziert und kann ein Unternehmen an den Rand des Ruins bringen, zumindest wenn man es vorzugsweise technizistisch angeht, sich zu sehr auf äußere Berater verlässt und die innerbetriebliche Sprengkraft einer solchen Transformation unterschätzt.

Viele Fallstricke

Generelle Kommunikationsprobleme und mangelnde Koordination zwischen IT- und Fachabteilungen oder auch offene oder versteckte Opposition einiger Akteure sind freilich nur die eine Seite der Gründe, warum eine entsprechende Transformation schiefgehen kann; nicht zu unterschätzen sind nämlich auch die vielen Detailprobleme, die eine Umstellung anspruchsvoll machen.

Nehmen wir noch einmal den Bankenbereich als Beispiel: Da kann es leicht passieren, dass man die Anbindung der Poststraße vergisst oder dass auf einmal das Online-Banking der Kundinnen nicht mehr funktioniert oder dass – etwa bei einer Migration des Wertpapier-Handels – offene Transaktionen, zum Beispiel zeitlich weit auseinander liegende Kapitalmaßnahmen, außer Acht gelassen werden.

Noch fehleranfälliger wird es, wenn eine Migration auch noch durch ein (Teil-) Outsourcing begleitet wird, beispielsweise wenn beim Umstieg von Monolithen mit vielen selbstgestrickten Software-Elementen auf service-orientierte Software die Wertpapier-Handelsplattform durch ein Business-as-a Service-Modell abgelöst wird. Angesichts der unvermeidbaren Komplexität einer entsprechenden Migration passiert es leicht, dass Bestände nicht mitmigriert werden, Buchungen doppelt ausgeführt oder alte und neue Zeichensätze nicht übereinstimmen und intern und extern Chaos verursachen.

Die technische und die personelle Seite der Migration

Den Übergang von alten, vertrauten Systemen, oder ehrlicher gesprochen: von Systemen mit alten vertrauten Fehlern, auf systemisches Neuland, in der Regel vermutlich Cloud-Strukturen, ist immer ein Sprung ins kalte Wasser. Auch wenn man ordentlich getestet hat, ist Vorsicht geboten.

Man wird also tunlichst nicht an Tag X das neue System anschalten, zwei Wochenenden lang Daten und Anwendungen migrieren, dann das alte System abschalten und nach dem Prinzip Hoffnung mit dem neuen System sofort und ohne Auffangposition die Kundschaft kontaktieren. Andererseits scheint es auch abenteuerlich, altes und neues System monatelang nebeneinander zu betreiben. Und auch IT-mäßige Parallelwelten in Teilbereichen haben ihre Tücken. Wer soll das alles verwalten, wer blickt da letzten Endes noch durch?

Letztlich wird eine große Software-Umstellung, die nicht das ganze Unternehmen an den Rand des Ruins bringen soll, eine schnelle Umstellung erfordern, die aber technisch und vor allem auch personell akribisch vorbereitet wird. Die technische Seite ist dabei anspruchsvoll, aber dennoch letztlich die einfachere, weil man das entsprechende Konzept – dieses muss natürlich gut dokumentiert vorliegen – nur Punkt für Punkt durchführen muss. Der menschlich-kommunikative Faktor ist weit mehr havarie-gefährdet, weil hierbei nicht einfach algorithmisch vorgegangen werden kann.

Integrationskomponente erstellen

Auf der technischen Seite wird es in aller Regel darum gehen, die Systemteile, die in die neue Welt übernommen werden sollen, geeignet zu kapseln und mit entsprechenden Anwendungsprogrammier-Schnittstellen (APIs) oder Andock-Software (Konnektoren) an die modernen (Cloud-) Architekturen anzubinden. Eine gute Möglichkeit, alte Architekturteile in die Cloud zu migrieren, ist auch die Anbindung über einen Switch mithilfe eines der vom System unterstützten Host-to-Host-Protokolle (wie ISO8583 oder auch Protokolle auf Basis der ISO20022). Dabei muss sichergestellt werden, dass innerhalb der neuen Architektur die Last gleichmäßig auf die vorhandene Infrastruktur verteilt wird und dass die Transaktionen konsistent ablaufen, beispielsweise auch dann, wenn eine Transaktion storniert wird.

Vorteilhaft ist in der Migrationsphase, mit einer Integrationskomponente zu arbeiten, mit der Defizite in der Analyse bezüglich Kompatibilität zwischen Alt und Neu ausgebügelt werden können. Ein Beispiel für eine solche Ausgleichoperation wäre das Hinzufügen fehlender Datenfelder.

Ohne ein ständiges Augenmerk auf die personelle Seite vor, während und nach der Umstellung dürfte diese vermutlich auch dann schief gehen beziehungsweise erheblich „rumpeln“, wenn technisch alles richtig gemacht wird. Geduldige Antworten auf alle Fragen sind Pflicht und wo die „Chemie“ zwischen Personen und ganzen Abteilungen offensichtlich nicht stimmt, muss behutsam eingegriffen werden. Natürlich müssen die Leitungspersonen dafür erst einmal über die soziale Kompetenz verfügen, solche „Chemie-Probleme“ überhaupt zu erkennen. Nicht einfach!

Altanwendungen ein neues Leben einhauchen, nicht beerdigen

Unternehmen sollten Legacy eine zweite Chance geben

Wichtig zu erwähnen – gerade weil es banal erscheint – ist die Tatsache, dass alle Personen und Gruppen, die mit der Umstellung betraut sind, große informationstechnische Kompetenzen haben müssen, und zwar vor allem auch, was die neuen Zielsysteme betrifft. Das ist nicht trivial, denn man wird vermutlich zu dem betreffenden Zeitpunkt, ausreichend Spezialisten für die alten Systeme haben, aber eher knappe Ressourcen für die neuen Systeme. Fehleinschätzungen hinsichtlich der jeweiligen Kompetenzen können hier besonders teuer werden.

Neue Single-Point-of Failure vermeiden

Die Umstellung eines großen monolithischen Software-Systems auf moderne service-orientierte Strukturen ist wie eine Großbaustelle im Verkehrsbereich, bei der bei laufendem Verkehr beziehungsweise Betrieb neue Adern geschaffen und alte stillgelegt werden: immer im Blick darauf, dass das neue System flexibler und sicherer ist und kein neuer Single-Point-of-Failure entsteht.

(ID:48107833)