SOA-Aufbau - Schritt für Schritt

Eine Service-orientierte Architektur (SOA) entsteht selbstverständlich nicht über Nacht. Vielmehr kann die Transformation einer bestehenden IT-Landschaft
– in Abhängigkeit von Grösse und Ausgangssituation – hin zur SOA auch schon einmal mehrere Jahre in Anspruch nehmen. Methodisches Vorgehen ist daher Grundvoraussetzung für ein Unterfangen dieser Grössenordnung, das sich grob in vier Phasen einteilen lässt (siehe Kasten).
Die Einführung einer SOA im Unternehmen ist eine strategische Entscheidung mit dem Ziel einer besseren Unterstützung und Abbildung von Geschäftsprozessen durch die IT, Einsparung von Betriebs- und Entwicklungskosten und letztlich Umsatzsteigerung. Eine Entscheidung dieser Tragweite kann also nicht nur auf technischer Ebene getroffen und durchgeführt werden – vielmehr müssen die Geschäftsprozess- und die IT-Verantwortlichen an einem Strang ziehen und die anfallenden strategischen Fragen gemeinsam klären.
Auf dem Weg hin zu einer Service-orientierten Architektur sind sieben konkrete Schritte zu gehen, die im folgenden skizziert werden.

Schritt 1: Analyse des Ist-Zustandes

Vor dem Start eines Projektes dieser Grössenordnung sind das Verständnis und die Dokumentation der Ausgangssituation unerlässlich. Erst die Ergebnisse dieser Analyse ermöglichen die Planung und bilden eine wichtige Grundlage für den weiteren Entscheidungsfindungsprozess.



- Funktionale Modellierung des Geschäftsmodells

In der funktionalen Modellierung werden alle Funktionen (Capabilities) und Unterfunktionen des Geschäftsmodells nach Geschäftsbereichen gruppiert und graphisch dargestellt. Aus dem Geschäfts­modell ist dann leicht ersichtlich, welche Funktionen und Fertigkeiten ein Unternehmen zur Durchführung seiner Geschäftsprozesse benötigt.


- Funktionale Applikations-analyse

Die funktionale Applikationsanalyse dokumentiert, welche Funktionen aus der zuvor durchgeführten funktionalen Modellierung des Geschäftsmodells durch bereits vorhandene Applikationen unterstützt werden. Das Ergebnis lässt sich in der Regel in einer Matrix darstellen, die alle Applikationen in der einen Achse und alle Funktionen in der anderen Achse auflistet. An den Schnittpunkten lässt sich dann ablesen, welche bereits bestehenden Applikationen welche Funktionen unterstützen.


- Technische Applikationsanalyse

Innerhalb der technischen Applikationsanalyse werden bestehende Applikationen hinsichtlich ihrer Tauglichkeit für eine zukünftige SOA bewertet. Dabei kommen u.a. Kriterien wie Art und Alter der technischen Plattform, Unterstützung von XML und Web Services, langfristige Sicherung des Herstellersupports, Betriebskosten sowie Skalierbarkeit zur Anwendung.
Durch das Übereinanderlegen des funktionalen Geschäftsmodells und der Ergebnisse der beiden Applikationsanalysen ergibt sich nun eine funktionale und technische Landkarte der aktuellen Applikationslandschaft. Diese Karte deckt funktionale und technische Schwachstellen und Lücken sehr anschaulich auf. Auch funktionale Überlappungen werden sofort sichtbar.

Schritt 2: Definition des Ziel-Zustandes

