Wie umgehen mit Legacy-Anwendungen? Ablösung der Cobol-Monolithen

Nur nicht anfassen! Viele IT-Abteilungen haben Leichen im Keller – Black Boxes, um die man einen großen Bogen macht. Nur: Wie lange kann man mit diesen abgeschlossenen Legacy-Anwendungen noch leben?

Anbieter zum Thema

Vogel IT-Medien GmbH

Fujitsu Technology Solutions GmbH

FNT GmbH

cellent AG

Die Gefahren bestehen in zweierlei Hinsicht: Einerseits traut sich keiner die alten Anwendungen anzufassen. Und oft sind es gerade die Kernsysteme einer Organisation, die lange Zeit aus Angst davor, etwas kaputt zu machen, nicht mehr erneuert wurden. Zu viele kritische Systeme hängen davon ab.

Andererseits versteht und kann es bald keiner mehr – je länger Unternehmen mit der Ablösung von Cobol-Applikationen warten, umso geringer die Wahrscheinlichkeit, einen Spezialisten dafür zu finden. Denn wer lernt heute schon noch die „Common Business Oriented Language“? Früher oder später laufen IT-Abteilungen in ein Generationenproblem.

Legacy-Applikationen lassen keine Ignoranz zu

Nichtstun ist daher keine Option. Am Ende des Tages haben Unternehmen zwei Möglichkeiten, wie sie mit ihrer Altanwendung umgehen. Die erste Möglichkeit ist es, das Alte in einem Durchgang komplett abzulösen. Ein „Big Bang“, bei dem das ganze Altsystem an einem Stichtag abgeschaltet und durch das neue ersetzt wird.

Doch das funktioniert nur bei sehr kleinen Systemen nach einer vollständigen Risikoanalyse – für alle anderen ist dieser Schritt zu kritisch. Denn die Komplexität der Legacy-Landschaft ist oft nur schwer einzuschätzen. Die Gefahr, dass bei einer Komplettablösung wichtige Funktionalitäten zunächst unbemerkt verloren gehen, ist nicht auszuschließen. Auch die Finanzierung einer Einmalumstellung ist meist bei weitem zu teuer.

Big Bang ist keine Alternative

Die andere – und fast immer vernünftigere – Variante im Großteil der Fälle ist daher: Den Cobol-Monolithen Schritt für Schritt aufbrechen und einzelne Funktionalitäten in neue Anwendungen überführen.

Es gibt Funktionen, die dafür mehr geeignet sind als andere. Wichtig ist, dass die zu überführende Funktion klar als logische Einheit vom Rest der Applikation getrennt werden kann – sowohl im operativen Betrieb als auch was den Cobol-Quellcode betrifft.

Bei einigen wenigen Bereichen ist es möglich, für die Modernisierung auf Standardsoftware zurückzugreifen. Für das Rechnungswesen beispielweise sind ERP-Lösungen durchaus sinnvoll.

In den meisten Fällen jedoch ist von Standardsoftware abzuraten: Die Anforderungen der Unternehmen sind schlichtweg zu speziell und eine etwaige Erweiterung der Lösung zu kostspielig. Daher braucht es sichere Konzepte, um historisch gewachsene Applikationen in flexible und moderne Anwendungen zu überführen, die den jeweiligen Bedürfnissen der Organisationen gerecht werden.

Schritt für Schritt von Cobol zu Java & Co.

Will man einen veralteten COBOL-Monolithen Schritt für Schritt aufbrechen und in ein neues System überführen, empfiehlt sich grob und verallgemeinert folgende Vorgehensweise:

• 1. Eigenständige Funktionalität identifizieren

• 2. Cobol-Schnittstelle im Monolithen und entsprechende Schnittstelle zur modernisierenden Funktionalität beispielsweise mit Web-Services erstellen

• 3. Fachbereichsanwendung programmieren oder Standsoftware verwenden und an die neu gestalteten Schnittstellen anbinden

