Die richtigen SOA-Züge

Einer Umfrage des IT-Dienstleisters Capgemini zufolge steht das Thema serviceorientierte Architektur (SOA) für jedes fünfte Unternehmen ganz oben auf der Prioritätenliste. Die Gründe für das wachsende Interesse sind leicht nachzuvollziehen: Auf der Basis einer SOA lässt sich eine an den Geschäftsprozessen ausgerichtete IT-Infrastruktur aufbauen, mit der ein Unternehmen schnell auf veränderte Anforderungen reagieren, Dienste und Anwendungen in verschiedenen Kontexten einsetzen und obendrein Redundanzen abbauen kann. Soweit die Theorie. In der Praxis fühlen sich derzeit jedoch zahlreiche Unternehmen mit der schier endlosen Auswahl unterschiedlicher Ansätze und Methoden alleingelassen. Gerade mittelständischen Unternehmen stellt sich die Frage, ob sich eine derart weitreichende Umstellung ihrer IT-Architektur überhaupt lohnt. Oder geht es letzten Endes vielleicht doch nur um Megaprojekte für die IT von Konzernen?

Unternehmensgrösse nicht entscheidend
Eine SOA ist nicht in erster Linie eine Technik, sondern vielmehr eine Idee. Kurz gesagt bildet eine SOA ein breit angelegtes Rahmenwerk, in dem sich Software-Module erstellen, verwalten und kombinieren lassen. Und manchmal ist es durchaus sinnvoll, dieses Rahmenwerk sukzessive auszubauen. Deshalb die klare Antwort für jedes mittelständische Unternehmen: eine SOA ist keine Frage der Größe und des Startkapitals. Ihr Nutzen hängt vielmehr davon ab, ob die Einführung richtig durchdacht, geplant und umgesetzt wird. In diesem Kontext bringt die evolutionäre Einführung einer SOA gegenüber einer Big-Bang-Strategie zahlreiche Vorteile mit sich. Denn ein behutsamer Wechsel verringert die Gefahr, dass bewährte Systeme vorzeitig ausgemustert, Vorhandenes nicht mehr integriert und auch die Gewohnheiten der Nutzer nicht genügend berücksichtigt werden. Ganz zu schweigen von den deutlich kostenfreundlicheren Rahmenbedingungen bei einer schrittweisen Veränderung der IT-Strukturen.

Alles dreht sich um den fachlichen Service
Dreh- und Angelpunkte einer SOA sind ihre Services genannten Software-Bausteine. Ein Service beschreibt eine wohldefinierte, in sich abgeschlossene fachliche Funktion. Der fachliche Charakter eines Services ist hierbei von besonderer Bedeutung: Während die konventionelle Anwendungsarchitektur eher technische Schwerpunkte setzt, stellt die prozessorientierte SOA die fachlichen Aspekte der Geschäftsprozesse in den Vordergrund. Die Services einer SOA sind IT-Einheiten, die einen in sich geschlossenen Verarbeitungsschritt eines Geschäftsprozesses ausführen. Sie bieten die Möglichkeit, Software-Komponenten lose gekoppelt miteinander interagieren zu lassen. Der größte Nutzen dieser losen Kopplung ist ein deutlich höheres Maß an Agilität. Sie äußert sich unter anderem in der Möglichkeit, durch die Komposition von Services geänderte oder neue Geschäftsprozesse innerhalb kürzester Zeitspannen abbilden zu können. Ein anschauliches Beispiel für Prozesse, die auf der Idee der SOA beruhen, bildet die Erstellung eines Archiv-Services. Ein derartiger Dienst stellt einem System die unterschiedlichsten Daten über einfache und definierte Schnittstellen zur Verfügung. Anwendungen, die auf Archiv-Services zugreifen, können die gelieferten Daten dann individuell nutzen und weiter verarbeiten. Verwendung finden diese gut organisierten und zudem leicht zugänglichen Datensätze unter anderem auf Internet-Präsenzen oder auch in internen Redaktionssystemen, beispielsweise zur Erstellung von Druckmedien. Der große Vorteil dieser Integrationsstrategie liegt auf der Hand: Ein solcher Dienst muss nur einmal erstellt und kann zugleich von mehreren Anwendungen genutzt werden. Unabhängig von der Art der Geschäftsprozesse gilt jedoch, dass zur Konzeption der Service-Granularität stets ein hohes Maß an Erfahrung und Augenmaß gefragt ist. Services lassen sich über standardisierte Schnittstellen aufrufen und können zudem auch für einen geänderten oder sogar komplett neuen Prozess genutzt werden. Was die meisten Mittelständler freuen wird: Die auf Services basierende SOA ist ein technologieneutraler Architekturstil und kein Produkt. Denn Services entsprechen nicht Objekten und können durch Web-Services-Technologien realisiert werden, müssen es aber nicht unbedingt. Und das wiederum macht das Unternehmen unabhängig von Entwicklern oder Lizenzen und wirkt sich damit auch erfreulich auf die Kosten aus. Anwender können mit .Net genauso agieren wie mit Corba, J2EE, Web Services oder natürlich mit Host-Systemen.

