Serviceorientierung - kein reines Softwarephänomen

Serviceorientierung ist in den letzten Jahren zu einem zentralen Thema im Schnittbereich von Informatik und Business geworden. Aus Informatiksicht wird es durch Kapselung von Funktionalitäten und Nutzung offener Standards möglich, interoperable und ubiquitäre Komponenten bereitzustellen, mit denen verteilte Applikationen flexibel implementiert werden können. Die Vorteile hinsichtlich Agilität und Betriebskosten von Softwarelösungen sind unstrittig, wenn die Softwareservices richtig geschnitten sind und man sich auf solche mit Wieder- beziehungsweise Weiterverwendungspotential beschränkt.

Die Fachseite erhofft sich von Serviceorientierung analoge Vorteile: Wenn Geschäftslösungen organisationsübergreifend und flexibel aus fachlichen Komponenten zusammengestellt werden könnten, würden sich viele aktuelle Probleme des Informationsmanagements elegant lösen lassen.
Ähnliche Erwartungen wurden vor etwa zwanzig Jahren an die Objektorientierung geknüpft. Die Tatsache, dass sich die Objektorientierung nicht als das «Silver Bullet» für die Analyse, den Entwurf und die Implementierung von betrieblichen Applikationen erwiesen hat, macht nachdenklich: Selbst wenn Serviceorientierung unter bestimmten Bedingungen ein vorteilhaftes Strukturierungs- und Realisierungskonzept ist: Macht Serviceorientierung dann automatisch auch auf fachlicher (Analyse- und Entwurfs-) Ebene Sinn? Sind Geschäftslösungen serviceorientiert? Gibt es für die fachliche Strukturierung Vorteile, die denen der Interoperabilität und Ubiquität von Softwareservices entsprechen? Erste (Standard-) Softwarehersteller verkünden nämlich bereits, dass eine auf Softwareservices basierende, unternehmensweite Komponentenarchitektur die richtige Grundlage für das flexible Zusammenstellen und Umbauen von Geschäftslösungen wäre.

Aber haben wir nicht in den vergangenen Jahrzehnten gelernt, dass Softwarelösungen erst dann sinnvoll strukturiert und realisiert werden können, wenn die fachlichen Anforderungen analysiert und in geeigneter Weise spezifiziert sind? Was sind dann die fachlichen «Services», die als Spezifikationen für die Entwicklung entsprechender Softwareservices dienen können? Wie vertragen sich fachliche «Services» mit etablierten Konzepten zur fachlichen Strukturierung wie etwa Geschäftsprozessmodellen? Sind Wiederverwendung und Komponentenorientierung überhaupt Entwurfsprinzipien, die für Geschäftsprozesse Sinn machen?

Offensichtlich gibt es hier viele Fragen und bisher nur wenige Antworten. Wie bei vielen anderen Innovationen auch führt bei der Serviceorientierung der Informatik-Hintergrund zu einer zunächst Software-orientierten Diskussion. Aber Softwareservices dürfen nicht nur in der Hoffnung gebaut werden, dass sie auch aus fachlicher Sicht zu geeigneten Strukturierungen führen, beziehungsweise dass es fachliche Pendants gibt, die auch aus Prozesssicht Sinn machen.
Um nachhaltig wirksam werden zu können, muss diese Bottom-up-Betrachtung durch eine Top-down-Betrachtung ergänzt werden: Es ist höchste Zeit, auf Fachseite (z.B. in der Prozessmodellierung) geeignete «Services» zu identifizieren und die Entwicklung serviceorientierter Architekturen durch entsprechende konzeptionelle Anforderungen zu steuern. Wenn nicht, könnte der Serviceorientierung das gleiche Schicksal bevorstehen wie der Objektorientierung.