Betrachtet man die Veröffentlichungen der letzten Jahre rund um SOA, könnte man schnell den Eindruck gewinnen, als wäre SOA nun der Weisheit letzter Schluss und würde das Thema "Enterprise Architecture" ablösen. Dieser Beitrag soll aufzeigen, dass SOA ein Teil der Enterprise Architecture ist und diese in wesentlichen Punkten ergänzt.

Dabei wird das Thema durch die Brille des Toolherstellers SAP betrachtet, der durch die Erweiterung des SOA-Gedankens zu enterprise SOA (enterprise Service Oriented Architecture) den Fokus auf die Entwicklung und die Verwal-tung von bereits erstellten unternehmensweiten Services legt. Damit befand sich die Enterprise Architecture Governance bei SAP in der gleichen Situation wie die Enterprise Architecture Governance in einem Großunternehmen, das sich mit bereits ausgerollten Lösungen beschäftigen muss und die Einführung von SOA vorbereitet. Die Situation der SAP ist sogar noch komplexer, da eine Vielzahl von Partnern/ Geschäftsprozessen aus allen Branchen berücksichtigt werden musste.

Zuerst gilt es festzuhalten, dass SOA eine Philosophie ist und kein Produkt, welches im Laden gekauft werden kann. Obwohl dies mittlerweile eine triviale Aussage zu sein scheint, liegt doch eine der Ursachen für die Diskussion, ob Enterprise Architecture (EA) und SOA unterschiedliche Dinge sind, genau darin begründet. Wäre SOA ein Produkt, dann würde es von einer EA Governance nach den gleichen Prinzipien verwaltet werden wie jede andere Applikation. Dies ist nicht der Fall. SOA stellt bestimmte Anforderungen an die Art und Weise, wie Geschäftsprozesse modelliert werden müssen. Diese werden dann technisch über (Web-)Services realisiert. Die Verwaltung der Services erfolgt
über ein Service-Repository. SOA setzt also (stark vereinfacht gesprochen) Standards für fachliche Modellierung und für die IT-Umsetzung fachlicher Abläufe.
Eine EA hat die gleichen Ansprüche, geht aber darüber hinaus. Hier sollen die im Unternehmen implementierten Lösungen harmonisiert, verwaltet und nach Standards geregelt betrieben werden. EA Governance hat allerdings zudem den Anspruch, auch Lösungen, die nicht nach den SOA-Prinzipien erstellt wurden, zu verwalten. Dies ist heutzutage der Normalfall. Die Integration der SOA-Philosophie in eine traditionelle EA stellt allerdings gerade in der Über-gangszeit besondere Anforderungen an die Governance und die Enterprise Architekten. SAP hat sich dieser Herausforderung in den letzten Jahren gestellt und viele Applikationen, die auf traditionellen IT-Mustern basierten, den SOA-Leitlinien folgend neu strukturiert. Die Geschäftsabläufe, die bisher eher mono-lithisch in Applikationen gegossen waren, wurden nun „serviceifiziert“ und sind jetzt in feinere Bausteine zerteilt über Webservices ansprechbar. SAP bezeichnet die eigene Variante von SOA als Enterprise SOA beziehungsweise enterprise SOA.
Das kleine „e“ soll dabei darauf hinweisen, dass es sich bei den von SAP zur Verfügung gestellten Lösungen und (Teile von) fertigen Geschäftsprozessen handelt und nicht nur um leere Hüllen. Der Prozess der Migration aller Produkte in eine enterprise SOA-Welt ist allerdings noch nicht abgeschlossen. Einen Überblick über die vorhandenen Services gibt www.sdn.sap.com (ES Workplace). Während der Migrationsphase und im Betrieb der Webservices hat sich SAP intensiv mit dem Thema der EA Governance beschäftigt. Dabei wurden einige grundsätzliche Vorgehensweisen und Prinzipien für eine Enterprise Architecture entwickelt.

Eine funktionierende EA Governance stellt folgende Punkte sicher:

Business und IT arbeiten zusammen an Lösungen: Auch in den Zeiten vor SOA ist dies bereits geschehen. Frameworks wie COBIT und ITIL geben hier wesentliche Hilfestellungen.
 

Wiederverwendung: Bereits existierende Lösungen können in anderen Kontexten wieder verwendet werden. Auch dies ist keine grundsätzlich neue Leistung von SOA.
 

Standardisierung des Vorgehens: Zur Erstellung, Weiterentwicklung und dem Betrieb von unternehmensweiten Architekturen gibt die EA Governance Standards und Leitlinien vor. Ein Beispiel dafür liefert das Framework TOGAF (www.togaf.org).
 

