Denn als ich neulich im Zuge der Wochenendplanung die Zitty durchblätterte viel mir der kleine Cartoon zu unserer Linken in die Hände. Und mir drängte sich sofort der Vergleich zu Workflow-Engines auf, auch wenn dies aus sozial-psychologischer Sicht vielleicht bedenklich ist

Fragt man Projekte warum sie Workflow- bzw. Process-Engines selbst bauen möchten hört man häufig:

• “Wir haben nur ganz einfache Anforderungen, einen ganz simplem Zustandsautomat. Da ist eine Workflow-Engine Overkill.”
• “Wir müssen die Engine in die eigene Anwendung einbauen.”
• “Wir haben Produkt x evaluiert und es passt einfach nicht”

Klingt ja soweit auch ganz plausibel, oder? Ich möchte den Argumente jedoch ganz kurz ein paar Gedanken widmen:

Wir haben nur ganz einfache Anforderungen

Mit jedem eingesetzten Produkt oder Framework steigt natürlich die Komplexität. Auch ist die Lernkurve mancher Workflow-Engines nicht gerade flach, gar keine Frage. Ich habe es jedoch schon so oft gesehen, dass mit einem einfachen Zustandsautomaten gestartet wird, meist dann so irgendwie eine Entät/Tabelle pro “Prozessinstanz” mit einer Spalte, die den Zustand angibt. Denn Persistenz und eine Datenbank braucht man ja sowieso.

Aber Moment, wenn ich Wartezustände habe, brauche ich dann nicht auch Timeouts oder Eskalationen?

Oder möchte ich nicht vielleicht von einem Zustand in einen Folgezustand “gehen”, wobei ich eine Entscheidung treffen muss (also ein datenbasiertes exklusives Gateway in BPMN)?

Naja, ok, das bauen wir schon auch irgendwie in den eigenen Zustandsautomat ein. Die Softwareentwicklung hat ja auch vor der Existenz von Workflow-Engines funktioniert. Werkelt man also weiter vor sich hin, möchte man häufig die Prozesse flexibler haben. Also fix ein XML-Format definiert. Eventuell sogar dem Standard XPDL oder bald BPMN 2.0 bedient, aber eher nicht. Ist ja auch wieder zu komplex. Es soll nur bitte der (Produkt-) Manager nicht mit dem Wunsch nach grafischer Darstellung der Porzesse kommen! Wozu auch, XML ist doch eh prima lesbar.

Okay, geschafft. War doch ganz einfach. Und wir haben keine unnötigen Features in unserer Maschine

Aber wir haben eben leider auch manch anderes nicht unbedingt in unserer Maschine: Skalierbarkeit? Concurrency bedacht? Versionierung von Prozessen? …?

Brauchen wir doch auch nicht, wir haben ja auch nur einfache Anforderungen. Und das Produkt entwickelt sich ja auch nich weiter, wenn man erstmal Begehrlichkeiten nach Workflows geweckt hat? Oder vielleicht benutzt es mal der Kollege an einer anderen Stelle (Hurra, Wiederverwendung)? In meiner Projekterfahrung habe ich auf jeden Fall schon so viele Engines gesehen, die dann doch nach und nach aufgebohrt wurden/werden mussten und am Schluß auch ganz schön leistungsfähig waren. Und dabei ist es dann nicht nur um die Personentage der Entwicklung schade, sondern vor allem um die Wartung. Und im gegensatz zur Neuentwicklung macht die noch nicht mal Spaß.

Wir müssen die Engine in die eigene Anwendung integrieren

Soll die Engine in das eigene Produkt eingebaut werden gelten in der Tat andere Regeln. Viele BPM Produkte und Workflow-Engines sind hier wirklich ungeeignet, wenn auch nicht generell. Das man Integration mit der eigenen Anwendung nicht mit Webservices realisieren möchte, nun das verstehe ich gut. Auch kommen manche Engines als dicke Server daher, mit entsprechenden Installtions- und Hardware-Anforderungen. Und günstig sind die Produkte auch nicht, schon dreimal nicht wenn man sie ins eigene Produkt integriert und weiterverkaufen möchte.

