Die Umsetzung einer Service-orientierten Architektur (SOA) verlangt die enge Zusammenarbeit zwischen Fachabteilungen und der IT. Vor Projektstart müssen sich Mitarbeiter finden, die in der Rolle eines Business Analyst die fachlichen Anforderungen aufnehmen und in eine fachliche Spezifikation für die IT übersetzen. Ebenso sind Architekten nötig, die im weiteren Verlauf beispielsweise sicherstellen, dass sich Komponenten wiederverwenden lassen und eine einheitliche technische Basis entsteht.

Der eigentliche SOA-Lebenszyklus beginnt mit einer "Discovery-Phase". In ihr identifiziert das Projektteam zunächst innerhalb des Unternehmens die wichtigsten zentral nutzbaren fachlichen Funktionen und legt gemeinsam mit dem Management die Projektziele fest. Die Verantwortlichen sollten zunächst an ausgewählten Geschäftsabläufen aufzeigen, wie diese Prozesse unter Einbeziehung zentraler Services effizienter ablaufen könnten. In der darauf folgenden "Assessment-Phase" sind dann die konkreten fachlichen Abläufe zu identifizieren. In der Praxis führt dies meist zu einem Business-Reengineering-Projekt mit Hilfe externer Berater. Dabei kann dass Verfahren beschleunigt werden, wenn sich bereits vorhandene Prozessdokumentationen nutzen lassen.

Suche nach dem Business-Service

Entscheidend für den Erfolg der SOA-Implementierung ist die präzise Definition ihrer Business-Services. Dies gelingt nur, wenn sich das SOA-Team nicht mit der Architektur und der darunter liegenden Technik beschäftigt, sondern vor allem herausfindet, welche Services ein Unternehmen wirklich braucht. Berechnungen des gewünschten Return on Investment fallen leichter, wenn der Bedarf bekannt ist und sich der konkrete Nutzen aufzeigen lässt.

Bottom-up-Ansatz

Ein Business-Service kann beispielsweise die unternehmensweite Pflege von Kundendaten beinhalten: Der Dienst stellt hierfür eine zentrale Schnittstelle bereit, die je nach Inhalt der Anfrage Kundeninformationen anlegt, ändert, löscht oder auch abfragt. Dieser Bottom-up-Ansatz führt schnell zu ersten Erfolgen, da mit vorhandenen IT-Systemen ein konkretes Fachproblem umgesetzt wird. Als Vorbild dient die Automobilindustrie: Hier hat sich der Plattformgedanke längst durchgesetzt. Die Hersteller haben zentrale Komponenten identifiziert, die sich - gegebenenfalls leicht angepasst - immer wieder in neuen Fahrzeugmodellen verwenden lassen. Ein vergleichbares Ziel verfolgen Organisationen, die eine SOA implementieren möchten.

Der Zeitbedarf für die ersten beiden Zyklen ist überschaubar: für das Kick-off-Meeting mit dem Projektteam sind etwa zwei bis vier Tage nötig, für das anschließende Assessment drei bis vier Wochen. Das Ergebnis ist eine klare Beschreibung von Diensten und Prozessen, die innerhalb der Organisation am meisten genutzt werden. Für die weitere Umsetzung ist es dann notwendig, dass Unternehmen eine einheitliche Technik für alle Schnittstellen einführen - wie beispielsweise Web-Services. Nur so lassen sich Services in unterschiedlichen Szenarien wiederverwenden, wie es der SOA-Idee entspricht. Die zu diesem Zweck eingesetzten Integrations- und Modernisierungswerkzeuge zur Legacy-Integration müssen in der Lage sein, alle im Unternehmen vorhandenen Systeme abzudecken. Andernfalls droht innerhalb der SOA-Welt eine Zwei-Klassen-Gesellschaft mit angebundenen und isolierten Systemen.

Für die Anbindung von Bestandssystemen auf Mainframes gibt es verschiedene Ansätze: den direkten Zugriff auf die Daten oder den indirekten über die entsprechenden Anwendungsfunktionen. Im SOA-Kontext wird der zweite Ansatz oft bevorzugt, weil sich die bereits vorhandene Geschäftslogik und die Integritätsregeln verwenden lassen.

Benutzerdialoge simulieren

Im Idealfall ist ein Bestandssystem bereits in einzeln aufrufbare Programmfunktionen strukturiert, die sich zur Verwendung als Services in einer SOA-Plattform eignen und nur noch mit den entsprechenden Standardschnittstellen "umhüllt" werden müssen. In der Praxis finden sich jedoch häufig über Jahre gewachsene monolithische Systeme. Ein Reengineering dieser Systeme in modulare Services ist aufwändig und nicht ohne Risiko. Für die Übergangszeit und für weniger strategische Lösungen bietet sich die Simulation eines Benutzerdialogs an: Immer dann, wenn der Quellcode oder die Programmierer, die sich damit auskennen, nicht mehr verfügbar sind, ist die Integration über die Benutzerschnittstelle der einzig mögliche Weg, um Legacy-Systeme in eine SOA-Welt zu integrieren. Das Ergebnis dieser Phase des "SOA-Enablements" ist eine Vielzahl fein granularer Komponenten.

Komponieren, orchestrieren

Die anschließende "Leverage-Phase" im Lebenszyklus besteht nun darin, die tatsächlich benötigten Services mit Hilfe einer Kompositions- und Orchestrierungsschicht zusammenzufügen. Alle IT-Funktionen, die ein Mitarbeiter für einen fachlichen Ablauf nutzt, werden nun in der SOA-Plattform bereitgestellt. Über einen Enterprise Service Bus lassen sich Funktionen zu einem neuen Business-Service komponieren - beispielsweise, damit der Anwender nicht mehr auf verschiedene Bestandssysteme oder Bildschirmmasken zugreifen muss, sondern nur das Ergebnis seiner Anfrage präsentiert bekommt. Dazu ist es notwendig, Business Services so intelligent zu implementieren, dass sie abhängig vom Inhalt einer Anfrage dynamisch entscheiden, welche Backoffice-Systeme wie zu bedienen sind.

