SOA ist eine Idee, keine Technik. Diese Botschaft kommuniziert die IT-Industrie schon seit längerem. Im gleichen Atem- zug überschüttet sie den Markt mit angeblich SOA-tauglichen Produkten und Dienstleistungen. Vereinfacht gesagt, bildet SOA ein breit angelegtes Rahmenwerk. Darin lassen sich Softwareservices erstellen, verwalten und kombinieren. Das große Ziel ist eine an Geschäftsprozessen ausgerichtete IT-Infrastruktur, die schnell auf veränderte Anforderungen reagiert. Weil Services mehrfach verwendet werden können, verspricht SOA zudem Kostenvorteile. Doch wo sollen Unternehmen beginnen? Erfordert SOA eine grundlegend veränderte IT-Landschaft? Müssen Geschäftsprozesse, Organisations- und Management-Strukturen neu definiert werden?

Mehr als zwei Jahre lang befragte die amerikanische CW-Schwesterpublikation "Infoworld" Spezialisten, die in ihren Organisationen SOA-Konzepte vorantreiben, unter ihnen Systemarchitekten, Entwickler und Projekt-Manager. Einige meldeten bereits erste Erfolge, beispielsweise eine leichtere Integration heterogener Applikationen oder die Wiederverwendung von Programmcode. Die Praxiserfahrungen ergänzten die US-Kollegen durch Empfehlungen von Analysten und anderen Experten.

Daraus entstand ein Ratgeber, der Planung, Aufbau und Verwaltung einer SOA in zehn Schritten beschreibt. Er enthält wesentliche Konzepte, die SOA zugrunde liegen, wenngleich die Reihenfolge der beschriebenen Stufen nicht auf jede Organisation passen muss. Das Procedere hängt davon ab, welche Bedingungen die Initiatoren vorfinden und was sie mit SOA erreichen wollen.

Think big, start small

Soll SOA Unternehmen agiler machen, muss eine Prozessbetrachtung am Anfang stehen, darin sind sich die meisten Experten einig. Je rascher sich die Anforderungen verändern, desto mehr profitieren Organisationen von den Vorteilen einer gut implementierten Servicearchitektur. "Beginnen Sie mit einem Topdown-Ansatz aus Sicht der Geschäftsprozesse", rät Jean-Michel Van Lippevelde von Accelior Consulting. Dabei gilt es einerseits, Verbesserungspotenziale zu identifizieren, andererseits aber auch, die nötige Rückendeckung aus dem Topmanagement zu gewinnen. "SOA ist ein Management- und kein Technologiekonzept", formuliert auch Thomas Helbig, CIO der Deutschen Post, die hierzulande zu den SOA-Pionieren zählt.

In der Umsetzung sollte sich der Blickwinkel wieder verengen. Big-Bang-Konzepte haben so manche ambitionierte SOA-Initiative scheitern lassen, berichtet Ed Horst vom kalifornischen Software- und Beratungshaus Amberpoint: "Die erfolgreichsten Einstiegsprojekte, die wir gesehen haben, waren klein angelegt. Es ging um sechs bis zehn Services, die zwei oder drei Dinge integrierten und innerhalb von etwa sechs Monaten abgeschlossen waren."

Viele Unternehmen machen die ersten Schritte Richtung SOA, indem sie wenige geschäftskritische Legacy-Anwendungen als Services zur Verfügung stellen. Andere Applikationen erhalten damit erstmals Zugriff auf wichtige Daten oder Funktionen der Altsysteme.

Fachabteilungen einbinden

Kein Projektverantwortlicher ist in der Lage, alle relevanten Geschäftsprozesse in Eigenregie zu sezieren. Von Beginn an sollte das Team die Fachverantwortlichen ins Boot holen. Sie wissen am besten, wie sich Prozesse restrukturieren lassen, und können den SOA-Spezialisten viel Arbeit abnehmen.

