Problematische Cobol-Altlasten

So bringen Sie Altanwendungen in die Cloud

Bernhard Steppan arbeitet als leitender Berater und Softwarearchitekt bei syracom Consulting in Wiesbaden sowie als Publizist. Er hat 100+ Artikel und zahlreiche Bücher über C++ und Java verfasst. Er betreibt mehrere Websites, unter anderem http://steppan.net, http://artouro.org und http://tourbine.com

Welche Sprachen, Frameworks, Datenbanken etc. werden genutzt?

Bei der näheren Analyse der IT-Bebauung mit den aufgeführten Individualanwendungen geht es darum, herauszufinden, welcher Technologiemix (Programmiersprache/n, Frameworks, Datenbanken, Dateisystem) in den verschiedenen Anwendungen eingesetzt wird. Zudem ist wichtig, den Schutzbedarf der Daten zu ermitteln, mit denen die Anwendung arbeitet. Ergebnis dieses Abschnitts ist eine genaue Vorstellung von der IT-Architektur der Anwendungen des Unternehmens.

Das rot markierte Buchungskernsystem steht im Mittelpunkt - leider eine in Cobol geschriebene, nicht modulare Mainframe-Anwendung (Abbildung 3).
Das rot markierte Buchungskernsystem steht im Mittelpunkt - leider eine in Cobol geschriebene, nicht modulare Mainframe-Anwendung (Abbildung 3).

In unserem Fallbeispiel des Touristikunternehmens erbringt das Review eine erste grobe Einschätzung, wie die Anwendungen aufgebaut sind (Abbildung 3). Das zentrale Buchungskernsystem ist eine in Cobol entwickelte, nicht modular aufgebaute Großrechner-Anwendung (rot markiert). Das Frontend für die Buchung von Reisen im Internet ist in PHP geschrieben. Die PHP-Anwendung ist ebenfalls nicht modular aufgebaut und durch mehrere Erweiterungen schwer zu pflegen. Die anderen im Bebauungsplan gelb markierten Systeme sind ältere Java-Systeme, die eher monolithisch und nicht serviceorientiert aufgebaut sind. Insgesamt ist die Anwendungslandschaft aus der Perspektive einer komponenten- und serviceorientierten Architektur stark verbesserungsbedürftig.

Im nächsten Schritt führt nun das IT-Architektur-Management auf Basis der vorhergehenden Analyse eine detaillierte Machbarkeitsstudie für jede der genannten Anwendungen durch. Dieses Proof of Concept soll zeigen, ob eine Cloud-Migration für das Unternehmen technisch und finanziell angesichts der unübersehbaren Architekturprobleme überhaupt realistisch ist. Die Studie stützt sich auf die vorgelagerte grobe Architekturanalyse der Anwendungen und beinhaltet unter anderem Analysen von Datenfluss, Datenhaltung und Umfeld. Ferner wird in der Studie für jede Anwendung eine eigene Kosten-Nutzen-Betrachtung angestellt. Ergebnis der Studie ist eine detaillierte Übersicht über Gesamtkosten und den Nutzen einer Migration. Ferner zeigt die Studie die Verfügbarkeit von Personal und bewertet das für eine Cloud-Migration benötigte interne Know-how zur Umstellung der Anwendungen.

Anwendungs-Arten

Anwendungen, die auf Basis älterer Programmiersprachen geschrieben wurden, lassen sich in der Regel nur schwer transformieren. Hier wäre eine Migration in die Cloud mit so hohen Kosten verbunden, dass es sich nicht lohnen würde. Manchmal hilft es, die Alt-Anwendungen in einer eigenen Infrastruktur zu hosten, von der ein Zugang zur Cloud geschaffen wird. Dieser Typ Anwendung ist in Abbildung 3 rot markiert.
Alt-Anwendungen, die schon mit modernen Programmiersprache wie PHP oder C++ entwickelt wurden, aber nicht modular aufgebaut sind, fallen in die Kategorie der schwierig anzupassenden Systeme. Sie sind in Abbildung 3 gelb markiert.
Alt-Anwendungen, die mit neuen Programmiersprachen entwickelt wurden und modular aufgebaut sind oder sogar bereits über Serviceschnittstellen verfügen, sind gute Kandidaten für eine Cloud. Dieser Typ Anwendung ist in Abbildung 3 hellgrün markiert.

Ernüchternde Machbarkeitsstudie

Im Fall des fiktiven Touristikunternehmens zeichnet die Studie folgendes Bild: Das besonders geschäftskritische Buchungskernsystem (rot markiert in Abbildung 3) für die Cloud anzupassen, wäre teurer, als es mit heutiger Technologie komplett neu zu entwickeln. Aufgrund der unzureichenden Dokumentation, der schlechten Modularisierung und den wenigen verfügbaren Mitarbeitern, die die Anwendung genau kennen, stehen die Kosten einer Ablösung in keinem Verhältnis zum Nutzen und den Risiken. Beim Internet-Buchungssystem (orange markiert in Abbildung 3) erbringt die Studie, dass eine Modernisierung der Anwendung ohnehin ansteht und außerdem prinzipiell sinnvoll wäre. Die Anwendung ist jedoch ebenfalls schlecht dokumentiert und hängt stark mit dem Buchungskernsystem zusammen. Da dieses Buchungssystem über keine Services verfügt, müsste entweder ein Serviceadapter für das Buchungskernsystem eingeführt oder ein spezieller Zugang zwischen Cloud und Kernsystem geschaffen werden.

