SOA meets BPM

Die aktuelle Diskussion um die Verzahnung von BPM und SOA erinnert mich an das Modell des Schweinezyklus, das ich während meines Studiums der Wirtschaftsinformatik verinnerlichen durfte:

Dem Modell zufolge findet die Preisbildung für Schweine als Wechselspiel zwischen übermäßigen Investitionen (steigendes Angebot, das zu fallenden Preisen führt) und übermäßigen Desinvestitionen (sinkende Produktionskapazitäten, die zu steigender Nachfrage führen) statt. Da sich die Angebots- und Nachfrageseite durch Versuch und Irrtum einander nähern und am Ende ein Preis zustande kommt, der keine Erwartungen mehr enttäuscht, gleicht der Zyklus einem Pendel, das immer schwächer ausschlägt und irgendwann zur Ruhe kommt.

Zwar gilt dieses Modell in den Wirtschaftswissenschaften inzwischen als teilweise überholt (siehe auch das nicht weniger unterhaltsame “Saure-Gurken-Problem”). Das Prinzip des Einpendelns lässt sich jedoch in ähnlicher Form vorrangig in solchen Märkten beobachten, die von Visionen, Erwartungen, Enttäuschungen und Skeptizismus geprägt sind.

In der letzten Zeit wurden wir mit der Vision ausgestattet, dass uns BPM in Kombination mit SOA in die Lage versetzen wird, auf der Business-Ebene Prozesse zu gestalten, und diese auf Knopfdruck in der IT abbilden (ausführen, automatisieren), überwachen und steuern zu können. Dank nicht-proprietärer Methoden wie BPMN und BPEL sollte diese Vision Vendor-unabhängig funktionieren. Es entstand die Erwartung, dass wir in Kürze mit den entsprechenden Tools versorgt werden, um diese Vision Wirklichkeit werden zu lassen. Und tatsächlich, es traten Hersteller auf den Plan, die (zumindest im Marketing-Material) glaubhaft versicherten, die entsprechende Lösung anbieten zu können. Jedoch führten die ersten Praxisprojekte zu Enttäuschungen, die sich u.a. auf Defizite in der Organisation, in der Kompetenz, aber natürlich auch in den Tools zurückführen lassen. Im Ergebnis hat das gebrannte Kind natürlich Angst vorm Feuer, und die Skepsis ist emotional verankert.

Auf den ersten Blick stellt sich jetzt eine einfache Kernfrage: Ist die Vision in der Sache verfehlt, oder existieren Defizite in der Realisierung, die abgebaut werden können? Um diese Frage dreht sich die aktuelle Diskussion, und sie ist geprägt von zwei Fraktionen, nämlich denen, die dringend etwas verkaufen wollen, und denen, die sich dazu berufen fühlen, genau dies zu verhindern (manchmal, nicht immer, weil sie etwas anderes verkaufen wollen).

Auf den zweiten Blick, und diesen möchte ich vertreten, stellt sich - völlig unabhängig davon - die Frage, ob die Vision überhaupt vollständig realisiert werden muss, um faktische Vorteile zu generieren. Im Grunde geht es doch nur darum, einige Methoden und Tools zu entwickeln, um informationszentrierte Prozesse besser (einfacher, schneller und flexibler) realisieren und betreiben zu können. Dafür ist es doch gar nicht zwingend erforderlich, einen Prozess vom Anfang bis zum Ende und von Top bis Down durch das Business so modellieren zu lassen, das eine Engine das Modell sofort verwerten kann. Es reicht völlig, für bestimmte Aspekte im Prozess neue Konfigurationsmöglichkeiten bereit zu stellen, für deren Handhabung man kein Programmierer sein muss. Das Business Rules Management geht genau in diese Richtung, und wer mir erzählen will, Business Rules hätten mit BPM nichts zu tun, hat entweder noch nie ein Prozessmodell mit Verzweigung gesehen (Business), oder eine if-then-Abfrage gebaut (IT). Für diesen Zweck (die abgestufte Automatisierung, nicht das BRM) ist die BPMN eine absolut praxistaugliche Methode, wobei auch ich den Mehrwert des Mappings auf BPEL in der derzeitigen Form sehr infrage stellen würde.

Und SOA, die heilige Kuh der IT-Architekten, kann als eigenständige Methode völlig unabhängig von BPM natürlich ganz fantastisch funktionieren. Das Problem bei SOA ist einfach nur, dass der Begriff inzwischen für alles und jeden herhalten muss (Prof. Dr. Robert Winter aus St. Gallen bemerkte, in Anspielung auf den OOP-Hype vor 20 Jahren, unlängst, dass seine Katze inzwischen ebenfalls service-orientiert sei). Es gibt eben das SOA-Paradigma auf der reinen Software-Ebene, und es gibt bestimmte Aspekte des Paradigmas, die in Kombination mit BPM in der Entwicklung und im Betrieb einer IT-Architektur bestimmte Vorteile generieren können (aber nicht müssen). Der vorgenannte Professor hat mit seiner Differenzierung des Begriffes (SOA auf Software-Ebene, auf Prozessebene, und auf der Agilitätsebene dazwischen) einen meines Erachtens extrem wichtigen Beitrag geleistet, um die diversen Meinungen ein wenig sortieren zu können. Und es ist halt so, dass wir auf der Software-Ebene inzwischen schon ziemlich weit sind in Bezug auf unser Verständnis, “wie es funktioniert”, auf der Agilitätsebene hingegen immer noch im Sandkasten spielen, und von der Prozessebene noch träumen dürfen. Das muss man bedenken, aber es ist kein Drama.

Die Essenz:

Ich kann aus dem Stand heraus eine ganze Reihe von Vorteilen aufzählen, die sich - hier und jetzt - mit Prozessautomatisierung bzw. einer BPM/SOA-Kombination realisieren lassen. Das sind keine weltbewegenden Dinge, aber sie schaffen Mehrwert, und sie sind auch heute schon mit vertretbaren finanziellen Aufwänden realisierbar - ich weiß das, weil ich es getan habe. Ich glaube, wir können uns Schritt für Schritt unserer Vision annähern, wo es aktuellen Mehrwert bietet, und solche Schritte vermeiden, die nicht praktikabel sind. Und sollte sich auf unserem Weg herauskristallisieren, dass unsere Vision in der jetzigen Form gar nicht sinnvoll ist, dann kann auch diese nachgebessert werden.

Der Begriff “Learning by Doing” stammt von Robert Baden-Powell, dem Gründer der Pfadfinderbewegung. Dort werden 15-jährige Gruppenleiter mit 3-8 Gleichaltrigen, für die sie Verantwortung tragen, auf mehrwöchige Großfahrten ins Ausland geschickt. Trotz fehlender Erwachsener gibt es weder Alkohol- noch Drogenexzesse (zumindest keine schlimmen), und der Weg durch die Wildnis wird mit Wagemut, Karte und Kompass bewältigt. Ich habe nie wieder in so kurzer Zeit so viel gelernt, wie in meiner Zeit als Pfadfinder.

Was wir meiner Ansicht nach für BPM-SOA brauchen ist die richtige Einstellung sowie die Kompetenz, mit “Karte und Kompass” umzugehen. Dann werden uns weder blinde Euphorie noch Schwarzmalerei daran hindern, fatale Fehler zu vermeiden und echte Chancen zu ergreifen.