Ja, ich bin ein SOA-Skeptiker. Allerdings kein Gegner, denn ich unterstütze alles, was uns erlaubt, wohldefinierten Problemen in der IT mit wohldefinierten Lösungen zu begegnen. Allerdings lässt sich in
Sachen SOA eine Menge falsch machen.
1. SOA bei den Anwendern
Lange Jahre hat die IT versucht, Anwender zu einer effizienteren Zusammenarbeit mit IT-Mitarbeitern zu
bewegen. Was haben wir nicht tausendfach nach Lasten- und Pflichtenheften gerufen, nach Ablaufbeschreibungen, Datenmodellen und Business-Strategien. Gekommen ist in aller Regel wenig Input – und meistens auch nur von der eng begrenzten Schar der Grenzgänger zwischen IT und Fachabteilungen.
In großen Unternehmen gibt es heute oft Prozessspezialisten, die sich etwa mit „Prozesshäusern“ beschäftigen. In solchen Fachabteilungen sitzen Mitarbeiter, die im Formulieren von Abläufen geschult sind, die zudem die Zusammenhänge zwischen den Bearbeitungsstellen im Unternehmen kennen. In kleinen und mittelständischen Unternehmen wird man solche Mitarbeiter kaum finden. Dort ist die Ablaufoptimierung Sache des Vorgesetzten. Das Gesamtbild ist in der „Regierungshoheit“ des Chefs, der gleichzeitig die sehnlichst erwünschte Business-Strategie mit einarbeitet.
Mit anderen Worten: Ein formales Business Process Management (BPM) wird in Großunternehmen eher
die Regel sein, in kleineren Unternehmen jedoch als Exot behandelt.
Es ist unstrittig, dass SOA ohne BPM nicht funktionieren kann. Das heißt, dass SOA auch nur in Großunternehmen mit vernünftigem Aufwand greifen kann, bei kleineren Unternehmen ohne BPM-Initiative aber kaum. Dort verkommt SOA schnell zur „technischen Spielwiese“ ohne mittel- bis langfristig nachweisbaren Benefits.
An einer „Vertechnisierung“ sind schon unzählige Initiativen gescheitert, wie etwa das Enterprise Architecture Management (EAM) und Enterprise Application Integration (EAI). Der Grund: Informatiker neigen
dazu, zu glauben, die (Business-)Welt sei durch eine Abfolge von Einzelszenarios und Anlagenabbildern mit klar abgegrenzten Entwicklungsstufen zu beschreiben. Weit gefehlt!
Jeder, der es als Unternehmer schafft, überraschende und effiziente Geschäftsstrategien, Produkte und Geschäftsprozesse schnell zu etablieren, gehört noch schneller zu den echten Gewinnern. Die sind oft unvorhersehbar. Auch für SOA wird das, obwohl es mit dem Anspruch antritt, schnellere Entwicklungszeiten durch die Servicefragmentierung zu bieten, wohl zur Schicksalsfrage werden. Läuft das Business wirklich schnell genug durch die Neumodellierung des Servicemodells, um die IT zu beschleunigen? Ich fürchte: eher nein.
Als Bereichs-CIO eines sehr großen deutschen Unternehmens hatten wir bei solchen Dingen den folgenden Grundsatz: erst mal einige Monate oder Jahre das Prozessmodell entwickeln und anpassen und danach über die hundertprozentige Implementierung nachdenken. Heute ist klar, dass wir mit diesem perfektionistischen Ansatz viel Geld verbrannt haben.
2. SOA unter IT-Entwicklern
Viele altgediente Entwickler haben noch in einer Zeit ihr Handwerk gelernt, in der Objektorientierung als Allheilmittel gepriesen wurde. Die Ernüchterung folgte bald, aber in den Köpfen hält sich eine solche Ausrichtung sicher länger. Für diese Entwicklerschar ist SOA ein Trend, der ihnen bekannt vorkommt und mit dem man sich schnell und intensiv anfreunden kann. All jene, die erst später kamen und mit Standardsoftware aufgewachsen sind, neigen vielleicht eher zu Skepsis, sind aber trotzdem schon sehr an zentralistisch geprägte Architekturmodelle gewöhnt und tun sich leichter mit einer Umstellung auf SOA-Entwicklungen.
Das Hauptproblem dürfte die Techniklastigkeit der IT-Entwickler sein, die eher technische Aspekte der
SOA überbewerten, also Dinge wie Bus-Systeme, Verfügbarkeiten, Implementierungssprachen oder gar technische Plattformen. Die überlebenswichtige Trennung zwischen IT-basierter Sicht auf Servicestrukturen und der viel wichtigeren Sicht der Fachabteilung darauf gelingt nicht immer.
Schon lange stehen die unterschiedlichen Sprachen und Semantiken in Hinblick auf das Business-IT-Alignment in der Kritik – das wird auch SOA nicht ändern können!
Und bis Fachabteilung und IT wirklich tragfähige RoIs und / oder Business Cases für ihre Implementierungen berechnen können, wird noch viel Wasser in die Ozeane fließen.
3. SOA und das Management
Eine erfolgreiche SOA-Strategie wird kaum ohne Neuordnung der IT-Strukturen vonstatten gehen können.
Völlig analog im Übrigen zu den enormen Umwälzungen, die seinerzeit der Run auf Standardsoftware ausgelöst hat. Die Verschiebung vom „Wie“ auf das „Warum“ in der Software bedingt zwangsläufig einen Paradigmenwechsel, weg vom klassischen IT-Mitarbeiter hin zum Business-getriebenen IT-Architekten. Dieser Wechsel muss natürlich seinen Abdruck in den IT-Organisationen hinterlassen, vom Betrieb bis hin zur Entwicklung und zu den Governance-Funktionen.
Eine Organisation, die nicht rechtzeitig vor Beginn einer SOA-Initiative solche Weichenstellungen erledigt, wird wohl oder übel an zwei Fronten kämpfen: an der technischen und an der internen organisatorischen. Eine Unterstützung des Top-Managements für SOA ist zwar wichtig und eine Voraussetzung für das spätere Gelingen. Sie ersetzt aber keinesfalls die organisatorische Abbildung von Zielen wie Wiederverwendbarkeit, Standardisierung und zentrale Regelung des entstehenden Servicenetzes in der IT-Struktur. Denn ein mehr oder weniger zentralistischer Ansatz wie SOA muss seine Entsprechung in der generellen Firmenstruktur und der Hierarchie finden. Klar ist: Lose gekoppelte SOA-Services funktionieren nicht zwangsläufig am besten in lose gekoppelten Firmeneinheiten!
Last, but not least: Wir sollten uns nicht einbilden, dass das Top-Management wirklich immer hinter den IT-Technologien steht (okay, vielleicht mit Ausnahme von jenen Gerätschaften, die in der Chefetage unverzichtbar geworden sind), sondern nur hinter überprüfbaren Kosten-Nutzen-Relationen, Business Cases und RoI-Betrachtungen. Und manchmal auch hinter massiven Kosteneinsparungsaktionen.
SOA wäre nicht der erste IT-Hype, der einen mehr oder weniger leisen Tod stirbt, weil auf halbem Weg
der Geldhahn zugedreht wird – entweder, weil der kurzfristige Return zu wünschen übrig lässt oder weil
eine andere Methoden-Fraktion noch mehr Benefits verspricht und Gehör findet.