SOA - Strategie oder Taktik?

Geht es um die Implementierung von SOA-Vorhaben, stehen viele Unternehmen und deren IT-Abteilungen vor einer Herausforderung ähnlich der Quadratur des Kreises: Ohne Beeinträchtigung des laufenden Betriebes sollen eine neue Technologie und neue Systeme eingeführt, alte Systeme stillgelegt und Datenbestände migriert werden – selbstverständlich bei gleichzeitig gesteigerter Agilität und zu geringeren Kosten. Bei unzureichender Planung lässt sich dieser Zielkonflikt kaum entschärfen! Verschiedene strategische und taktische Transformationsansätze – je nach Ausgangslage im Unternehmen und angestrebten Zielen – versprechen jedoch Erfolg.


Eines der grössten Probleme bei der Umsetzung von SOA-Vorhaben besteht in der Tatsache, dass im allgemeinen nicht bei Null gestartet wird, sondern vielmehr bereits eine Systemlandschaft existiert, die häufig historisch gewachsen, technisch und architektonisch veraltet und mit vielen Problemen beladen ist. Nicht selten sind sogar die Probleme mit der alten Systemlandschaft die treibende Kraft hinter der SOA-Initiative – in der Hoffnung auf eine «schöne neue Welt».
Für eine verständlichere Darstellung der Planungsansätze sei eine fiktive Ausgangssituation mit folgenden Merkmalen beschrieben:

- heterogene Systemlandschaft

- viele Punkt-zu-Punkt-Integrationsschnittstellen

- Einsatz unterschiedlicher, grösstenteils proprietärer Integrationstechnologien und Protokolle

- starke technische und funktionale Abhängigkeiten der Systeme untereinander

- keine Integrationsplattform im Einsatz.



Je nach Ausgangslage und individuellen Prioritäten können taktische oder strategische Ziele die Oberhand gewinnen. Dementsprechend muss auch der SOA-Transformationsprozess an diese übergreifenden Ziele angepasst werden.



Taktischer versus strategischer Transformationsansatz

Der taktische Trans-formationsansatz im Detail

Der taktische Ansatz zielt zunächst auf eine kurzfristige Verbesserung der Ausgangslage, indem zuerst die bestehende Applikationslandschaft durch Einführung einer Enterprise-Application-Integration-Plattform (EAI) entflochten wird. Die daraus resultierende Verringerung der Schnittstellenanzahl in Verbindung mit den verbesserten Überwachungs- und Managementfunktionen einer EAI-Plattform führt in der Regel schon kurzfristig zu einer Senkung der laufenden Betriebskosten. Gleichzeitig wird der kommenden SOA der Weg bereitet, da im nächsten Schritt der Zielzustand durch eine Aufwertung der EAI-Plattform hin zu einem Enterprise Service Bus (ESB) auf einem relativ geradlinigen Weg erreicht werden kann. Allerdings ist für ein solch schrittweises Vorgehen auch mehr Zeit einzuplanen und Kompromissbereitschaft nötig, da die bestehende Applikationslandschaft im Kern beibehalten wird. Eine radikale Umgestaltung ist auf diesem Wege nicht zu erreichen. Das schrittweise Vorgehen läuft beim taktischen Ansatz nach dem folgenden Muster ab:



1. Unterteilung in Subsysteme: Die bestehende Systemlandschaft muss in unabhängige Subsysteme aufgeteilt werden. Ein Subsystem besteht dabei aus einer Gruppe von Einzelsystemen, die gemeinsam eine klar abgegrenzte Funktion haben, untereinander eng gekoppelt sind, aber in ihrer Gesamtheit nur eine oder wenige Schnittstellen nach aussen hin aufweisen.

2. Implementation der EAI-Plattform: Umsetzung und Test einer EAI-Plattform mit den erforderlichen Adaptern zur Anbindung der einzelnen Subsysteme. Bis zu diesem Zeitpunkt bleibt die bestehende produktive Systemlandschaft unangetastet. Die EAI-Plattform wurde mittels Testsystemen evaluiert und steht nun in der Produktiv­umgebung bereit.



3. Anschluss der Subsysteme: Die Subsysteme werden nun schrittweise mit der EAI-Plattform verbunden; die alten Punkt-zu-Punkt-Verbindungen werden dabei aufgelöst. Wichtig: Bei diesem Schritt ist es nicht notwendig, umfangreiche Änderungen an den bestehenden Systemen vorzunehmen. Die bestehenden Schnittstellen werden sozusagen nur «neu verdrahtet», ohne dass die angeschlossenen Systeme davon etwas merken. Unterschiedliche Protokolle und Datenformate werden von der EAI-Plattform umgesetzt. Im Einzelfall lassen sich kleinere Änderungen jedoch nicht vermeiden. So kann es sein, dass ein System zusätzliche Informationen an seiner Schnittstelle bereitstellen muss, damit die EAI-Plattform die Informationen an das richtige Zielsystem weiterleiten kann.



4. Nutzung der Basisdienste: Im nächsten Schritt lassen sich die durch die Entflechtung gewonnenen Freiheitsgrade zur Modernisierung der bestehenden Systemlandschaft nutzen. Die Aktualisierung oder Ablösung von Altsystemen und die Einführung neuer Systeme fällt nun deutlich leichter, da immer nur eine Schnittstelle (zur EAI-Plattform) betroffen ist.