Aber spätestens seit die Open Source Gemeine Process Engines entdeckt hat, gilt dieses Argument nicht mehr. Mit den verschiedenen Vertretern dieser Zunft (Beispielsweise JBoss jBPM, Nova Bonita oder Enhydra Shark) kann eine meist leichtgewichtige Java Engine in die eigene Anwendung problemlos integriert werden. Oft bieten die Engines entsprechend vielseitige Konfigurationsmöglichkeiten, so dass sie entsprechend dem eigenen Bedarf angepasst werden können. Teilweise kann auch die Workflow-Sprache noch angepasst oder erweitert werden.  Konsequent zu Ende gedacht ist dies aktuell auch in der JBoss Process Virtual Machine (PVM), die nur den grundlegenden Zustandsautomat definiert, und keine Sprache. Möchte man also tatsächlich eine eigene Engine bauen, könnte man dies zumindest als Grundlage nehmen um nicht das ganze Rad neu zu erfinden.

Wir haben x evaluiert, es passt nicht

Den Punkt habe ich reserviert, um mir ein bisschen Frust von der Seele zu schreiben Evaluieren heißt halt leider mehr, als einen Studi nen Tag ranzusetzen, der das dann auf Anhieb erst mal nicht zum Laufen bekommt. Ich entschuldige mich bei allen, die sich auf den Schlips getreten fühlen (aber wer trägt denn in der IT heute noch Schlips )! Ja, es ist leider wahr, dass gerade die Open Source Engines eine gewisse Einstiegshürde legen. Also mal eben nebenbei aufsetzen ist daher recht schwierig. Man muss sich also ein bisschen Zeit nehmen. Um einmal jBPM als Beispiel zu nehmen: Bisher hatte ich bei keinem Kunden in einem Workshop etwas gefunden, was mit jBPM nicht relativ einfach umgesetzt werden kann. Immerhin sind in die aktuelle Version einige Jahre an Reifeprozess und Erfahrung eingeflossen. Meist erlebt man schon nach einigen Minuten bei der ersten Frage ein “Ah ha”-Erlebnis beim Kunden: “So geht das also. Cool. Ist ja ganz einfach. Zum Glück haben wir das nicht selbst gebaut.”

Natürlich darf man den zweiten Teil des Satzes nicht vergessen: “Das muss man aber wissen”. Ja, stimmt. Da erfordern die Produkte eben leider doch ein bisschen Einarbeitung. Aber aus meiner Sicht ist die Zeit hier deutlich besser investiert als in der eigenen Engine. Denn

• Die Wartung erfolgt extern,
• Das Produkt wird weiter entwickelt,
• Man profitiert von der Erfahrung, die im Produkt steck,
• Man kann Support kaufen bzw. sich Internet-Foren bedienen und
• Man bekommt viele Features, die man zu Anfang vielleicht nicht braucht, später aber wichtig werden können.

Zu guter Letzt

Ich kann also nur immer sagen: Bitte, nicht selbst entwickeln! Die Engines bringen einiges mit, was man nicht mal so eben selbst entwickelt. Es ist die Lernkurve fast immer wert! Und diese Engine ist dann eben kein unkalkulierbares Risiko. Um in der Analogie des Comics vom Anfang zu bleiben: ich glaube sogar, dass es zukünftig für viele Anwendungen wichtiger wird, Prozessorientierung besser zu verinnerlichen. Dies würde vielen Anwendungen auch gut tun. Es ist also ein wichtiger Fortschritt, bei dem ich lieber dabei bin als zuzuschauen. Aber klar, muss ich ja sagen, ist ja mein Job

Kurz gesagt: In einer perfekten Welt wird die Engine also vielleicht sogar eine Art Selbstverständlichkeit. So wie OR-Mapper heute. Und es will doch auch keiner mehr ein zweites Hibernate entwicklen, oder?

