SOA im Mittelstand - kein Big Bang

Evolutionäre Einführung von Service-orientierter Architektur von Vorteil Kein SOA Big Bang im Mittelstand Entwickler wie Anwender haben es in den vergangenen Jahren ausgiebig diskutiert: Service- orientierte Architekturen bilden eine hervorragende Voraussetzung, um die IT-Landschaft eines Unternehmens auch auf lange Sicht zukunftsfähig zu machen. Doch trotz aller einhelligen Begeisterung sind klare und verständliche Anleitungen bisher Mangelware. Gerade für den Mittelstand stellt sich häufig die Frage, ob eine schlagartige Umstellung der gesamten IT-Struktur überhaupt rentabel ist. Deshalb plädieren Experten insbesondere beim gehobenen Mittelstand für eine evolutionäre Einführung der SOA. Von Dr. Michael Bark, evodion Information Technologies GmbH Einer Umfrage von Capgemini zufolge steht das Thema Service-orientierte Architektur in diesem Jahr für jedes fünfte Unternehmen ganz oben auf der Prioritätenliste. Die Gründe für die wachsende Begeisterung sind leicht nachvollziehbar: Auf 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, Services, 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 Modelle allein auf weiter Flur. Insbesondere mittelständische Unternehmen stellen sich die Frage, ob sich eine derart weit reichende Umstellung ihrer IT-Architektur überhaupt lohnt. Oder ist es letzten Endes doch nur ein Megaprojekt für die IT von Konzernen? Unternehmensgröße ist nicht entscheidend Eine Service-orientierte Architektur ist keine Technik, sondern vielmehr eine Idee. Kurz gesagt bildet das Konzept der SOA ein breit angelegtes Rahmenwerk, in dem sich Software-Services 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: SOA ist keine Frage der Größe. 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 Service-orientierten Architektur gegenüber einer Big Bang- Strategie sogar zahlreiche Vorteile mit sich. Denn ein behutsamer Wechsel verringert die Gefahr, dass bewährte Systeme 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 Service Dreh- und Angelpunkte einer SOA sind ihre Services. Ein Service beschreibt eine wohl definierte, 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ßerst 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, ist 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 Service-orientierter 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 dot.net genauso agieren wie mit CORBA, J2EE, Web-Services oder natürlich mit HOST-Systemen. Top-down oder Bottom-up? Zur Einführung einer Service-orientierten Architektur gibt es zwei grundlegende Vorgehensweisen. Der Top-down-Ansatz verkörpert den Big Bang, die schlagartige Umstellung des Unternehmens und seiner gesamten IT auf SOA. Diese Methode beginnt stets mit einer Analyse der Geschäftsprozesse. Die definierten Geschäftsprozesse werden danach 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 Gefahr 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 weit reichende 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. 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 Funktion nun auch als Dienst zur Verfügung. Die Vorteile dieser etwas 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. Taktik statt Strategie Um die Vorteile der Bottom-up-Lösung zu verdeutlichen, sei im Folgenden ein konkretes Einführungsszenarium 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 mit zweifelhafter Reife einzusetzen. Dieser sowohl finanz- als auch nervenschonende Ansatz gliedert sich in fünf Einzelschritte. 1. Projektdefinition 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. Außerdem fungiert die erste Service-orientierte 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. 2. Wahl der Technologie Die oberste Maxime lautet: Vorhandenes Nutzen. Die Entwicklungsumgebung, Web-Services oder auch Application-Server müssen in die Planung eines neuen Service 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 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. 3. Durchführung des Projekts mit klassischem Projektmanagement Bei der Planung und Durchführung des konkreten Projekts kommt es vor allem darauf an, pragmatisch zu bleiben und nicht weit über das eigentliche Projekt hinaus zu planen. Außerdem ist die Überlegung sinnvoll, inwieweit einer oder mehrere Services als Web-Services implementiert werden sollten. 4.