SOA wurde in den letzten Jahren zum Inbegriff wohldefinierter verteilter Architekturen und als die Lösung für die Entwicklung und Weiterentwicklung komplexer IT-Architekturen gehandelt. Zahlreiche Unternehmen haben SOA-Projekte initiiert und dabei teilweise gute, aber auch weniger gute Ergebnisse beziehungsweise Zwischenergebnisse erzielt. Im jüngsten Gartner Hype Cycle für Emerging Technologies ist der Begriff SOA nicht mehr zu finden. Hat sich das Konzept nun etabliert oder nicht? In der Gartner-Terminologie würde man fragen, ob sich SOA auf dem "Plateau of Productivity" befindet, oder ob das Konzept als "obsolete before Plateau" einzustufen ist.

Eines ist jedenfalls sicher: Es gibt keinen Königsweg für SOA, jedes Unternehmen muss unter Berücksichtigung der eigenen Anwendungslandschaft einen individuellen Weg finden, Service-orientierte Prinzipien einzuführen. Zwei Ansätze werden dabei diskutiert.

Die radikalste Einführungsvariante setzt eine umfassende Dekomposition der bestehenden Anwendungssysteme voraus. Services, die in verschiedenen Anwendungssystemen genutzt werden, stellt man zentral bereit und entwickelt sie in einer zentralen Organisationsinstanz weiter. Jedes einzelne Anwendungssystem muss dafür unter Beachtung einer Gesamtarchitektursicht genau analysiert werden. Das erwartete Ergebnis dieser sehr langwierigen Vorge-hensweise ist ein zentraler Service-Pool im Unternehmen sowie Anwendungssysteme, die weitgehend redundanzfrei sind und zentrale Services in der Regel über einen Service-Bus nutzen. Aufgrund des enormen Aufwands stellen sich natürlich mehrere Fragen zur Sinnhaftigkeit eines derart rigorosen Ansatzes: Kann man so lange im Voraus planen? Wie lässt sich eine Dekomposition alter Anwendungen am besten angehen? Wie soll der Service-Pool innerhalb des Unternehmens organisiert werden? Sind ein neuer Engpass und noch komplexere Abhängigkeiten zu befürchten? Fragen, die sich nicht ohne weiteres beantworten lassen.

Eine gemäßigtere Vorgehensweise ist die Einführung einer partiellen SOA. Hierbei erfolgt keine komplette Zerlegung der Anwendungssysteme in Komponenten, sondern nur eine partielle "Absenkung" von Services in einen zentralen Service-Pool. Nur die wichtigsten Services werden aus den Anwendungssystemen herausgezogen. Letztere bieten zudem bei Bedarf eine eigene Serviceschnittstelle für Funktionen, die nur wenige andere Anwendungssysteme benötigen. Die technische Kommunikation könnte ebenfalls auf einen Service-Bus umgestellt werden. Doch auch hier treten ähnliche Fragen wie in der ersten Variante auf, allerdings scheint das Ziel einer partiellen SOA-Einführung im Rahmen einer sanfteren Migration eher erreichbar zu sein.

Übertriebene Erwartung und Kritik

Nicht zuletzt aufgrund dieser Fragen löst der Begriff SOA inzwischen oft kritische Reaktionen aus, die genauso übertrieben sind wie die ursprünglichen Erwartungen. Erkenntnisse und Erfahrungen aus SOA-Projekten sollten hinterfragt werden, um festzustellen, ob das Konzept weiter empfohlen werden kann. Dabei können fünf Thesen helfen, die wir aus der Beobachtung mehrerer Projekte abgeleitet haben.

These 1:

Die komplette Dekomposition bestehender Anwendungssysteme im Sinne von SOA ist für die meisten Unternehmen so gut wie unmöglich.

Diese Behauptung zielt vor allem auf die oben beschriebene erste SOA-Umsetzungsvariante ab. Sie ist vor allem für größere Anwendungslandschaften nicht realisierbar. Eine vollständige Dekomposition von Anwendungssystemen würde einen immensen Aufwand verursachen, der nicht im Verhältnis zum Nutzen steht. Der Grund liegt in erster Linie darin, dass manche Altsysteme nur noch sehr schwer zerlegbar sind. Sie müssten mit riesigem Aufwand in Komponenten strukturiert werden, zentrale Services müssten identifiziert und über einen Service-Bus wieder in die bestehenden Systeme integriert werden, ohne dass dies funktionale Verbesserungen zur Folge hätte. In einer typischen Anwendungslandschaft eines größeren Unternehmens oder einer größeren Organisation würden die IT-Abteilung und auch die zuarbeitenden Fachabteilungen über Jahre stark belastet.

These 2:

Der Ansatz der Zentralisierung von Services erhöht die Abhängigkeiten im Unternehmen oder bringt zumindest neue mit sich.

Wenn man es schafft, in einer IT-Anwendungslandschaft einen zentralen Service-Pool einzurichten, muss dieser auch weiterentwickelt werden. Änderungen in zentralen Services haben aber möglicherweise weitreichende Folgen, weil davon gegebenenfalls viele Anwendungssysteme betroffen sind. Schließlich ist ja die Verwendung zentraler Services von vielen Anwendungen das Ziel. Damit hat die Änderung an der Schnittstelle eines Service eine Anpassung aller nutzenden Anwendungssysteme zur Folge. Erst nach dieser Anpassung kann eine Änderung in Betrieb gehen. Das setzt aber zwangsweise einen hohen Testaufwand voraus. Der Preis einer übertriebenen Zentralisierung ist also eine erhöhte Komplexität bei Änderungen in den Services. Die Auswirkungen sind unter Umständen immens.

