Serviceorientierung ist modern, aber nicht neu. Fachbereiche und IT versuchen seit Jahrzehnten, in Prozess- und Softwarearchitekturen Komponenten zu finden, die sich auf einfache Weise zu neuen Lösungen orchestrieren lassen. Damit wollen sie erreichen, was Monolithen verhindern: Agilität.
Erste Erfahrungen mit großen Applikationslandschaften zeigen, dass CIOs die Potenziale loser Kopplung und Wiederverwendung verspielen. Wenn neben neuen Services alte Versionen weiter bestehen, entsteht die gleiche „Verdrahtung“, die man eigentlich überwinden wollte.
Das Agilitätspotenzial von Software-Services verpufft auch, wenn die Schnitte auf der Fachseite nicht kompatibel sind: Kann man für die fachliche Strukturierung Vorteile erreichen, die denen der Interoperabilität und allgemeinen Verfügbarkeit von Software-Services entsprechen? Sind Geschäftsmodelle, Organisations- und Führungskonzepte serviceorientiert?
Eine mögliche Antwort besteht darin, die Serviceorientierung in verschiedene Ebenen zu differenzieren: Aus Software-Services lassen sich Applikationen orchestrieren; aus Applikationskomponenten lassen sich fachliche Strukturen orchestrieren; aus fachlichen Komponenten lassen sich Geschäftslösungen orchestrieren.
Zwischen den drei Ebenen sollten CIOs sorgfältig unterscheiden, weil ihr „Zuschnitt“ jeweils unterschiedlichen Regeln folgt:
Software-Services kapseln implementierte Funktionen (z.B. Zinsberechnung) mit den Zielen Interoperabilität und Allgemeinverfügbarkeit; Applikationskomponenten (z.B. Kennzahlenermittlung) bündeln Funktionalitäten, die organisatorisch oder informatorisch zusammenhängen; fachliche Komponenten (z.B. Inkasso) bündeln manuelle wie auch IT-unterstützte Funktionen mit Synergiepotenzial für unterschiedliche Geschäftslösungen.
SOA ist noch kein Silver Bullet. Das könnte aber passieren, wenn außerdem Methoden zum zielgerichteten Zuschnitt der jeweils „richtigen“ Komponenten hinzukommen. Hier existieren bereits viele gute Ansätze – ihre Integration scheitert jedoch oft an inkompatibler Terminologie und methodischen Grabenkämpfen.
Wie bei vielen Innovationen führt Serviceorientierung zunächst zu einer Software-orientierten Diskussion. Aber Software-Services dürfen nicht nur in der Hoffnung gebaut werden, dass sie auch auf fachlicher Seite automatisch Service-Pendants finden.
CIOs müssen die Bottom-up-Betrachtung um eine Top-down-Sicht ergänzen: Es ist höchste Zeit, auf Fachseite geeignete Komponenten zu identifizieren und die Entwicklung von SOAs duch konzeptionelle Anforderungen zu steuern. Sonst könnte SOA das gleiche Schicksal bevorstehen wie der Objektorientierung.