Bei den gelb und hellgrün markierten Java-Anwendungen sieht die Situation anders aus. Die gelb markierten Java-Anwendungen könnten mit hohem Aufwand migriert werden. Aber auch hier überwiegen die Kosten den zu erzielenden Nutzen. Besser sieht die Situation bei den hellgrün markierten Anwendungen aus. Durch ihren modularen Aufbau können sie relativ leicht an eine neue Topologie und Infrastruktur angepasst und mit Services erweitert werden. Da sich die Investitionen in vergleichbar kurzer Zeit amortisieren, beschließt der Reisekonzern, die Cloud-Migration zunächst nur an diesen beiden Anwendungen vorzunehmen, auch um Erfahrung in der Cloud-Technologie mit diesen nicht so kritischen Anwendungen zu sammeln.

Wie im Vorgehensmodell festgelegt, geht es nun darum, die Anwendungen noch genauer als in den vorhergehenden Phasen zu analysieren. Das geschieht unter dem Blickwinkel der wichtigsten Designkriterien für eine Cloud-Umgebung: Unabhängigkeit von Topologien, Serviceorientierung, Unabhängigkeit vom Dateisystem, zustandslose Sessions und Services, Infrastrukturunabhängigkeit und Portabilität. In dieser Phase wird möglichst genau geschätzt, was geändert werden muss, um diese Hauptkriterien zu erfüllen. Zudem kalkuliert das Projektteam, welcher Aufwand sich daraus ergibt. Danach stellt der Projektleiter in Zusammenarbeit mit den Architekten eine Zielarchitektur sowie einen Zeit- und Ressourcenplan auf.

Diese Phase kann weitere Erkenntnisse liefern, die in der Machbarkeitsstudie übersehen wurden. Gegebenenfalls müssen die Erkenntnisse der Studie dann nochmal angepasst werden. Im Fall des Reisekonzerns gehen wir davon aus, dass die Analyse und Planungsphase keine neuen Erkenntnisse bringt und die eigentliche Transformation beginnen kann. Hier bietet sich für jedes Projekt ein iteratives Verfahren an, bei dem die Anwendung nach der Maßgabe der Analysephase in überschaubare, fachlich getrennte Bestandteile zerlegt und qualitätsgesichert wird.

Vier wichtige Unternehmensanwendungen (dunkelgrün) sind bereit für die Cloud (Abbildung 4).
Vier wichtige Unternehmensanwendungen (dunkelgrün) sind bereit für die Cloud (Abbildung 4).

Im Rahmen des Projekts werden die zwei bestehenden Anwendungen mit ihren Nachbarsystemen um Serviceschnittstellen erweitert. Das Design der Schnittstellen orientiert sich hierbei an den Geschäftsprozessen. Die neuen Schnittstellen ersetzen alte Cloud-untaugliche Datei- und Datenbankschnittstellen. Des weiteren werden alle topologischen und infrastrukturbezogenen Abhängigkeiten beseitigt. Nachdem die neuen Schnittstellen implementiert und getestet sind, hat sich die IT-Bebauung bereits erheblich verändert (Abbildung 4). Als Ergebnis der Sanierung sind nun vier wichtige Unternehmensanwendungen bereit für die Cloud. Eine weitere Anwendung ist als Folge der neuen Services ein zusätzlicher Kandidat für die Cloud-Transformation.

Fazit

Cloud Computing kann die Flexibilität der IT deutlich erhöhen. Der Weg zu dieser flexiblen IT kann je nach Unternehmen und Anwendungslandschaft allerdings steinig sein. Das Migrationsverfahren, das hier vorgestellt wurde, zeigt einen Weg auf, wie man Altanwendungen strukturiert überprüft, Kosten und Nutzen bewertet sowie die Anwendungen für den Betrieb auf einer Cloud vorbereitet.

Inhalt dieses Artikels

 

Bernhard Steppan

Nein, das Buchungskernsystem sollte aus strategischen Gründen nicht für "immer" auf dem Host bleiben. Die Ablösung wäre aber in Praxis nicht so trivial. An der Ablösung solcher Systeme sind schon viele Firmen gescheitert. Solche Anwendungen sind in Jahren optimiert worden und funktionieren meistens weit performanter als Anwendungen, die mit neuer Technologie entwickelt wurden. Sie sehen aber im Prinzip schon, wie eine Ablösung funktioniert: Man verbindet das System über Webservices mit den Nachbarsystemen und löst so per EAI Stück für Stück jede alte Schnittstelle durch eine moderne ab. Das muss immer im Hinblick auf die Performance geschehen, denn das Daten-Mapping zwischen einem Service und dem alten Datenmodell "kostet" unter Umständen viel. Hat man alle Schnittstellen abgelöst, kann man das System hinter der Fassade neu entwickelt und gegen das Altsystem transparent austauschen. Das klingt einfach, ist aber alles andere als trivial.

marina.ribke@ribke-consulting.

Was passiert denn nun mit dem Buchungskernsystem? Bleibt es für immer im Host? Irgendwann geht auch der letzte Cobol Entwickler in Rente. Das ist doch ein existentielles Risiko für das Unternehmen. Wenn sich eine Neuentwicklung nicht lohnt und keiner mehr die Applikation betreiben kann, bleibt ja nur noch die Schließung des Unternehmens als Alternative? Oder wurde noch etwas anderes geplant?

comments powered by Disqus