Ein Spiel zwischen Genie und Wahnsinn attestierten Sportinteressierte gerne dem Handballer Christian Zeitz bei der WM in Deutschland. Vergleichbares lässt sich für das Paradigma der Service-orientieren Architektur (SOA) festhalten. Es verspricht, den Umgang mit Software genial zu vereinfachen; doch jede detaillierte Betrachtung gleitet schnell ins Wahnwitzige ab. „SOA gilt als Synonym fürs Moderne, aber auch Unbeherrschbare“, sagte Rüdiger Spies auf der vom CIO-Schwesterblatt Computerwoche veranstalteten Fachkonferenz „SOA-Initiative 2007“ (www.computerwoche.de/zone/soa2007).
"Massives Herstellermarketing und das immer noch stark technisch geprägte SOA-Vokabular verunsichern die Verantwortlichen in Unternehmen“, sagt IDC-Analyst Spies. Allerdings werden Analysten, Berater und Hersteller nicht müde, die betriebswirtschaftlich-fachliche Perspektive als entscheidenden Faktor für eine erfolgreiche Umsetzung von SOA zu propagieren. Für Vorstand Wolfram Jost von IDS Scheer steht fest, dass SOA-basierende Anwendungen künftig von betriebswirtschaftlichen Prozessbeschreibungen und -modellen gesteuert werden: "SOA beginnt und endet bei den Prozessen.“ Selbst Analyst Spies kommt in seiner allgemeinen SOA-Definition ohne den Zusatz "Business-orientiert“ nicht aus.
Doch bei der mittlerweile ermüdenden Diskussion über die betriebswirtschaftlich-fachlichen Prozesse und Services: Ganz ohne Technik geht es nicht. Ein Geschäftsablauf muss in einer technischen Komponente abgebildet sein. Diese Komponente kann wiederum aus mehreren Services bestehen. Um nun das Ziel von SOA - eine flexibel anpassungsfähige Software - zu erreichen, sind außerdem eine Entwicklungsumgebung für die Erstellung von Services sowie eine Ablaufumgebung für den sicheren Betrieb der Programme nötig. Die ITAssets sollen mittels dieser durchgängigen Technik - von der Modellierung bis hin zum ablauffähigen Service - häufiger wiederverwendet werden, und die kontinuierliche Prozessverbesserung kann durch SOAbasierte IT besser unterstützt werden, so versprechen es die Marketing-Folien der Hersteller.
Ob das in der Praxis allerdings funktioniert, muss erst noch bewiesen werden, wie Wolfgang Beinhauer vom Fraunhofer-Institut IAO erklärt: "Die effiziente Gestaltung von Services im Hinblick auf spätere Änderungen der Einsatzzwecke ist weitgehend unerprobt“, sagt der Forscher und warnt davor, anders lautende Herstellermeldungen für bare Münze zu nehmen. Es müsse großer Aufwand betrieben werden, um die benötigten Software-Services zu erstellen und zu betreiben. "SOA braucht neben Teilen wie Service- fähigen Anwendungen und einer neuen Denke vor allem ein stabiles IT-Fundament: einen ‚Baukasten‘, dessen Elemente aufeinander aufbauen und einander ergänzen“, sagt Markus Görg, Solution Architect bei der Danet GmbH. Sowohl in horizontaler als auch in vertikaler Richtung müssen die Komponenten miteinander interagieren: vom User-Frontend bis zur Datenbank, zwischen Applikationen und innerhalb einer Anwendung.
Gedränge auf dem SOA-Markt
Kurzum: Eine SOA ist komplex. Dieses facettenreiche Aufgabenspektrum einer SOA ist zugleich der Auslöser für das Engagement unterschiedlichster Hersteller, ihre Offerten in Richtung SOA auszubauen. Insbesondere die etablierten Softwareanbieter gehen dazu über, den Funktionsumfang ihrer Produkte gezielt durch Zukäufe und Weiterentwicklung zu vollständigen Suites auszubauen, die allen Ansprüchen – auch Richtung Business Process Management (BPM) – genügen sollen.
"In den vergangenen zwei Jahren hat die Zahl der SOA-Anbieter stark zugenommen, und es tummelt sich eine Vielzahl unterschiedlicher Produkt- und Serviceanbieter auf dem Markt“, erklärt Beraterin Melanie Mack von Pierre Audoin Consultants (PAC). Der deutsche SOA-Markt, der sich aus Projektgeschäft und Infrastruktursoftware sowie Tools (Produktumsatz) zusammensetzt, weist nach Schätzungen von PAC 2006 ein Volumen von rund 384 Millionen Euro auf - Tendenz stark steigend. Die Marktbeobachter von IDC schätzen den Umsatz mit SOA-fähiger Software 2006 weltweit auf rund 2,3 Milliarden Dollar, 2008 sollen es bereits 6,4 Milliarden sein.
So verwundert es nicht, dass große Anbieter eine SOA-Roadmap für ihre Produkte vorgelegt haben. Key Player sind Anbieter wie SAP, IBM, Oracle, Microsoft und die Software AG. Aber auch Spezialisten wie Tibco, Webmethods, Bea Systems, Sun (Seebeyond), Vitria und Iona Technologies spielen eine wichtige Rolle. Die Vielfalt im SOA-Markt bewog die Analysten von Forrester Research, die bisherige Kategorie Integrationssoftware nun in Integration-Centric Business Process Management Suites (IC-BPMS) umzutaufen.
SOA braucht zentrale Kontrollinstanz
Gemeinsamer Nenner der Integrations-Suites ist in der Regel ein sogenannter Enterprise Service Bus, der als technische Kommunikationsinfrastruktur einer SOA die Komposition und Orchestrierung von Services begleitet. Zu den Spezialisten, die von Beginn an mit einem „nackten“ ESB-Angebot am Markt agieren, zählt Forrester-Analyst Ken Vollmer neben Cape Clear, Polar Lake, Progress-Tochter Sonic oder Iona auch Größen wie Bea oder IBM, deren ESB aber auch als Bestandteil umfangreicher Suites vermarktet wird.
Eine gewichtige Komponente dieser Suites sind die so genannten Registries und Repositories, die der Steuerung und Kontrolle - neudeutsch Governance - einer SOA und deren Services dienen. "Strategische und bereichsübergreifende Ansätze wie SOA benötigen eine zentrale Kontrollinstanz, die sicherstellt, dass strategische Ziele, Architektur und Projektfortschritte im Einklang zueinander stehen“, erläutert dazu Ivo Totev, SOA-Spezialist bei der Software AG.
Eine Registry stellt – vergleichbar einem Branchentelefonbuch - ein Verzeichnis verfügbarer Dienste bereit, aus dem neben der Adresse nur wenige zusätzliche Informationen (Metadaten) über einen Dienst hervorgehen. Ein Repository hingegen speichert und kategorisiert Dienste zusammen mit ihren Eigenschaften sowie zusätzlichen Informationsobjekten. Zugleich fördern sie eine systematische Wiederverwendung und vermeiden einen kostenintensiven Service-Wildwuchs.
Spezialisten werden aufgekauft
Analysten und Anbieter sind sich einig: Registries und Repositories sind im Hinblick auf die angeführten SOA-Ziele wichtige Komponenten. Dass die Spezialisten im Markt weitgehend ihre Unabhängigkeit verloren haben, darf durchaus als ein Beleg für die hohe Bedeutung gewertet werden. So verschaffte sich BEA mit dem Kauf von Flashline ein Repository-Angebot zur Unterstützung des Designprozesses. Das kürzlich von IBM vorgestellte Websphere Registry and Repository (WSRR), das auf der Rational-Technik sowie Webify und Unicorn basiert, unterstützt die Optimierung des Produktivbetriebs (Runtime). Webmethods hat nach der Übernahme des Registry-Anbieters Infravio mit Cerebra-Repository-Technik zum Management von semantischen Inhalten erworben. Repository-Spezialist Systinet findet sich nach dem im Januar 2006 erfolgten Kauf durch Mercury nun plötzlich in HP-Armen wieder, da die US-Firma den neuen Eigner übernahm.
Die Fülle des SOA-Angebots macht die Auswahl schwierig. Ein CIO muss sich entscheiden, ob er einer Komplettlösung oder einer Best-of-Breed-Lösung den Vorzug geben will. Komplettlösungen bergen stets die Gefahr der Abhängigkeit und Funktionsüberfrachtung. Software auf Basis dieser Frameworks lässt sich in anderen Umgebungen oft nicht verwenden. Hinzu kommt, dass die Integration einzelner Bausteine einer Suite untereinander insbesondere bei Zukäufen nicht selten zu wünschen übrig lässt.
Probleme, die es vor SOA nicht gab
Auch liefert der Open-Source-Markt für technisch geprägte SOA-Projekte inzwischen konkurrenzfähige Alternativen: Red Hat (JBoss ESB), Logicblaze (SOA-Plattform Fuses), Mulesource (J2EE-ESB Mule), das von Sun initiierte Projekt Open ESB sowie Ionas Celtix.
Trotz Fusionen wird der Markt bunter. Die einschlägigen Standardisierungsgremien bieten bezüglich Auswahlkriterien noch wenig Orientierung. "Einige sind bisher nur Ideen“, urteilt Beinhauer hart, aber fair. Für ihn steht fest, dass mit SOA zunächst nicht alles einfacher wird. Im Gegenteil: „Mit dem ESB muss eine neue Infrastrukturkomponente angeschafft werden. Und zum SOA-Management braucht man ein Governance-Werkzeug, um die Probleme zu lösen, die man ohne SOA nicht gehabt hätte."