P.S.

Sollte jemand anderer Meinung sein oder doch einen guten Grund parat haben, warum die Eigenetwicklug sein musste bzw. Sinn macht, lasst es mich wissen!

3.3.2.3    SOIA in der Praxis
Die Integrations- oder Agilitätsebene umreißt das Themengebiet, das in der öffentlichen Diskussion auch gern als Zusammenspiel von BPM und SOA bezeichnet wird. Es geht um die an der Unternehmensorganisation ausgerichtete Definition und Wartung von Services, sowie um ihre prozessorientierte Nutzung. Leider befinden sich die Kenntnisse und Erfahrungen im SOIA-Bereich heute noch weit unter dem Niveau der SOSA-Ebene. Das bedeutet, es existieren noch viele offene Fragen, wie eine SOIA richtig umgesetzt werden kann – und teilweise sind noch nicht einmal die richtigen Fragen gestellt worden.

Als relativ sicher gilt die grundsätzliche Feststellung, dass sich die Prozessagilität aus der Fähigkeit ableitet, definierte Services relativ einfach neu kombinieren zu können, und dass es deshalb eine Möglichkeit geben muss, die Reihenfolge der Nutzung vieler Services direkt an der Prozesslogik auszurichten, und diese Reihenfolge über einen Mechanismus verändern zu können, der keine direkte Programmierung erfordert. Diese Überlegung führt zunächst zum Ansatz der Service Orchestrierung, bei dem eine Orchestration Engine die Rolle eines Dirigenten übernimmt, und wie bei einem Orchester ausgehend vom Prozessmodell mal den einem, mal den anderen Service zur Ausführung einer Aufgabe anweist. Solche Aufgaben können sich auf einfache Datenoperationen beziehen, wie das Auslesen von Kundenstammdaten aus einem CRM-System, oder auf komplexe Geschäftslogik, wie die Berechnung eines Beleihungswertes im Rahmen einer Baufinanzierung.

Sofort drängt sich der Vergleich zum Human Workflow Management  auf: Dort übernimmt die Workflow Engine diese Rolle, und die am Prozess beteiligten Mitarbeiter und Partner stellen mit ihrer Arbeitskraft und Kompetenz die „Services“ bereit, die mittels Aufgabenzuweisung aufgerufen werden.
Somit wird auch ersichtlich, warum ein ganzheitliches Business Process Management die Methoden „Human Workflow Management“  und „Service Orchestration“ gleichermaßen abdecken muss.

Eine für die praktische Serviceorchestrierung sehr wichtige Differenzierung ist die Unterscheidung von synchronen und asynchronen Service Aufrufen („Service Calls“; Bild 3.18): Bei einem synchronen Service Call geht der Consumer davon aus, dass der Provider kurzfristig die Aufgabe abarbeiten und das Ergebnis zurückgeben wird. Dementsprechend wartet der Consumer auf diese Antwort und führt keine weiteren Prozess-Schritte aus. Dieses Szenario macht Sinn, wenn der Provider nicht überlastet ist oder die auszuführende Aufgabe nicht zu viel Zeit in Anspruch nimmt, wie zum Beispiel die Ausführung einer überschaubaren Berechnung. Mitunter kann der Consumer aber nicht wissen, wie lange die Antwort des Providers auf sich warten lassen wird. Möglicherweise dauert es Stunden, Tage oder gar Monate, weil die Realisierung des Services selbst ein komplexer Prozess ist. In solchen Fällen wird der Service asynchron aufgerufen, d.h. der Provider schickt nach erfolgtem Service Call lediglich eine Empfangsbestätigung und beendet dann vorerst die Kommunikation. Der Consumer führt seinen Prozess weiterhin aus, sofern er hierzu nicht auf die Antwort des Providers angewiesen ist, und irgendwann, zu einem späteren Zeitpunkt, meldet sich der Provider mit dem Ergebnis der erledigten Aufgabe. Diese Meldung findet dann als Aufruf des Consumer durch den Provider statt, weshalb dieser Vorgang auch „Callback“ genannt wird.