• 4. Falls notwendig: Daten migrieren

• 5. Neue Anwendung in den Fachbereichen einführen

Cobol-Monolithen besitzen natürlich bereits Schnittstellen. Doch diese wurden nicht geschrieben, um das Anflanschen von neuen Funktionen zu ermöglichen. Für jede neue Funktion braucht es eine eigene Schnittstelle, um das Neue an das Alte anzudocken. Und diese müssen in Cobol geschrieben werden.

Interfaces zu Web-Services

Als Technologie für die Schnittstelle bieten sich Web-Services an, da diese universell für Java, .net und andere Sprachen einsetzbar ist. Sollte keine Standardsoftware zum Einsatz kommen, muss sodann eine neue Fachbereichsanwendung programmiert werden.

Hierbei müssen die Initiatoren alte Strukturen überdenken: Oftmals beruhen Cobol-Systeme auf Vorgängen, die auf Papier definiert wurden. Da mittlerweile jedoch viel mehr Prozesse digital stattfinden, muss die neue Applikation darauf ausgelegt und gegebenenfalls neue Kategorien und Funktionen eingeführt werden.

Auf Dauer gehört außerdem die Frage gestellt: Wo sollen die Daten liegen, auf die die neue Anwendung zugreift? Im Hinblick auf die nächsten Jahrzehnte und die schrittweise Abschaltung des Cobol-Monolithen ist es sinnvoll, die Verwaltung der Daten im neuen System anzusiedeln, um so unabhängig wie möglich von der alten Anwendung zu sein.

Denn auf lange Frist ist der Aufwand für die Datenmigration ohnehin nicht zu vermeiden. Und ganz am Schluss gehört zur Ablösung des Altsystems auch die operative Einführung der neuen Anwendung in die Fachbereiche – mit Training und allem, was dazu gehört.

Weit mehr als ein IT-Problem

Je länger man veraltete Anwendungen „nachschleppt“, desto stärker kommen technische Schulden durch unsauberes Arbeiten in der Vergangenheit zum Tragen. Das An- und Umbauen um den Fehler herum wird nicht nur sehr teuer, es liegt früher oder später bei den Verantwortlichen sowieso als Krisenprojekt auf dem Tisch. Einige Branchen, das Bankenwesen zum Beispiel, sind durch Änderungen an Gesetzen und Regularien wie die Solvabilitätsverordnung sogar zur Aktualisierung ihrer Anwendungen gezwungen.

Einen Schritt weiter gedacht: Auch der Vorstand sollte beim Thema Legacy-Applikationen hellhörig werden. Altanwendungen sind mitunter ein beliebtes Ziel für Cyber-Kriminelle. Sollten Angreifer sich den Weg durch Sicherheitslücken in einem Cobol-System bahnen, haben Verantwortliche aufgrund der enormen Komplexität der veralteten Anwendung kaum Chancen, schnell genug zu reagieren, um Schäden zu verhindern.

Aus Berater- und Entwicklerperspektive ist zu bemerken, dass das Bewusstsein über die Dringlichkeit des Problems entgegen vieler Behauptungen durchaus vorhanden ist. Es ist also keine Frage der Aufklärungsarbeit, sondern vielmehr der Bereitstellung realistischer Konzepte für die schrittweise Ablösung von Cobol-Monolithen.

Experten, die sowohl die alte als auch die neue Welt beherrschen und entsprechend übersetzen können, werden immer gefragter. Unternehmen sollten bei diesem kritischen Projekt auf Berater setzen, die bereits Erfahrungen und Projekte bei der Modernisierung von Legacy-Applikationen vorweisen können. Java können heute alle, Cobol immer weniger, aber beides – dieses Wissen wird immer mehr zur Mangelware.

* Matthias Müller ist Software-Architekt bei dem Stuttgarter IT-Dienstleister Cellent AG.

(ID:44391125)