Top-Down oder Bottom-Up?
Zur Einführung einer SOA gibt es zwei verschiedene Vorgehensweisen. Der Top-down-Ansatz entspricht dem Big Bang, der schlagartigen Umstellung des Unternehmens und seiner gesamten IT auf SOA. Diese Methode beginnt stets mit einer Analyse der Geschäftsprozesse. Die definierten Prozesse werden dann auf Basis der SOA implementiert. Auch wenn dieses Vorgehen auf den ersten Blick nur Vorteile mit sich zu bringen scheint, birgt es doch zahlreiche Risiken: Neben den hohen Initialkosten lauern sowohl die Gefahren kultureller Verwerfungen und sozialer Widerstände als auch die Tücken einer zu hastigen und damit unzureichenden Organisation. Die plötzliche Umstellung der gesamten Arbeitsumgebung und eine fehlende Lernphase können zu einer Überforderung der Mitarbeiter und damit zu weiteren Effizienzeinbußen führen. Die weitreichende Dimension und die extremen Laufzeiten solcher Big-Bang-Projekte können die geschäftskritischen Prozesse eines Unternehmens auf empfindliche Weise verzögern, ja sogar gefährden.

Rascher Nutzen und geringes Risiko
Deutlich schonender als die Top-down-Methode ist der sogenannte Bottom-up-Ansatz. Mit ihm lassen sich die Risiken einer zu schnellen, großflächigen SOA-Einführung reduzieren. Hier wird die SOA punktuell durch eine zusätzliche Web-Services-Schnittstelle für eine bestehende Funktionalität eingesetzt. Damit steht die entsprechende Software-Komponente nun auch als Dienst zur Verfügung. Die Vorteile dieser behutsameren Herangehensweise liegen in einem raschen, unmittelbaren Erfolg, einer ebenso zügigen Amortisation, einer effektiven Lernphase bei den Mitarbeitern sowie einem parallelen Aufbau von technischer Umgebung, personellem Know-how und organisatorischen Strukturen. Das Bottom-up-Verfahren führt jedoch nicht zu einer geschlossenen Gesamtarchitektur im Sinne einer SOA. Um die Vorteile der Bottom-up-Vorgehensweise zu verdeutlichen, sei ein konkretes Einführungsszenario für ein mittelständisches SOA-Projekt vorgestellt. Der Ansatz basiert nicht auf der Analyse der kompletten Geschäftsprozesse und ist damit weniger strategisch als vielmehr punktuell durchdacht und damit als taktisch zu verstehen. Diese evolutionäre Methode beginnt mit einfachen Szenarien, die komplexe und zudem kostspielige Infrastrukturen noch nicht unbedingt erfordern. Damit kann ein Unternehmen gleichzeitig vermeiden, Produkte zweifelhafter Reife einzusetzen. Dieser sowohl geld- als auch nervenschonende Ansatz gliedert sich in fünf Einzelschritte.

Projektdefiniton
Der erste Schritt einer solchen taktischen IT-Umstellung liegt in der Definition des Projekts. Zum Einstieg in eine SOA sollte ein Unternehmen einen Prozess identifizieren, der in das erste Projekt und damit in den ersten Service umgewandelt werden kann. Das Projekt, also die Implementierung des Services, muss unbedingt einen praktischen Nutzen erfüllen und einen geschäftlichen Wert haben. Außerdem fungiert die erste serviceorientierte Modifizierung zugleich als Grundstein und erste Stufe der SOA. Es empfiehlt sich, mit einem kleinen und überschaubaren Service zu beginnen, der genutzt werden soll. Hier bietet sich beispielsweise ein Bonitäts-Auskunfts-Service an, der bei entsprechenden Dienstleistern eine Auskunft einholt und die Information anschließend allen relevanten Systemen zur Verfügung stellt. Auch dieser Service muss nur einmal realisiert werden, um anschließend von mehreren Anwendungen des Unternehmens gleichzeitig genutzt werden zu können. Grundsätzlich sollte die Planung erster SOA-Module auf den Einsatz weniger Ressourcen und auf eine kurze Laufzeit zielen, da sich nur so die Risiken komplexer Projekte vermeiden lassen.

