Risiken einer falschen Weichenstellung

Es ist weniger die Service-orientierte Architektur, die den Projektverantwortlichen Hürden in den Weg stellt. SOA hat mittlerweile einen hohen Reifegrad erreicht. Dieser spiegelt sich sowohl in der Unterstützung marktwichtiger Systeme, fundierter Fachliteratur zu diesem Thema als auch in zahlreichen, in den Unternehmen bereits realisierten SOA-Projekten wider. Auf Risiken treffen die Projektverantwortlichen vielmehr an der Nahtstelle zwischen den Geschäftsprozessen und der IT-Architektur. Bisherige Erfahrungen, die die Unternehmen vor allem im Rahmen von EAI-Projekten (Enterprise-Application-Integration) gemacht haben, helfen nicht weiter. Der Aufbau eines Unternehmensdatenmodells und die Erstellung eines unternehmensweiten Funktionalitäten-Repository sind Beispiele dafür. Obwohl beide Ansätze IT-technisch gesehen oft erfolgreich umgesetzt wurden,mussten sie prozessoral unter Wahrung fachlicher und betriebswirtschaftlicher Ziele zu kurz greifen. Denn um IT-Technik und Prozesse ohne hohe Projektrisiken unter einen Hut zu bringen, sind andere Konzepte gefordert, beispielsweise das Business- Domain-Modell (BDM).

BDM wirkt dreifach: Es reduziert die technische Komplexität der SOA, liefert einen schrittweisen Realisierungsansatz und verbessert die Kommunikation zwischen der Fachseite und den IT-Zuständigen. Für all das strukturiert BDM die fachliche Gesamtarchitektur in lokale Fachverantwortlichkeiten (Domains). So wird sie der zunehmenden Verteilung von Aufgaben im Unternehmen gerecht. Die technische Interaktion zwischen den Fachbereichen einschließlich der dafür notwendigen Schnittstellen ist weniger ein Problem. Sie lässt sich über BDM verhältnismäßig einfach in SOA ein- beziehungsweise an SOA anpassen. Zumal dank der auf Web basierenden Technologien nur wenige Schnitt-stellen adaptiert und geprüft werden müssen. Das wiederum erleichtert auch die Einführung eines Governance-Modells im Unternehmen. Die konzeptionelle Unterstützung durch BDM macht sich für das Unternehmen in einer weiteren Hinsicht bald bezahlt: Es strukturiert das SOA-Projekt in klar voneinander abgegrenzte Teilvorhaben und schließt so viele Risiken aus, die mit einem Großprojekt wie »SOA in einem Rutsch« einhergingen.Vor allem die Paradigmen und Regeln dieser Architektur, die dynamische Fachprozesse in Gang setzen, bergen, weil bisher völlig unbekannt, zahlreiche Umsetzungsrisiken. Sie werden parallel zum BDM durch den Einsatz eines Projekt-Vorgehensmodells umgangen.

Es liefert einen Leitfaden dazu, wie Anwendungen unterteilt werden müssen, damit sie logische, auf die Fachabteilungen zugeschnittene dynamische Services liefern. Die Kombination von BDM und Projekt- Vorgehensmodell hat einen weiteren Vorteil: So angeleitet, erkennen die Projektverantwortlichen schnell, in welchen (Fach-) Bereichen die Einführung der SOA mit ihren dynamisch interagierenden Web-Services nicht praktikabel ist beziehungsweise zu teuer kommt. Dafür typische Bereiche sind spezifische Business-to-Business-Dienstleistungen und die Verarbeitung von Massendaten im Produktionsbereich. In beiden sind die Prozesse äußerst geschäftskritisch. Hier dennoch in eine Web- Service-orientierte Verarbeitung einzusteigen, setzt fundierte Erfahrungen im Aufbau einer hochverfügbaren, -performanten und -skalierbaren SOA-Plattform voraus.

Dafür, die Migration zur SOA nicht einseitig als technische Service-Architektur voranzutreiben, spricht insbesondere der dynamische Charakter der Web-Services. Damit später die Prozesslogik an die sich immer schneller verändernden Anforderungen der Fachbereiche angepasst werden kann, müssen sich die Services gegenüber der kommenden Prozessgestaltung als flexibel erweisen. Dafür müssen diese Web-Dienste horizontal (wie zu trennen?) und vertikal (wie zusammenzufügen?) entsprechend strukturiert werden. Der Service-Zuschnitt wird allerdings nur dann aufgehen, wenn er sich strikt an den Geschäftsprozessen und deren wahrscheinlichen Ausprägungen orientiert. Ein Top-down-Ansatz, der vor allem auf die Zuarbeit der Fachbereiche angewiesen ist, liefert für die richtige Service-Ausgestaltung die notwendigen, fachlichen Inhalte. Erst danach sollten die konkreten Services auf die dafür notwendigen IT-Systeme gespiegelt werden (Meet-in-the-Middle-Ansatz).