Um diese abstrakte Darstellung besser greifbar zu machen, kann man sich Beispiele aus der physischen Welt vor Augen führen: Im Rahmen des jährliches Prozesses der Einkommenssteuererklärung überkommt den Bürger, während er das Formular ausfüllt, eine Idee zur Steueroptimierung. Weil er nicht weiß, ob diese auch legal ist, nimmt er die Beratungsleistung seines Steuerberaters in Anspruch, und ruft diesen kurzerhand an. Technisch gesehen führt er via Telefon einen Service Call durch, wobei er in diesem Call seine Frage als Parameter übergibt, und nun darauf wartet, dass der Steuerberater die Aufgabe des darüber Nachdenkens ausführt, und ihm in seiner Antwort seine Einschätzung der rechtlichen Lage mitteilt. Solange der Bürger am Telefon sitzt und auf die Antwort wartet, unterbricht er das Ausfüllen des Formulars, und sein Prozess ist in einen Wartezustand eingetreten. Es handelt sich also um einen synchronen Service Call.

Hätte der Bürger hingegen damit gerechnet, dass der Steuerberater gerade nicht verfügbar ist oder seine Fragestellung so komplex ist, dass diese eine ausführliche Prüfung erfordert, hätte er seinen Service Call möglicherweise via Email durchgeführt. Dann hätte er, ohne auf die Antwort zu warten, das Ausfüllen seines Formulars fortgesetzt. Irgendwann wäre er an einem Punkt angelangt, wo er die Antwort des Steuerberaters gebraucht hätte, um das Formular zu finalisieren, und wäre in einen Wartezustand eingetreten (zumindest, was diesen Prozess angeht). Technisch gesehen hätte er auf den Callback des Services gewartet, den er zuvor via Email asynchron aufgerufen hätte (Bild 3.19).

Die Nutzung asynchroner Service Calls ist mit einer besonderen Herausforderung verbunden, die sich ebenfalls mit dem skizzierten Beispiel erklären lässt: Die Antwort des Steuerberaters erreicht den Bürger vermutlich ebenfalls per Email. Dieser registriert zunächst den Erhalt und erkennt anhand des Absenders, dass es sich um eine Email seines Steuerberaters handelt, und (für gewöhnlich) anhand des Betreffs, dass sich diese nicht auf die noch offene letzte Honorarabrechnung bezieht, sondern eine Antwort auf die zuvor gestellte Frage ist. Er hat also eine gedankliche Zuordnung der Nachricht zu seinem Prozess vorgenommen. Dieser schlüsselbasierte Zuordnungsvorgang wird Corellation Handling genannt und ist eine unabdingbare, aber auch schwierige Anforderung im Rahmen der Service Orchestrierung.
Einige Service Orchestration Prozesse funktionieren aus der Business-Perspektive nur nach dem Alles-oder-nichts-Prinzip: Es müssen alle Service-Aufrufe erfolgreich durchgeführt werden. Sollte auch nur ein Service-Aufruf fehlschlagen, müssen alle bereits erfolgten Aufrufe rückgängig gemacht werden. Dieses Prinzip der Atomarität dient der Transaktionssicherheit und gilt beispielsweise im Rahmen von Überweisungen:  Wenn im ersten Service Call der Betrag vom Konto A abgebucht wurde, jedoch der zweite Service Call zur Buchung auf Konto B fehlschlägt (zum Beispiel, weil es einen technischen Defekt im Netzwerk gibt), muss der Betrag auf das Konto A zurückgebucht werden, damit das Geld nicht „verloren“ geht. In derart kritischen Szenarien muss für jeden Service, der eine Aktion ausführt, vom Service Provider ein zweiter Service bereitgestellt werden, der genau diese Aktion wieder rückgängig machen kann und durch die Orchestration Engine im Fehlerfall aufgerufen werden kann. Der Umgang mit solchen Szenarien wird für gewöhnlich Compensation Handling genannt.

