Der Bauplan für die SOA

Think big, start small lautet eine oft gehörte Empfehlung zum Aufbau einer SOA. Doch wie sollen Projektverantwortliche solche allgemeinen Ratschläge praktisch umsetzen?

Der Analyst Christian Hestermann erklärt, wie sich die Marktforscher von Gartner eine pragmatische Herangehensweise vorstellen. Unternehmen, die neu in das Thema einsteigen, empfiehlt er, den potenziellen Nutzen anhand überschaubarer Projekte deutlich zu machen und damit das Management ins Boot zu holen. Wenn erste Erfolge zu verzeichnen sind, geht es an die unternehmensweite Einführung. Hier kommt die klassische Top-down-Strategie ins Spiel: Das Projektteam setzt bei den Geschäftsprozessen an, spricht mit Anwendern und beschreibt, wie die Abläufe künftig aussehen sollen. Erst danach folgen die Arbeiten an der IT-Infrastruktur (siehe auch: In zehn Schritten zur SOA).

SOA-Strategie der Deutschen Bank

Die Deutsche Bank operiert nach einem ähnlichen Muster. CIO Wolfgang Gaertner unterscheidet zwei Phasen: "In der Experimentierphase geht es zunächst darum, Grundprinzipien zu erklären und Tools und Modelle auszuprobieren." Das Projektteam brauche dazu Freiheiten. Wenn erste Erfahrungen und ein gewisses Interesse vorhanden sind, sollte das Management die großen Themen vorgeben und durchsetzen. Die Deutsche Bank verfolge derzeit mehrere große SOA-Projekte, darunter auch solche in den USA, die allesamt top-down getrieben seien (siehe auch: Bottom-up oder top-down?).

Olaf Herbig, Vice President Operations Implementation & Management bei T-Systems, setzt ebenfalls auf kleine Pilotprojekte als Einstieg in die Service-Orientierung. "SOA-Verantwortliche sollten sich eine klar umrissene fachliche Anforderung suchen und diese mit Hilfe von Services umsetzen", lautet seine Empfehlung. "Damit können sie zeigen, dass das Konzept funktioniert."

Für eine "große Lösung über die Architektur" plädiert dagegen IDC-Analyst Rüdiger Spies. Er rät Unternehmen generell zu einer Top-down-Strategie, kombiniert mit Erfahrungen aus einem Bottom-up-Vorgehen: "Erst muss die Architektur stehen, zumindest als Konzept."

Modelle helfen beim Planen

Den Königsweg zur SOA gibt es nicht, argumentiert wiederum Wolfgang Beinhauer vom Fraunhofer-Institut Arbeitswirtschaft und Organisation (IAO). Nach seiner Erfahrung können völlig konträre Vorgehensweisen zum Erfolg führen. Zwar komme von Experten immer wieder der Rat, mit kleinen Pilotprojekten zu beginnen. Doch in der Praxis funktioniere auch der umgekehrte Weg: "Manche Unternehmen bauen in einem aufwändigen Verfahren erst die komplette Infrastruktur, bevor sie den ersten Service einführen." Eine Firma, deren Namen er nicht nennen will, habe eine komplette SOA unter dem Deckmantel eines Forschungsprojekts entwickelt. Beinhauer: "Von einem Tag auf den anderen wurde das System dann live geschaltet."

Beim Aufbau einer SOA helfen auch theoretische Modelle von Beratern und Analysten. Gartner etwa unterscheidet drei Stufen von SOA. Auf der ersten Ebene geht es um die klassische Anwendungsintegration mit Hilfe von Service-Wrappern oder einem Enterprise Service Bus (ESB), erläutert Hestermann. Schon weiter fortgeschritten ist das Wiederverwenden von Legacy-Komponenten, beispielsweise in Mashups und Portalen. Die Königsdisziplin sieht Gartner in modellbasierenden Anwendungen mit einer klaren Trennung zwischen Programmcode und Prozessbeschreibung

Fachabteilungen müssen ins Boot

Last, but not least sollten Projektverantwortliche aus den Erfahrungen anderer Unternehmen ihre Lehren ziehen. Analysen typischer Fehler in SOA-Projekten gibt es inzwischen zuhauf. Ein zentrales Problem scheint noch immer darin zu liegen, dass die Protagonisten SOA als reines IT-Thema ansehen und entsprechend kommunizieren. Wer den Ansatz aber nur als Architekturparadigma für die Softwareentwicklung begreift, wird die erhofften Vorteile wie Flexibilität, Agilität und Effizienz kaum ernten können. Das volle Potenzial entwickelt eine SOA erst über die damit zu erzielenden Prozessverbesserungen. Dazu müssen die Fachabteilungen ins Boot (siehe auch: SOA Best Practices).

Damit zusammen hängt ein weiteres Problem, auf das auch das Business Application Research Center (Barc) hinweist. Trotz des Hypes auf dem SOA-Markt fehlt noch immer eine einheitliche SOA-Definition. "Das massive Hersteller-Marketing mit dem Begriff SOA und ein teils sehr technisches Vokabular verwirren die Verantwortlichen zusätzlich", monieren die Barc-Experten.

Hinzu kommen weiche Faktoren, die SOA-Verantwortliche allzu oft vernachlässigen. Anne Thomas Manes, Analystin beim Beratungsunternehmen Burton Group, nennt die Begriffe Vertrauen und Kultur beim Zusammenwirken von Business- und IT-Mitarbeitern. Es sei Sache der IT-Abteilung, dieses Vertrauen aufzubauen. "Sie müssen einen kulturellen Wandel schaffen", forderte sie die Besucher der hauseigenen Fachkonferenz "Catalyst" auf. In Anspielung auf viele von der IT frustrierte Anwender appellierte sie an die Techniker unter den Zuhörern: "Sie haben die Herzen der Fachbenutzer über so viele Jahre gebrochen, jetzt ist es an Ihnen, den ersten Schritt zu tun."

Typische SOA-Fehler

• Unklarer Business-Nutzen der SOA.

• Unterschätzte organisatorische Auswirkungen.

• Fehlende Unterstützung aus dem Management.

• Zu knappe Budgets.

• Fehlende Fachkenntnisse.

• Schwaches Projekt-Management.

• SOA als Projekt statt als Architektur begriffen.

• Unterschätzte Komplexität.

• Vernachlässigte SOA-Governance.

• Hersteller bestimmen die Architektur.

Mehr zu typischen Fehlern in SOA-Projekten finden Sie hier.

Gesucht: Die SOA-Definition

Eine breit akzeptierte Definition des Begriffs SOA gibt es nicht. Die IBM-Mitarbeiter Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones und Rawn Shah geben eine Business-orientierte Erklärung: "Eine Service-orientierte Architektur ist ein Framework für die Integration von Geschäftsprozessen und unterstützender IT-Infrastruktur in Form von sicheren, standardisierten Komponenten - Services -, die sich wiederverwenden und kombinieren lassen, um wechselnde Geschäftsanforderungen abzubilden."

Technisch orientierte Autoren beschreiben SOA oft lediglich als "unternehmensweite IT-Architektur, die lose Kopplung, Wiederverwendung und Interoperabilität zwischen Systemen unterstützt".

Das Business Application Research Center (Barc) verwendet eine Definition des Wirtschaftsinformatikers Hans Robert Hansen: "Die SOA ist eine Form der verteilten Informationsarchitektur. Charakteristisch sind das Ankündigen, Auffinden und dynamische Aufrufen von Diensten. Diese sind anwendungsnah und in sich geschlossen."

Mehr zum Thema im CW-Experten-Blog SOA meets BPM.