Ajax hilft am Frontend

Aus diesen Services generieren modellbasierende Werkzeuge orchestrierte Composite Applications. Letztere sind eine neue Art von Anwendungen, die sich durch eine hohe Flexibilität auszeichnen und mit interaktiven Benutzerschnittstellen aufwarten, die beispielsweise moderne Ajax-Technik (Asynchronous Java Script and XML) nutzen. Werden in eine SOA auch öffentlich zugängliche Services wie beispielsweise "Google Maps" oder von Amazon.com in die eigenen Systeme eingebunden, entsteht eine neue Generation von offenen Geschäftsanwendungen: die "Mashups". Diese Anwendungen laufen ohne Installationsaufwand im Browser und verhalten sich interaktiv wie eine Desktop-Anwendung. Die Ajax-Technologie eignet sich zur Realisierung solcher Applikationen sehr gut. Entwickler sollten jedoch auf die manuelle Ajax-Programmierung wegen der hohen Komplexität verzichten und auf Frameworks setzen, die auf Basis visueller Modelle Ajax generieren und verwalten.

Müssen Composite Applications mehrere Rollen und Prozessschritte unterstützen, sollten Unternehmen Systeme für das Business-Process-Management (BPM) einsetzen. Über diese erhalten sie eine geschäftliche Sicht auf die Abläufe. So lassen sich beispielsweise alle Aktivitäten modellieren und automatisieren, die zum Beantworten einer Kundenanfrage notwendig sind. Die notwendige Verbindung zu den IT-Systemen wird durch die Verknüpfung der Business Services mit dem BPM-System geschaffen.

Auswahl der Granularität

Wie viele Komponenten innerhalb eines Geschäftsprozesses über einen Enterprise Service Bus zu einem fachlichen Service zusammengefasst werden, hängt von deren Granularität ab. Letztere zu bestimmen ist Erfahrungssache. Es gibt jedoch zwei Randbedingungen, die als Hilfestellung dienen können: Sind die Antwortzeiten einer auf SOA-Komponenten basierenden Anwendung gut, die Wiederverwendbarkeit der Komponenten aber stark eingeschränkt, dann sind die Services zu grob granular.

Sind auf der anderen Seite die Services gut wiederverwendbar, stimmt die Performance aber nicht mehr, dann ist das System zu fein granular entworfen. Unterstützung für das Feintuning finden Unternehmen bei Beratern oder Herstellern, die Erfahrung mit der Umsetzung von SOA-Projekten haben.

Wichtig ist in dieser Phase, dass Projektverantwortliche über den Tellerrand der IT-Implementierung schauen und Erfolge auf der Geschäftsebene messbar machen. Dies kann auf Basis von Service-Level-Agreements oder tatsächlichen Bearbeitungszeiten erfolgen. Dieser Schritt sollte schon an dieser Stelle fest im Projektplan vorgesehen werden.

SOA-Architekturen optimieren

Bei fortgeschrittenen SOA-Projekten lassen sich die entstehenden Architekturen nicht mehr manuell verwalten. Damit ist eine weitere Phase im SOA-Lebenszyklus erreicht: Jetzt sind Management und Governance gefragt. Beispielsweise werden Informationen erforderlich, wie sich der Ausfall eines Dienstes auf das laufende Geschäft auswirkt. Weiterhin ist zu prüfen, wer Services ändern kann und ob Anwender und Partner die erforderlichen Zugriffsberechtigungen haben. Auch die Servicequalität und die Lebensdauer einzelner Komponenten sind festzuhalten. Spätestens in dieser Phase sollte ein SOA-Bibliothekar oder zu neudeutsch Cybrarian (abgeleitet von dem Librarian im Cyberspace) das Projekt unterstützen. Dieser Mitarbeiter kennt, verwaltet und kommuniziert alle Details zu den vorhandenen Systemen und Services. Er erhöht durch sein Engagement die Sichtbarkeit der SOA-Projekte im eigenen Unternehmen und hilft bei der Definition eines Regelwerks.

Die notwendigen Werkzeuge hierfür sind in SOA-Registries und Repositories enthalten, d ie mehr als ein Verzeichnis gemäß den Spezifikationen Universal Description, Discovery and Integration (UDDI) bieten. So erfasst ein Repository sämtliche SOA-Komponenten, speichert Prozesse, Regeln, Service-Level-Agreements, Verfügbarkeiten, Zugriffsrechte und weitere Details der Infrastruktur. Erst mit Hilfe dieser Management-Infrastruktur sind Organisationen überhaupt in der Lage, den gesamten SOA-Lebenszyklus zu beherrschen.

Prozessschritte neu ordnen

In der Optimierungsphase schauen sich Unternehmen die zuvor definierten Geschäftsziele an und erarbeiten Möglichkeiten, die fachlichen Abläufe weiter zu verbessern. Dies erfolgt auf Grundlage der Ergebnisse, die die Measurement-Phase liefert. In der Praxis werden hier Prozessschritte neu angeordnet, weitere IT-Systeme hinzugeschaltet und die Ressourcen für einzelne Abläufe justiert.

Ein wesentliches Fazit aus SOA-Kundenprojekten ist, dass die Frage nach Management und Governance von SOA-Infrastrukturen gerne verdrängt wird: Wer sich erst damit beschäftigt, wenn die Komplexität nicht mehr zu beherrschen ist, wird mit zusätzlichen Projektkosten oder Verzögerungen bestraft. (as)