IT-Management Offen für neue Architekturen

Die Transformation bestehender IT-Infrastrukturen hin zu serviceorientierten Architekturen ist anspruchsvoll. Methodisches Vorgehen ist daher eine Grundvoraussetzung.
Von Stefan Thurow

Vor dem Start der Transformation von serviceorientierten Architekturen (SOA) stehen das Verständnis und die Dokumentation der Ausgangssituation. Erst die Ergebnisse dieser Analyse ermöglichen die Planung und bilden eine wichtige Basis für die weitere Entscheidungsfindung.

In der funktionalen Modellierung werden alle Funktionen und Unterfunktionen des Geschäftsmodells nach Geschäftsbereichen gruppiert und grafisch dargestellt. Aus dem Geschäftsmodell ist dann ersichtlich, welche Funktionen und Fertigkeiten ein Unternehmen zur Durchführung seiner Geschäftsprozesse benötigt.

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 einer Grafik darstellen, die alle Applikationen in der einen Achse und alle Funktionen in der anderen Achse auflistet. An den Schnittpunkten lässt sich ablesen, welche bereits bestehenden Applikationen welche Funktionen unterstützen.

Innerhalb der technischen Applikationsanalyse werden bestehende Applikationen hinsichtlich ihrer Tauglichkeit für eine künftige SOA bewertet. Dabei kommen unter anderem 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 Karte der aktuellen Applikationslandschaft. Diese Karte deckt funktionale und technische Schwachstellen und Lücken sehr anschaulich auf.

Lückenfreie Applikationslandschaft

Lückenfreie Applikationslandschaft

Jetzt lässt sich der ideale Zielzustand deutlich ablesen: eine lückenfreie Applikationslandschaft ohne technische Schwachstellen und funktionale Überlappungen. Um diesen Zustand zu erreichen, sind strategische 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 Schritt ist die Definition der Servicelandschaft, wobei das funktionale Geschäftsmodell wiederum wertvolle Dienste leistet. Bei genauer Betrachtung wird klar, dass eigentlich nur das Wort Funktion durch Dienst (Service) ersetzt werden muss, um einen ersten Entwurf zu erhalten.

Es sind allerdings weitere Schritte notwendig, um diesen ersten Entwurf in eine technisch sinnvolle Servicelandschaft zu überführen: die Identifizierung von Basisdiensten, B2B- und B2C- sowie regionalen oder geschäftsbereichspezifischen Diensten, die Skizzierung der Systemgrenzen und unbedingt die Festlegung der Datenhoheit. Beim Entwurf der Dienste gilt es zudem auf Granularität und Semantik zu achten: Dienste einer SOA orientieren sich immer an echten Geschäftsvorfällen, nicht an technischen Gesichtspunkten!

Nun kann die Umsetzung strategisch geplant werden; eine Detailplanung erscheint aufgrund des Umfangs und (noch) fehlender Erfahrung zum gegenwärtigen Zeitpunkt nicht sinnvoll. Mittels einer zu entwerfenden Roadmap wird das Gesamtvorhaben der SOA-Transformation in überschaubare Häppchen aufgeteilt und nach strategischen Gesichtspunkten bewertet.

Jedes Teilprojekt sollte dabei nach einheitlichen Kriterien beurteilt werden, die anschließend zur Positionierung der Projekte innerhalb der Roadmap herangezogen werden. Diese Kriterien sind zum Beispiel die Höhe der notwendigen Investitionen, die Höhe des Einsparpotenzials sowie Komplexität und Abhängigkeiten zu anderen Projekten der Roadmap.

Überschaubare Häppchen

Überschaubare Häppchen

Am Anfang einer SOA-Pilotierung ist darauf zu achten, dass zumindest Service Repository, Servicerichtlinien, Sicherheitskonzepte, Message Routing sowie Reliable Messaging als wichtige Konzepte und Technologien bereits Bestandteil sind. Darüber hinaus sollte sich die geplante Zielarchitektur mit der Architektur des Piloten weitestgehend decken.

Ist es also etwa vorgesehen, künftig einen Enterprise Service Bus einzurichten, sollte diese Plattform schon Bestandteil des Piloten sein. Daneben gilt es, auch die notwendigen Entwicklungs- und Testumgebungen einzurichten, den Know-how-Aufbau der Entwickler aktiv zu fördern und wichtige Schlüsselwerkzeuge wie XML- und Designtools einzuführen.

Beim Einsatz von Unified Modeling Language für SOAs ist jedoch Vorsicht geboten. Aufgrund ihrer starken Ausrichtung an objektorientierten Konzepten ist diese zum Design für SOAs nur eingeschränkt tauglich. Besser geeignet sind Tools, die Domain Specific Language für SOAs unterstützen. Nach der Pilotphase sind die Erkenntnisse zu analysieren und in der Transformationsphase anzuwenden. Bewährt hat sich die Strategie, die gewonnenen Erkenntnisse in die Ziel- und Systemarchitektur sowie in die Roadmap einfließen zu lassen.

Transformation durch Iteration

Darauf aufbauend kann mit der Transformation der gesamten IT-Landschaft in eine SOA begonnen werden. Dieser Schritt ist mit Sicherheit der aufwendigste, aber nicht unbedingt der schwierigste – denn die schwierigsten Schritte sind mit Analyse und Planung bereits realisiert. Vielmehr ist jetzt die Roadmap konsequent und aufgrund des Umfangs sowie der sich verändernden Rahmenbedingungen unbedingt iterativ umzusetzen.

Bei langfristigen, strategischen Projekten wie einer SOA-Transformation ist es nie einfach, sich an den ursprünglichen Zielvorgaben zu orientieren. Neue Ziele kommen hinzu, alte fallen weg. Dies ist ein weiterer wichtiger Grund, den beschriebenen iterativen Prozess einzuhalten und auch dann konsequent fortzusetzen, wenn das formulierte Ziel erreicht zu sein scheint.

Wann ist das Ziel allerdings jemals erreicht? In Zeiten sich ständig verändernden Rahmenbedingungen ist das die falsche Frage – schließlich sind Flexibilität und Effizienz einige der wichtigsten Argumente für die Einführung von SOAs. Der Erfolg einer SOA-Transformation sollte sich daher auch genau daran messen lassen: an höherer Flexibilität bei gleichzeitig geringeren Kosten.

Mehr lesen über