Wahl der Technologien
Im zweiten Schritt geht es um die Wahl der Technologien. Die oberste Maxime lautet: Vorhandenes nutzen. Die Entwicklungsumgebung, Web Services oder auch Application Server müssen in die Planung eines neuen Dienstes eingebunden werden. Am Anfang ist es zudem sinnvoll, mit einer SOA ohne Orchestrierung und ohne Enterprise Service Bus (ESB) zu beginnen und vielmehr auf die Möglichkeiten von bloßen Web Services zu setzen. Gerade mittelständische Unternehmen können besser in gute Architekten als in neue Technologien investieren. In diesem Zusammenhang ist es vor allen Dingen wichtig, standhaft zu bleiben und sich nicht von der Produktvielfalt verunsichern zu lassen.

Projektmanagement und -Planung
Der dritte Schritt betrifft die Durchführung des Vorhabens – durchaus mit herkömmlichem Projektmanagement. Bei der Planung und Durchführung des konkreten SOA-Teilprojekts kommt es vor allem darauf an, pragmatisch zu bleiben und nicht weit über das eigentliche nächstgelegene Ziel hinaus zu planen. Außerdem ist die Überlegung sinnvoll, inwieweit Dienste als Web Services implementiert werden sollten. Im vierten Schritt einer taktischen und gleichwohl soliden Einführung einer SOA geht es darum, die Planung und Durchführung weiterer Projekte ins Auge zu fassen. Hier beginnt der Zyklus von vorne – bereichert durch die Erfahrungen des Pilotprojekts. Funktionen und die Zahl ihrer Verwendungsmöglichkeiten müssen erneut definiert werden. Mit jedem umgesetzten Service erweitert sich das SOA-Netzwerk einer effizienten IT-Architektur. Damit ein optimales Zusammenspiel möglich ist, sollte beim Zuschnitt der Services auf die richtige Granularität geachtet werden: hier gibt es keine Patentrezepte. Wenn die Services zu umfangreich sind, kommen die IT-Mitarbeiter in die unangenehme Lage, Anwendungen über herkömmliche Enterprise-Application-Integration-Werkzeuge verbinden zu müssen. Sind die Services zu klein angelegt, erhält das Unternehmen schon nach kurzer Zeit einen Service-Zoo, der aufgrund seiner Unübersichtlichkeit schwer zu verwalten ist und mit an Sicherheit grenzender Wahrscheinlichkeit funktionale Überlappungen enthält. Deshalb ist es so wichtig, sich beim Zuschnitt der Services auf die Fachlichkeit zu stützen und den operativen Nutzen einer Funktion nicht aus den Augen zu verlieren.

Ausbau der Architektur
Die weitere Planung und der Ausbau der Architektur gelingen ohne eine Gesamtstrategie nicht. Im fünften Schritt empfiehlt es sich daher, ein projektübergreifendes Team einzuführen, das über eine Top-down-Sicht die weiteren Ausbaustufen festlegt, Synergien erkennt und Regeln aufstellt. Dieses Regelwerk betrifft Verantwortlichkeiten, Service Level Agreements und Implementierungsstandards. Ob zur Steuerung der einzelnen Arbeitsschritte eine Workflow Engine auf Basis der Business Process Execution Language (BPEL) erforderlich ist, sollte jedes Unternehmen für sich entscheiden. Gleiches gilt für weitere Module wie beispielsweise einen Enterprise Service Bus (ESB) oder andere Middleware. Wer auf eine schlagartige Implementierung verzichtet und SOA stattdessen in kleinen, konzentrierten Schritten einführt, der kann jedenfalls schon nach kurzer Zeit großen Nutzen aus der Idee einer SOA ziehen – letztlich unabhängig von der Größe seines Unternehmens.

Dr. Michael Bark ist Senior Consultant bei dem Hamburger IT-Dienstleister Evodion Information Technologies.