Tailoring (Anpassung) an spezifische Fragestellungen ist möglich: Das Vorgehen zur Umsetzung von Teilen der EA ist an die konkreten Aufgaben-stellungen anpassbar.
 

Herstellerunabhängigkeit: Eine unternehmensweite Architektur ist im Allge-meinen herstellerunabhängig. Gerade in Großunternehmen und deren erweiterten Ökosystemen (Partner, Zulieferer) ist dies absolut erforderlich. Eine Festlegung auf auch nur wenige Hersteller kann hier fatal sein. Herstellerunabhängigkeit bedeutet aber nicht, dass Hersteller nicht in die Erstellung der EA mit einbezogen werden müssen. Hersteller können durch ihre branchenweite Sicht die unternehmenseigene EA deutlich verbessern.

Soll SOA in die traditionelle EA integriert werden, gilt es bestimmte Punkte zu berücksichtigen, die von traditioneller EA und EA Governance nicht oder zumindest nicht in diesem Maße betrachtet werden beziehungsweise wurden:

SOA-Philosophie: Durch den Einsatz von Services zum Aufruf von Geschäfts-prozessabläufen ändern sich die Vorgehensweisen zur Softwareerstellung dramatisch. Wiederverwendung, Tailoring und die Zusammenarbeit zwischen IT und Business werden stark verbessert und erfordern bei allen Beteiligten neue Fähigkeiten und Kenntnisse. Man denke nur an die Verwaltung des ESR (Enterprise Service Repository) und an den ESB (Enterprise Service Bus).
 

Packaged Applications: enterprise SOA gestattet es, aus bestehenden Services und Geschäftsabläufen heraus neue Abläufe zu erstellen und diese als neue „Applikationen“ zu betreiben. Durch die Zusammenführung von bereits existierenden Services entstehen neue Services, die diese verwenden und selbst wieder als Teil eines weiteren Service verwendet werden können. Die besondere Herausforderung besteht nun darin, die einzelnen Abhängigkeiten seitens der EA Governance im Blick zu behalten. Ändert sich ein Service auf unterster Ebene, hat dies Auswirkungen auf alle Ebenen darüber, die diesen Service wieder verwenden.
 

Metamodell: Die meisten Frameworks zur EA Governance beschäftigen sich wenig mit der Erstellung von Metamodellen zur Definition der eigenen Abläufe. Dies führt häufig zu Missverständnissen in der Kommunikation. Ein klassisches Beispiel dafür ist die Definition von „Prozess“. Fachabteilungen haben hier meist ein anderes Verständnis als eine IT-Abteilung. Es ist daher absolut erforderlich zu definieren, wie sich „Prozess“ von anderen Begriffen wie „Work-flow“ oder „Aktivitäten“ abgrenzt.

Um ein EA Framework mit SOA-Fokus zu etablieren, hat sich SAP genau diesen Fragestellungen stellen müssen. Als Erfolg versprechend haben sich folgende Dimensionen für eine enterprise SOA herausgestellt (siehe Bild 1). Diese sind nach unseren Erfahrungen auch auf die EA Governance in Großunternehmen übertragbar:

Verfügbarkeit von unternehmensweit tätigen Enterprise Architekten: Die Architekten wurden spezifisch hinsichtlich EA und enterprise SOA ausgebildet, um Projekte und Kundenvorhaben gezielt unterstützen zu können. Sie dienen dabei als wesentlicher Teil der EA Governance als Ansprechpartner nach Innen und Außen. Die Architekten sind verantwortlich regional und lokal als Ansprech-partner und Wissensbasis zu fungieren.
 

Methodik: Die methodischen Ansätze zur Softwareentwicklung, Projektmanage-ment, Analyse und Design wurden vereinheitlicht und an die Erfordernisse einer enterprise SOA angepasst. Diese Aufgabe war und ist nicht trivial und verlangt hohe Disziplin. Teilweise werden derzeit noch Koexistenzen von Vorgehensweisen geduldet, die in dedizierten Einsatzszenarien verwendet werden, zum Beispiel klassische R/3-Implementierung.

Werkzeuge und Tools: Es gibt derzeit eine ganze Reihe von Tools am Markt, die SOA unterstützen, zum Beispiel Eclipse und andere. Aus Sicht einer EA Governance ist das aber nicht ausreichend, da diese Werkzeuge sich auf die technische Realisierung von Services konzentrieren. SAP hat viel Mühe darauf
verwendet, die Geschäftsabläufe formal zu modellieren und den Projekten werkzeuggestützt zur Verfügung zu stehen. Damit ist eine Wiederverwendung auf Geschäftsprozessebene über echte Business Services möglich. Durch die formale Modellierung kann es auch nicht zu Missverständnissen kommen.
 