Nach Abschluss des ersten Schrittes ist der ideale Ziel-Zustand bereits deutlich zu sehen: eine lückenfreie Applikationslandschaft ohne technische Schwachstellen und funktionale Überlappungen. Um diesen Zustand zu erreichen, ist eine Reihe strategischer Entscheidungen zu treffen: Lücken können durch Erweiterung bestehender oder Einführung neuer Applikationen geschlossen werden; technisch ungeeignete Systeme sollten Upgrades erfahren oder ganz abgelöst werden; Überlappungen können durch Konsolidierung bestehender Systeme beseitigt werden.
Ein weiterer wichtiger Schritt ist die Definition der Servicelandschaft, wobei das funktionale Geschäftsmodell wiederum wertvolle Dienste leistet. Bei genauerer Betrachtung wird schnell ersichtlich, dass eigentlich nur das Wort Funktion durch Dienst (Service) ersetzt werden muss, um einen ersten Entwurf einer Servicelandschaft zu erhalten. Es sind allerdings noch weitere Schritte notwendig, um diesen ersten Entwurf in eine technisch sinnvolle Servicelandschaft zu überführen. Diese sind die Identifizierung von Basisdiensten, B2B- und B2C- sowie der regionalen oder geschäftsbereichspezifischen Diensten, die Skizzierung der Systemgrenzen und unbedingt die Festlegung der Datenhoheit.

- Identifizierung von Basisdiensten

Basisdienste sind Dienste, die in mehreren Geschäfts- oder Funktionsbereichen benötigt werden. Eine dahingehende Überprüfung des funktionalen Geschäftsmodells liefert in der Regel schnell eine Liste von Diensten, die in verschiedenen Geschäftsbereichen mehrfach vorkommen und somit aus den Geschäftsbereichen in einen gesonderten Bereich für Basisdienste ausgelagert werden sollten. Typische Basisdienste können dabei sein: Dokumenten- und Contentmanagement, E-Mail, Workflow, Business Rules Engine sowie Single-Sign-On (SSO).



- Identifizierung von B2B- und B2C-Diensten

Dienste, die ein Unternehmen Kunden oder externen Partnern zur Verfügung stellen möchte, verdienen ebenfalls besondere Beachtung und sollten entsprechend hervorgehoben werden. Ein besonderes Augenmerk liegt dabei auf den Punkten Sicherheit und Verfügbarkeit.



- Identifizierung von regionalen oder geschäftsbereichspezifischen Diensten

Dienste, die aufgrund von regionalen oder sonstigen Besonderheiten in mehreren Instanzen vorhanden sind, sollten entsprechend dargestellt werden. Bei frühzeitiger Berücksichtigung können solche Dienste bei der späteren Implementierung einheitliche Schnittstellen bereitstellen.



- Skizzierung von Systemgrenzen

Ausgehend von der Ziel-Applika-tionslandschaft wird skizziert, wie die mögliche Implementierung welcher Dienste in welchem System aussehen könnte.



- Festlegung der Datenhoheit

Ein wichtiger Grundsatz beim Entwurf verteilter Systeme ist die eindeutige Regelung der Datenhoheit: Wem gehören welche Daten? In einer SOA bedeutet das, dass immer nur ein System pro Daten-Entität Dienste zum Modifizieren dieser Entität bereitstellen darf. Andere Systeme, die dieselben Entitäten zur Erfüllung ihrer Aufgaben benötigen, müssen sich regelmässig mit aktuellen Kopien versorgen.
Beim Entwurf der einzelnen Dienste ist ausserdem darauf zu achten, dass Granularität und Semantik stimmen: Dienste einer SOA orientieren sich immer an echten Geschäftsvorfällen – und nicht bloss an technischen
Gesichtspunkten!

Schritt 3: Strategische Planung

Nachdem das Ziel jetzt klar vor Augen liegt, kann die Umsetzung zunächst strategisch geplant werden; eine Detailplanung erscheint aufgrund des Umfanges und (noch) fehlender Erfahrung zum gegenwärtigen Zeitpunkt
nicht sinnvoll. Mittels einer zu entwerfenden Roadmap wird das Gesamtvorhaben der SOA-Transformation nun in überschaubare Häppchen aufgeteilt – schliesslich kommt ein Sieben-Gänge-Menü ja auch nicht auf einem einzigen grossen Teller auf den Tisch! Es geht also darum, das Gesamtvorhaben in einzelne Projekte aufzuteilen, diese zu bewerten und nach strategischen Gesichtspunkten in die Roadmap einzubauen. Jedes Teilprojekt sollte dabei nach einheitlichen Kriterien beurteilt werden, die anschliessend zur Positionierung der Projekte innerhalb der Roadmap herangezogen werden.
Wichtige Kriterien, die auf jedes Projekt Anwendung finden sollten, sind:



