Ü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.