5. ESB-Migration: Parallel dazu kann mit dem Ausbau der EAI-Plattform zu einem ESB das SOA-Zeitalter eingeläutet werden. Konkret heisst das: Einführung von Web-Service-Standards (WS-*); sukzessive Ablösung bestehender proprietärer Schnittstellen durch Web Services. In dieser Übergangsphase muss die EAI-Plattform die Brücke zwischen der neuen und der alten Welt aufrechterhalten, indem sie die proprietären Protokolle der Altsysteme in Web-Service-Protokolle (und umgekehrt) umsetzt.



6. SOA-Upgrade von Einzelsystemen: Nun kann auch zügig mit der Implementierung von unternehmensweiten Diensten begonnen werden, denn erst durch die gemeinsame Nutzung und Wiederverwendung von Diensten entfaltet eine SOA ihre grössten Vorteile. Wenn am Ende alle Systeme ausschliesslich Web Services nutzen und auch bereitstellen, ist die SOA-Transformation abgeschlossen.



SOA-Transformationsansätze im Überblick

Der strategische Trans-formationsansatz im Detail

Der strategische Ansatz verzichtet zunächst auf kurzfristige Erfolge und setzt daher eine Investitionsbereitschaft voraus. Er beginnt mit der Definition der Zielarchitektur, ohne die bestehende Applikationslandschaft einzubeziehen, und führt somit zu einer wesentlich radikaleren Umgestaltung, die hier allerdings auch gewünscht ist. Bei gründlicher Planung und Vorbereitung können bei dieser Vorgehensweise viele Aufgaben parallel in Angriff genommen werden und demnach insgesamt schneller zum Ziel führen als ein von taktischen Notwendigkeiten geprägter Ansatz. Konkret wird beim strategischen Ansatz wie folgt vorgegangen:



1. Definition der Zielarchitektur:Entwurf der Zielarchitektur und Applikationslandschaft auf Basis der Anforderungen des (zukünftigen) Geschäftsmodells. Die Applikationslandschaft wird dabei aufgeteilt in unternehmensweite Basisdienste (wie zum Beispiel Dokumentenmanagement, Customer Data Integration, Referenzdatenmanagement etc.), die von allen Abteilungen und Geschäftsbereichen gleichermassen genutzt werden können, und geschäftsspezifische Dienste (beispielsweise Rechnungswesen, Auftragsbearbeitung etc.).

2. Abbilden bestehender Systeme: Nun wird versucht, die bestehende Applikationslandschaft auf die neue Ziellandschaft abzubilden, indem nach existierenden, die gewünschten Dienste der Ziellandschaft schon bereitstellenden Applikationen gesucht wird. Dabei werden jedoch diejenigen Systeme ausser Acht gelassen, die aus technischen oder funktionalen Gründen bereits zur Ablösung oder Stillegung vorgesehen sind. Das Ergebnis weist in der Regel einige nicht unerhebliche Lücken auf, die mit neuen Applikationen besetzt werden müssen.



3. Implementation des ESB: Planung, Implementierung und Test einer ESB-Plattform inklusive aller technischen Basisdienste (Service Directory, Metadata Repository, Rules Engine, etc.) sowie der dazugehörigen Überwachungs- und Analysemöglichkeiten.



4. Bereitsstellen der Basis-Services: Bereitstellung der unternehmensweiten Basisdienste aus der Ziel-Applikationslandschaft als Web Services im ESB. Anmerkung: Bis zu diesem Zeitpunkt bleibt die bestehende produktive Systemlandschaft unangetastet. Die ESB-Plattform wurde mit Testsystemen getestet und steht nun in der Produktivumgebung bereit.



5. Anbindung von Web-Diensten an den ESB: Jetzt kann mit der eigentlichen SOA-Transformation begonnen werden. Die bestehenden Systeme werden – nach und nach oder gleichzeitig – mit Web-Service-Schnittstellen versehen und an den ESB angebunden und profitieren nun von den Vorteilen der bereits vorhandenen Basisdienste.



6. Ablösen von «alten» Anwendungen: Parallel dazu können die als ungeeignet eingestuften alten Applikationen durch neue, Service-orientierte Applikationen abgelöst werden. Wurde die Ziel-Applikationslandschaft am Ende vollständig auf der Basis von Service-orientierten Applikationen umgesetzt, lässt sich auch hier die SOA-Transformation als abgeschlossen betrachten.

Fazit

Beide Ansätze haben ihre Vor- und Nachteile und sind deshalb hinsichtlich der konkreten Aufgabenstellung je nach Unternehmens­situation genau zu prüfen. Der taktische SOA-Transformationsansatz eignet sich für Unternehmen mit einem relativ stabilen Geschäftsmodell und einer im grossen und ganzen funktionierenden Applikationslandschaft, jedoch einer komplexen, historisch gewachsenen Integrationslandschaft. Der strategische SOA-Transformationsansatz hingegen ist eher geeignet für Unternehmen, die sich gerade neu ausrichten oder deren Applikationslandschaft den Anforderungen nur ungenügend gerecht wird, was eine Neugestaltung notwendig macht.
Wesentliche Voraussetzung zum Gelingen der jeweils gewählten Vorgehensweise ist es allerdings, einen gründlichen und methodischen Ansatz zu verfolgen und diesen mittels hohen kommunikativen Austausches zwischen sämtlichen beteiligten Abteilungen umzusetzen.

Der Autor

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