Definition von Dienstleistungen: Die Enterprise Architekten stellen den Projekten klar definierte Dienstleistungen zu Verfügung, beispielsweise Coaching, Training, methodische Unterstützung, Analysen, etc. Sie sind zudem verantwortlich für die Verwaltung der bereits realisierten Services.
 

Training: Es hat sich als notwendig erwiesen, die Mitarbeiter der EA Gover-nance auf den gleichen Wissensstand zu bringen. Hierzu wurden spezielle Trainings aufgesetzt, die Vorgehensmodelle, Architekturframeworks, SOA und andere Faktoren und natürlich auch das Training von Architekten im neu entwickelten Framework, umfassten. Als wesentlicher Erfolgsfaktor hat sich eine Zertifizierung von Mitarbeitern im neuen Vorgehen herausgestellt. Diese Zertifizierung wird auch Kunden angeboten.
 

Etablierung einer Community: EA Governance ist keine Initiative von einigen wenigen Personen, sondern muss von allen Beteiligten und Betroffenen getragen und weiterentwickelt werden. Dabei sind auch externe Partner mit einzubeziehen. Dies bedeutet meist auch einen kulturellen Wandel. Geistiges
Eigentum muss mit anderen geteilt und gemeinsam weiterentwickelt werden. Dies fällt nicht immer leicht.

Von Vorteil für die Entwicklung eines Frameworks für enterprise SOA hat sich erwiesen, auf bestehenden Frameworks aufzusetzen. Auf den ersten Blick erscheint ein Ansatz auf der grünen Wiese sinnvoller, da er mehr Freiheits-grade bietet. In der Praxis lässt sich das jedoch kaum realisieren, es ist aber auf den zweiten Blick von Vorteil, auf bereits etablierten Ansätzen aufsetzen zu können. Wenn Ihr Unternehmen noch kein eigenes Framework im Einsatz hat, so empfiehlt es sich, einen Blick auf die frei verfügbaren Frameworks wie TOGAF zu werfen und diese spezifisch zu erweitern. Bild 2 zeigt das Grob-modell des EAF der SAP, welches seine Wurzeln in den SAP Frameworks und in TOGAF hat. Wie Sie vielleicht wissen hat SAP auch an der Entwicklung von TOGAF mitgewirkt, daher lag dieses Framework nahe.

Bild 2 ist der Originaldokumentation entnommen und stellt die Bestandteile des Frameworks dar. Besonders hervorzuheben ist dabei die zweite Schicht von unten (im Bild blau hervorgehoben). Aufbauend auf den TOGAFPrinzipien wurden SAP-spezifische Erweiterungen vorgenommen (Tools, Werkzeuge, Beschreibungen von Geschäftsprozessen). Ein solches Vorgehen ist von Nutzen, um das „leere“ Framework mit den Inhalten und Prozessen des Unternehmens zu befüllen.
So ist eine Konsistenz zwischen Methodik und konkreten Geschäftsprozessen gewährleistet. Unternehmensspezifische Erweiterungen zur Modellierung von (neuen) Abläufen komplettieren diese Schicht.
Aufbauend auf dieser Schicht finden sich zwei große Blöcke, von denen nur einer außerhalb der SAP von Nutzen sein dürfte, die SAP Enterprise Architecture Framework Extensions. Der andere Block beinhaltet eine Vormodellierung von Referenzprozessen am Markt. Dies führt aus SAP-Sicht zu einer beschleunigten Projektabwicklung bei der Erstellung von neuen Abläufen und ist für ein Unternehmen einer bestimmten Branche nicht relevant.

