SOA - Service Orientierte Architekturen als Teil der IT-Strategie

Königsweg zur Ausrichtung der IT am Geschäft?

Ein Begriff der im Jahr 2005 durch viele Events und White Papers geprägt wurde: SOA - die «Service Orientierte Architektur». Die Fragestellung, ob SOA etwas vollkommen neues ist, lässt sich schnell beantworten: Nein – SOA ist nicht wirklich neu, dennoch SOA ist anders als die Architektur-Themen in der Vergangenheit.

Über die Ursprünge von SOA gibt es unterschiedliche Aussagen, Gartner Group beispielsweise hat bereits 1996 eine solche verteilte Architektur beschrieben, im zweiten Halbjahr 2005 positionierte die Gartner Group das Thema SOA auf dem bekannten Gartner-Hype-Cycle wie folgt:


SOA im Gartner-Hype-Cycle-Modell per Mitte 2005

Die Erwartungshaltung, dass SOA viele Probleme der IT löst, ist im zweiten Halbjahr 2005 entsprechend hoch. SOA wird aber auch das Tal der Desillusionierung durchwandern - dann wird Ernüchterung wird eintreten. Bis SOA den Durchbruch analog der Technologie Web-Services schafft dauert es noch rund 12 bis 18 Monate dauern (Mitte 2008). Ab diesem Zeitpunkt sind SOA-Konzepte als Best Practice verfügbar sein.

Themenbereiche von SOA

Das Verständnis von SOA heute ist jedoch umfassender als «nur» das einer verteilten Architektur. SOA ist wesentlich mehr als ein technisches Konzept oder ein neues Architektur-Paradigma. SOA ist ein ganzheitlicher Ansatz, die Geschäftsstrategien und die IT-Strategie aufeinander abzustimmen und diese zielgerichtet gemeinsam umzusetzen. Das Themengebiet der Service Orientierte Architektur umfasst die folgenden Teilgebiete:
  • Denken und Steuern in Prozessen (Ende-zu-Ende bzw. Kunde-zu-Kunde)
  • Abstimmung der Geschäftsziele mit der IT-Strategie
  • Auf die Geschäftsziele ausgerichtetes IT-Architekturmanagement
  • Transparentes Anforderungsmanagement von der Erfassung der Idee über die Umsetzung bis zur Archivierung/Entsorgung einer Anforderung
  • Verankerung der Rollen Prozess-Verantwortliche und Service-Verantwortliche im Governance-Modell

Der Aufbau einer SOA ist ein umfassendes Vorhaben, welche die UNterstützung des Managements erfordert. Die Aufbauarbeit mit stufenweiser Einführung beinahltet auch einiges an Change Management, sie stellt in jedem Fall ein mehrjähriges Programm dar, das strategisch geplant und umgesetzt werden muss.

Eine SOA besteht aus verschiedenen Schichten

Das Schichtenmodell stellt beispielhaft dar, auf welchen unterschiedlichen Ebenen SOA relevant ist. Auszugsweise einige Fragestellungen, welche in der Konkretisierung eines SOA-Programmes relevant sind:
  • Welche Vertriebskanäle und welche Endgeräte sollen unterstützt werden?
  • Welche Prozesse und welche Rollen werden auf den einzelnen Vertriebskanäle unterstützt?
  • Wie integrieren bzw. orchestrieren wir die Applikationen und Services, damit jeder am Prozess beteiligte jederzeit über die identischen Daten, Informationen und Funktionen verfügt?
  • Welche Services entwickeln und betreiben wir selbst, welche Services kaufen wir extern ein?
  • Welche Services bieten wir externen Partnern auf Basis eines Service Level Agreements an?

Die Fragen bzw. noch mehr die konkreten Antworten darauf fordern einiges - sowohl vom Fachbereich wie auch von der IT-Organisation oder dem externen IT-Partner.

Abstimmung der Geschäftsziele mit der IT-Strategie

Eine für die IT-Führung elementare Disziplin, ist die Abstimmung der Geschäftsziele mit der IT-Strategie. Eine Voraussetzung für die Umsetzung dieser Abstimmung ist die Verfügbarkeit von konkreten und möglichst messbaren Geschäftszielen der einzelnen Geschäftseinheiten und/oder Bereiche.

IT-Architekturmanagement
Das IT-Architekturmanagement muss geschäftsorientiert gestaltet sein. Das heisst, dass es sich primär auf die Geschäftsprozesse ausrichtet und Architekturen definiert, welche die Leistungserstellung für die Kunden entlang der Geschäftsprozesse optimal unterstützen. Eine Geschäfsprozess-Architektur ist somit Voraussetzung für die Entwicklung und Kommunikation einer Applikations- oder technischen Architektur. Der Aufbau einer geschäftsorientierten IT-Architektur ist eine anspruchsvolle Aufgabe, welche Fachleute mit hybriden Kenntnissen (Geschäftsbereiche und -prozesse sowie deren optimale IT-Unterstützung) und ausgeprägten Komminikationsfähigkeiten erfordert.

