Im zweiten Schritt folgt eine Inventarisierung sämtlicher Hard- und Softwaresysteme, die in einer SOA eine Rolle spie- len könnten. Diese Herkulesaufgabe müsse nicht unbedingt vor dem ersten Projekt in Angriff genommen werden, raten Experten. Soll SOA aber später über ein eng eingegrenztes Projekt hinausgehen, ist eine vollständige Bestandsaufnahme unabdingbar.
SOA umfasst eine breite Palette an Techniken: Werkzeuge, um Services zu erstellen und anzubieten; eine Registry, in der Dienste wiedergefunden werden können; eine Messaging-Infrastruktur, über die Services und Anwendungen kommunizieren; Tools, die eine Orchestrierung der Services erlauben, sowie Funktionen für das Service-Management. In komplexeren Umgebungen kommen Business-Process-Management (BPM-) und Business-Activity-Monitoring- (BAM-)Systeme hinzu. Darüber hinaus sind Web-Services-Interfaces bestehender Anwendungen zu berücksichtigen.
Nutzen Unternehmen überwiegend Standardsoftware, sollten sie sich beim Hersteller über dessen SOA-Pläne und -Fähigkeiten informieren. Die großen ERP-Anbieter, allen voran SAP und Oracle, haben längst eine SOA-Roadmap für ihre Kernprodukte vorgelegt.
4. Erste Services einbinden
Sind Geschäftsprozesse und IT-Ressourcen analysiert, kann das SOA-Team einen Bereich für ein Pilotprojekt auswählen. Im ersten Schritt empfiehlt es sich, redundante Logik in den beteiligten Applikationen zu identifizieren und diese als Service zu definieren. Zu entscheiden ist dann, wer den Service erstellt und inwieweit dazu Tools benutzt werden.
Als typisches Beispiel gilt das Anlegen einer Kundendatei - eine Funktion, die mehrere Altanwendungen häufig auf unterschiedlichen Wegen erledigen. Würde sie in einem separaten Service abgebildet, den alle Applikationen gemeinsam nutzen, ließen sich Redundanzen auflösen und der Wartungsaufwand vermindern.
Welche grundlegenden Eigenschaften charakterisieren Services im Sinne von SOA? Sie sind lose gekoppelt, wiederverwendbar und auffindbar, lautet eine ebenso gängige wie unvollständige Definition. SOA-Praktiker ergänzen, ein Service solle zudem "grobkörnig" gestaltet sein, also eher einen kompletten Schritt innerhalb eines Geschäftsprozesses abbilden als einen technisch definierten Teil einer Anwendung. Auf diese Weise lasse sich die geforderte Wiederverwendbarkeit einfacher realisieren.
5. Registry installieren
In vielen Unternehmen markiert die Einrichtung einer Registry zum Auffinden der Services den Beginn ihrer SOA-Initiative. Anhand von Metadaten können Entwickler prüfen, ob ein bestimmter Service bereits erstellt wurde, und so unnötige Arbeit vermeiden. Diese Minimalanforderung lässt sich auch ohne größeren Aufwand erfüllen, erläutert Timothy Vibbert, Senior Systems Engineer bei Lockheed Martin: "Es kann einfach eine Website sein, die Services auflistet."
Steigt die Anzahl der Dienste sowie der Anwendungen, die sie nutzen, kommt das SOA-Team um eine "echte" Registry nicht herum. Die Spezifikationen des Verzeichnisdiensts "Universal Description, Discovery and Integration" (UDDI) haben sich dafür als Grundlage durchgesetzt. Die meisten kommerziellen Registries oder Repositories gehen in ihrem Funktionsumfang über UDDI hinaus. In der Praxis verschwimmen zudem die Grenzen zwischen Registry und klassischem Repository. Letzteres hält die beschriebenen Services zugleich vor.
Die Auswahl einer Registry stellt Unternehmen einmal mehr vor die Entscheidung, ob sie in Sachen SOA auf das Portfolio eines einzigen Anbieters setzen oder Best-of-Breed-Lösungen bevorzugen sollen. Alle großen Plattformanbieter, darunter Bea, IBM, Oracle und Sun, bewerben eigene Registry- oder Repository-Produkte innerhalb ihrer SOA-Frameworks. Spezialanbieter wie Above All Software, Flashline oder Systinet halten dagegen: Beim Aufbau der Infrastruktur für SOA sollten sich Anwender keinesfalls auf eine proprietäre Plattform eines Anbieters einlassen, lautet ihr Argument. Andernfalls drohe die Abhängigkeit von einem Hersteller.
6. Governance regeln
Registries sind mehr als Verzeichnisse, in denen sich Services anhand von Metadaten auffinden lassen. Sie dienen zugleich als Governance-Instrument der SOA-Infrastruktur. Das IT-Team benennt darin beispielsweise die "Besitzer" der Services, verwaltet unterschiedliche Versionen und stellt sicher, dass Unternehmensvorgaben eingehalten werden.
In diesem Kontext lässt sich Governance als eine Kombina- tion von Workflow-Regeln definieren: Wer zeichnet für welche Services verantwortlich? Was geschieht, wenn Qualitätsprobleme auftreten? Auch die Definition von Serviceschnittstellen und deren Verwaltung gehört dazu. Solche Definitionen können sich als Gegenstück zu einem IT-Organigramm entwickeln. Experten prognostizieren, dass Service-orientierte Architekturen herkömmliche Organisationsstrukturen allmählich auflösen. Zu Ende gedacht, bilden Serviceschnittstellen ein Abbild des Unternehmens, kommentiert Randy Heffner, Vice President beim Marktforschungs- und Beratungshaus Forrester Research.