Die angesprochenen SAP Enterprise Architecture Framework Extensions erweitern TOGAF und die unternehmensspezifischen Blöcke um wichtige Hilfsmittel wie Handbücher, Beispiele und Referenzen. Es ist auf jeden Fall notwendig, gerade unerfahrenen Architekten entsprechende Hilfestellungen zu geben, die über das Maß hinausgehen, das im Standard definiert ist. Hier ist auch das bereits angesprochene Metamodell realisiert, welches die Begriffe hinter dem Framework definiert. Beispiel: „In welcher Beziehung steht ein Prozess mit den Rollen und den Ergebnissen?“ Bild 3 zeigt zur weiteren Illustration einen Ausschnitt aus dem Metamodel (ohne Beziehungen zwischen den Entitäten).
Bild 4 zeigt die bisher vorgestellten Elemente im Zusammenhang. Das konkrete Unternehmen wird als Instanziierung des Metamodells beschrieben. Diese wiederum ist getrieben durch Referenzabläufe am Markt und die aktuell vorliegende technische Architektur. Die Instanziierung wird in einer „Architecture Ressource Base“ verwaltet. Es hat sich gezeigt, dass es sinnvoll ist, hier auf Tool-Unterstützung zurückzugreifen, um schnell Auswertungen durchführen zu können, zum Beispiel zur Ermittlung von Inkonsistenzen in den Modellen. Aus der Ressource Base lassen sich über Reports schnell anwenderspezifische Sichten genieren. Bestimmte Stakeholder interessieren sich nur für einen Ausschnitt der Architektur oder nur für eine bestimmte Detailtiefe.

In jedem Fall stellt das Metamodell die zentrale Plattform zur Erfassung der EA dar. Daher ist auf die Erstellung des Metamodells besonderes Augenmerk zu legen. Daher ist es sinnvoll, auf bewährte Modelle wie TOGAF zurück zu greifen. Obwohl TOGAF derzeit (Stand beim Erstellen dieses Beitrags ist die Version 8.1) kaum auf die Spezifika einer (e)SOA Rücksicht nimmt, ist es über die unternehmensspezifischen Erweiterungen gelungen, die wesentlichen Elemente nahtlos zu integrieren.
Anhand eines Beispiels soll der Ablauf verdeutlicht werden: Um einen Service (sei er nun gekauft oder selbst entwickelt) zu beschreiben, ist die Angabe des Service Interfaces (Operationen), der nötigen und bereitgestellten Rahmen-bedingungen (Policys) und der Orte, an denen der Service ausgeführt werden soll, erforderlich. Hierfür ist das Konzept des „Contract“ aus TOGAF zu einem „Service Contract“ erweitert und angepasst worden. Nach diesen Ausführungen stellt sich vielleicht die Frage, ob enterprise SOA nicht einer Enterprise Architecture entspricht. Mit anderen Worten: Wenn enterprise SOA in eine EA Governance mit hohem Aufwand integriert wird, welchen Mehrwert bietet dann die EA für enterprise SOA? Die Antwort auf diese Fragen ist leicht zu finden, wenn man sich die klassischen Dimensionen einer EA ansieht. Die Auflistung (siehe Bild 5) zeigt wichtige Dimensionen einer EA und gibt an, welche von SOA zumindest teilweise (für die SOA-relevanten Teile der unternehmensweiten Architektur) abgedeckt werden.

Diese Tabelle ließe sich je nach Detaillierungsgrad der EA im Unternehmen noch erweitern. Überall dort, wo man in der Tabelle einen Strich sieht, kann die EA einen Mehrwert liefern. Auf die einzelnen Punkte soll hier nicht näher eingegangen werden, da die Schlagworte selbsterklärend sind. In die Gestaltung der EA müssen auch die Partner mit eingebunden werden. Es hat sich herausgestellt, dass ein Unternehmen allein gerade im Falle einer enterprise SOA nicht in der Lage ist, eine sinnvolle EA zu gestalten. Zu häufig müssen die Anforderungen von externen Partnern berücksichtigt werden, denen nur schwer eine bestimmte Art der Architektur vorzuschreiben ist. Aber nicht nur die Partner in der Liefer- oder Distributionskette sind zu berücksichtigen, sondern auch die Hersteller von externen Services. Das Release-Management des Herstellers (zum Beispiel der SAP) bei Auslieferung/Modifizierung von Services ist in die eigene Rollout-Strategie mit aufzunehmen.
SOA und Enterprise Architecture sind also kein Widerspruch, sondern ergänzen sich. Die Ergänzung ist allerdings nicht völlig überlappungsfrei. Daher müssen an einigen Stellen Nachjustierungen vorgenommen werden. Diese sollen formal über ein Metamodell der Enterprise Architecture vorgenommen werden und dürfen auf keinen Fall ad hoc geschehen. Die Erfahrungen, die bei SAP bei diesem Vorhaben gemacht wurden zeigen, dass ein solches Vorhaben möglich und erfolgreich ist. Vor allem, wenn auch Partner in den Prozess eingebunden werden, die ihre Sicht einbringen und die EA ergänzen.
Dr. Andreas Elting
Diese E-Mail-Adresse ist gegen Spam-Bots geschützt, Sie müssen Javascript aktivieren, damit Sie es sehen können

Diesen Artikel finden Sie auch in der Ausgabe 11/12 2007 des it fokus.