Die bis hierher vorgestellten Konzepte der

• Prozessorientierte Servicenutzung über Service Orchestration
• Synchrone versus asynchrone Service Calls
• Correlation Handling zur Zuordnung von Callbacks
• Compensation Handling zur Realisierung atomarer Service Orchestrations

sind bei weitem nicht alle, aber die in der Praxis besonders häufigen Aspekte, die es bei der technischen Umsetzung einer SOIA zu beachten gilt. Sie werden in vielen BPM-Suites entweder proprietär oder durch Implementierung von Standards wie z.B. BPMN zur optischen Gestaltung oder BPEL zur technischen Realisierung abgebildet.

Während diese Herausforderungen, wenngleich anspruchsvoll, so doch intellektuell bereits weit durchdrungen sind, existieren weitere, vergleichsweise mangelhaft geklärte Probleme auf der SOIA Ebene. Ein besonders schwieriges Problem bezieht sich auf die sinnvolle fachliche Abgrenzung von Services. Diese Abgrenzung mündet in eine Service Definition, die wiederum Grundlage der Service Implementierung ist. Dieser Prozess ist aufwendig, führt aber, sofern erfolgreich durchlaufen, erst wirklich zum gewünschten Effekt der flexiblen Nutzung von Services, um sie in verschiedenen Prozessen einsetzen zu können bzw. innerhalb eines Prozesses zu verschiedenen Zeitpunkten aufrufen zu können, und somit Prozessänderungen rasch umzusetzen – also genau der Zielsetzung der Integrationsebene, die dynamische Organisationsebene mit der starren Software-Ebene flexibel zu verbinden. Wenn diese organisatorische Ausrichtung fehlschlägt, führt dies im Ergebnis zu starren Services, die nur eine ganz bestimmte fachliche Anforderung abbilden, und nur zu einem ganz bestimmten Zeitpunkt innerhalb eines Prozesses aufgerufen werden können. In der Konsequenz könnten die implementierten Services zwar dank Orchestration Engine relativ schnell neu kombiniert werden, sind aber selbst gar nicht fähig zu unterschiedlichen Kombinationen, weil der Grad der „losen Kopplung“ nicht ausreicht und logische Abhängigkeiten zwischen den Services bestehen, die eine bestimmte Reihenfolge der Ausführung erzwingen, obwohl diese Reihenfolge nicht zwangsläufig der Prozesslogik geschuldet ist.

Für den Prozess der SOIA-gerechten Abgrenzung, Definition und Implementierung von Services gibt es (noch) kein Patentrezept, sondern nur die häufig leidvollen Erfahrungen derjenigen, die ihn bereits durchlaufen haben. Nicht wenige gehen tatsächlich den Weg über die Prozesse: Sie sammeln sämtliche Abläufe, die durch die SOIA zukünftig unterstützt werden sollen, und identifizieren die Gemeinsamkeiten und Unterschiede der jeweils benötigten IT-Unterstützung einzelner Schritte und Aktivitäten. Aus dieser Sammlung entsteht ein Domänenmodell, in dem sich zunächst Gruppen von Services zusammenfassen lassen. Innerhalb der Domänen werden dann einzelne Services voneinander abgegrenzt, wobei es durchaus zu Überlappungen in der bereitgestellten Leistung kommen darf. Die Implementierung dieser sehr grobgranularen Services muss dann auch nicht direkt in Code erfolgen, sondern kann selbst wieder eine Orchestrierung eher feingranularer Services sein – wobei man sehr darauf achten muss, die unterschiedlichen Prozessebenen konsistent aufeinander abzustimmen. So kann es vorkommen, dass ein feingranularer Service in unterschiedlichen grobgranularen Services Verwendung findet.

