Laut TwoBitHistory.org nutzen immer noch mehr als 95 Prozent der Fortune-1000-Unternehmen IMS, das alte, hierarchische DBMS von IBM. Interesse daran, in dieser Umgebung zu arbeiten, dürften circa null Prozent der fähigen IT-Entwickler haben. Dabei ist die Fähigkeit, Top-Fachkräfte zu gewinnen und zu binden einer der wichtigsten Gründe für CIOs, ihr Anwendungsportfolio zu modernisieren. Weitere Gründe sind etwa niedrigere Lizenz- und Supportgebühren sowie verbesserte Flexibilität und Anpassungsfähigkeit. Allerdings ist das mit der Legacy-App-Modernisierung nicht so einfach, wie es vielleicht scheint. Sie birgt dunkle Geheimnisse, die intelligente CIOs bei ihren Entscheidungen berücksichtigen sollten.

1. Komplexitätsvielfalt

Anwendungsmodernisierung umfasst eine Reihe sehr unterschiedlicher Lösungen für eine Reihe sehr unterschiedlicher Probleme. Je nach Anwendung und je nachdem, mit wem Sie sprechen, kann App Modernization wahlweise Versionsaktualisierung, Replatforming, Plattformersatz, Sprachmodernisierung, Refactoring oder COTS-Konvertierung bedeuten. Obwohl all diese Begriffe unter "Modernisierung" fallen, haben sie wenig bis gar nichts gemeinsam. Außer, dass sie erkennbare und versteckte Fallstricke beinhalten, die es zu beachten gilt. Bevor Sie eine bestimmte Applikation modernisieren können, müssen Sie auch entscheiden, welche Art der Modernisierung sie benötigt.

2. Versionsaktualisierung als Schuldenform

Einige IT-Führungsteams sind davon überzeugt, es wäre eine kluge Idee, "keine Technologie um der Technologie willen zu kaufen" und - um ein Klischee auf das andere zu setzen - bei der Verwaltung von Anwendungen und den Stacks, auf denen sie laufen, nach dem Motto "never change a running system" zu verfahren.

Diese Logik wird auf alle kommerziellen Anwendungen und auf jede Plattform angewandt - Server-Betriebssystem, DBMS, CMS, Entwicklungsumgebung, Desktop-Betriebssystem, Browser und so weiter. Aktualisiert wird nur, wenn neue Funktionen einen bestimmten ROI liefern.

Ein klassischer Fall von "Pay-it-Now" oder "Pay-it-Later". In diesem Fall ist "Pay-it-Later" aber wesentlich teurer und störender als alles auf dem aktuellen Stand zu halten.

3. Replatforming-Illusionen

Die Verlagerung von Legacy-Anwendungen in eine offene Umgebung mit entsprechenden Plattformen auf allen Ebenen des Stacks ist ein weiterer beliebter Modernisierungsansatz - mit einem nicht ganz so geheimen Haken. Replatforming bedeutet zum Beispiel die Migration von Mainframe-gehostetem z/OS + COBOL + CICS + DB2 zu x86-gehostetem Linux + COBOL + CICS + DB2. Bei Cloud-Migrationen wird diese Vorgehensweise als "Lift & Shift" bezeichnet.

Das Ergebnis sind geringere Lizenz- und Anbieter-Supportgebühren. Das dunkle Geheimnis: Das ist alles, was Sie bekommen.

4. Teure Plattformwechsel

Bei der Plattformersetzung handelt es sich um eine Modernisierungsmethode, bei der nur eine Plattform, auf der eine Anwendung läuft, ausgetauscht wird, weil sie veraltet ist oder an Marktanteil und/oder Aufmerksamkeit verliert. Sie könnten zum Beispiel das DBMS einer Anwendung von Sybase- auf SQL-Server umstellen. Das wird zwar manchmal auch als "Replatforming" bezeichnet, hat aber nichts mit dem oben beschriebenen, dritten Punkt gemein.