- Höhe der notwendigen Investitionen

- Höhe des Einsparpotentials

- Potentielle Umsatzsteigerung für das Unternehmen

- Komplexität

- Abhängigkeiten zu anderen Projekten innerhalb der Roadmap.


Anhand dieser und anderer unternehmensspezifischer Erfolgsfaktoren lässt sich eine zieloptimierte Roadmap aufbauen. Ist zum Beispiel die Umsatzsteigerung primäres Ziel und steht dafür genügend Kapital zur Verfügung, werden die Projekte mit dem höchsten Umsatzsteigerungspotential priorisiert. Steht jedoch für die Umsetzung nur wenig Geld zur Verfügung, ist eine Cash-Flow-optimierte Vorgehensweise am sinnvollsten, bei der die sich aus der Umsetzung eines Projektes ergebenden Einsparungen in das Nachfolgeprojekt re-investiert werden (siehe Abbildung).



Cash-Flow-optimierter Umsetzungsplan

Schritt 4: Pilotierung und Know-how-Aufbau

Am Anfang eines jeden grösseren Projektvorhabens sollte immer eine Pilotierungsphase stehen, um grundlegende Konzepte zu verifizieren, Erfahrungen zu sammeln und Know-how aufzubauen. Im Rahmen einer SOA-Pilotierung ist besonders darauf zu achten, dass zumindest Service Repository (UDDI), Servicerichtlinien (WS-Policy), Sicherheitskonzepte
(WS-Security), Message Routing (WS-Addressing) sowie Reliable Messaging (WS-Reliability) als wichtige Konzepte und Technologien Bestandteil des Pilotprojektes sind. 
Darüber hinaus ist es wichtig, die geplante Zielarchitektur mit der Architektur des Piloten bereits weitestgehend abzudecken. Ist es also beispielsweise vorgesehen, künftig einen Enterprise Service Bus (ESB) einzurichten, sollte diese Plattform schon Bestandteil des Pilotprojektes sein. Daneben gilt es, auch die notwendigen Entwicklungs- und Testumgebungen aufzubauen sowie den Know-how-Aufbau der Entwicklungsmannschaft aktiv zu fördern und wichtige Schlüsselwerkzeuge wie
XML- und Designtools, IDE etc.
einzuführen. Beim Einsatz von Unified Modeling Language (UML) für SOAs ist jedoch Vorsicht geboten: Aufgrund ihrer starken Ausrichtung an objektorientierten Konzepten ist UML zum Design für SOAs nur sehr eingeschränkt tauglich. Besser geeignet sind deshalb Tools, die die Domain Specific Language (DSL) für SOA unterstützen.

Schritt 5: Auswertung und Planung der nächsten Phase

Nach dem Abschluss der Pilotierungsphase kommt es darauf an, die gewonnenen Erkenntnisse zu analysieren und in der nachfolgenden eigentlichen Transforma­tionsphase anzuwenden. Bewährt hat sich hier die Strategie, die Schritte 2 und 3 nochmals zu wiederholen und die nun gewonnenen Erkenntnisse in die Ziel­architektur, die Systemarchitektur und auch die Roadmap einfliessen zu lassen. Auf der Basis der so verfeinerten Ziele und der bereits gewonnenen Erfahrungen ist es nun möglich, die nächsten Projekte auf der Roadmap detaillierter zu planen.

Schritt 6: Transformation durch Iteration

