Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

17.01.2008

SOA braucht eine klare Definition

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.
SOA kann die feste Verdrahtung von Prozessen und IT-Funktionen aufheben.
SOA kann die feste Verdrahtung von Prozessen und IT-Funktionen aufheben.
Das Business Engineering Framework der Universität St. Gallen unterscheidet fünf Gestaltungsebenen der Service-Orientierung.
Das Business Engineering Framework der Universität St. Gallen unterscheidet fünf Gestaltungsebenen der Service-Orientierung.

Das Konzept der Service-orientierten Architektur 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.

Fazit

Die Service-Orientierung verspricht bedeutende Potenziale in der Flexibilisierung und funktionalen Weiterentwicklung von Unternehmensarchitekturen. Die damit verbundenen Herausforderungen sind jedoch nicht zu unterschätzen. Sie erfordern terminologische Klarheit und ein methodengeleitetes Vorgehen.

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.

Gestaltungsebene

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 Prozess-architektur (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).

Hürden in der Praxis

Das Umsetzen von Service-Orientierung ist oft schwierig, weil im Vergleich zu klassischen Gestaltungsansätzen meist fundamentale Unterschiede bestehen. Service-Orientierung ist beispielsweise mit dem seit 30 Jahren für betriebswirtschaftliche Applikationen vorherrschenden Paradigma der Basierung auf integrierten Datenbanken weitgehend inkompatibel. Um komplexe Unternehmensarchitekturen Service-orientiert weiterzuentwickeln, reicht es nicht aus, auf Standardprodukte der großen Softwarehersteller zu warten. Stattdessen ist es wichtig, methodische Kompetenz aufzubauen, um geeignete Bereiche und vor allem das richtige Maß an Service-Orientierung zu identifizieren. Dabei sollten Unternehmen Schwarzweiß-Denken nach dem Motto "Vollständig oder gar nicht" vermeiden. Service-Orientierung lässt sich auch in vielen Zwischenformen und lokal begrenzt erreichen. Außerdem ist sie wie die meisten Innovationen im Informations-Management nicht nur in Form von Projekten zu bewerkstelligen. Vielmehr ist es notwendig, sie auch in dauerhaften Prozessen am Leben zu erhalten.

Komplexität bewältigen

Service-Orientierung ist kein allein substitutives Konzept, sondern ergänzt bestehende und bewährte Strukturierungs- und Evolutionskonzepte. Aus diesem Grund macht sie die ohnehin schon sehr komplexe Unternehmensarchitektur in der Regel noch komplexer. Deshalb sollten Projektverantwortliche die Service-Orientierung mit entsprechend erweiterten Governance-Regeln begleiten. Eine gestaltungsorientierte Governance sollte festlegen, welche Rollen im Unternehmen welche Kompetenzen und Pflichten beim Definieren, Entwickeln, Freigeben und Abschalten von Services haben. Dabei müssen Unternehmen auch bestimmen, welche Gremien die Regeln definieren, nach denen neue Services gebaut werden. Schließlich gilt es, Prozesse zu definieren, die zum Beispiel die Wiederverwendung bereits bestehender Services auf allen Architekturebenen systematisch unterstützen. (wh)