Datum
20.08.2010
Dieser Beitrag wurde verfasst von:
Innerhalb meiner Master Thesis versuchte ich u.a. diese einfach klingende Frage zu beantworten. Bei genauerer Betrachtung fiel jedoch auf, dass eine zufrieden stellende Beantwortung dieser Frage nicht in einem Satz formuliert werden kann. Dies geht mit der Komplexität der gesamten Thematik einher. In diesem Beitrag möchte ich mich daher darauf beschränken, die wesentlichen Ergebnisse aufzuzeigen…
In den letzten Jahren haben sich die Budgets für den Einsatz von IT in Unternehmen reduziert. Zusätzlich sind jedoch weitere Anforderungen hinzugekommen. So besteht eine Anforderung darin, mit immer weniger Mitteln immer mehr leisten zu müssen.
Was hat es mit Software-as-a-Service auf sich?
Sofware-as-a-Service (SaaS) kann als eine Möglichkeit gesehen werden diese Anforderungen zu erfüllen. Sie verspricht Unternehmen Software als Dienstleistung, günstig und weitestgehend wartungsfrei bereitzustellen. Dabei werden diese Dienste entweder nach Verbrauch oder monatlich als Abonnement abgerechnet.
SaaS wird zur Unterstützung von neuen und auch bereits etablierten Geschäftsprozessen eingesetzt. Die Einführung von SaaS vollzieht sich dabei nicht sofort, sondern schrittweise. Hierbei werden z.B. IT-Systeme die einen Geschäftsprozess unterstützen mithilfe von SaaS ausgelagert. Die meisten Geschäftsprozesse bestehen aus mehreren Teilprozessen. Diese Teilprozesse können durch verschiedene IT Systeme realisiert werden zu denen auch SaaS Lösungen zählen. Somit muss die Möglichkeit gegeben sein SaaS Lösungen mit der unternehmensinternen IT zu integrieren.
Wie SaaS integriert werden kann
SaaS Anbieter stellen dazu applikationsspezifische Schnittstellen, sogenannte APIs zur Verfügung. Diese APIs können z.B. mithilfe von WebServices genutzt werden. Die hinter den WebServices stehenden Funktionen werden dabei mit der Web Service Description Langage (WSDL) beschrieben. Leider gehen viele SaaS Anbieter davon aus, dass die Bereitstellung einer WebService API mithilfe von WSDL alleine ausreicht um ihre Dienste integrieren zu können. Ein Argument könnte lauten: WebServices und WSDLs sind doch standardisiert! Das stimmt. Jedoch ist nicht standardisiert, wie die in einer API bereitgestellten Dienste strukturiert sind und semantisch auszusehen haben.
Also können diese Dienste beliebig unterschiedlich ausfallen. Die, von diesen Diensten, erwarteten Eingabewerte können ebenfalls beliebig sein. Somit wird es notwendig sich sehr eng mit einer API auseinander zu setzen. Zu diesem Zweck müssen nicht nur die, zur Integration relevanten Dienste ermittelt werden, sondern es muss auch in Erfahrung gebracht werden, welche Vorbedingungen erfüllt sein müssen um die API verwenden zu können. Die Modellierung der Ein- und Ausgabeparameter in Form von Business Objects der SaaS Applikationen müssen zusätzlich betrachtet werden.Darüber hinaus werden die APIs im SaaS Umfeld schneller, als bei traditioneller Software aktualisiert. Zum Beispiel werden neue und ausgereiftere Funktionen hinzugefügt. Somit besteht die Notwendigkeit bereits durchgeführte Integrationen immer an die sich verändernden APIs anzupassen. Für jede Anpassung muss sich wieder eng an die neuen Eigenschaften der jeweiligen APIs gehalten werden.
Sind die APIs verstanden und die notwendigen Dienste sowie ihre Vorbedingungen und Business Objects identifiziert, stellt sich die Frage, wie überhaupt integriert werden soll und wer diese Integrationen durchführt. Die letzen Jahre haben gezeigt, dass selbst programmierte Punkt-zu-Punkt Integration zwar schnell umgesetzt ist, jedoch auf lange Sicht, viel Wartungsaufwand in sich birgt. Die Hub-and-Spoke Architektur hingegen stellt einen Zentralen Verbindungsknoten, den Hub, bereit an den alle zu integrierenden Systeme angeschlossen werden können. Dieser Ansatz wird auch von verschiedenen EAI Lösungen, wie dem WebSphere Message Broker oder dem WebSphere ESB aufgegriffen.
Ist der WebSphere Message Broker zur SaaS Integration geeignet?
Basierend auf dem WebSphere Message Broker, der eine sehr reife und zuverlässige Lösung darstellt, könnte eine SaaS Integration vorgenommen werden. Um ihn jedoch einsetzen zu können sind viel Erfahrung und Programmierkenntnisse notwendig, da er sehr flexibel ist und für eine Vielzahl von Integrationen eingesetzt werden kann. Somit werden bei diesem Ansatz Mitarbeiter mit Expertenwissen benötigt.
Zusätzlich ist der WebSphere Message Broker dazu konzipiert hunderte, wenn nicht sogar tausende Applikationen in hoch komplexen Umgebungen zu integrieren. Bei der SaaS Integration hingegen, werden nur zwei oder drei Applikationen integriert. Also stellt sich die Frage, wieso einfache Integrationsszenarien mit komplizierten Mitteln durchgeführt werden sollten. Prinzipiell wäre es erstrebenswert einfache Integrationsszenarien mit einfachen Mitteln zu begegnen.
Anbieter für SaaS Integration
Bei der SaaS Integration hingegen, werden nur zwei oder drei Applikationen integriert.Also stellt sich die Frage, wieso einfache Integrationsszenarien mit komplizierten Mitteln durchgeführt werden sollten. Prinzipiell wäre es erstrebenswert einfache Integrationsszenarien mit einfachen Mitteln zu begegnen.Mittlerweile hat sich ein diese Problematik adressierender Markt etabliert. Verschiedene Anbieter wie Informatica, Boomi, Cast Iron und Pervasive bieten speziell auf die SaaS Integration ausgelegte Lösungen an.
Diese Lösungen kapseln dabei die Komplexität, die mit der Integration von SaaS Applikationen verbunden ist. Somit besteht z.B. nicht mehr die Notwendigkeit sich in APIs, Business Objects und eventuell daraus resultierenden Vorbedingungen, einarbeiten zu müssen. Ein daraus resultierender Vorteil besteht darin, dass Integrationen nicht mehr programmiert sondern konfiguriert werden.
Meistens werden dazu nur drei Schritte benötigt:
- Verbindung zu den zu integrierenden Anwendungen herstellen
- Die verschiedenen zu integrierenden Datenobjekte der jeweiligen Anwendungen auswählen und transformieren
- Die Integrationslösung in Betrieb nehmen und warten
SaaS Integrationslösungen kapseln die Komplexität, die mit einer Integrationsentwicklung verbunden ist. Durch die Kapselung der mit der Integration einhergehenden Komplexität wird IT affines Personal in die Lage gebracht letztendlich selber Integrationen durchzuführen und diese zu warten. Dies wird durch eine Minimierung des Aufwandes bei der Entwicklung von Integrationen und durch Bereitstellung von Integrationstemplates – und -assistenten realisiert. Somit besteht unter Zuhilfenahme spezieller SaaS Integrationslösungen, nicht mehr die Notwendigkeit erfahrene Integrationsentwickler in SaaS Integrationen zu involvieren.
Fazit
Reichen APIs alleine also aus um SaaS Applikationen effizient zu integrieren? Abschließend kann diese Frage mit einem klaren NEIN beantwortet werden. APIs reichen nicht aus, um Integrationen effizient zu integrieren. Mit einer speziellen SaaS Integrationslösung wird SaaS Integration jedoch fast zu einem Kinderspiel.
Welchen Unterschied machten diese Informationen und Eindrücke?
- Die Erfahrungswerte der Kundenprojekte halfen in den letzen Wochen in der Bewertung einer Kundensituation zum Thema Business Process Management.
- Die Integration von ILOGs Businnes Rules Management System (neben den Optimization Tools und Supply Chain Management Lösungen) stellen einen guten Erweiterungsansatz für einen Kunden und dessen WebSphere Middleware dar – um dessen Fachbereich, die wahren Prozessinhaber, die automatisierten Abläufe dynamisch und flexibel anpassen zu lassen.
- Zudem wurden die Neuerungen oder deren Vorabversionen als Patches im Betrieb eines Kunden genutzt und
- natürlich die persönlichen Kontakte zu den Entwicklern in de nweltweiten IBM Labors im Nachgang intensiviert.
Cloud Buzz – Was bringen die wolkigen Versprechen? Regen?!
Aber was waren technologisch Trends? Vielfach ist zu lesen, dass „SOA in die Cloud“ wächst – Was ist darunter zu verstehen? Ist dem wirklich so? Und was sind die Vorteile – was die sonstigen Implikationen? Wie sind die dazu passenden Software Landschaften auszurichten? Wie sehen Betriebskonzepte dazu aus? …
Einordung Cloud Computing
Das heutige Buzzword ist „Cloud Computing“ – ein neues Hype-Thema, getrieben von Herstellern und Analysten. Aber SOA und Cloud Computing können viel zur zukünftigen Gestaltung der Geschäftswelt beitragen.
Worüber reden wir hier eigentlich? Buzzword-Bingo? Oder echter Nutzen?
Wahrscheinlich zutreffende These: Wer ständig hohle Begriffe verwendet, landet bei bedeutungslosen Ergebnissen – mit entsprechenden Auswirkungen auf Erfolg und Reputation.
Doch was ist „Cloud Computing“? Ist es wirklich? Innovativ? Nur eine aktuelle Welle? Eine zukünftige Welle? Kosteneffizient? Interoperable? Findet es heute Verwendung? Bringt es Nutzen? Ja, z.B. bei IBM, Amazon, Google, …!
Können Unternehmen (auch mittelständische!) schon heute von den verfügbaren Modellen, Diensten und Anwendungen profitieren? Ja, denn auch „private Cloud“-Ansätze auf Basis von etablierten Virtualisierungslösungen werden heute in mittelständischen Unternehmen untersucht und „public Clouds“ können genutzt werden: zum Beispiel mittels Amazon EC2 dynamische WebSphere Application Server Workloads für intensive Softwaretest von eigenen J2EE Applikationen auf Pay-per-Use Basis zu nutzen. Schneller Nutzen ohne hohe Kosten.
Also was ist „Cloud Computing“? Ist es Grid Computing? Organic Computing? Utility Computing? Oder Software-as-a-service? Oder – gar SOA?
Nein – „Cloud Computing“ ist anders – mehr –
In Kürze: “Cloud Computing ist ein Service-Management Modell (Plattform), welche eine transparente Infrastruktur mit geringen Managementkosten zur Verfügung stellt.“
Cloud Computing ist bisher nicht allgemeingültig oder gar eindeutig definiert. Jedoch existieren eine Reihe von Definitionsansätzen.
Exkurs: Zitate zur Cloud Definition aus Sekundärquellen – in der rechten Marginalie.
Demzufolge geht Cloud Computing über andere gegenwärtig diskutierte Ansätze (siehe oben) und Konzepte (Virtualisierung, Konsolidierung) hinaus.
Nutzbarkeit und Wert
Aber hier soll nicht weiter auf die allgemeine Cloud Thematik eingegangen werden, sondern auf die Nutzbarkeit und den Wert den dieser Ansatz für Unternehmen haben kann.
Dieser wird jedoch im Wesentlichen durch die spätere Software bestimmt, welche die Geschäftprozesse unterstützt und so die Menschen produktiv und effektiv ihre Arbeitet gestalten lässt. Diese Anwendungen sollten so flexibel und agil reagieren können, wie dies auch die Menschen – wenn Sie denn hinreichend motiviert sind – es täglich unter Beweis stellen. Die Softwareindustrie stellt heute Anwendungssysteme zur Verfügung, welche diese Agilität besitzen. Die zugrunde liegende Software Architektur orientiert sich an der etablierten Arbeitsteilung und Dienstestruktur und fasst dies über die Serviceorientierte Architektur (SOA) zusammen. Reale Umsetzung nutzen heute die seit über einer Dekade bestehenden Erfahrungen in der asynchronen Kommunikation – wenn sinnvoll – an heutigen Standards orientiert. Damit entstanden (und entstehen weiterhin täglich) Integrationslandschaften, die auf stabilen Enterprise Service Bus Implementierungen fußen und diese SOA in einen praktischen Nutzen für Unternehmen umsetzten.
Wenn doch die Cloud alles transparent macht – wieso sollte es dann Implikationen auf die Anwendungssysteme geben?
Dazu erlauben Sie die Frage, ob Sie die Aufwände kennen, welche Unternehmen in die Nutzung von Legacy-Anwendungen (z.B. Cobol oder RPG basiert) und Plattformen (z.B. Mainframes, AS400- oder Tandem-Systeme) in der heutigen verteilten, heterogenen Welt vornehmen mussten? Worin war und ist dies begründet? Einerseits in den wertvollen Bestandslösungen, die einen Investitionsschutz erfordern und andererseits in den Chancen, welche in der Nutzung innovativer Techniken liegen. Da passten nun die ehemaligen und heutigen, bzw. zukünftigen Modelle, z.B. in der Softwarearchitektur, nicht zusammen. Vielfach erfolgreich umgesetzte Lösungskonzepte sehen hier heute die oben genannten SOA Konzepte und Realisierungen vor.
Wolkige Herausforderungen
Nun stehen mit den wolkigen Versprechungen neuartige Konstellationen ins Haus, welche die Kommunikation von Anwendungen innerhalb einer Cloud und über die Grenzen hinweg vor neue Herausforderungen stellt. Warum?
Weil – und bitte verzeihen Sie, dass nun ein bisschen an der Oberfläche der Details gekratzt werden muss – z.B. ein sinnvolles Programmiermodells (REST) für die Cloud nicht mit den Konzepten des üblichen SOA Programmiermodell (SOAP) übereinstimmt. Sollte uns dies sorgen? Ist eines schlechter oder besser? Nein! Nur angepasst auf die Umgebung – und das ist gut so!
SOAP ist eine Weiterentwicklung des XML-RPC und stellt damit die standardisierte Interprozesskommunikation analog zum altenehrwürdigen Remote Procedure Protocol in der SOA zur Verfügung – sprich für die verteilte, heterogene Welt.
REST steht für Representational State Transfer und bezeichnet einen Architekturstil in dem jede Ressource eigenständig (mit einer eigenen URI) verfügbar ist. Enorm erfolgreich im World Wide Web. REST sieht wohldefinierte Operationen vor, die auf alle Ressourcen angewendet werden können (z.B. GET, POST, PUT und DELETE).
Eine SOA kann ebenso RESTful sein, wobei hier ein Mapping von logischen Ressourcen und Diensten notwendig ist (REST handelt mit Ressourcen, nicht mit Services). Eine architekturelle Wahl, keine Implementierungsentscheidung.
Dieses (einfache) Beispiel zum Programmiermodell ist nur eine der Implikationen, die durch ein anderes Betriebs- und Managementmodell zu betrachten sind.
Allgemein sind wesentliche Überlegungen zur Interopearbilität von Multi-tier Anwendungslandschaften zu tätigen und für die eigene Situation zu bewerten. Ob von operativer Seite oder gar hinsichtlich der End-to-End Prozessverfolgung, sprich Nachrichtenverfolgung über die Grenzen der eigen- und fremdbetriebenen Systeme hinweg. Die gute Nachricht: dazu gibt es heute bereits Lösungen, da dies z.B. im Bereich von verteilten Integrationsumgebungen (federated ESBs) hinsichtlich der Inter-/Intra-ESB Interaktionen und des Government, sprich der Ansätze zu Domain-bezogenen Service Registries, in konkreten Projekten erarbeitet wurde.
Die schlechte Nachricht: es wird durch Connectivity-as-a-Service oder Integration-as-a-Service Ansätze nicht weniger komplex – die gute Nachricht dazu im Kontext der schlechten: die konsequente Arbeit der letzen Jahre im Bereich SOA hilft hierzu die richtigen Antworten zu formulieren.
Doch nur Buzzword-Bingo?
Aber was hat das mit der heutigen Praxis zu tun? Wie steht es mit dem Nutzen? Dazu ein Beispiel eines Kunden:
Er hat seine Integrationslandschaft – sein Rückgrat seiner SOA – seit Jahren bei einem großen Outsourcing Partner im Betrieb und wechselt nun diesen. Dabei stellt er fest, dass viele der Applikationen Abhängigkeiten von anderen haben, welche nicht im Detail dokumentiert oder bewusst bekannt und damit auch nicht automatisiert sind. Somit muss nun eine entsprechende Analyse diese Details zusammentragen, die Implikationen und Abhängigkeiten bewerten, für den Übergang die notwendigen Infrastrukturbedingungen schaffen und den Aufbau im neuen Environment automatisiert generieren.
Wie sähe eine Lösungsmöglichkeit mit einer Private Cloud heute aus: Die oben beschriebenen Abhängigkeiten, etc würden heute in der privaten Cloud konfiguriert sein und im eigenen Rechenzentrum oder beim alten Partner betrieben werden – als elastische Workloads. Beim Wechsel könnte dies logisch als Einheit transferiert werden oder gar bei saisonalen Erfordernissen zusätzlich verteilt werden.
Kann dies nicht schon heute so erfolgen? Ja – zum Teil – über Virtualisierungslösungen (z.B. mit Systemen wie VMware, oder den entsprechenden IBM Hypervisors auf System p oder z, …)
Warum nur zum Teil, bzw. warum wird es nicht mehr und stringent genutzt? Weil viel Aufwand in die Erstellung der „Verskriptung“ zum Aufbau der Umgebung, zur Installation der Applikationsserver, zum automatischen Hoch- und Runterfahren der (Anwendungs-)Systeme, etc. zu stecken ist. – Viel Gelegenheit für Fehlersituationen, geringe Wiederverwendbarkeit in anderen Umbegungen – Viel Arbeit!
“Take this labour out!” – von Regenmachern und Wolkenbrüchen
Also braucht es auf die Virtualisierungslösungen aufbauende Konzepte und Produkte und hier setzt Cloud Computing an. Wenn dann noch die Applikationsschicht automatisiert verteilbar ist und die Services korrekt, sicher, zuverlässig und performant kooperieren können, kommen wir der schönen, neuen SOA/Cloud Welt einen Schritt näher. Die Architekturimplikationen sind mannigfach – doch SOA birgt die notwendigen Antworten und im Bereich des Deployments gibt es nun einen weiteren Schritt der helfen kann, das Platform-as-a-Service Versprechen einzulösen.
Die zum Thema Cloud Computing passende Produktankündigung auf der Impact 2009 in Las Vegas war WebSphere Cloudburst. Bei der IBM WebSphere CloudBurst Appliance handelt es sich um ein Komplettsystem, um die Installation und Inbetriebnahme (Roll Out) von neuen Applikationen in einer Cloud Infrastruktur zu vereinfachen und zu beschleunigen (Minuten vs. Wochen) und damit dieses Deployment produktiv und zuverlässig abzuwickeln. Die Grundlage hierfür ist, dass mit dieser Appliance die Images von virtuellen Maschinen komplett gemanagt werden können (insbesondere wichtig: die geschützte Speicherung), solange sie WebSphere Application Server Hypervisor Edition zur Grundlage haben. Diese Images repräsentieren also spezielle WebSphere Anwendungen.
Ist das reell? Reell ist die Anforderung, und die Umsetzung von Szenarien – wie im obigen Kundenbeispiel beschrieben, wird zeigen in welcher Konstellation dies Arbeit, Zeit und Kosten spart.
Es gab weitere Cloud Offerings auf der Impact – BlueWorks als cloud-basiertes Werkzeug zur Modellierung von Geschäftsprozessen und deren weitere Übersetzung in IT-gerechte Arbeitschritte, um unkompliziert diese Techniken auszuprobieren. Und IBMs Innov8 (gesprochen Innovate), ein „ernsthaftes Spiel“ zur Simulation realer Geschäftsabläufe, sowie weitere mit dem Cloud Computing zusammenhängende SaaS Ansätze wie z.B. LotusLive. Auf diese Punkte gehen wir zu einem späteren Zeitpunkt ein.
Schluss
SOA und Cloud Computing werden helfen, Verbraucher und Herausgeber von Diensten zusammenzubringen. Wie beschrieben kann dies enorme Implikationen auf die Art haben, wie wir Systeme bauen aber auch unsere Organisationen führen, denn solch eine Technologie kann neue unternehmerische Ansätze und organisatorische Transformationen ermöglichen.
P.S. Die Möglichkeiten an Flexibilität und Agilität die nun im Cloud Computing versprochen werden, lassen die Cloud als Erweiterung der SOA in die physische Welt erscheinen – ja, insofern „wächst SOA in die Cloud“ hinein!
