Ein nützliches Buch zur Prozessautomatisierung, allerdings mit Lücken
Geschafft! Zwei Mal habe ich dieses Buch nun gelesen – von vorne bis hinten, keine Seite, keinen Satz auslassend. Das erste Mal, als Bernd mir freundlicherweise sein frühes Skript zum Review zur Verfügung stellte (das war im Oktober 2020) und nun nach dessen finaler Veröffentlichung. Zum Spaß habe ich gerade nochmals geschaut, wie viele Kommentare ich damals nach meinem ersten Review an Bernd zurückmeldete: Es waren knapp 400. Wir haben im Anschluss an mein Review auch noch intensiv über unsere unterschiedlichen Ansätze der Prozessentwicklung diskutiert. So ganz konnte ich ihn von meiner Herangehensweise wohl doch nicht überzeugen, wie das nun vorliegende Buch zeigt. Aber das ist auch nicht weiter schlimm. Es ist gut, dass es für die Prozessautomatisierung unterschiedliche Implementierungsalternativen gibt. Architekten haben nun die Wahl und sie können jetzt bewusste Entscheidungen treffen, welchem Architekturansatz sie bei Prozessautomatisierungsprojekten bevorzugen wollen: Den in Bernds Buch beschriebenen, auf Microservices basierenden Stil oder meinen „Prozessgesteuerten Ansatz“ (englisch „Process-Driven Approach“ und daher in meiner Rezension ab jetzt mit PDA abgekürzt).
Sie merken schon: Dies wird keine normale Rezension. Bernd und ich kennen und schätzen uns nun schon seit vielen Jahren. Wir sind beide leidenschaftliche BPMN- und Process Engine-Enthusiasten. Jeder treibt auf seine Weise die Entwicklung rund um die BPMN-basierte Prozessautomatisierung mit viel Herzblut voran. Mein Buch mit dem Titel „Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN“ aus dem Jahre 2013 (englische Fassung: „Process-Driven Applications with BPMN“ aus dem Jahre 2014) ist zwar schon etwas älter, hat aber bis heute nichts an seiner Aktualität verloren. Nun liegt mit „Practical Process Automation“ also ein weiteres Buch rund um die BPMN-basierte Prozessautomatisierung vor und es gibt Einiges zu diesem Buch zu sagen.
Ein paar grundsätzliche Anmerkungen vorweg: Bernds Buch ist ein wichtiger Beitrag zur aktuellen Diskussion rund um die digitale Transformation. Dabei sind wir uns in vielen Punkten einig: BPMN-basierte Prozessautomatisierung unter Einsatz von Process Engines spielt bei der digitalen Transformation eine Schlüsselrolle! Wer bei der Umsetzung neuer digitaler Geschäftsmodelle in Form von Prozessen auf den Einsatz von Process Engines verzichtet, verspielt großes Potenzial. Prozess Engines spielen bei der Prozessautomatisierung eine ebenso wichtige Rolle wie seinerzeit Datenbanken für die transaktionsgesicherte Datenhaltung. Heute würde auch niemand mehr auf den Gedanken kommen, zur Datenhaltung eine Datenbank selbst zu entwickeln. Aber bei der Automatisierung von Prozessen glauben viele Unternehmen noch immer, sie müssten dafür ein eigenes Framework entwickeln. Was für eine Zeit- und Ressourcenverschwendung! Bernds Buch ist allein aus diesem Grund schon wertvoll, weil er in aller Deutlichkeit die Vorteile des Einsatzes von Process Engines anhand unzähliger Beispiele verdeutlicht. Dies zieht sich wie ein roter Faden durch sein Buch – gut so! Es ist also ein längst überfälliges Buch zur Etablierung von Process Engines als neue Standard-Infrastrukturkomponente in Unternehmen.
Bernds Buch ist immer dann stark, wenn er anhand konkreter Beispiele aus dem Nähkästchen plaudern kann – Anekdötchen aus seinem umfangreichen Erfahrungsschatz, die seine Argumente untermauern. Seine vielen Fallbeispiele aus der Praxis machen auch beim Lesen durch seine auflockernde Art viel Spaß. Das Buch ist daher angenehm zu lesen. Auch inhaltlich wird eine Fülle von Themen behandelt. Dabei ist Bernds Faible für Technologien nicht zu übersehen. Er kennt sich aus – keine Frage!
Dennoch bin ich, wie schon einleitend angedeutet, nicht immer seiner Meinung. Das ist auch kein Beinbruch und nicht jeder muss meiner Meinung sein. Es ist auch beileibe kein Grund, hier mit Sternabzug das Buch abstrafen zu wollen, wie das vielleicht andere Rezensenten tun würden. Aber ich möchte zumindest auf den fundamentalen Unterschied zwischen seinem und meinem Vorgehen aufmerksam machen, denn dieser Unterschied hat enorme Auswirkungen auf die Architektur von Prozessanwendungen, auf deren Wartbarkeit, Betrieb sowie deren Anpassbarkeit. Es spielt also schon eine wichtige Rolle, dass sich Architekten dieses Unterschieds bewusst sind und deren jeweiligen Vor- und Nachteile kennen. Denn durch Bernds Buch erhalten sie diese Informationen nicht. Deshalb möchte ich an dieser Stelle kurz darauf eingehen und diese Lücken schließen.
Im Wesentlichen liegen meine Bedenken in zwei Punkten begründet:
- Keine strikte Trennung zwischen Fach- und Integrationsprozessen
- Direkte Aufrufe von Backend-Systemen aus BPMN-Modellen heraus
Keine strikte Trennung zwischen Fach- und Integrationsprozessen
Bernd sieht eine solche strikte Trennung zwischen Fach- und Integrationsprozessen nicht. Bezeichnend dafür ist ein Zitat aus dem vierten Kapitel (S. 92), auf das ich hier zurückgreifen möchte:
„To implement an end-to-end process you might need to orchestrate humans, RPA bots, SOA services, microservices, decisions, functions, and other software components, all within the same process.“
Dieser Aussage kann ich mich nicht anschließen: Für mich ist die Trennung zwischen Fach- und Integrationsprozessen fundamental wichtig. Wir haben über diesen Punkt auch intensiv diskutiert. Bernd hat auf S. 11 seines Buches unter der Überschrift „Business Processes, Integration Processes, and Workflows“ dazu Stellung bezogen. Dort schreibt er:
„The boundary between these categories is often not sharp at all, as most integration cases have a business motivation. This is why you don’t find ‘integration processes’ discussed as a separate category in this book. […] ‘Extracting (Integration) Logic into Subprocesses’ on page 211 will explain that you can extract some portions of the process model into child models.”
Wie bereits oben gesagt, sehe ich diesen Punkt komplett anders: In Fachprozessen haben Integrationsprozesse nichts zu suchen, auch nicht in Teilprozessen, die ja nach wie vor eng mit dem aufrufenden Prozess verwoben sind. Die Trennung zwischen den beiden Kategorien ist sehr wohl scharf und leicht zu identifizieren. Wie ich in meinem Buch gezeigt habe und in vielen Projekten leider auch lernen musste, macht diese Vermischung die BPMN-Modelle unnötig kompliziert. Das kann im Laufe der Zeit, während dessen die Modelle ja ständig weiterentwickelt werden, letztendlich zu völlig unbrauchbaren Ergebnissen und somit zur Anhäufung technischer Schulden führen.
Kleines Beispiel: In einem Genehmigungsprozess für einen Beschaffungsantrag soll dieser aus fachlicher Sicht nach dessen Genehmigung unter Nutzung einer BPMN-Serviceaufgabe einfach nur verbucht werden – so die Anforderung der Fachabteilung. Bei der Analyse des Prozesses und unter Berücksichtigung der IT-Landschaft des Unternehmens stellt sich jedoch heraus, dass die einzelnen Antragspositionen in einem SAP-, einem Microsoft- und einem eigenen System abzuspeichern sind. Also wird aus der einen Serviceaufgabe, die die Fachabteilung bei der ursprünglichen Modellierung vorsah, eine parallele Verzweigung mit drei Serviceaufgaben (je System eine Serviceaufgabe). Bei der weiteren Analyse stellt sicher zudem heraus, dass die Funktion im SAP-System nur asynchron erreichbar ist. Folglich ist im Prozess die für das SAP-System vorgesehene Serviceaufgabe durch eine Kombination von Sende- und Empfangsaufgabe zu ersetzen, um die asynchrone Kommunikation zu ermöglichen. Ich kann dazu nur sagen: Willkommen in der komplexen Welt der Integration! Aus einem anfangs einfachen, übersichtlichen BPMN-Modell ist aufgrund des Einbringens der Integrationsanforderungen ein komplexer, schwer handhabbarer Moloch geworden. Außerdem enthält das Modell nun Details, die die Fachabteilung überhaupt nicht interessiert.
Hier hat also die Berücksichtigung der Systemlandschaft des Unternehmens massive Auswirkungen auf das ursprüngliche BPMN-Modell und Schritte werden ergänzt, die rein aus Integrationszwecken hinzugekommen sind. Auch wenn ich sie, wie von Bernd vorgeschlagen, in einen Teilprozess auslagere, ändert dies an der Vermischung von Fach- und Integrationsprozess nichts.
Bei PDA ist das ganz anders. PDA verfolgt das Ziel, den Fachprozess so zu belassen, wie ihn die Fachabteilung benötigt. Keine Kompromisse an dieser Stelle. Der Fachprozess wird nicht durch technische Integrationsanforderungen „verschmutzt“. Stattdessen separiert PDA die Integrationsaspekte vollständig, ganz einfach durch Anwendung des in der Informatik bewährten Prinzips des „Separation of concerns“. Wie das funktioniert, würde den Rahmen dieser Rezension sprengen, ist aber in meinen zahlreichen Publikationen zu diesem Thema und auch auf meiner Homepage kostenlos nachzulesen.
Kurz zusammengefasst: Ja, man kann es so machen, wie Bernd es beschreibt, allerdings würde ich für professionelle Prozessanwendungen mit Enterprise-Qualitätsansprüchen aufgrund der entstehenden Komplexität und der Vermischung von Zuständigkeiten darauf verzichten. Ich hätte mir gewünscht, dass Bernd im Rahmen seines Buches diese Alternative zumindest anspricht und sowohl die Vor- als auch die Nachteile gegeneinander abwägt. So aber bleibt Architekten, die nur sein Buch lesen, die PDA-Option verwehrt. Die Leser könnten den Eindruck gewinnen, Prozessimplementierungen könnten nur so wie von Bernd beschrieben umgesetzt werden. Dem ist aber nicht so. Ich möchte an dieser Stelle auch auf die potenzielle Gefahr völlig entarteter BPMN-Prozessmodelle hinweisen, bei denen man vor lauter Integrationsaufgaben die Fachlichkeit nicht mehr sieht. Dies könnte zu Frust bei allen Beteiligten führen, bis hin zur Ablehnung der BPMN-basierten Prozessautomatisierung, was meiner Meinung nach fatal wäre.
Direkte Aufrufe von Backend-Systemen aus BPMN-Modellen heraus
Bleibt noch die Diskussion des zweiten Punktes: Die direkten Aufrufe von Systemen aus BPMN-Modellen heraus. Auch hier sagt PDA ganz klar: Nein, auf keinen Fall! Bei Bernd ist es die Normalität und damit öffnet er, meiner Meinung nach, die Büchse der Pandora. Er ist mittendrin in der höchst komplexen Welt der Systemintegration. Diese Entscheidung, Systeme aus BPMN-Modell direkt aufzurufen, bringt so viele Herausforderungen mit sich, dass dies auch nicht ohne Folgen für die Weiterentwicklung von Process Engines bleibt. Es stellt sich nämlich die Frage, welche Features in Process Engines hinzugenommen werden müssen, die lediglich der Tatsache geschuldet sind, dass sich Process Engines des Integrationsthemas öffnen. Ein klassisches Beispiel dafür ist der Retry. Auf S. 8 schreibt Bernd:
„We just touched on the two most important capabilities of a workflow engine: Persist the state, which allows waiting. Scheduling things, like retries.”
Die Funktionalität des wiederholten Aufrufs bei fehlerhafter Kommunikation ist eine reine Integrationsanforderung, die meiner Meinung nach eben nichts in einer Process Engine zu tun hat. Denn der Funktionsumfang einer Process Engine ist ohnehin schon recht herausfordernd. Warum sollte ich sie darüber hinaus noch mit Integrationsthemen belasten? Denn das ist ja erst der Anfang! Dazu eine Anekdote aus der jüngsten Vergangenheit: Ich habe mir das Webinar zum neuen Release 7.15 von Camunda’s Process Engine angesehen (20.04.2021 – auch online abrufbar). Ein Kernthema dieses Releases ist die Orchestrierung von RPA-Bots (RPA: Robotic Process Automation), das ja auch in Bernds Buch ab S. 88 Gegenstand einer Diskussion ist. In dem Webinar wurde u.a. die nahtlose Integration des RPA-Tools von „Automation Anywhere“ über eine RPA-Bridge gezeigt (von Minute 11:09 bis Minute 22:25 der Aufzeichnung). Wie hinlänglich bekannt, ist Bernd ja auch Mitgründer von Camunda. Daher ist es immer interessant zu sehen, wie sich Camunda‘s Process Engine weiterentwickelt und wo der Fokus des Unternehmens liegt. Aber das nur am Rande. Jedenfalls wurde im Webinar die einfache Integration von Automation Anywhere in einen BPMN-basierten Prozesse anhand einer kleinen Demo gezeigt. Neben dem Happy Path beinhaltete die Demo auch das Verhalten im Fehlerfalle. Es handelte sich also abermals um einen klassischen Integrationsprozess. Interessant aber war die Reaktion der Webinar-Teilnehmer auf diese Demo. Sie fragten natürlich gleich nach der Unterstützung weiterer RPA-Lösungen wie UIPath und BluePrism (ab Minute 52:35). Und genau das meinte ich mit der Büchse der Pandora. Derartige Feature-Wünsche, die nichts mehr mit BPMN-basierter Prozessautomatisierung sondern ausschließlich mit Integration zu tun haben, werden Hersteller von Process Engines, die Prozessautomatisierung mit Integration verbinden wollen, jetzt zunehmend treffen. Doch warum sollten sich Hersteller von Process Engines so etwas antun?
Dieses Beispiel der RPA-Anbindung zeigt übrigens auch sehr schön, wie Unternehmen aktuelle Markttrends aufgreifen und für sich nutzen. Die Gefahr besteht natürlich darin, dass über das Aufgreifen jedes Trends (vielleicht sogar nur aus marketingtechnischen Gründen) der ursprüngliche Fokus eines Produkt verlorengeht. Von daher bin ich bei Kundenanforderungen in diese Richtung immer skeptisch und erinnere gerne an das Zitat, das vermeintlich von Henry Ford stammt: „Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie gesagt: »schnellere Pferde«“.
Wie dem auch sei: Ich persönlich halte die Entwicklung des Einbringens von Integrationsaspekten in Process Engines für unglücklich. Als ehemaliger Produktmanager für SAP’s Integrationslösung SAP Process Integration weiß ich, wovon ich rede: Die Domäne der Integration ist so gigantisch groß und komplex, dass ich den Herstellern von Process Engines nur davon abraten kann, sich in diesen Strudel reinziehen zu lassen. Nicht umsonst hat Gregor Hohpe zusammen mit Bobby Woolf mit „Enterprise Integration Patterns“ (EIP) die Bibel der Integration geschrieben, in dem so ziemlich sämtliche Integrationsherausforderungen mit möglichen Lösungen diskutiert werden. Über 700 Seiten (!!!) geballtes Integrationswissen. Und all diese Fragestellungen sollen jetzt durch Process Engines mit abgedeckt werden? Das ergibt für mich keinen Sinn.
Ich sehe zudem das Problem der wachsenden technischen Schulden, sollten Systemaufrufe direkt aus den BPMN-Modellen erfolgen: Jede Schnittstellenänderung, jedes Hinzufügen oder Entfernen eines Systems hat unmittelbare Auswirkungen auf die BPMN-Modelle und Architekten müssen sich fragen, ob sie sich dieser Konsequenzen bewusst sind und ob sie dies wirklich wollen?
Sie sehen also: Auch in diesem Punkt kann man anderer Meinung sein. Der Schlüssel zur Lösung liegt einmal mehr in der Trennung von Zuständigkeiten, also den „Separation of concerns“. Process Engines sollen sich auf die vollumfängliche Unterstützung der BPMN konzentrieren und all die Features liefern, die wirklich mit der Prozessautomatisierung zu tun haben. Die Integrationsaufgaben sollten Process Engines den Integrationsprofis überlassen. Beim Hausbau lasse ich die Sanitärinstallation ja auch nicht vom Parkettleger erledigen, nur weil er das Zuhause mal gemacht hat. Derartige Integrationslösungen müssen nicht teuer sein. Ich kann an dieser Stelle auf das leichtgewichtige Apache Camel-Framework verweisen, dass auf besagtem EIP-Buch basiert und die dort beschriebenen Lösungen bereits im Bauch hat. Durch geschickte Kombination von Process Engine und Integrationsframework in einer nachhaltigen Softwarearchitektur lässt sich dann eine professionelle Prozesslösung erstellen, die auch für zukünftige Herausforderungen bestens gerüstet ist und den Aufbau neuer technischer Schulden vermeidet. Auch das ist alles in meinem PDA-Buch nachzulesen. Allerdings würden dann einige Abschnitte aus Bernds Buch überflüssig werden, da er auf BPMN-Basis Integrationsprobleme löst, die durch die Nutzung von beispielsweise Camel entbehrlich würden. Beispielhaft sei hier das Aggregator-Pattern auf S. 180 genannt, das so auch in Camel vorhanden ist. Retries sind ebenfalls durch Camel abgedeckt und gehören aus diesem Grund meiner Meinung nach nicht in eine Process Engine.
Kurz zusammengefasst: Viele Integrationsherausforderungen, die in dem Buch thematisiert und durch Lösungsansätze auf Basis einer Process Engine diskutiert werden, sind in über viele Jahre gewachsenen und damit ausgereiften Integrationsframeworks schon längst professionell gelöst worden. Eine Notwendigkeit, dies jetzt auch noch in Process Engines zu verlagern, sehe ich nicht.
Auch an dieser Stelle hätte ich mir von Bernds Buch eine Diskussion der Architektur-Optionen gewünscht, die leider letztendlich ausbleibt.
So ganz kann ich an dieser Stelle auch Bernds Argumentationskette nicht folgen. Auf der einen Seite wendet er sich aus guten Gründen gegen die Eigenentwicklung einer Process Engine. So schreibt er auf S. 7:
„Ash’s story could also easily lead to the development of a homegrown workflow engine. Such company-specific solutions cause a lot of development and maintenance effort and will still lack behind what existing tools can deliver.”
Oder auf S. 121:
“I strongly recommend that you skip the undertaking of building a custom platform. I have seen it fail even with very smart teams that tried hard. Unless you are a process automation company, don’t build a process automation platform.”
Dem kann ich mich uneingeschränkt anschließen! Dieser Aufwand zahlt sich nicht aus!
Auch bei der Entwicklung proprietärer Prozess-Modellierungssprachen nimmt er eine kritische Stellung ein, die ich nur unterstützen kann. So schreibt er auf S. 102:
„Custom process modeling languages often come with the promise of being simpler than BPMN. But in reality, claims of simplicity mean they lack important patterns. Hence, if you follow the development of these modeling languages over time you will see that they add patterns once in a while, and whenever such a tool is successful it almost inevitably ends up with a language complexity comparable to BPMN, but in a proprietary way.“
Korrekte Beobachtung – dann also gleich BPMN.
Soweit so gut also. Allerdings fördert Bernd auf der anderen Seite mit der Aufnahme von Integrationsaspekten in eine Process Engine genau das, was er in obigen Zitaten kritisiert: Über die Zeit hinweg wird durch das Hinzufügen von Features, die lediglich der Integration dienen, eine Integrationslösung auf Basis einer Process Engine mehr recht als schlecht nachgebaut. Auch hier gilt: Dann kann ich auch gleich auf eine bereits existierende Integrationslösung zurückgreifen.
Für mich passt das an dieser Stelle also nicht zusammen.
Fazit
Es gäbe zu diesem Buch noch deutlich mehr zu schreiben. Weiter unten gehe ich noch genauer auf die einzelnen Kapitel des Buches ein. Doch für die Rezension hier bei Amazon soll das bisher Geschriebene genügen. Alles in allem ein spannendes Buch, das (zumindest bei mir) sehr zum Nachdenken angeregt hat. Leider verliert das Buch meiner Meinung nach aufgrund der vielen integrationslastigen Herausforderungen ein wenig den Fokus auf die Automatisierung fachlicher Prozesse. Dabei spielen doch gerade die innovativen Fachprozesse bei der digitalen Transformation die entscheidende Rolle. Vier Sterne vergebe ich, weil der Fokus auf die Fachprozesse verlorenging und weil mir die Diskussionen um Alternativen gefehlt haben, insbesondere bei den beiden o.g. Punkten, die jedoch gravierende Auswirkungen auf die finalen Prozesslösungen haben, wie ich hoffentlich deutlich machen konnte. Wie gesagt: Bernd muss nicht meiner Meinung sein. Aber zu einer halbwegs objektiven Darstellung gehört zumindest die Erwähnung von Alternativen, die Bernd durch unseren Austausch auch bekannt sind. Durch die Kombination von Bernds und meinem Buch erhalten Architekten allerdings sämtliche Informationen, um zukünftig bewusste Entscheidungen für die eine oder andere Implementierungslösung zu treffen. Und das ist doch ein versöhnlicher Abschluss 😊.
Die Kapitel in der Einzelkritik
Soweit meine Diskussion der beiden Kernaspekte, die ich kritisch sehe. Im Folgenden möchte ich auch noch kurz auf die einzelnen Kapitel eingehen.
Bereits im Vorwort ist auf den Seiten xi und xii von modernen Architekturen die Rede. Da der Untertitel des Buches „Orchestration and Integration in Microservices and Cloud Native Architectures“ lautet, nehme ich mal an, dass mit „modern architectures“ genau diese Architekturen gemeint sind. Dem stehe ich kritisch gegenüber, da ich Microservices beispielsweise nicht als richtungsweisend ansehe, im Gegenteil. Der Microservice-Architekturstil ist mit gravierenden Problemen behaftet. Diese hier alle aufzuzählen und zu behandeln kann nicht Sinn einer Rezension sein. Allerdings habe ich auf lange Sicht größte Zweifel an dem Bestand dieser Architekturen. Darunter könnte natürlich auch das Buch eines Tages mal leiden: Sollte sich nämlich herausstellen, dass der Weg über Microservice-basierte Architekturen einmal mehr eine Sackgasse war, dann fällt natürlich auch der Wert dieses Buches, da es sich schon sehr stark an Microservices orientiert, wie in späteren Kapiteln noch zu sehen sein wird.
Wichtig ist in diesem Vorwort Bernds Hinweis auf sein Unternehmen und somit auf seine Voreingenommenheit in Bezug auf Process Engines (S. xiii). Tatsächlich kann man das Buch auch als kleine Werbebroschüre für die Camunda-Lösungen sehen, da an vielen Stellen auf Eigenschaften von Process Engines hingewiesen wird, die von den Camunda-Lösungen selbstredend erfüllt werden. Hier ist insbesondere der Abschnitt „Evaluating Workflow Engines“ auf S. 123 kritisch zu sehen. Da Camunda beispielsweise bei den Einzelfeatures nicht so gut abschneidet wie die Hersteller großer Prozessautomatisierungs-Suiten wie beispielsweise Bizagi, Pegasystems, Appian oder Axon Ivy, lautet die Empfehlung auf S. 124:
„Both aspects, vision and extensibility, are actually more important than specific features.“
Dementsprechend wird im Buch auch nicht auf bestimmt Features eingegangen. Leser sollten sich dieser Ausgangslage (Bernd als Mitgründer eines Unternehmens, dass Process Engine-Lizenzen verkauft) also bewusst sein.
Kapitel 1 hat sogleich unter dem Problem der Unterscheidung zwischen Fach- und Integrationsprozessen zu leiden. In seinem auf S. 4 beginnenden Beispiel der „Wild West Integrations“ beschreibt Bernd ein Szenario, das ausschließlich mit Integrationsproblemen zu kämpfen hat. Damit wird schon gleich zu Beginn die Richtung vorgegeben, was ich persönlich schade finde. Warum? Integrationsprozesse sind für die digitale Transformation nun mal eher unwichtig. Der Markt für die neuen digitalen Geschäftsmodelle wird auf fachlicher Ebene entschieden und nicht auf Integrationsebene. Darunter leidet das Buch. Ich hätte mir eine klare Ausrichtung auf die Automatisierung von Fachprozessen gewünscht. Bernd erkennt dieses Dilemma seines Einführungsbeispiels auch und schreibt auf S. 9:
„So far, the payment process is more of an integration process, which is not the most typical use for process automation. I like starting with it as it helps technical audiences to understand core workflow engine capabilities, but we’ll examine a more typical business process in the next section.“
Allerdings ist besagtes Fachszenario im darauffolgenden Abschnitt, von dem er in letztem Zitat spricht, ein Prozess bestehend aus genau drei Service-Aufgaben. Auch im weiteren Verlauf des Buches werden die Szenarien kaum komplexer. Das mag der Lesbarkeit und dem Verständnis zuträglich sein. In der Praxis sieht dies jedoch sehr oft ganz anders aus.
Auf S. 11 folgt dann das Zitat mit den seiner Meinung nach nicht eindeutig trennbaren Fach- und Integrationsprozessen, das ich bereits weiter oben besprochen habe. Wie gesagt, sehe ich sehr wohl eine eindeutige Trennung zwischen den beiden Prozessarten, die auch anhand konkreter Kriterien leicht zu treffen ist.
Kapitel 2 ist ganz stark. Hier wird alles in die Waagschale geworfen, was für den Einsatz einer Process Engine spricht. Dem kann ich mich uneingeschränkt anschließen. Jedes Unternehmen sollte die Vorzüge kennen. Kapitel 2 ist dafür bestens geeignet!
In Kapitel 3 gibt es eine Kurzeinführung in BPMN. Da „Practical Process Automation“ kein BPMN-Lehrbuch ist, kann dieses Kapitel wirklich nur oberflächlich in die Notation einführen. Immerhin wird stets der Bezug zur Ausführbarkeit hergestellt, worauf ich in meinen Lehrveranstaltungen zu BPMN auch immer wieder hinweise. Etwas seltsam ist die Camunda-eigene Variante der Implementierung einer Service-Aufgabe, also wie Prozessmodelle mit Programmcode zusammengebracht werden können (S. 54ff). Die angesprochene Variante über Publish/Subscribe finde ich schon sehr konstruiert und kann über ein Integrationsframework wie Camel meiner Meinung nach eleganter gelöst werden. Aber das ist Ansichtssache. Eindrucksvoll ist gegen Ende des Kapitels der Teil über Prozessversionierung und wie es Process Engines gelingt, mehrere Prozessversionen parallel verarbeiten zu können. Sehr cool!
Das Integrationsthema lässt Bernd allerdings nicht los und so startet Kapitel 4 erneut mit einem Integrationsszenario: Vier unterschiedliche Systeme gilt es zu integrieren. Doch damit nicht genug: Im weiteren Verlauf des Kapitels wird über die Process Engine alles integriert, was die Informatik so zu bieten hat. Nicht umsonst ist das Kapitel mit „Orchestrate Anything“ überschrieben (S. 67): Ob SOA-basierte Services (S. 69), Microservices (S. 79), Serverless Functions (S. 71), Monolithen (S. 74), Entscheidungen (S. 76), Menschen (S. 81), RPA Bots (S. 88) oder physikalische Geräte im Internet der Dinge (S. 91) – hier kann sich Bernd technisch so richtig austoben. Das Kapitel endet dann mit dem bereits besprochenen Zitat von S. 92, dass all diese Komponenten innerhalb eines einzigen Prozesses orchestriert werden können, was ich ja für keine gute Entscheidung halte.
In diesem Kapitel wird im Abschnitt über Entscheidungen auch das Thema DMN (Decision Model and Notation) kurz angerissen. DMN ist komplementär zu BPMN zu sehen und ergänzt die Prozessnotation perfekt zur Kapselung von Entscheidungen. Von daher hätte hier eine ausführlichere Diskussion dieses Themas erfolgen können. Zudem wäre an dieser Stelle eine Diskussion über die Rolle von Entscheidungstabellen in Integrationsprozessen (z.B. Datenvalidierung, Routingentscheidungen, Mappingentscheidungen) sicherlich eine Bereicherung für das Buch gewesen, zumal Integration einen großen Teil des Buches einnimmt.
Eine interessante Exkursion in die Welt der Alternativen zu Workflow Engines und Prozessautomatisierungsnotationen startet Bernd in Kapitel 5. Ich folge Bernd hier in allen seinen Punkten. Auch dieses Kapitel sollte ein Pflichtkapitel für jedes Unternehmen werden, damit diese verstehen, auf welche Vorzügen sie verzichten, wenn sie den Einsatz von Process Engines und BPMN meiden. Sehr überzeugend!
Mit Kapitel 6 beginnt Teil 2 des Buches, in dem es konkret um den Einsatz von Prozessautomatisierung im Unternehmen geht. Kapitel 6 nimmt sich dabei einmal mehr des Themas „Process Engine“ sowie deren Nutzung im Unternehmen an. Bernd gibt wichtige Hinweise für Kriterien zur Auswahl einer Process Engine. Man sollte hierbei lediglich Bernds Rolle als einer der Mitbegründer von Camunda im Hinterkopf behalten. Nichtsdestotrotz sind die genannten Kriterien für den Auswahlprozess zweifellos wertvoll! Auf S. 123 verweist er sogar auf die Webseite zum Buch, auf der man angeblich eine Liste mit Process Engines finden soll. Doch zum Zeitpunkt meiner Recherche (27.04.2021) war die Liste noch nicht vorhanden.
In Kapitel 7 versucht Bernd die Quadratur des Kreises: Er möchte Prozessautomatisierung in die Zwangsjacke von Microservices stecken – so kommt es mir zumindest vor. Das Kapitel ist stark von Microservices geprägt und leider wird dieser Architekturstil meiner Meinung nach nicht kritisch genug hinterfragt. Im Gegenteil: Gleich zu Beginn des Kapitels auf S. 127 wird der Architekturstil als „modern“ bezeichnet. Wie weiter oben auch schon geschrieben, kann man hier durchaus anderer Meinung sein.
Wie dem auch sei: In dem Kapitel wird der wichtigen Frage nachgegangen, wie Prozesse aufzuteilen sind. Für mich bleibt das Kapitel die Antwort auf diese Frage in weiten Teilen schuldig, denn Bernds Argumente überzeugen mich an dieser Stelle nicht. Seine Analyse mündet auf S. 131 in der knackigen Überschrift: „Respect Boundaries and Avoid Process Monoliths“. Zur Verdeutlichung zieht er ein Beispiel aus seinem BPMN-Grundlagenbuch heran und erklärt anhand dessen, warum das dort gewählte Beispiel so im Unternehmen nicht zur Ausführung kommen sollte, weil eben die Zuständigkeiten wie Kreditkartenabrechnung, Lagerverwaltung, Auslieferung und Kundenzufriedenheitsanalyse nicht sauber gekapselt sind. Sie sollten daher besser in separaten Prozessmodellen und damit Microservices mit klaren „Boundaries“ ausgelagert werden. Darin spiegelt sich die typische Denke der Microservices-Befürworter wieder, bloß keine Monolithen zu produzieren. Alles wird in kleine, handhabbare Microservices verpackt, die selbst natürlich auch ausführbare, BPMN-basierte Prozesse umfassen können.
Beim Lesen dieses Kapitels habe ich mich schon ein wenig gewundert, da zuvor gefühlt auf jeder Seite die Bedeutung der Ende-zu-Ende-Prozesse betont wurde. Doch auf einmal spielt das alles keine Rolle mehr und der Gesamtprozess soll stattdessen aufgeteilt und jeder Microservice einen Teil des Gesamtprozesses übernehmen. Dazu ein Zitat von S. 134:
„Instead, you need to cut the end-to-end process into appropriate ‘pieces’ that fit into the different services.“
Und später auf S. 135:
“You need to distribute responsibilities to different services to achieve a level of isolation that allows scaling development…”
Und wo bleibt da auf einmal die Ende-zu-Ende-Transparenz, die zuvor an so vielen Stellen noch so wichtig (und meiner Meinung nach auch richtig) war? Bernd begründet dies mit Verantwortlichkeiten und der Skalierung der Entwicklungsleistung. Und genau diesen Aspekt meinte ich mit „Quadratur des Kreises“. Für mich wird dort etwas in die Microservices-Denke gepresst, was so nicht zusammenpasst. Eine weitere Empfehlung hinsichtlich der Aufteilung von Prozessen mündet in folgender Aussage (S. 135):
„How you divide things essentially boils down to the question of ‘who to blame’ if something does not work.“
Ich verstehe, was Bernd damit ausdrücken möchte, doch ist es wirklich hilfreich?
Vielleicht hängt die Empfehlung für die Aufteilung von Prozessen in Fragmente aber auch mit der fehlenden Unterscheidung zwischen Fach- und Integrationsprozessen zusammen. Auf S. 145 fasst Bernd seine Ergebnisse wie folgt zusammen:
„Business processes often touch multiple contexts and services. This is fine, but you need to make sure that every executable process is clearly owned by exactly one service, and that you avoid process monoliths.“
Für Integrationsprozesse unterschreibe ich diese Aussage, nicht aber für Fachprozesse. Für Fachprozesse ist es nichts Verwerfliches, Ende-zu-Ende modelliert und ausgeführt zu werden. Ganz im Gegenteil: Erst dadurch gewinnt die Ende-zu-Ende-Transparenz an Gewicht. Sie (die Transparenz) ist so wertvoll für Unternehmen, dass ich sie nicht dem Microservices-Diktat unterwerfen möchte. Dieser Punkt ist sicherlich eine weitere Diskussion wert.
Noch eine Randbemerkung: In diesem Kapitel 7 zitiert Bernd auf S. 144 Martin Fowler mit folgenden Worten:
„The microservice community favours an alternative approach: smart endpoints and dumb pipes.“
Ich halte dieses Zitat für zumindest fragwürdig. Bei der Kommunikation zwischen Systemen ist zu regeln, wer mit wem kommuniziert. Dieses Kommunikationswissen kann in den Endpunkten oder in einer Integrationslösung liegen. Bei den „Smart Endpoints“ weiß entweder der Sender, wen er aufzurufen hat (Command) oder der Empfänger hat sich auf bestimmte Ereignisse abonniert (Events). Das Integrationswissen liegt bei diesen beiden Optionen in den beteiligten Systemen und ist somit in der gesamten Systemlandschaft verteilt. Ich halte diese Vorgehensweise deshalb für fragwürdig, da niemand genau weiß, wer wen wann aufruft (Command) oder wer sich alles auf bestimmte Ereignisse subskribiert hat (Events). Änderungen in der Systemlandschaft werden dann zu einem Glücksspiel. Von daher bevorzuge ich für Unternehmensarchitekturen ganz eindeutig die Integrationslösungen, bei denen zentral das Integrationswissen gut aufgehoben ist. Die Übersichten in den zentralen Integrations- oder API-Management-Lösungen ermöglichen die gezielte Veränderung von Kommunikationsstrukturen, ohne dass sich etwas an den beteiligten Systemen ändern muss. Nachhaltig orientierte Architekturen sollten sich daher von obige Empfehlung der „Smart endpoints and dumb pipes“ distanzieren.
Die Diskussion um Orchestrierung über Commands und Choreographie über Events greift Bernd in Kapitel 8 nochmals auf. Was er hier über die vielfältigen Nachteile der Eventverarbeitung sagt, findet meine volle Unterstützung. Anhand einer Vielzahl von Beispielen legt er seine Finger in die Wunden der Event-Verarbeitung, eine der wesentlichen Bestandteile von Microservice-basierten Architekturen. Diese kritische Auseinandersetzung hätte ich mir auch bei anderen Aspekten von Microservices gewünscht. Am Beispiel der Events macht er dies allerdings vorbildlich. Am Ende des Kapitels zeigt er dann anschaulich, wie Process Engines für Ordnung in dem Ereignis-Mix sorgen. Daumen hoch!
Kapitel 9 greift den Faden der Integration ein weiteres Mal auf. Bernd spricht grundlegende Kommunikationsarten wie synchrone und asynchrone Kommunikation an. Er zeigt, wie diese Kommunikationen mit Prozessmodellen umgesetzt werden können. Dazu gesellen sich Fragen wie Transaktionen, Konsistenz in verteilten Systemen (Stichwort: Eventual Consistency), das Saga-Pattern, Kompensation und Idempotenz. Allerdings ist der direkte Aufruf von Systemen aus den BPMN-Modellen heraus auch hier in allen Diskussionen omnipräsent. Sie kennen meine Einstellung diesbezüglich mittlerweile. Die in Kapitel 9 angesprochenen Probleme und BPMN-basierten Lösungsmöglichkeiten wären nicht notwendig, würde die Integration außerhalb der Prozess Engine durch ein Integrationsframework geregelt. Von daher halte ich die Diskussionen in diesem Kapitel für müßig. Lediglich bei zustandsbehafteten Integrationspattern wie dem Aggregator halte ich den Einsatz von Process Engines für wertvoll. Allerdings sollte sie nur für die Prozessablauflogik des zustandsbehafteten Integrationsprozesses verwendet werden, jedoch nicht für die eigentliche Kommunikation mit den Systemen. Da sollte dann beispielsweise wieder Camel Verwendung finden.
Kleine Randnotiz: Warum im Prozessmodell zum Saga-Pattern auf S. 188 nicht auf den in BPMN verfügbaren Transaktions-Teilprozess zurückgegriffen wird, erschließt sich mir nicht.
Auf Fachabteilungen und deren Zusammenspiel mit IT-Kollegen kommt Bernd in Kapitel 10 zu sprechen. Das Zusammenspiel verschiedenster Prozessrollen und der Nutzen von grafischen Prozessmodellen wird anhand eines typischen Projektablaufs erklärt. Das macht Spaß zu lesen und der Mehrwert wird unmittelbar deutlich. Im Abschnitt „The Power of One Joined Model“ auf S. 205 beginnt die Diskussion um verschiedenste Arten von Prozessmodellen. Er nennt sie „Strategische Prozessmodelle“, „Operative Prozessmodelle“, „Menschliche Prozessflüsse“ bzw. „Technische Prozessflüsse“. Nachdem diese Unterscheidung für mich zunächst nicht nachvollziehbar war (ich hatte schon Probleme bei der Einführung dieser Gedanken in seinem anderen Buch „Praxishandbuch BPMN“, denn dort kommen sie ursprünglich her), so lichtete sich der Schleier nach für nach. Insbesondere der Begriff „Technische Prozessflüsse“ irritierte, da Bernd auch noch zwei Varianten von technischen Prozessflüssen unterscheidet. Das kann schon mal verwirren. Anhand eines konkreten Beispiels auf S. 208 wird es dann doch nachvollziehbar. Allerdings überzeugt mich die Darstellung nicht sonderlich, denn zwei Prozessmodelle (der menschliche Prozessfluss und eine Variante des technischen Prozessflusses) dienen ausschließlich der Dokumentation. Sie reflektieren daher selten die Realität und sind folglich nur begrenzt nützlich. Sie zu erstellen macht, wenn überhaupt, nur punktuell Sinn, um die Kommunikation zwischen Prozessrollen und Projektteilnehmern zu erleichtern. Ansonsten finden sie in realen Projekten wohl kaum Anwendung. Die Diskussion darum ist daher eher theoretischer Natur.
Kapitel 10 wird mit einer Diskussion um aussagekräftige Prozessmodelle abgeschlossen. An dieser Stelle musste ich schon ein wenig schmunzeln. Bruce Silver hat diesem Thema ein ganzes Buch gewidmet und hier werden sie auf sechs Seiten (S. 211 bis 216) abgehandelt. Neben einigen sinnvollen Hinweisen enthält dieser Abschnitt auch eine Empfehlung, wie man das Retry-Verhalten einer Serviceaufgabe durch eine Textannotation ergänzen kann (S. 214, Abbildung 10-12). Nun ja: Diese Überlegungen erübrigen sich genau dann, wenn man die Integration durch ein Integrationsframework außerhalb der Process Engine abwickelt. Aber das hatten wir schon…
Um die Sichtbarkeit von Prozessen zur Laufzeit dreht sich alles im vorletzten Kapitel 11. Informativ und mit viel Sachverstand führt Bernd den Leser durch die vielfältigen Möglichkeiten der Prozesssichtbarkeit, des Monitorings und des Reportings. Auf diese Weise werden weitere Vorteile des Einsatzes von Process Engines für Unternehmen offensichtlich.
Last but not least hilft Bernd in seinem abschließenden wertvollen Kapitel 12 Unternehmen bei der Einführung von Prozessautomatisierung basierend auf der Nutzung von Process Engines. Wie sieht eine schrittweise Vorgehensweise über Pilotprojekt, Leuchtturmprojekt und schließlich breiter Anwendung im Detail aus? Er geht dabei sowohl auf die Einführung für unterschiedliche Szenarien (Austausch einer existierenden Workflow-Lösung, Einsatz in SOA-Umgebungen, Einsatz in ereignisbasierten Umgebungen) als auch auf die Argumente ein, die die Managementebene überzeugen. Mögliche hilfreiche Argumente hat er dazu in einer Tabelle von Leistungsversprechen bei dem Einsatz von Prozessautomatisierung auf S. 252/253 zusammengefasst. Ein wirklich schöner Abschluss eines äußert nützlichen Kapitels.