SOA, BPM und Enterprise Architecture

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ößten 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ößtenteils 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.

Der taktische Transformationsansatz 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-(EAI-)Plattform 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:

1. Unterteilung der bestehenden Systemlandschaft in unabhängige Subsysteme. 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 außen hin aufweisen.

2. Implementierung und Test einer EAI-Plattform mit den erforderlichen Adaptern zur Anbindung der einzelnen Subsysteme. Anmerkung: Bis zu diesem Zeitpunkt bleibt die bestehende produktive Systemlandschaft unangetastet. Die EAI-Plattform wurde mittels Testsystemen getestet und steht nun in der Produktivumgebung bereit.

3. Die Subsysteme werden nun schrittweise mit der EAI-Plattform verbunden; die alten Punkt-zu-Punkt-Verbindungen 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 beispielsweise 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. 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. Parallel dazu kann mit dem Ausbau der EAI-Plattform zu einem ESB das SOA-Zeitalter eingeläutet werden. Konkret bedeutet 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. 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ößten Vorteile. Wenn am Ende alle Systeme ausschließlich Web Services nutzen und auch bereitstellen, ist die SOA-Transformation abgeschlossen.

Der strategische Transformationsansatz 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.

Das schrittweise Vorgehen:

1. 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 gleichermaßen genutzt werden können, und geschäftsspezifische Dienste (beispielsweise Rechnungswesen, Auftragsbearbeitung, etc.).

2. 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 außer Acht gelassen, die aus technischen oder funktionalen Gründen bereits zur Ablösung oder Stilllegung vorgesehen sind. Das Ergebnis weist in der Regel einige nicht unerhebliche Lücken auf, die mit neuen Applikationen besetzt werden müssen.

3. 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. 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. 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. 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 Unternehmenssituation genau zu prüfen. Der taktische SOA-Transformationsansatz eignet sich für Unternehmen mit einem relativ stabilen Geschäftsmodell und einer im Großen 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 allen beteiligten Abteilungen umzusetzen.

Autor: Stefan Thurow, Senior Architect bei Avanade.