SOA braucht eine klare Definition

21.01.2008
Von Robert Winter
Die Diskussion um Service-orientierte Architekturen ist von Begriffen und Abstraktionsebenen geprägt, die sich nicht von selbst verstehen. Werden sie uneinheitlich gebraucht, drohen Missverständnisse.

Das Konzept der Service-orientierten Architektur (SOA) ist in aller Munde. Viele verbinden damit die Erwartung, einmal gebaute IT-Funktionen nicht nur beliebig oft wiederverwenden zu können, sondern diese auch systematisch aufzufinden und in standardisierter Form durch fachliche Prozesse nutzbar zu machen. Vor allem soll sich die IT-Unterstützung bei Prozessänderungen auf einfache Weise "re-orchestrieren" lassen. Dass so viele unterschiedliche Erwartungen nicht gleich gut und vor allem nicht auf einmal zu erfüllen und zu kommunizieren sind, zeigt die anhaltende Diskussion unter Praktikern, Tool-Herstellern und Wissenschaftlern.

Im Folgenden soll ein Beitrag zu einem konsolidierten Verständnis von Service-Orientierung (nicht nur SOA) geleistet werden. Dabei geht es um wesentliche Prinzipien und Erscheinungsformen von Service-Orientierung. So interessiert die Frage, wie sich Service-Orientierung im Rahmen der Gestaltung der Unternehmensarchitektur positionieren lässt und welche Konsequenzen daraus für das Architektur- und Integrations-Management erwachsen.

Das Problem der Verdrahtung

Der Kerngedanke der Service-Orientierung besteht darin, die komplexe "Verdrahtung" von IT-Funktionen - beispielsweise aufgrund programmierter Aufrufsequenzen - durch loses Koppeln feiner granularer, aber gleichwohl fachlich abgeschlossener IT-Funktionsbündel zu ersetzen. Lose Kopplung heißt, dass die gebildeten IT-Funktionsbündel ("Services") so weit unabhängig sind, dass sie in sehr unterschiedlichen Kombinationen zusammenfügt sein können. So lassen sich beispielsweise mit dem gleichen Bündelumfang unterschiedliche fachliche Anforderungen erfüllen (Standardsoftware) oder geänderte fachliche Anforderungen abdecken, ohne den Bestand an IT-Funktionsbündeln ändern zu müssen (Re-Orchestrierung).

Lose Kopplung

Im Idealfall erfolgt die Zuordnung von Services zu fachlichen Anforderungen dann auch nicht mehr direkt 1:1, sondern über eine m:n-fähige Zuordnungs-Infrastruktur. Der durch Bündelung und m:n-Zuordnung ermöglichte Paradigmenwechsel ist in der Grafik "Lose Kopplung statt Verdrahtung" dargestellt. Sie macht auch deutlich, dass die Kopplungen zwischen IT-Funktionsbündeln entscheidend verringert werden müssen, wenn die Zuordnung zu fachlichen Anforderungen flexibler werden soll.

Gestaltungsebenen

Die Bündelung und lose Kopplung von Funktionen wurde zuerst unter Schlagworten wie Web-Services oder SOA primär auf die Gestaltung von Software angewendet. Doch die Prinzipien der Service-Orientierung sind auch für Architekturen im gesamten Spektrum von "Business-to-IT" nutzbar. Das Business Engineering Framework der Universität St. Gallen unterscheidet zwischen den Gestaltungsebenen Strategie, Organisation, Integration, Software und IT-Infrastruktur.

Service-Orientierung ist nicht nur auf Softwareebene, sondern mindestens auch auf Integrations- und Organisationsebene anwendbar, um die jeweiligen Strukturen besser änderbar und flexibler nutzbar zu gestalten. Allerdings sollten die Protagonisten entstehende Funktionsbündel dann auch jeweils anders nennen: Auf Softwareebene sollte von Software-Services, auf Integrationsebene von fachlichen Services und auf Organisationsebene von Prozess-Services gesprochen werden. Da nicht nur die daraus entstehenden Konstrukte, sondern aufgrund der unterschiedlichen Gestaltungsziele auch die Gestaltungsmethoden unterschiedlich sind, sollten dann auch mindestens drei Erscheinungsformen von Service-Orientierung unterschieden werden: Service-orientierte Softwarearchitektur (SOSA), Service-orientierte Integrationsarchitektur (SOIA) und Service-orientierte Prozessarchitektur (SOPA). Die Positionierung der verschiedenen Services und den Zusammenhang der verschiedenen Architekturen illustriert die Grafik "Formen der Service-Orientierung".

Ziele auf verschiedenen Ebenen

Die auf der Softwareebene verfolgten Gestaltungsziele heißen Interoperabilität und Wiederverwendung von Software-Services. Diese sind gleichzeitig die Voraussetzung, um auf der Integrationsebene möglichst agile Applikationen bauen zu können (Pfeil 1 in der Grafik). Die auf der Integrationsebene anvisierten Gestaltungsziele sind Alignment von fachlichen und IT-Strukturen sowie Flexibilität der fachlichen Services. Fachliche Services bilden gleichzeitig die Voraussetzung, auf der Organisationsebene Prozessänderungen möglichst einfach unterstützen zu können (Pfeil 2). Auf der Organisationsebene schließlich lauten die Ziele Effektivität und Effizienz. Prozess-Services sind nötig, um auf der Strategieebene Geschäftsmodelle möglichst flexibel anpassen zu können (Pfeil 3).