Die eigentliche Herausforderung einer Service-orientierten Architektur ist fachlicher Natur. So lautet der Tenor der bisherigen Artikel der SOA-Serie im CIO-Magazin. Die Entwicklung einer Service-Architektur und das Management von Services markieren folglich die wesentlichen Schritte in Richtung SOA. Wenn aber die fachliche Vorarbeit geleistet ist, spielt eben doch die Technik eine Rolle, um die mit SOA verbundenen Konzepte umzusetzen. Der Aufbau einer entsprechenden Plattform ist somit integraler Bestandteil einer SOA-Einführungsstrategie.
Auch wenn man berücksichtigt, dass sich eine SOA über Services definiert und nicht über die Plattform, sind die Anforderungen bei deren Realisierung einer entsprechenden technischen Infrastruktur nicht zu unterschätzen. Die Plattform muss dabei in der Lage sein, eine auf SOA basierende Business-Architektur und die mit SOA verbundenen strategischen Zielsetzungen bruchlos auf der Ebene der Technik abzubilden. Letztlich bedeutet dies, dass sich in der Ausgestaltung einer Plattform zentrale Prinzipien und Konzepte von SOA wiederfinden müssen.
Welche wesentlichen Faktoren dabei eine Rolle spielen, soll im Folgenden erläutert werden. Als Referenz dient dabei die SOA-Plattform SOPware, die von der Deutschen Post in eigener Regie entwickelt wurde und sich bereits seit 2001 im produktiven Praxiseinsatz befindet. Dabei sind zahlreiche Erfahrungen entstanden, die in die kontinuierliche Weiterentwicklung eingeflossen sind. SOPware steht stellvertretend für eine offene und verteilte SOA-Lösung, die konsequent auf Modularität und Standards setzt.
Plattform ohne Business-Logik
Betrachtet man die IT-Landschaft eines Unternehmens, so spielt eine SOA-Plattform darin eine bemerkenswerte Rolle. Sie enthält keinerlei Business-Logik und ist auf keine Geschäftsprozesse ausgerichtet. Letztlich hat sie lediglich die Aufgabe, Mediator für Services zu sein. Diese bieten die fachliche Funktionalität unterschiedlichster Applikationen auf transparente Weise an - und unterstützen somit in Kombination ganze Geschäftsprozesse. Um genau dies zu ermöglichen, hält eine SOA-Plattform indes umfangreiche und hoch spezialisierte Service-orientierte Funktionalität bereit.
Die Agilität des Business zu erhöhen, ist wesentliches Ziel einer SOA-Strategie. Dies kann indes nur gelingen, wenn starre Verknüpfungen zwischen Geschäftsprozessen und IT-Systemen schrittweise aufgelöst werden. Eine SOA-Plattform stellt dafür eine technische Infrastruktur bereit, auf deren Basis Services für eine schnellere und flexiblere Unterstützung heutiger und künftiger Geschäftsprozesse sorgen. Der damit verbundene Wandel ist dynamisch und wird vom Business getrieben. Flexibilität - auch im Sinne von Offenheit und Erweiterbarkeit - wird somit zum wichtigen Designkriterium für die Plattform selbst.
Gleichzeitig spielt eine SOA-Plattform die Rolle einer fundamentalen Integrationsinfrastruktur. Sie verknüpft heterogene Systeme und transformiert diese in den Kontext einer SOA. Das technische Umfeld einer SOA-Plattform befindet sich dabei in permanenter Veränderung. Eine SOA-Plattform muss damit paradoxerweise einerseits Wandel ermöglichen und andererseits ein hochgradig stabiles Element darstellen, um Wandel beherrschbar zu machen. Folgerichtig markieren Flexibilität und Stabilität die beiden zentralen Gestaltungspole einer SOA-Plattform.
Auf verteilte Strukturen bauen
Für die Ausgestaltung einer SOA-Systemarchitektur gilt dabei die bekannte Gestaltungsregel "Form follows Function". Es lohnt sich daher, einen kurzen Blick auf die funktionalen Abläufe in einer SOA zu werfen. Mit Service-Gebern und -Nehmern stehen dort zwei Teilnehmer im Vordergrund, zwischen denen klare Aufgabentrennung herrscht. Die SOA-Plattform tritt dabei als Vermittler auf; Gegenstand der Vermittlung sind Dienste. Das Anbieten, Nachfragen und Ableisten der Dienste erfolgt dabei auf Basis standardisierter Nachrichtenformate.
Daraus resultiert nun eine entscheidende Funktion einer SOA-Plattform: Sie koppelt die teilnehmenden Anwendungen voneinander ab - und schafft so die Basis für mehr Flexibilität. In Bezug auf Ausgestaltung einer SOA-Plattform entsteht daher - Form follows Function - ein nahe liegender Gedanke: Statt eine zentrale Struktur aufzubauen, die in sich starke Abhängigkeiten enthält, erscheint es logischer, eine SOA-Plattform im Sinne eines Frameworks modular, gekapselt und verteilt zu realisieren. Das Prinzip der Entkopplung wird somit bereits auf der Ebene der Systemstruktur verwirklicht.
Ein solches Konzept markiert einen deutlichen Unterschied zu "Hub and Spoke" oder zentralen Bus-Architekturen: So vermeidet ein verteiltes System erstens Engpässe, die durch zentrale Komponenten leicht herausgefordert werden können. Zweiter Vorteil eines Frameworks ist dessen Modularität, das heißt, Bestandteile sind leichter austausch- und erweiterbar. Dies hat auf der technischen Ebene eine gesteigerte Flexibilität zur Folge - was mithin eine der zentralen Zielsetzungen einer SOA-Strategie ist.
Entkoppeln als Gestaltungsprinzip
Entkopplung als Gestaltungsprinzip einer SOA-Plattform ist nicht in struktureller und in funktionaler Hinsicht ein entscheidendes Kriterium. Grundlage dafür ist zunächst d ie k onsequente T rennung z wischen SOA-Implementierung und Business-Logik. Darüber hinaus gilt diese Anforderung aber auch für die Funktionalität der SOA-Plattform selbst. Ziel ist dabei, dass Services ihre Arbeit unabhängig von der jeweiligen technischen Implementierung verrichten können.
Dies bezieht sich insbesondere auf die erforderliche Funktionalität, die einen beliebigen Service-Aufruf flankiert. Dazu gehören etwa das Auffinden von Services, die Autorisierung oder das Aushandeln von Qualitätsparametern - und vieles mehr. Wenn nun jeder Service diese umfangreichen Details beachten müsste, wurde ein wesentliches Ziel von SOA verfehlt: Eine Plattform, in der Service-Funktionalität "hart verdrahtet" ist, leistet tatsächlich lediglich einen Beitrag zur Standardisierung auf der technischen Ebene. Ein Framework im Sinne von SOA, das Änderungen auf schnelle und flexible Weise integriert, repräsentiert eine solche Plattform indes nicht.
Um Entkopplung also auch auf der Ebene der Funktionalität zu erzielen, nutzt die SOA-Plattform der Deutschen Post zwei einfache Konzepte. Erstens ist die erforderliche SOA-Funktionalität selbst in Form von Services implementiert. SOPware unterscheidet dabei nur zwischen Business- und technischen Service-Teilnehmern, arbeitet also in sich Service-orientiert. Zweitens sorgt das Framework durch Policies für eine transparente Mediation von Services. Konfigurationsdetails sind somit unabhängig von Services, Qualitätsparameter können zwischen Teilnehmern des Frameworks selbstständig ausgehandelt werden.
In Bezug auf die Implementierung wird häufig die generelle Technikunabhängigkeit einer SOA hervorgehoben. Generell ist dies zwar richtig, in der Praxis gestalten sich die Dinge indes differenzierter. Insbesondere ein heterogenes, verteiltes und anspruchsvolles Unternehmensumfeld stellt spezifische Anforderungen, an denen sich die gewählte Implementierungsstrategie ausrichten muss.
Robust gegen technischen Wandel
Konkret gilt es dabei zu bedenken, dass eine SOA-Plattform eine in hohem Maße geschäftskritische Komponente darstellt. In einem Maximalszenario kann etwa die gesamte Kommunikation zwischen den Applikationen eines Unternehmens über eine SOA vermittelt werden. Daraus resultieren nicht nur hohe Anforderungen an Performance und Ausfallsicherheit, sondern auch an die langfristige strategische Stabilität des Frameworks. Faktoren, die dabei eine Rolle spielen, sind Robustheit gegenüber dem permanenten Wandel von Technologie, der umgebenden Applikationslandschaft sowie vor Veränderungen in den Produktstrategien der Herstellerunternehmen.
Aus diesen Überlegungen heraus hat die Deutsche Post bei der Realisierung von SOPware auf ein Best-of- Breed-Konzept g esetzt. Die Gefahr, in eine zu große Abhängigkeit von einem Hersteller zu geraten, wird damit wirkungsvoll verhindert. Zusätzliche Flexibilität wird dabei durch den konsequenten Einsatz offener Standards erzielt. Komponenten werden somit nicht nur leichter austausch- und erweiterbar, auch die Wahlfreiheit wird insgesamt gesteigert. Auswirkungen hat das insbesondere auf die Reaktions- und Lieferfähigkeit gegenüber spezifischen Anforderungen der Geschäftsbereiche - die viel beschworene "Time to Market" wird signifikant verbessert.
Für den Ansatz der Deutschen Post, eine SOA-Plattform aus eigener Kraft zu entwickeln, gab seinerzeit nicht nur die mangelnde Verfügbarkeit alternativer Lösungen im Markt den Ausschlag. Vielmehr spiegelt sich darin die Überzeugung wider, dass ein offenes SOA-Framework die skizzierten Anforderungen an die Flexibilität bei gleichzeitiger Stabilität mit Abstand am besten erfüllt. Die Frage nach dem "Make or Buy" würde die Deutsche Post daher auch heute durchaus in ähnlicher Weise beantworten wie im Jahr 2001.
Eine aus heutiger Sicht für viele Anwender interessante Alternative könnte indes mit der Fragestellung "Buy or Use" verbunden sein. Konkret heißt das: Soll eine herstellerspezifische Lösung zum Einsatz kommen, oder soll das SOA-Framework durch Nutzung von Open Source-Komponenten im Rahmen einer Best-of-Breed-Strategie realisiert werden? Schließlich hält die Community heute ernst zu nehmende und ausgereifte Alternativen bereit, die sich in Bezug auf Funktionalität, Support und insbesondere die Unterstützung offener Standards keinesfalls hinter proprietären Lösungen verstecken müssen.
Post nutzt Open Source
Der Einwand höherer Integrationsaufwände von Open Source greift hierbei nicht. Denn ob herstellerspezifisch oder nicht: Die Integration einer SOA-Lösung und deren Anpassung auf den spezifischen Bedarf des Unternehmens werden auf jeden Fall zu leisten sein. In Bezug auf die Total Cost of Ownership kann Open Source hier sogar punkten. Zuletzt verbleibt somit die Wahl einer konkreten Lösung bei den Unternehmen - und kann primär aus strategischen Motiven heraus getroffen werden. Wie gut SOA-Konzepte in den jeweiligen Lösungen umgesetzt worden sind, kann dabei eine wesentliche Rolle spielen. Ein intensiver Blick unter die Haube lohnt sich daher aus den Erfahrungen der Deutschen Post heraus auf alle Fälle.