Digitalisierung ist derzeit eines der beherrschenden IT-Themen. Sie ist die treibende Kraft, die dafür sorgt, dass sämtliche Prozesse und Geschäftsmodelle auf den Prüfstand kommen. Dazu gehören auch die oft schwerfälligen Prozesse bei der Bereitstellung der IT-Infrastruktur. Um hier flexibler und kostengünstiger zu werden, bietet es sich an, möglichst viele Anwendungen in eine Cloud zu verschieben. Unternehmen, die ihre Individualanwendungen in die Cloud hieven wollen, müssen jedoch einen steinigen Weg beschreiten.
Im Gegensatz zu vielen Standardanwendungen, die inzwischen bereit für die Cloud sind, ist Individualsoftware oftmals inkompatibel zu gängigen Cloud-Lösungen. Der Grund hierfür ist, dass diese Anwendungen aus einer Zeit stammen, in der Cloud Computing noch kein Thema war. Derartige Individualsoftware ist für eine spezielle Topologie und Infrastruktur entwickelt worden, die sich von heutigen Cloud-Umgebung mehr oder weniger stark unterscheidet.
Beispiel: Touristikunternehmen
Um Individualsoftware in einer Cloud betreiben zu können, müssen diese Lösungen Schritt für Schritt umgestellt und an die neue Cloud-Umgebung angepasst werden. Hierbei sind, je nach Ausgangssituation, mehr oder weniger tiefgreifende Änderungen an den Anwendungen notwendig. Hier stellt sich die Frage, wie das Verhältnis von Kosten zu Nutzen aussieht. Das Vorgehen bei der Überprüfung der Wirtschaftlichkeit und bei der Transformation hängt stark vom Reifegrad der IT eines Unternehmens und dem Aufbau der Anwendungen ab.
Ein Beispiel ist in Abbildung 1 zu sehen. Es zeigt in Kern einen konventionellen Wasserfallprozess. Die eigentliche Transformation kann jedoch iterativ ablaufen. Insgesamt ist der Prozess so ausgerichtet, dass sich das nicht unerhebliche Risiko einer Migration von Alt-Anwendungen in den Griff bekommen lässt.
Anhand eines fiktiven Touristikunternehmens soll gezeigt werden, wie sich dieses Vorgehensmodell anwenden lässt. In der Definitionsphase beschreibt in diesem Beispiel ein Projektteam die Motivation für eine Cloud-Migration wie folgt: Die Hauptmotivation ist, dass der Konzern unter starkem Kostendruck steht und zudem ein eigenes Rechenzentrum nicht mehr als eine seiner Kernkompetenzen ansieht. Zudem werden einige Anwendungen nur saisonal stark benötigt, blockieren aber das ganze Jahr über Rechnerkapazitäten.
Das Projektteam legt daher folgende Ziele fest: das eigene Rechenzentrum soll ausgelagert werden. Als erste Outsourcing-Maßnahme gilt es, möglichst viele Anwendungen zu einem Drittanbieter in eine kostengünstige Cloud zu verlagern. Ziel soll sein, die Rechnerkapazitäten nur dann zu bezahlen, wenn sie auch benötigt werden.
Der IT-Bebauungsplan hilft bei der Bestandsaufnahme
Der Konzern hat eine historisch gewachsene Anwendungslandschaft mit vielen unternehmenskritischen Individualanwendungen, die in einer Zeit entstanden sind, als es noch keine Alternativen zu einer individuellen Entwicklung gab. In einer Inventarisierungsphase aktualisiert das Architektur-Management des Unternehmens den bisherigen IT-Bebauungsplan.
Mithilfe dieses Plans lassen sich die Anwendungen einordnen: nach ihrer Technologie, nach den Organisationseinheiten und nach ihrer Stellung innerhalb der Geschäftsprozesse. Der IT-Bebauungsplan gibt Auskunft darüber, welche Anwendungen bestimmte Geschäftsbereiche und Prozesse des Konzerns abdecken, zum Beispiel den Vertrieb oder die Katalogproduktion. Zudem liefert der IT-Bebauungsplan eine Bestandsausnahme der vorhandenen IT-Anwendungen.
Ergebnis der Phase ist ein Plan der gesamten Anwendungslandschaft, wovon die Abbildung 2 die wichtigsten Teile der IT-Bebauung zeigt. Die Abbildung besteht im linken Bereich aus dem Buchungskernsystem, mit dem sich im Reisebüro Reisebuchungen vornehmen lassen. Daran hängt der Internetauftritt des Unternehmens, mit dessen Hilfe Reisen über das Internet gebucht werden können. Diese Anwendungen initiieren die Transaktionen im Buchungskern. Unterhalb des Buchungskerns ist das Flugeinkaufssystem zu sehen, über das der Einkäufer Charterflüge für den Konzern organisiert und der Buchungssoftware zur Verfügung stellt.
Im mittleren Bereich des Bebauungsplans befindet sich das Hoteleinkaufssystem. Damit beschafft der Einkäufer Zimmerkontingente bei Hotels und stellt sie dem Buchungssystem zur Verfügung. Mit dem Preiskalkulationssystem berechnen die Produktmanager auf Basis der Vorjahrespreise die neuen Preise für die aktuelle Saison. Darunter befindet sich das Last-Minute-System, über das der Konzern steuern kann, welche Produkte in den Abverkauf kommen. Den Reigen der Individualanwendungen schließt das Rechnungsprüfungs-System, mit dem die von Hoteliers eingereichten elektronischen Rechnungen automatisiert gegen die vom Einkauf vereinbarten Preise für die unterschiedlichen Buchungskonditionen geprüft werden.
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.
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.
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.
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.