Jetzt, wo das Fundament für eine SOA gelegt ist, kann mit der Transformation der gesamten
IT-Landschaft in die neue Service-orientierte Architektur begonnen werden. Dieser Schritt ist mit Sicherheit der aufwendigste des gesamten Projekts, aber nicht unbedingt der schwierigste – denn die schwierigsten Schritte sind mit Analyse und Planung bereits vorangegangen.
Vielmehr ist es jetzt geboten, die Roadmap konsequent – und aufgrund des Umfanges und der sich laufend verändernden Rahmenbedingungen unbedingt iterativ – umzusetzen.
Immer dann, wenn eine weitere Ausbaustufe erreicht wurde, sollten deshalb die Schritte 2 und 3 erneut durchlaufen werden, um Ziele und Planung wieder an eventuell veränderte Umstände und neu gewonnene Erkenntnisse anzupassen.

Schritt 7: Verifizierung der Zielvorgaben

Bei langfristigen strategischen Projekten wie einer SOA-Transformation ist es nie einfach, sich an den ursprünglichen Zielvorgaben zu orientieren. Langfristige Ziele haben eine starke Tendenz, sich als ‹Moving Targets› zu entpuppen: Neue Ziele kommen hinzu; alte fallen einfach weg.
Dies ist ein weiterer wichtiger Grund, den beschriebenen iterativen Prozess einzuhalten und auch dann konsequent fortzusetzen, wenn das formulierte Ziel bereits erreicht zu sein scheint. Nur so bleibt es möglich, sich flexibel auf veränderte und neue Zielvorgaben einzustellen.
Wann ist dann allerdings jemals das Ziel erreicht? Eigentlich darf diese Frage in Zeiten der sich durch Globalisierung und Internet ständig verändernden Rahmenbedingungen gar nicht mehr gestellt werden – schliesslich sind Flexibilität und Effizienz heutzutage Trumpf und einige der wichtigsten Argumente überhaupt für die Einführung von Service-orientierten Architekturen. Der Erfolg einer SOA-Transformation sollte sich daher auch genau daran messen lassen: an höherer Flexibilität bei gleichzeitig geringeren Kosten.

Die vier Hauptphasen bei der SOA-Implementation

Phase 1: Planung und Organisation
Im Fokus der ersten Phase stehen die Analyse des Ist-Zustandes sowie die Festlegung des Umfanges der SOA-Transformation. Nach Abschluss dieser Planungs- und Organisationsphase muss Klarheit bestehen über den Ist-Zustand, den Ziel-Zustand und den bis dahin einzuschlagenden Weg.



Phase 2: Pilotierung und Basisdienste

Phase 2 stellt fast alle Weichen für die Zukunft – und ist deshalb auch die wichtigste! Im Rahmen eines Pilotprojektes werden erste Erfahrungen mit einer SOA-Architektur und den zugrundeliegenden Technologien gesammelt. Die so gewonnenen Erkenntnisse fliessen danach direkt in die Implementierung von SOA-Basiskomponenten sowie die Einführung primärer Basisdienste ein. Am Ende dieser Phase sollten alle notwendigen Prozesse und das Know-how für die Implementierung weiterer Dienste sowie für den Betrieb und die Nutzung der bis dato implementierten Dienste vorhanden sein.



Phase 3: SOA-Transformation

Innerhalb der dritten (und in der Regel umfangreichsten) Phase erfolgt das sukzessive Einbinden aller verbleibenden Systeme und deren Dienste in die SOA. Darüber hinaus können zusätzliche Mehrwertdienste wie Business Orchestration, Business Rules, Workflow etc. implementiert werden.



Phase 4: Weiterentwicklung und Betrieb

Keine unternehmensweite IT-Architektur ist jemals ganz fertig – auch eine SOA macht da keine Ausnahme. Gerade vor dem Hintergrund sich ständig verändernder wirt-
schaftlicher Rahmenbedingungen ist Agilität auch – oder gerade – im IT-Bereich unabdingbar. Deshalb sind die kontinuierliche Weiterentwicklung, Anpassung und Verbesserung bestehender und die Einführung neuer Dienste sowie die Optimierung des laufenden Betriebs notwendig.

Der Autor

Stefan Thurow arbeitet als Senior Architect bei Avanade, einem global operierenden Joint Venture von Accenture und Microsoft.