SOA meets BPM

SOA hilft BPM und BPM ist die Königsdisziplin der Serviceorientierung. Soweit die einfache These. Natürlich hat eine technisch ausgelegte SOA bereits oft eine starke Berechtigung, hilft sie doch bei der Entwirrung komplexer Schnittstellenknäuel. Wie bereits auch hier im Blog diskutiert sollte aber nicht auf BPM als das Wundermittel für den Erfolg der eigenen SOA gewartet werden. Vielmehr muss bei der Planung und Umsetzung der SOA entschieden werden, welches Ziel verfolgt wird. Wird SOA primär als Integrationsmethode genutzt, dann werden Funktionen und Daten möglichst aus existierenden Anwendungen zur Nutzung durch andere Anwendungen bereitgestellt. Die Herausforderung beim Zuschnitt der Services liegt primär darin, die Daten- und Funktionsartefakte der unterschiedlichen Anwendungen interoperabel zu gestalten und dabei die Konsistenz der Daten und Prozesse zu gewährleisten. Gelingt das und werden dabei Services mehrfach genutzt dann ist dies zweifelsfrei bereits eine sehr erfolgreiche SOA Einführung. Eine so gestaltete SOA lässt sich ohne intensive Einbindung der Fachseiten umsetzen, basiert sie doch im Wesentlichen auf IT Engineering bestehender Anwendungen, Daten und Funktionen.

Sind jedoch auch die Prozesse selbst das Ziel, dann müssen erheblich weiterführende Überlegungen angestellt werden. Oft kommt so die gesamte Anwendungslandschaft auf den Prüfstein, ebenso das Datenmodell. Also Kernelemente der IT Unternehmensarchitektur, womit wir über BPM beim Thema Enterprise Architecture Management angekommen sind. Die SOA wird Mittel zum Zweck, nur eine - zwar wichtige - Methode unter anderen. Sind bei einer technisch orientierten SOA die Varianten zur Gestaltung noch prinzipiell einfach, geraten BPM Lösungen selten ähnlich. Sicher gibt es auch für einen BPM Ansatz grundlegende Muster und “best practices”. Die hohen Freiheitsgrade, die ja in der Regel auch das Ziel der Nutzung von BPM Werkzeugen sind, erlauben sehr unterschiedliche Lösungen für nach außen hin ähnliche Aufgabenstellungen. Das Optimum zwischen Aufwand und Nutzen zu finden ist von erheblich mehr Faktoren abhängig, deren Ursprung auch nicht mehr primär in der IT Technik begründet ist. Kritischer Erfolgsfaktor für eine SOA basierte BPM Einführung ist also - deutlich stärker als bei einer technischen SOA - die enge, partnerschaftliche Zusammenarbeit zwischen IT und Fachseiten. Um dies erfolgreich zu etablieren muss vor allem in den Nahtstellen zwischen Fachseiten und IT umgedacht werden. Denn die Flexibilität einer SOA basierten BPM ist das Ergebnis einer durchdachten und diszipliniert umgesetzten Gesamtarchitektur und entsteht nicht durch Hau-Ruck Aktionismus. Das bedeutet, das IT Projekte nicht länger isoliert durchgeführt und allein durch den kurzfristigen Nutzen getrieben werden dürfen, sondern sich deutlich mehr auf die Bereitstellung von Infrastruktur und wieder verwendbare Funktionalität konzentrieren müssen. Schritt für Schritt entsteht so eine IT, die kurzfristige Anforderungen primär durch Konfiguration wieder verwendbarer Services bereitstellt und gleichzeitig in Zusammenarbeit mit den Fachseiten die strategische Ausrichtung des Unternehmens mitgestaltet und vorausschauend in klar geschnittene Funktionsblöcke der Anwendungslandschaft übersetzt. Eine starke und konsistente Governance der IT in den Dimensionen Budget, Portfolio, Standards und Ressourcen ist hierzu ebenso unverzichtbar wie ein konsequent ausgerichtetes Management der gesamten Architektur. Daraus darf aber kein schwerfälliger Wasserkopf entstehen, sondern ein pragmatischer und nutzenorientierter Partner der Fachseiten und der umsetzenden Kollegen der IT. Dies, liebe Leserinnen und Leser, ist die eigentliche Königsdisziplin.