Wer Anwendungen in die Cloud verlagern möchte, sollte zunächst das Zusammenspiel mit Legacy-Systemen genau unter die Lupe nehmen.
von Christian Tüffers (Senior Manager bei Accenture und Experte für Cloud Computing)
Die meisten Unternehmen verlagern vorzugsweise Anwendungen in die Cloud, die lediglich unterstützende Funktionen erfüllen - zum Beispiel E-Mail-, CRM- oder Logistikanwendungen. Kernsysteme dagegen verbleiben meist im hauseigenen Rechenzentrum und laufen weiterhin auf ihrer angestammten Server-Farm oder einem Mainframe. Diese Rollenverteilung ergibt sich schlicht aus der Tatsache, dass unterstützende Funktionen in aller Regel keine unternehmensspezifischen Prozesse und Funktionen betreffen: Die zugrunde liegenden Abläufe gleichen sich in vielen Unternehmen. Sie weisen einen hohen Standardisierungsgrad auf und sind eben deshalb prädestiniert für die Verlagerung an einen internen oder externen Cloud-Provider.
Anders verhält es sich mit den Kernsystemen: Sie spiegeln die Individualität des Unternehmens wider und sind daher selten standardisiert. Das ist insbesondere bei Banken oder Versicherungsunternehmen zu beobachten, aber auch in anderen Branchen unterscheiden sich die Kerngeschäftsprozesse verschiedener Unternehmen mitunter beträchtlich. Dabei basieren die in der IT abgebildeten Prozesse oft auf Legacy-Anwendungen.
Doppelte Perspektive: Daten und Prozesse im Auge behalten
Verlässt eine Applikation das Haus in Richtung Cloud, muss das Unternehmen neu organisieren, wie diese Lösung mit den "daheim bleibenden" Anwendungen und Daten kommuniziert. Wer beispielsweise die Kundenbetreuung zu Salesforce.com transferiert, dabei aber den eigentlichen Kundendatenstamm im hauseigenen ERP-System belässt, muss für einen reibungslosen Datenaustausch sorgen. Vergleichbares gilt, wenn etwa Logistikfunktionen in die Cloud ausgelagert werden, während die Materialverwaltung im eigenen Unternehmen läuft. Ohne Integration zwischen Cloud-Systemen und lokal betriebenen Anwendungen droht in beiden Fällen, dass die Daten nicht mehr konsistent sind, weil die Datenpflege auseinanderdriftet. Das mündet fast zwangsläufig in eine doppelte Datenhaltung - was nichts anderes heißt als Mehrkosten und Zeitverlust.
Unternehmen sollten bei der Cloud-Integration nicht nur die Daten, sondern auch die Prozesse im Auge behalten. Der Fokus liegt dabei auf den Möglichkeiten des wechselseitigen Funktionszugriffs. Hat zum Beispiel eine Versicherung ihr Schadens-Management in die Cloud verlagert, muss dieser Schadensservice auch ungehindert auf Versicherungspolicen zugreifen können, die im Kernsystem der Versicherung hinterlegt sind. Nur wenn sowohl der Daten- als auch der Funktionszugriff sichergestellt sind, lässt sich ein bruchloser Workflow prozessübergreifend etablieren.
Altlasten erweisen sich als Barriere für das Cloud Computing
Eine erfolgreiche Cloud-Integration sollte also gleichermaßen auf Daten- wie Applikationsebene ansetzen. Bei modernen IT-Systemen, die unter anderem via Web-Service angesprochen werden können, ist diese Integration technisch mit relativ einfachen Mitteln erreichbar. Denn mittlerweile stellen die meisten Cloud-Provider Web-Service-basierende Standardschnittstellen zur Verfügung.
Schwieriger gestaltet sich indes die Verzahnung von Cloud-Diensten mit Legacy-Systemen - wobei mit Legacy in diesem Kontext keineswegs nur in Cobol geschriebene Mainframe-Anwendungen gemeint sind. Auch viele ältere J2EE-Applikationen ohne zeitgemäße Softwarearchitektur fallen in diese Kategorie. Viele Unternehmen haben Kernanwendungen im Lauf der Jahre selbst entwickelt, darunter auch individuelle ERP-Systeme.
Solche Eigenentwicklungen nennt man gern "historisch gewachsen" - ein Euphemismus, der lediglich verschleiert, dass es sich dabei meist um schlecht strukturierte Programmungetüme handelt. Insbesondere Geschäftslogik, Datenhaltung und Nutzeroberfläche sind oft nicht sauber genug voneinander getrennt. Diese mangelnde Entkoppelung der verschiedenen Architekturebenen verursacht den hohen Wartungsaufwand solcher Systeme. Außerdem sind die meisten Legacy-Anwendungen kaum dokumentiert. Die Entwickler haben das Unternehmen oft längst verlassen - und mit ihnen das zugehörige System-Know-how.
All das erschwert für sich allein schon die Integration zwischen Legacy- und Cloud-Anwendungen. Hinzu kommt die Tatsache, dass viele Altsysteme auf eine starre Stapelverarbeitung festgelegt sind, im Gegensatz zur ereignisorientierten Natur von Cloud-Transaktionen. Allerdings ist keine der genannten Integrationsherausforderungen grundsätzlich neu. Sie stellen sich so oder in ähnlicher Form auch Unternehmen ohne Cloud-Ambitionen.
Am Enterprise Service Bus führt selten ein Weg vorbei
Cloud Computing ist eine konsequente Weiterentwicklung des SOA-Konzepts (Service-oriented Architecture). Das legt den Gedanken nahe, auch die Cloud-Legacy-Integration mit weiterentwickelten SOA-Instrumenten ins Werk zu setzen. Berücksichtigt man die Doppelperspektive aus Daten- und Prozesssicht, dann gibt es prinzipiell zwei Integrationswege:
-
Legacy-Systeme per Datenaustausch an die Cloud anzubinden;
-
Anwendungen per Enterprise Service Bus (ESB) zu integrieren.
Die erste Option entspricht der engeren Datensichtweise, der ESB dagegen repräsentiert die umfassendere Prozessperspektive. Reicht eine einfache punktuelle Verbindung zwischen Cloud- und Legacy-Anwendung aus, kann manchmal ein einfacher Dateitransfer die kostengünstigere Integrationsalternative sein. Das ist allerdings nur der Fall, wenn die beiden Applikationen nicht synchronisiert werden müssen - zum Beispiel, wenn Materialbestände in einer alten Mainframe-Datenbank aus einem logistischen Cloud-Service nur in größeren zeitlichen Abständen als Wareneingang gebucht werden müssen.
In den allermeisten Fällen müssen Cloud- und Legacy-Anwendung in Echtzeit miteinander interagieren. Dann führt kein Weg am ESB vorbei. Der Begriff ESB kam vor knapp zehn Jahren im SOA-Umfeld auf und bezieht sich auf eine Schicht aus verschiedenen Softwarewerkzeugen, die zwischen den diversen Enterprise-Applikationen dolmetschen. Idealerweise ermöglicht der ESB, dass verschiedene Anwendungen reibungslos miteinander kommunizieren können, ohne dass dafür Code-Änderungen an den beteiligten Anwendungen notwendig sind. Das gilt sowohl für den Datenaustausch als auch für den wechselseitigen Funktionszugriff zwischen den Anwendungen. Die wichtigsten Mittel dafür sind hauptsächlich Web-Services auf Basis von XML sowie SOA-typische Messaging-Formate.
Steht kein ESB zur Verfügung, muss für jede Einzelinteraktion zwischen zwei Anwendungen eine exklusive Punkt-zu-Punkt-Schnittstelle programmiert werden - eine extrem aufwendige Angelegenheit. Der Zugriff auf Mainframe-basierende Legacy-Anwendungen lässt sich dabei über spezielle Adapter wie beispielsweise den Transaktionsmonitor CICS umsetzen. Die Lösung unterstützt diverse Programmiersprachen und Protokolle aus der Großrechnerwelt, darunter Cobol, PL/1 und Assembler. Mit CICS lassen sich Transaktionen unter Mainframe-Betriebssystemen wie MVS sozusagen in einen Web-Service einpacken. Sie sind in dieser Form dann auch für Cloud-Anwendungen konsumierbar. Zusammen mit den ESB-Messaging-Funktionen gelingt es damit in vielen Fällen auch, eine Brücke zwischen Mainframe-typischer Stapelverarbeitung und der ereignisorientierten Cloud-Arbeitsweise zu schlagen.
Wenn nichts hilft: Legacy-Systeme lassen sich umbauen
Die wenigsten Unternehmen müssen in Sachen Legacy-Cloud-Integration bei null anfangen. Vielerorts sorgen ESBs bereits seit Jahren für die interne Anwendungsintegration. Prüfen sollte man allerdings, ob der jeweilige ESB-Anbieter auch geeignete Konnektoren für die Cloud-Anbindung bereitstellt, etwa für das Session- und Transaktions-Management. Mittlerweile bieten einige ESB-Hersteller sogar Cloud-spezifische Konnektoren an, zum Beispiel einen Adapter für Salesforce.com.
Gleichwohl: Auch ein ESB ist kein Allheilmittel. Manche Legacy-Anwendung widersetzt sich hartnäckig dem externen Zugriff auf ihre Kernfunktionen - ursprünglich war einfach keine Öffnung nach außen vorgesehen. Dann muss das Legacy-System selbst angepasst werden, was wiederum oft mit einem tiefgreifenden Umbau der zugrunde liegenden Softwarearchitektur einhergeht. Für die Legacy-Anpassung empfehlen sich im Wesentlichen drei Ansätze:
-
Beim Re-Factoring wird die Architektur punktuell angepasst, um Cloud-relevante Funktionen neu zu kapseln und auf diese Weise einen externen Zugriff zu ermöglichen. Wichtig dabei: Re-Factoring verändert die Programmfunktionen als solche nicht. Aus der Blackbox-Sicht bleibt alles wie vorher.
-
Unter Re-Writing versteht man das Neuschreiben der kompletten Legacy-Anwendung. Sowohl Funktions- als auch Architekturänderungen sind in diesem Fall möglich.
-
Der Begriff Re-Platforming fasst unterschiedliche Tools und Methoden zur automatischen Portierung einer Legacy-Applikation auf eine andere Plattform zusammen, beispielsweise von Cobol/Mainframe auf .NET/Microsoft oder Java/Linux. Ratsam ist Re-Platforming allerdings nur, wenn die betreffende Anwendung (respektive die durch sie abgebildeten Prozesse) tatsächlich eins zu eins erhalten bleiben soll. Denn die Programmiersprache und die Plattform sind zwar neu, aber an der eigentlichen Softwarestruktur ändert Re-Platforming nichts.
Die Alternative: Integration als Cloud-Service
Unternehmen, die keinen eigenen Enterprise Service Bus (ESB) für ihre internen Systeme benötigen, können Anwendungsintegration mittlerweile auch als Cloud-Service beziehen. Anbieter wie die von IBM übernommene Cast Iron oder die Dell-Tochter Boomi erlauben eine ESB-ähnliche Verzahnung zwischen lokalen Anwendungen und Cloud-Systemen. Vorteilen wie schneller Verfügbarkeit und kostengünstiger Verrechnung steht allerdings die eingeschränkte Flexibilität der ESB-Cloud gegenüber. Vor allem komplexe Integrationsvorhaben lassen sich mit den begrenzten Konfigurationsmöglichkeiten einer ESB-Cloud heute meist noch nicht bewerkstelligen. Stattdessen sind dann Codeerweiterungen nötig.
Verantwortliche, die eine Migration von Legacy-Anwendungen per Re-Writing oder Re-Platforming planen, sollten unbedingt auch die Option Platform as a Service (PaaS) in Betracht ziehen. PaaS vereinfacht die Entwicklung von dezidierten Cloud-Applikationen. Bekannte PaaS-Beispiele sind Microsoft Azure und die Google App Engine. Die Vorteile liegen auf der Hand: PaaS-Anwendungen lassen sich wahlweise lokal im eigenen Haus betreiben oder an einen Cloud-Provider delegieren. In der Cloud ist die Skalierung bei schwankendem Lastverhalten kein Problem mehr, denn dafür ist die Provider-Plattform verantwortlich. Hochinteressant ist die PaaS-Option zudem für Unternehmen, die von jedem Ort aus erreichbar sein wollen. Immerhin verfügen Cloud-Provider wie Microsoft und Google über weltweit vernetzte Rechenzentren.
Fazit: Re-Writing ermöglicht Prozessoptimierung
Für die Entscheidung zwischen ESB und Legacy-Anpassung gibt es kein Patentrezept. Jedes Unternehmen hat seine individuellen Voraussetzungen und verfolgt mit der Cloud-Integration eigene Ziele. Wichtigstes Entscheidungskriterium ist im Einzelfall zweifellos die konkrete Kosten-Nutzen-Analyse. Aus strategischer Sicht sollte dabei jedoch berücksichtigt werden, dass nur der endgültige Abschied von abgeschriebenen Altsystemen die vielfältigen Legacy-Probleme auf lange Sicht lösen kann.
Die konsequenteste Option, das Re-Writing, verbessert dabei nicht nur die IT-Systeme selbst, sondern bietet gleichzeitig die Chance, die betreffenden Geschäftsabläufe neu zu strukturieren. Insofern sollte die Cloud-Legacy-Integration immer auch ein Anlass sein, über die Optimierung von Prozessen nachzudenken. (Dieser Beitrag wurde von Computerwoche, einer Schwesterpublikation von ChannelPartner, übernommen / rb)