Die Führungskräfte aus den Fachbereichen können dadurch mit der Sicht der Geschäftsprozesse suksessive die IT-Architektur verstehen lernen, deren Umsetzung aktiv unterstützen und auch selbst mitgestalten.

Transparentes Anforderungsmanagement
Der professionelle Umgang mit Anforderungen ist sowohl für den Fachbereich wie auch für die IT eine grosse Herausforderung. Einerseits muss der Fachbereich in der Lage sein, basierend auf den Strategien die konkreten, möglichst messbaren Anforderungen (Requirements) im Rahmen von Programmen und Projekten zu dokumentieren und diese zum geplanten Zeitpunkt abgestimmt dem IT-Partner in Form eines Auftrages zu übergeben. Andererseits muss der IT-Partner in der Lage sein, die Anforderungen zu verstehen und daraus entsprechende Applikationen mit GUI's und dahinterliegender Logik zu entwickeln. Die IT-Architektur gibt für beide Parteien entsprechende Leitplanken vor.

Eine Anforderung ist jedoch nicht mit der Umsetzung in einer Applikation «erledigt», die Anforderung ist in diesem Status nur «umgesetzt» - sie bleibt aber in jedem Fall eine Anforderung und muss jederzeit aus Sicht der Geschäftsprozesse nachvollziehbar in IT-Systemen umgesetzt sein.

Rollen Prozess-Verantwortliche und Service-Verantwortliche
Diese Rollen sind getrennt auf Seite des Fachbereichs und in der IT-Organisation oder beim IT-Partner anzusiedeln.

Der Prozess-Verantwortliche wird optimalerweise direkt über den Erfolg eines optimalen Prozesses geführt, das heisst, dass der verantwortete Prozess möglichst günstig und mit der erforderlichen Qualität abgewickelt wird, die Risiken bekannt sowie die potenziellen Risikokosten ermittelt sind.

Der Service-Verantwortliche überwacht die Leistungserstellung seines IT-Services (in Form von einer oder mehreren Applikationen). Er entwickelt den Service ausgerichtet auf die Geschäftsziele und innerhalb der Architekturvorgaben weiter um die Zielerreichung des Prozess-Verantwortlichen zu unterstützen.

Technologien für SOA

Das Technologie-Portfolio zur Umsetzung einer SOA kann durchaus heterogen gestaltet werden/sein. Aus Sicht der Reduktion der IT-Kosten (Entwicklungskosten, Unterhalts- und Ausbildungskosten) sollten die verwendeten Technologien jedoch mittelfrisig homogenisiert werden.

soa service prinzip

Die Services einer SOA müssen verschiedene einfache Prinzipien unterstützen:
  • Der Service besitzt eine Beschreibung, welche sowohl für die IT-Organisation (technische Optik), wie auch für den Fachbereich (Optik der Prozess-Unterstützung) lesbar ist
  • Ein Verzeichnis verwaltet die Service-Beschreibungen
  • Die Service-Beschreibung beinhaltet eine Schnittstellen-Beschreibung, der Service stellt eine Schnittstelle zur Verfügung
  • Die Service-Beschreibung beinhaltet eine von der Schnittstellen-Beschreibung getrennte Semantik-Beschreibung. Diese Beschreibung dient zur Verifikation der fachlichen Korrektheit des Services.

Web-Services
Die Verwendung von Web-Services ist im Kontext von SOA kein Zwang, das Konzept der Web-Services unterstützt den Service Orientierten Architektur-Ansatz aber positiv. Im Grundsatz kann eine SOA jedoch auch mit anderen Technologien, welche verteilte Architekuren unterstützen aufgebaut werden.
 
CORBA, RMI und RPC
Auch vorhandene Implementierungen von Komponenten oder Services, beispielsweise auf Basis von CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation) oder RPC (Remote Procedure Call) sind für den Aufbau einer SOA zweckdienlich. Zu beachten ist jedoch die mittelfristige Konsolidierung wie zu Beginn des Abschnitts «Technologien für SOA» erläutert.

Reifegradmodell für SOA

Die Entwicklung einer SOA erfolgt stufenweise und stellt typischerweise ein mehrjähriges Programm dar, das strategisch geplant und umgesetzt werden muss. Als Ordnungs bzw. Orientierungshilfsmittel für einzelne Services bietet sich die Verwendung eines Reifegradmodells an. In diesem Reifegradmodell können einzelne Services bezüglich Serviceorientierung eingestuft werden.

soa reifegradmodell

Das Reifegradmodell unterteilt den Entwicklungspfad für Services in 5 Stufen, wobei die Stufe 0 nicht gezählt wird, da dies eine nicht kontrollierte, sondern eher zufällige Entwicklungsstufe von einzelnen Services oder von Teilen einer SOA darstellt. Für ein Unternehmen mit heterogener IT-Landschaft und/oder Absichten einer SOA-Umsetzung ist die Stufe 3 möglichst bald zu erreichen, dies um unternehmensintern eine gemeinsame bezüglich Entwicklung nach Service Orientierter Architektur-Ansätzen zu schaffen. Die gemeinsame Basis sollte durch einen externen Review überprüft werden.