These 3:

Eine komplette SOA-Einführung in großen Unternehmen dauert zu lange und führt deshalb nicht zum Erfolg.

SOA-Einführungen im großen Stil dauern sehr lange. Zehn bis 20 Jahre sind gerade in umfangreichen Anwendungslandschaften nicht ungewöhnlich. Echte Erfahrungswerte für eine SOA-Komplettumstellung kann es deshalb heute noch gar nicht geben. IT-Projekte über eine derart lange Laufzeit sind unsicher, ihre Planung fast unmöglich. Selbst ein überzeugter CIO stößt hier auf große Widerstände. Die Wahrscheinlichkeit ist groß, dass er das Projekt nach einiger Zeit an die nächste Manager-Generation übergeben muss, welche die bisherige Strategie grundsätzlich in Frage stellt und verändert.

Vor allem die Fachabteilungen profitieren zunächst gar nicht von SOA, da die funktionale Weiterentwicklung zunächst in den Hintergrund rückt. Sobald der Druck der Kunden beziehungsweise Anwender steigt, verliert die Idee einer sauberen Architektur wieder an Bedeutung. In vielen Unternehmen, die ihren Kunden kontinuierliche Fortschritte in der Anwendungsfunktionalität versprechen, ist es schon heute schwierig, technische ohne fachliche Verbesserungen durchzusetzen.

These 4:

Im Unternehmen auf eine SOA-Organisation umzustellen ist schwer und wird enorme interne Widerstände auslösen.

Die Einführung von zentralisierten Services erfordert eine Neustrukturierung im Unternehmen. Eine neue Unternehmensinstanz (Abteilung, Bereich) muss für die Entwicklung und Pflege des Service-Pools verantwortlich sein. Diese Aufgabe erfordert sowohl fachliche als auch technische Fertigkeiten. Änderungen in den Services müssten immer mit der neuen Instanz abgestimmt werden und ließen sich nur umsetzen, wenn die Anwendungssysteme die neuen Serviceversionen auch einbinden. Für die Verantwortlichen der Anwendungssysteme geht diese Maßnahme möglicherweise mit einem Kompetenzverlust einher, was zu schwerwiegenden Akzeptanzproblemen führen kann.

Hinzu kommt, dass neue Stabsinstanzen in der klassischen Art oft mehr Probleme mit sich bringen, als sie lösen. Einige oft missglückte Ansätze der Vergangenheit wie die Einrichtung übergreifender Architektur-Boards und Datenmodellierungsinstanzen (Stichwort: unternehmensweites Datenmodell) bestätigen dies.

These 5:

Viele Fachabteilungen schaffen die hochgelobte Service-orientierte Modellierung der Geschäftsprozesse nicht alleine, die Aufgabe überfordert sie.

Im Rahmen der SOA-Diskussion wurde auch die große Hoffnung geschürt, dass die Definition von Services von den Geschäftsprozessen her abgeleitet werden kann. Geschäftsprozessmodellierung und die automatisierte Ausführung von Workflows wurden eng mit der SOA-Idee verknüpft. In den letzten Jahren hat die Branche viele neue Tools zur Unterstützung der Geschäftsprozessmodellierung entwickelt, welche Standards wie BPEL und BPMN unterstützen. Wenn Fachabteilungen ihre Geschäftsprozesse unter Einbeziehung des Servicegedankens modellieren sollen, sind sie oft überfordert. Weiterhin leidet der Ansatz am Henne-Ei-Problem: Wenn noch keine Servicelandschaft da ist, lassen sich auch keine Geschäftsprozesse definieren, welche Services nutzen sollen.

Lessons learned

Die kurzfristigen Erwartungen an SOA wurden, wie so oft bei Hype-Themen, viel zu hoch gesteckt. Einige SOA-Projekte sind gescheitert oder dauern länger als erwartet, aber es gibt auch Fortschritte zu verzeichnen. Das SOA-Konzept fasst grundsätzlich wichtige Ansätze zur Entwicklung guter Softwarearchitekturen zusammen (Kapselung, Information Hiding etc.). Das ist zwar nichts Neues, aber ein geeigneteres Konzept zum Beherrschen komplexer IT-Landschaften ist derzeit nicht in Sicht.

Während bei übertriebenen und radikalen Ansätzen der Umgestaltung großer Anwendungslandschaften ein Misserfolg droht, scheint der Weg über eine partielle und gut portionierte SOA-Einführung gangbar zu sein. Bewusst in Kauf genommene Redundanz in den Anwendungssystemen könnte die Weiterentwicklung einer Anwendungslandschaft machbarer gestalten. Eventuell sollten nur Services zentralisiert werden, bei denen eine Kernfunktionalität des Unternehmens unbedingt an einer Stelle implementiert sein muss, weil sie so komplex oder wichtig ist, dass sie überall exakt gleich ablaufen muss (etwa Preisberechnungen). Die Komplexität könnte auch durch die Konzeption möglichst kontextfreier, beispielsweise nur lesender Services reduziert werden. Services sollten also robust und zustandslos sein.

Eine sinnvolle Unternehmensorganisation müsste die bisher für die bestehenden Anwendungssysteme Verantwortlichen eng in die Servicegestaltung einbeziehen, so dass der Servicegedanke nicht zu Kompetenzverlusten führt. Denkbar wäre eine zentrale Servicegruppe im Unternehmen, die zum Beispiel der CIO selbst als verantwortlicher Architekt leitet und in die auch Vertreter der einzelnen Anwendungsteams rekrutiert werden. Sie wiederum könnten die SOA-Konzepte in die einzelnen Entwicklungsteams einbringen. (ue)