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.
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äftsmodell 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.
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.
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
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.
Nach dem Abschluss der Pilotierungsphase kommt es darauf an, die gewonnenen Erkenntnisse zu analysieren und in der nachfolgenden eigentlichen Transformationsphase anzuwenden. Bewährt hat sich hier die Strategie, die Schritte 2 und 3 nochmals zu wiederholen und die nun gewonnenen Erkenntnisse in die Zielarchitektur, 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.
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.
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.
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.
Stefan Thurow arbeitet als Senior Architect bei Avanade, einem global operierenden Joint Venture von Accenture und Microsoft.
