SOA polarisiert. Für die einen sind Wiederverwendbarkeit und Komponenten kaum mehr als alter Wein in neuen Schläuchen. CORBA, DCOM und Co. lassen grüssen. Für andere wiederum gilt SOA als das Allheilmittel schlechthin. Kein Weg führt an SOA vorbei, so der Schlachtruf. Recht haben beide. Richtig ist: Die grundlegende Idee hinter SOA ist nicht neu und unter dem Client-Server-Label seit vielen Jahren üblich. Ein Client (als Service Consumer oder auch als Service Requester bekannt) fordert von einem Server (Service Provider) Dienste an, die dieser durch die Abarbeitung bestimmter Funktionen bereitstellen kann. Rein technisch betrachtet kommt eine derartige Request-Reply-Sequenz in unterschiedlichen Ausprägungen vor.
Neu im Umfeld von Web Services ist die UDDI-Registry (Universal Description, Discovery and Integration). Der Verzeichnisdienst (Service Registry) definiert Methoden, um Web Services zu registrieren, Verfahren für einen kontrollierten Zugang zu einem Verzeichnisdienst und Kommunikationswege zur Distribution von Verzeichnissen. Kurz gefasst übernimmt UDDI in einer Service-orientierten Architektur die Aufgabe eines Brokers.
Für eine SOA-Architektur ist UDDI unabdingbar. UDDI ermöglicht Entwicklern, Applikationen, Geschäftslogik und Datenquellen als Web Services zu definieren und die notwendigen beschreibenden Informationen über ein UDDI-Verzeichnis zugänglich zu machen. SOA Integration Suites unterstützen UDDI, indem Entwickler Services aus unterschiedlichen Quellen zusammentragen und sie in neue oder vorhandene Anwendungen einbauen können. Auch darin zeigen sich die Prinzipien der Komponentenarchitektur und Wiederverwendbarkeit.
Nun ist UDDI eine der notwendigen, wenn aber auch nicht hinreichende technische Voraussetzung, die eine SOA erfüllen muss. Dies gilt zumindest dann, wenn SOA-Web-Services als Konstruktionsprinzipien verwendet werden. Dazu kommt SOAP (Simple Object Access Protocol). Als zentrales Web-Services-Protokoll ermöglicht SOAP den Applikationen, XML-Informationen via HTTP und JMS oder auch in Form von EJBs auszutauschen.
Aber auch Web-Services, SOAP und WSDL alleine machen noch keine SOA-Plattform aus. Dazu kommen weitere Bedingungen, die erfüllt sein sollten. Ohne die Unterstützung von BPEL sowie zusätzlicher Web-Services-Standards kommt keine SOA-Integration-Suite aus. Zu den wichtigsten Web Services in diesem Umfeld zählen: WS-Security (Integrität und Vertraulichkeit von Nachrichten sicherstellen), WS-Policy, WS-Policy Framework (Formulierung benutzerspezifischer Sicherheits-Policies), WS-Routing (asynchrones Weiterleiten von SOAP-Messages) und WS-Addressing (Austausch von Adressinformationen).
Im gesamten Bereich der Applikationsentwicklung – und darum geht es letztendlich ja auch bei SOA – hat sich seit einiger Zeit immer stärker Eclipse in den Vordergrund geschoben. Für Eclipse spricht die Standardisierung und Offenheit. Konzeptionell sieht SOA die Bereitstellung fachlicher Funktionalitäten in Form von Services vor, die in einer Eclipse-Umgebung modelliert werden. Konsequenterweise wird natürlich nicht nur einmal ein Prozess technisch modelliert, sondern er muss im laufenden Betrieb immer wieder angepasst und geändert werden. Genau das macht SOA aus: eine an den Geschäftsprozessen ausgerichtete IT-Infrastruktur, die schnell auf veränderte Anforderungen im Geschäftsumfeld reagieren kann.
Speziell die Modellierung bildet die Schnittstelle zwischen der IT und den Fachabteilungen. Softwarearchitekten planen und designen die technische Abbildung SOA-fähiger Geschäftsprozesse und Infrastrukturen. Ein wesentliches Kennzeichen dabei ist die Modularität und Flexibilität. Denn damit ist gewährleistet, dass die Prozesse bei Bedarf rasch an neue Gegebenheiten anzupassen sind. Den Input liefern die Fachabteilungen, die wiederum eigene Werkzeuge verwenden, um ihre Prozesse zu modellieren. Im Idealfall können diese Modelle dann recht komfortabel in die SOA-Entwicklungsumgebungen der IT-Abteilung übernommen werden. Diese enge Kopplung von Fachabteilung und IT ist von grosser Bedeutung, dreht sich doch bei SOA letztlich alles um Geschäftsprozesse.
Der Push in Richtung SOA kommt aus zwei Richtungen: Da sind erstens die externen Business-Treiber. Was heute im Wettbewerb um die Kunden zählt, sind Geschwindigkeit und Anpassungsfähigkeit, denn in den Prozessen steckt die Innovation. Die notwendige Flexibilität, um Prozesse optimieren und neu gestalten zu können, liefert in vielen Fällen die IT. Dazu kommen zweitens die internen Treiber. So fordern die Fachabteilungen immer wieder eine bessere IT-Unterstützung für ihre Geschäftsprozesse, die ihnen die IT in Form einer hochflexiblen SOA liefern kann. Überall in den Unternehmen, wo beide Entwicklungen zusammenkommen, hat man begonnen, erste SOA-Projekte umzusetzen. Die Initiative kann dabei von der Fachabteilung, aber auch von der IT ausgehen. Denn gerade im Softwarebereich hat die Technologie – verglichen mit den Client-Server-Architekturen der 90er Jahre – sehr grosse Fortschritte gemacht und ermöglicht beispielsweise unter dem Einfluss der Standardisierung bei Web Services überhaupt erst neue Geschäftsprozesse und -modelle.
Allerdings geht heute kaum ein Unternehmen das Risiko ein, SOA als Big Bang einzuführen. Vielmehr startet SOA in Form überschaubarer Lösungen für brennende Probleme, für Geschäftsprozesse, bei denen es kein «weiter so» geben kann. Bedingt durch knappe IT-Budgets werden erste Projekte oft bottom-up angegangen und müssen dann ihren Nutzen in einem konkreten Geschäftsprozess wie Supply Chain Management, Fulfillment oder Customer Relationship Management erweisen. Aus Sicht von Vitria hat sich gezeigt, dass sich SOA in solchen Fällen durch die Kosteneinsparungen und effizienteren Prozesse recht bald refinanziert.
SOA-Enabling von Anwendungen
Die konkreten Anlässe, SOA einzuführen, sind von Unternehmen zu Unternehmen und von Branche zu Branche sehr unterschiedlich. In einigen Fällen entsteht der Druck dadurch, schneller und preisgünstiger als der Wettbewerb neue Produkte und Services auf den Markt zu bringen. Man denke hier zum Beispiel an Festnetzbetreiber, die unter dem Titel Triple Play ihre Sprachnetze durch Breitbandservices und Video on Demand ergänzen und ausbauen.
Analog dazu könnten dies auch Kabel-TV-Anbieter sein, die ihre Netze technisch so auf- und umrüsten, dass ihre Kunden einen breitbandigen Webzugang erhalten, mit dem sie auch via Internet telefonieren können. Das sind Services, die man zuvor überhaupt nicht im Portfolio hatte. In solchen und ähnlichen Einsatzgebieten liefert SOA Antworten auf Businessfragen und trägt dazu bei, Geschäftsprozesse zu optimieren. Erweist SOA ihren Nutzen in den Prozessen und ist die Akzeptanz der Anwender vorhanden, wird sie sich immer neue Einsatzgebiete in den Unternehmen erobern. Hier dreht sich sehr viel um das Thema Prozesse, Prozessmanagement und messbare Verbesserungen.
Das Stichwort lautet dann Überwachung und Steuerung der Geschäftsprozesse, kurz: BAM, Business Activity Monitoring. Insbesondere dort, wo es auf Leistung, Skalierbarkeit und Zuverlässigkeit etwa bei lang laufenden Geschäftsprozessen ankommt, zählen Funktionen zum Monitoring und zur Steuerung der Prozesse, bekannt auch als SOA Governance. Solche Verhaltensregeln zum Business Process Management gelten für komplexe SOA-Infrastrukturen als einer der Ordnungsfaktoren und liefern zugleich die entscheidenden Steuerungsfunktionen. Ohne Regeln ist die viel zitierte Wiederverwendbarkeit von in Software gegossenen Business-Services nicht zu erreichen. Mehr noch: Ohne Wiederverwendbarkeit bleiben SOA-Vorteile wie Flexibilität und Effizienz in den Prozessen aus. Der Nutzen und das enorme Potential von SOA kommen dort zum Tragen, wo die in einer einheitlichen Umgebung mit Modellierwerkzeugen entworfenen Prozesse auch durchgängig überwacht und gesteuert werden können.
SOA baut in vielerlei Hinsicht auf Client-Server- sowie BPM-Fundamenten auf und erweitert diese um aktuelle Technologien wie Web Services. Die synchrone, häufig Service-orientierte Einbindung von Web Services wird dort, wo notwendig, um asynchrone Ereignis-gesteuerte Integrationsansätze ergänzt. Denn jeder einzelne Geschäftsprozess unterliegt einem kontinuierlichen Wandel, er wird ständig an neue Gegebenheiten angepasst. Allein schon deshalb ist es entscheidend, die erwarteten oder unerwünschten Events gezielt zu erfassen und sie in eine umfassende SOA zu integrieren. Bedingung dafür ist eine ganzheitliche und transparente Sicht auf die Geschäftsprozesse vom Anfang bis zum Ende.
In diesem Zusammenhang ist SOA Governance kein einmaliger Akt, sondern vielmehr ein kontinuierlicher Prozess. Er umfasst das Design und die Implementierung, aber auch die kontinuierliche Überwachung und Steuerung der wertschöpfenden Prozesse eines Unternehmens. Das Ziel ist eine effizientere Gestaltung und Durchführung von Geschäftsprozessen, die als Folge positive Auswirkungen auf den Unternehmenserfolg haben. Spürbare Effekte stellen sich nur dann ein, wenn zeitnah ein kontinuierliches Monitoring der Wertschöpfungskette stattfindet.
Thomas Egeling ist Presales Consultant bei Vitria Technology
in der Geschäftsstelle München.