Sind Services implementiert und publiziert, können sie durch die „Allgemeinheit“ innerhalb, mitunter auch außerhalb des Unternehmens genutzt werden. Aufgrund des dezentralen Charakters einer SOA muss auch nach der Implementierung der Betrieb der Services gewissenhaft betreut werden, weshalb man hier auch vom Service LifeCycle Management spricht. Schließlich darf es nicht passieren, dass ein Service zur Angebotskalkulation, der im Unternehmensbereich A entwickelt und betrieben wird, eines Tages abgeschaltet wird, ohne alle anderen Unternehmensbereiche, die den Service in ihren Prozessen nutzen, rechtzeitig darüber zu informieren. Eine weitere unerwünschte Entwicklung wäre die Einrichtung einer eigenen Angebotskalkulation durch Unternehmensbereich B, weil sie den Service von Bereich A für mangelhaft hält, sodass innerhalb des Unternehmens zwei verschiedene Services für dieselbe fachliche Anforderung existieren. Die Sicherstellung der Serviceverfügbarkeit, die Vermeidung eines Wildwuchses und weitere Aspekte des Service LifeCycle Managements werden im Rahmen einer SOA-Governance organisiert. Doch auch für den Aufbau einer solchen Governance existieren bislang keine standardisierten, wissenschaftlich fundierten und praxiserprobten Verfahren, sondern lediglich die ersten punktuellen Erfahrungen von Unternehmen, die eine SOA größeren Umfangs eingeführt haben.

Abschließend muss konstatiert werden, dass sich SOIA momentan immer noch in einem Prozess der Entdeckung befindet. Zwar haben viele, vor allem größere Unternehmen bereits umfangreiche Projekte zur Steigerung ihrer Agilität durch die Einrichtung einer solchen Ebene angestoßen, und einige haben auch schon erste Erfolge melden können. Aber in der Breite existieren noch nicht ausreichend viele analysierbaren Ergebnisse, um eindeutige Muster für alle auftretenden Herausforderungen ableiten zu können. Wer sich mit der Einrichtung einer SOIA beschäftigt, muss deshalb  Pioniergeist und einen längeren Atem mitbringen, denn es passiert noch vieles nach dem Prinzip „Versuch-und-Irrtum“. Es wird vermutlich noch einige Jahre dauern, bis sich der Erfahrungshorizont im SOIA-Bereich auf dem heutigen Niveau der SOSA-Ebene befindet – diese zunächst negative Feststellung bedeutet natürlich gleichzeitig auch eine Chance für Unternehmen, die als „First-Mover“ eine Agilitätsebene in ihrer Prozesslandschaft entwickeln und somit einen Vorsprung gegenüber ihren Wettbewerbern realisieren wollen.

Die Idee der SOIA-Ebene steht auch in einem direkten Zusammenhang mit der allgemeinen Zusammenführung der Organisations- und IT-Perspektive von Business Process Management. Weitere Herausforderungen und Lösungsansätze in diesem Themenfeld werden in Kapitel 4 beschrieben.

3.3.2.4    SOPA in der Praxis
Zum Thema Service-Orientierung auf Prozessebene gibt es über die allgemeine Zielsetzung hinaus in der Praxis momentan noch nicht viel zu sagen: Die Klärung der wesentlichen Fragen der SOIA-Ebene ist Voraussetzung, um sich überhaupt seriös mit Vorgehensweisen zur Einrichtung einer serviceorientierten Organisation befassen zu können. Deshalb ist es müßig, sich heute bereits die Frage zu stellen, wie man die eigenen Geschäftsprozesse organisatorisch „serviceorientiert“ gestalten kann. Diskussionen und Publikationen zu diesem Thema rutschen derzeit schnell in eher schwammige Diskurse über Kundenorientierung und Dienstleistungsmentalität ab, und münden gern in Forderungen wie „Prozesse müssen als Service gegenüber dem Kunden gestaltet werden, den dieser muss im Mittelpunkt der Betrachtung stehen“. Diese Ambition ist zwar löblich, aber gleichzeitig eine absolute Binsenweisheit und hat mit dem eigentlichen SOA-Paradigma nichts mehr zu tun.