"Um die Prozesse zu verstehen, haben wir uns mit jeder Dienststelle einzeln zusammengesetzt", erläutert Dan Thomas, IT-Manager in der Verwaltung des US-Regierungsbezirks District of Columbia. Ziel des von ihm verantworteten Programms DC Stat ist es, die 65 Daten-Repositories der Regierungsbüros zu verbinden. Hohe Beamte sollen damit rasch Informationen für politische Entscheidungen abrufen können. Auch im SOA-Konzept der Deutschen Post spielen Fachabteilungen in der Umsetzung die entscheidende Rolle, erklärt Helbig. Sie sind Herren ihrer Anwendungsdomänen und Daten.

Bestands- aufnahme

Zu den SOA-Grundsätzen gehört es, vorhandene IT-Ressourcen in der Anfangsphase so weit wie möglich zu nutzen. Die dazu nötige Bestandsaufnahme lässt sich in einem mehrstufigen Prozess bewältigen. Zunächst geht es darum, Datenquellen und Anwendungen zu dokumentieren, die von der ersten SOA-Implementierung betroffen sind. Dazu gehören auch Services von Partnern außerhalb der Firewall, die gegebenenfalls anzubinden sind.

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.

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.

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 Her- steller.

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.

Sicherheit planen

SOA wird derzeit vorwiegend als unternehmensinternes Thema betrachtet. Dennoch gilt die Anbindung externer Partner als natürliche Ergänzung, die erhebliche Vorteile bringen kann. Spätestens an diesem Punkt müssen sich SOA-Verantwortliche intensiver mit Sicherheitsmaßnahmen beschäftigen, rät Heffner.

Für die Absicherung von XML-Messages hat sich die Industrie auf ein relativ simples Framework geeinigt: WS-Security gehört neben Soap (Simple Object Access Protocol) und WSDL (Web Services Description Language) zu den am häufigsten genutzten Web-Services-Spezifikationen. Das Problem: Notwendige Ergänzungen wie WS-Trust, WS-Secure Conversation oder WS-Security Policy befinden sich noch im Entwicklungsstadium. Keine dieser Spezifikationen wird bislang in der Praxis breit genutzt.

"Bis sich neue Standards und Vorgehensmodelle durchge- setzt haben, müssen wir mit Behelfslösungen auskommen", berichtet Bob Laird, Chief IT Architect beim US-amerikanischen Telefonkonzern MCI. Um den durch SOA verursachten XML-Datenverkehr abzusichern, nutzt er dedizierte Hardware wie die Firewalls des Spezial- anbieters Sarvega, der inzwischen von Intel übernommen wurde.

Messaging-Infrastruktur aufbauen

Eine weitere kritische Entscheidung dreht sich um die Frage, wie Nachrichten zwischen Services und Applikationen gesendet und empfangen werden. In kleineren SOA-Implementierungen genügen oft direkte synchrone XML-Verbindungen auf Basis der Soap-Spezifikationen. Steigen Komplexität und Umfang, benötigen Unternehmen asynchrone verlässliche Messaging-Funktionen. Weil die IT-Industrie dafür unterschiedliche Lösungen anbietet, droht Kunden auch hier die Abhängigkeit von einem Anbieter.

Eine ganze Reihe von Softwareprodukten bietet inzwischen diese Art von Messaging-Funktionen. Dazu gehören klassische EAI-Plattformen von Unternehmen wie Tibco oder Webmethods, aber auch um Integrations-Features ergänzte Application Server beispielsweise von Bea, IBM und Oracle. Mit dem Konzept des Enterprise Service Bus (ESB) kommt eine weitere Produktkategorie hinzu, die Anwender wie Hersteller sehr unterschiedlich definieren. Die meisten Produkte unterstützen mehrere Messaging-Protokolle, darunter Soap, JMS (Java Message Service) und MQ (Message Queuing). Hinzu kommen Adapter für Altanwendungen. Bis heute allerdings stellt jede Lösung auf unterschiedliche Weise sicher, dass Nachrichten ihr Ziel erreichen, monieren Experten. Die Verbreitung der Web-Services-Spezifikationen WS-Reliable Messaging werde daran kaum etwas ändern.