Was Sie davon haben: weniger Risiken und Schwachstellen, die sich aus der Verwendung von Legacy-Technologie ergeben. Außerdem haben Sie Zugang zu einem besseren Pool von Talenten. Was Sie nicht bekommen: Geringere Kosten oder verbesserte Features. Im Gegenteil: Die Kosten werden steigen, weil Sie die Ersatzplattform lizenzieren müssen.

5. Sprachmodernisierung als Fail

Es gibt zahlreiche verführerische Marketing-Botschaften, die versprechen, dass automatisierte Tools die Geschäftslogik aus Ihrem alten COBOL-Code extrahieren und in einer modernen Sprache neu schreiben. Das wird oft dadurch erreicht, dass beispielsweise eine COBOL-Anwendung mit 100.000 Zeilen durch eine Java-Anwendung mit 100.000 Zeilen ersetzt wird.

Das Problem dabei: Sprachen bestehen nicht nur aus Vokabular und Syntax - sie beinhalten auch Anwendungsdesign-Philosophien. Darüber hinaus bringen Programmiersprachen im Allgemeinen auch ganze Bibliotheken mit vorentwickelter Logik mit. Entwicklungsteams, die neue Anwendungen coden, machen sich diese Bibliotheken zunutze. Nur die wenigsten Code-Konverter bewältigen eine solche Übersetzungsaufgabe zufriedenstellend. Im Regelfall ist der konvertierte Code noch schwieriger zu pflegen.

6. Refactoring mit Tücken

Refactoring ist eine Modernisierungstechnik, bei der die Struktur einer veralteten Anwendung so umgewandelt wird, dass sie bewährten Praktiken entspricht. Beispiele wären etwa die Normalisierung von Daten oder die Umstrukturierung von monolithischem Code in eine Microservices-Architektur.

Auch hier gibt es zahlreiche Tools, die versprechen, einen Großteil dieser Umstrukturierung zu automatisieren. Das sollten Sie auf jeden Fall (auf Kosten des Anbieters) ausprobieren, bis ein Proof-of-Concept Sie davon überzeugt, dass die Tools wie angekündigt funktionieren.

Dabei sollten Sie Vorsicht walten lassen: Einige Versionen des automatisierten Refactoring behalten das Verhalten der Anwendung exakt bei. Dies minimiert zwar die Unterbrechung der Geschäftsabläufe, aber eine Anwendung kann so nicht in Echtzeit verarbeitet werden - die architektonische Änderung, die am ehesten zu einem Wettbewerbsvorteil führt.

Refactoring bietet einen erheblichen geschäftlichen Nutzen in Form von verbesserter Anpassungsfähigkeit und Flexibilität. Aber das kostet.

7. Die COTS-Alternative

Ein aktuelles Anwendungs-"Ökosystem" durch eine moderne Applikations-Suite zu ersetzen, die von jemand anderem geschrieben wurde, ist oft der beste Weg zu einem modernisierten Anwendungsportfolio.

Eine solche Umstellung ist bei jedoch wie so oft kein Allheilmittel - jeder, der schon einmal mit der Umstellung auf eine COTS/SaaS-Suite zu tun hatte, weiß, wie diffizil sich das gestalten kann. Trotzdem ist es in vielen Fällen der risikoärmste und sauberste Weg, eine Applikationssammlung, deren Plattformen und Architektur von gestern sind, durch etwas zu ersetzen, das Zukunft hat.

8. Vergessene Grundlagen

Nachdem wir nun die dunklen Geheimnisse der verschiedenen Modernisierungsmethoden gelüftet haben, gibt es noch etwas Grundlegendes zu beachten: Bevor Sie etwas modernisieren können, müssen Sie wissen, welche Anwendungen Sie haben und wie diese aufgebaut sind. Ansonsten können Sie nicht bestimmen, welche der soeben besprochenen Modernisierungsarten in Frage kommt.

