SOA - Service Ohne Akzeptanz

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!