Service-Management einrichten

Sind mehr als eine Handvoll Services installiert, und sind einige davon geschäftskritisch, sollten sie ebenso penibel verwaltet werden wie jede wichtige Netzressource. Die IT-Industrie offeriert dazu Cockpit-ähnliche Lösungen. Sie überwachen beispielsweise Zustand und Leistungswerte der Services; sie prüfen, ob Service-Levels eingehalten werden, oder setzen Failover-Mechanismen auf.

Die Standardisierung in Sachen Service-Management steckt noch in den Kinderschuhen. Einen ersten Schritt unternahm das internationale Gremium Oasis im März mit der Anerkennung der Spezifikationen für Web Services Distributed Management (WSDM). Mit WS- Management bildet sich ein zweiter Standard heraus, der sich mit WSDM überlappt, aber die Verwaltung von Netzhardware in den Vordergrund stellt. Im Juni übergaben Intel, Microsoft und Sun Microsystems die Spezifikationen der Distributed Management Task Force.

Trotz des Engagements der Branchenschwergewichte haben Spezialanbieter die Nase vorn, wenn es um Web Services Management geht. Zu ihnen gehören Actional, Amber Point, Blue Titan und SOA Software. Doch die großen Netz-Management-Anbieter holen auf: BMC, CA, Hewlett-Packard, IBM und Novell unterstützen allesamt WSDM und sind dabei, Service-Management-Features in ihr Portfolio einzubauen. Hin- zu kommt Ciscos Initiative Application-Oriented Networking (AON), mit der das Unternehmen Netzgeräte um Service-Management-Fähigkeiten erweitern will.

Services orchestrieren

Fast jede SOA-Plattform bietet Methoden, um aus Services größere Anwendungen zusammenzufügen. Ob sie funktionieren, ist eine andere Frage. Um der SOA-Vision von prozessgestützten "Composite Applications" näher zu kommen, ist Service-Orchestrierung unabdingbar. In der Praxis verfolgen bislang nur wenige Unternehmen diesen Ansatz. Das liegt zum einen an der Komplexität des Vorhabens, zum anderen an den bislang eher bescheidenen SOA-Rollouts, die in der Regel auch ohne Service-Orchestrierung auskommen.

Der einzige verfügbare Standard in diesem Kontext heißt Business Process Execution Language (BPEL), obgleich klassische BPM-Lösungen schon seit Jahren proprietäre Orchestrierungsmodelle bieten. Doch BPEL allein scheint den Praxisanforderungen bislang nicht zu genügen.

Charles Stack, CEO des Registry-Anbieters Flashline, moniert, BPEL lasse menschliche Interaktionen außer Acht. Die Entscheidung, mit den Spezifikationen ausschließlich auf die Serviceorchestrierung zwischen Maschinen abzuheben, bezeichnet er als gravierende Schwäche: "Wir haben keine Kunden, die BPEL für etwas anderes als einfache experimentelle Zwecke einsetzen." Dies gelte selbst für fort- geschrittene Web-Services-Nutzer wie den Touristikdienstleister Sabre.

Abhilfe könnte eine Erweiterung schaffen, die IBM und SAP gemeinsam vorgeschlagen haben: BPEL4People. Ob sie SOA-Verantwortlichen das Leben leichter macht, lässt sich noch nicht beurteilen. In der Zwischenzeit könne es nicht schaden, sich mit proprietären BPM-Lösungen zu befassen, rät Scott Thompson, IT-Manager bei der Steuerberatungsgesellschaft H&R Block. In seinem Unternehmen habe der Einsatz von Tibcos BPM-Tool die Akzeptanz für SOA verbessert: "Bevor wir anfingen, Services zu einem Geschäftsprozess zu orchestrieren, konnte sich niemand so recht für SOA begeistern. Viele sahen darin ein IT-Projekt auf der unteren Ebene."