Trotz der hochtrabenden Werbeversprechen, mit denen Tools zur automatischen Erkennung daherkommen: Im Regelfall erkennen diese zwar Server, aber nicht, welche Applikationen darauf laufen. Davon abgesehen: Wenn die Dokumentation Ihres Inventars so unvollständig ist, dass Sie ein Automatisierungs-Tool benötigen, dann ist es sehr wahrscheinlich, dass auch ihre Plattformen (Entwicklungsumgebung, Serverbetriebssystem, DBMS, CMS, etc.) nicht dokumentiert sind. Falls dem so ist, sollten Sie dringend Licht ins Dunkel bringen.

9. Software ist eine Meinung

Jede Geschäftsanwendung kodiert die Meinung eines Entwicklungsteams darüber, wie ein bestimmter Aspekt der Organisation ablaufen sollte. Die Syntax der Meinung ist im Code festgehalten. Ihr Vokabular ist in das Datendesign der Anwendung eingemeißelt.

Wenn sich der Anwendungsbereich von zwei oder mehr Anwendungen überschneidet, ist eine Automatisierung erforderlich, um die beiden Datensätze synchron zu halten. Zählt man diese Überschneidungen in einem Portfolio zusammen, können im Ergebnis Hunderte von benutzerdefinierten Punkt-zu-Punkt-Schnittstellenprogrammen zusammenkommen, die jedes Mal, wenn ein Entwicklungsteam eine Anwendung hinzufügt oder ändert, ebenfalls geändert und auf Regression getestet werden müssen.

Ein Enterprise Service Bus (ESB) oder eine ähnliche Technologie kann dazu beitragen, die schiere Anzahl der Schnittstellen zu reduzieren, indem ein einziges Interface für jede Anwendung definiert wird. Daneben gibt es aber auch das Problem der semantischen Fehlanpassungen - das heißt, die Kundendatenmodelle Ihrer Debitoren- und CRM-Systeme unterscheiden sich. Der Abgleich dieser unterschiedlichen Definitionen ein und derselben Entität macht die Integration anfangs schwierig und die Wartung zu einer dauerhaften Herausforderung. Ein ESB kann das Problem der unterschiedlichen Semantik nicht beheben, weil das Problem nicht in erster Linie technologischer Natur ist. Es geht darum, dass die Entwickler sich nicht einig sind.

10. Mitarbeitermodernisierung

Die Modernisierung der IT-Mitarbeiter ist oft schwieriger als die Modernisierung der von ihnen unterstützten Anwendungen. Vermutlich ist Ihr Team äußerst kompetent, wenn es um Wartung und Verbesserung von Applikationen und den zugrundeliegenden Plattformen geht. Sie verfügen auch über ein umfassendes Wissen darüber, wie ihre Anwendungen eingesetzt werden, damit das Unternehmen so läuft, wie es laufen soll.

Weniger kompetent dürften die Mitarbeiter in den Ersatzanwendungen und -plattformen sein, die Ihr Modernisierungsplan implementiert. Wenn dieser aufgehen soll, muss das Team sich mit den Ersatzanwendungen ebenso gut wie mit der aktuellen Applikationsarchitektur auskennen. Im Idealfall erkennen die Mitarbeiter so auch Chancen für geschäftliche Verbesserungen.

Das dunkle Geheimnis: Ihr Team vor die Tür zu setzen und stattdessen Ersatz einzustellen, läuft nicht. Es ist weder billig noch einfach, kompetenten Ersatz zu finden - und egal, wie kompetent der Ersatz ist, eine Faustregel besagt, dass es das Äquivalent eines Jahresgehalts kostet, einen Mitarbeiter zu entlassen.

11. Gute Führung

Gut geführte IT-Organisationen müssen selten modernisieren, weil sie ein Lifecycle Management praktizieren. Dadurch, dass solche Teams alles auf dem neuesten Stand halten, bleibt das Budget überschaubar. Der Aufwand für die Applikationsmodernisierung verläuft gleichmäßig und es gibt nur wenige "Big Bang"-Initiativen. Das hat den angenehmen Nebeneffekt, dass die Mitarbeiter zusammen mit Anwendungen und Plattformen modernisiert werden. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.