Praktische Prozessautomatisierung

Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Los geht's! In diesem Kapitel geht es um:

• Was ich mit Prozessautomatisierung meine

• Besondere technische Herausforderungen bei der Automatisierung von Prozessen

• Was eine Workflow-Engine leisten kann und warum sie einen enormen Mehrwert bietet

• Wie Business und IT bei der Automatisierung von Prozessen zusammenarbeiten können

• Wie sich moderne Werkzeuge von den BPM- und SOA-Werkzeugen der Vergangenheit unterscheiden

Prozessautomatisierung

Im Wesentlichen bezieht sich ein Prozess (oder Workflow) einfach auf eine Reihe von Aufgaben, die ausgeführt werden müssen, um ein gewünschtes Ergebnis zu erzielen.

Prozesse gibt es überall. Als Entwicklerin sehe ich meinen persönlichen Entwicklungsprozess darin, dass ich in der Lage bin, bestimmte Aufgaben zu bewältigen, die von einem Problem bis zu einer Codeänderung reichen, die dann in die Produktion einfließt. Als Angestellter denke ich an die Optimierung meines Prozesses bei der Bearbeitung von E-Mails, d.h. an Techniken, um schnell Prioritäten zu setzen und meinen Posteingang leer zu halten. Als Unternehmer denke ich an End-to-End-Geschäftsprozesse wie die Erfüllung von Kundenbestellungen, auch bekannt als "Order to Cash". Und als Backend-Entwickler denke ich vielleicht auch an Remote-Aufrufe in meinem Code, da diese eine Reihe von Aufgaben beinhalten - vor allem, wenn du Wiederholungs- oder Bereinigungsaufgaben in Betracht ziehst, denn ein verteiltes System kann jederzeit fehlschlagen.

Prozesse können auf verschiedenen Ebenen automatisiert werden. Der wichtigste Unterschied ist, ob ein Mensch den Prozess steuert, ob ein Computer den Prozess steuert oder ob der Prozess vollständig automatisiert ist. Hier sind einige Beispiele, die diese verschiedenen Stufen der Automatisierung verdeutlichen.

Nach der High School half ich bei der Organisation von Essen-auf-Rädern, die ältere Menschen zu Hause beliefern. Es gab einen täglichen Prozess, um die Essensbestellungen zu bearbeiten, eine Liste der Bestellungen zusammenzustellen, die an die Küche ging, die Mahlzeiten zu verpacken und schließlich sicherzustellen, dass alle Bestellungen richtig beschriftet waren, damit sie den richtigen Empfängern zugestellt wurden. Dazu kam noch der Lieferservice selbst. Als ich anfing, war der Prozess komplett papiergestützt und nahm einen ganzen Vormittag in Anspruch. Ich änderte das und nutzte Microsoft Excel, um einige Aufgaben zu automatisieren. Dadurch verringerte sich die Bearbeitungszeit auf etwa 30 Minuten - es war also viel effizienter. Aber es gab immer noch körperliche Tätigkeiten, wie das Verpacken und Beschriften der Lebensmittel und die Fahrt zu den Empfängern nach Hause.

Noch wichtiger war, dass der Prozess immer noch von Menschen gesteuert wurde, denn es war meine Aufgabe, die richtigen Knöpfe zu drücken und zur richtigen Zeit mit den entsprechenden Listen in der Küche aufzutauchen. Nur einige Aufgaben wurden durch Software unterstützt.

Bei meinem letzten Krankenhausbesuch habe ich mich mit dem Personal darüber unterhalten, wie die Zubereitung der Mahlzeiten funktioniert. Die Patienten mussten eine Papierkarte ausfüllen, auf der sie ihre Allergien und Essenswünsche vermerkten, und diese Informationen wurden in einen Computer eingegeben. Das IT-System war dann dafür zuständig, diese Informationen zur richtigen Zeit an den richtigen Ort zu transportieren, und das musste automatisch geschehen. Menschen spielten zwar immer noch eine Rolle in diesem Prozess, aber sie steuerten ihn nicht. Es war ein computergesteuerter, aber nicht vollautomatischer Prozess.

Wenn du dieses Beispiel noch weiter führst, gibt es heute Kochroboter. Wenn du diese Roboter in den Prozess einbinden würdest, wäre es möglich, den Computer nicht nur mit der Automatisierung des Kontrollflusses, sondern auch mit den Kochaufgaben zu beauftragen. Das bringt den Prozess näher an einen vollautomatischen Prozess heran.

Wie du sehen kannst, gibt es einen wichtigen Unterschied zwischen der Automatisierung des Kontrollflusses zwischen den Aufgaben und der Automatisierung der Aufgaben selbst:

Automatisierung des Kontrollflusses

Die Interaktionen zwischen den Aufgaben sind automatisiert, aber die Aufgaben selbst sind es vielleicht nicht. Wenn Menschen die Arbeit erledigen, steuert der Computer den Prozess und bezieht sie bei Bedarf ein, z. B. über die Benutzeroberfläche der Aufgabenliste. Dies wird als menschliches Aufgabenmanagement bezeichnet. Im vorherigen Beispiel waren es die Menschen, die das Essen gekocht haben. Das steht im Gegensatz zu einem vollständig manuellen Prozess, der funktioniert, weil Menschen den Aufgabenfluss kontrollieren, indem sie Papier oder E-Mails weitergeben.

Automatisierung der Aufgaben

Die Aufgaben selbst sind automatisiert. Im vorherigen Beispiel wären das die Roboter, die das Essen kochen.

Wenn du die Automatisierung sowohl des Kontrollflusses als auch der Aufgaben kombinierst, erhältst du vollautomatische Prozesse, die auch als Straight-Through-Processing (STP) bezeichnet werden. Diese Prozesse erfordern nur dann ein manuelles Eingreifen, wenn etwas außerhalb des erwarteten Normalbetriebs passiert.

Natürlich gibt es eine allgemeine Tendenz, Prozesse so weit wie möglich zu automatisieren, aber es gibt auch bestimmte Gründe, die für die Automatisierung sprechen:

Hohe Anzahl von Wiederholungen

Der Aufwand für die Automatisierung lohnt sich nur, wenn die potenziellen Einsparungen die Kosten für die Entwicklung übersteigen. Prozesse mit einem hohen Ausführungsvolumen sind hervorragende Kandidaten für die Automatisierung.

Normung

Prozesse müssen strukturiert und wiederholbar sein, um leicht automatisiert werden zu können. Ein gewisses Maß an Varianz und Flexibilität ist bei automatisierten Prozessen zwar möglich, erhöht aber den Aufwand für die Automatisierung und schmälert einige der Vorteile.

Compliance-Konformität

In einigen Branchen oder bei bestimmten Prozessen gibt es strenge Regeln für die Nachvollziehbarkeit oder sogar Regeln, die vorschreiben, dass ein dokumentiertes Verfahren in einer wiederholbaren und überprüfbaren Weise befolgt werden muss. Die Automatisierung kann dies leisten und sofort hochwertige, relevante Daten liefern.

Bedarf an Qualität

Manche Prozesse sollten Ergebnisse von gleichbleibender Qualität liefern. Du könntest zum Beispiel eine bestimmte Liefergeschwindigkeit für Kundenaufträge versprechen. Das ist mit einem automatisierten Prozess leichter zu erreichen und einzuhalten.

Informationsreichtum

Prozesse, die viele digitalisierte Informationen enthalten, eignen sich besser für die Automatisierung.

Die Automatisierung von Prozessen kann mit verschiedenen Mitteln erreicht werden, wie im Abschnitt "Einschränkungen anderer Implementierungsoptionen" näher erläutert wird, aber es gibt auch spezielle Software, die auf die Prozessautomatisierung ausgerichtet ist. Wie im Vorwort erwähnt, wird sich dieses Buch auf diese Tools konzentrieren und vor allem auf Workflow-Engines eingehen.

Hinweis

Prozesse zu automatisieren bedeutet nicht zwangsläufig, Software zu entwickeln oder eine Art Workflow-Engine zu verwenden. Es kann so einfach sein wie der Einsatz von Tools wie Microsoft Office, Slack oder Zapier zur Automatisierung von Aufgaben, die durch bestimmte Ereignisse ausgelöst werden. Jedes Mal, wenn ich zum Beispiel einen neuen Konferenzvortrag in meine persönliche Tabelle eintrage, löst das eine Reihe automatisierter Aufgaben aus, um ihn auf meiner Homepage, in der Veranstaltungstabelle des Unternehmens, im Slack-Kanal für unsere Entwicklerbeziehungen und so weiter zu veröffentlichen. Diese Art der Automatisierung ist relativ einfach zu implementieren, auch von Nicht-IT-Leuten im Selbstbedienungsmodus, aber natürlich ist ihre Leistungsfähigkeit begrenzt.

Im weiteren Verlauf dieses Buches werde ich mich nicht auf diese büroähnlichen Tools zur Automatisierung von Arbeitsabläufen konzentrieren. Stattdessen werden wir die Prozessautomatisierung aus der Perspektive der Softwareentwicklung und -architektur betrachten.

Damit du verstehst, wie du mit einer Workflow-Engine Prozesse automatisieren kannst, wollen wir dir kurz eine Geschichte erzählen, die dir zeigt, welche Probleme Entwickler im Alltag damit lösen können.

Wild West Integrations

Stell dir vor, Ash ist ein Backend-Entwickler, der die Aufgabe hat, ein kleines Backend-System für den Einzug von Zahlungen per Kreditkarte zu entwickeln. Das klingt doch nicht allzu komplex, oder? Ash fängt sofort an und entwirft eine schöne Architektur. In Gesprächen mit den Leuten, die für die Auftragsabwicklung zuständig sind, sind sie sich einig, dass es am einfachsten ist, eine REST-API für den Auftragsabwicklungsdienst bereitzustellen. Also fängt Ash mit der Programmierung an.

Auf halbem Weg kommt ein Kollege herein und schaut auf Ashs Whiteboard, auf dem die Schönheit der Architektur festgehalten ist. Der Kollege sagt beiläufig: "Ah, du benutzt diesen externen Kreditkartenservice. Ich habe früher auch mit ihm gearbeitet. Damals hatten wir eine Menge Probleme mit undichten Verbindungen und Ausfällen; hat sich das gebessert?"

Diese Frage kommt für Ash überraschend. Dieser teure SaaS-Dienst ist unzuverlässig? Das bedeutet, dass Ashs netter, geradliniger Code zu naiv ist! Aber keine Sorge, Ash fügt etwas Code hinzu, um den Anruf zu wiederholen, wenn der Dienst nicht verfügbar ist. Nach einem weiteren Gespräch verrät der Kollege, dass sein Dienst manchmal stundenlang ausfällt. Ash muss sich also etwas einfallen lassen, wie er es über einen längeren Zeitraum hinweg erneut versuchen kann. Aber verdammt, dazu muss man Zustände verarbeiten und ein Zeitplannungsprogramm benutzen! Also beschließt Ash, dieses Problem nicht sofort in Angriff zu nehmen, sondern es in den Rückstand zu verschieben, in der Hoffnung, dass das Team für die Auftragsabwicklung es in Ordnung bringen kann. Im Moment löst Ashs Code einfach eine Ausnahme aus, wenn der Kreditkartenservice nicht verfügbar ist, und drückt die Daumen, dass alles gut geht.

Zwei Wochen nach Beginn der Produktion kommt ein anderer Kollege aus der Auftragsabwicklung vorbei, zusammen mit dem Geschäftsführer. Was zum Teufel ist hier los? Es stellt sich heraus, dass Ashs System eine Menge "Kreditkarten-Service nicht verfügbar"-Fehler auslöst, und der Geschäftsführer ist nicht glücklich über die Menge der nicht erfüllten Bestellungen - dieses Problem hat zu Umsatzeinbußen geführt. Ash versucht sofort zu handeln und bittet das Auftragserfüllungsteam, die Zahlungen erneut zu versuchen, aber sie müssen andere dringende Probleme lösen und zögern, Aufgaben zu übernehmen, die von Ashs Dienst erledigt werden sollten (und sie zögern völlig zu Recht, wie du in Kapitel 7 nachlesen wirst).

Ash verspricht, das Problem zu beheben und so schnell wie möglich etwas auf die Beine zu stellen. Zurück am Schreibtisch erstellt Ash eine Datenbanktabelle namens payment mit einer Spalte namens status. Jede Zahlungsanforderung wird dort mit dem Status open eingefügt. Darüber hinaus fügt Ash ein einfaches Zeitplannungsprogramm hinzu, das alle paar Sekunden nach offenen Zahlungen sucht und diese abarbeitet. Jetzt kann der Dienst zustandsabhängige Wiederholungen über längere Zeiträume hinweg durchführen. Das ist großartig. Ash ruft die Leute von der Auftragsabwicklung an und sie besprechen die notwendigen Änderungen an der API, da die Zahlungen jetzt asynchron verarbeitet werden. Die ursprüngliche REST-API gibt HTTP 202 (Accepted) als Antwort zurück, und Ashs Dienst kann entweder den Erfüllungsdienst zurückrufen, ihm eine Nachricht schicken oder ihn regelmäßig nach dem Zahlungsstatus fragen lassen. Die Teams sind sich einig, dass der Polling-Ansatz eine schnelle Lösung ist. Ash muss also nur einen weiteren REST-Endpunkt bereitstellen, um den Zahlungsstatus abzufragen.

Die Änderung wird in der Produktion eingeführt und Ash ist froh, die Bedenken des CEOs ausgeräumt zu haben. Doch leider währt der Frieden nicht allzu lange. Eine Karawane von Leuten trifft in Ashs Büro ein, darunter auch der Betriebsleiter. Sie teilen Ash mit, dass keine Bestellungen ausgeliefert werden können, weil keine Zahlungen erfolgreich entgegengenommen werden. Wie bitte? Ash macht sich eine mentale Notiz, dass er eine Überwachung einbauen muss, um in Zukunft nicht von solchen Situationen überrascht zu werden, und wirft einen Blick auf die Datenbank. Oh nein, es stapeln sich eine Menge offener Zahlungen. Ein Blick in die Protokolle zeigt, dass das Zeitplannungsprogramm durch einen Ausnahmefall unterbrochen wurde und abgestürzt ist. Verdammt.

Ash legt die eine vergiftete Zahlung, die den ganzen Prozess unterbrochen hat, beiseite, startet das Zeitplannungsprogramm neu und sieht, dass die Zahlungen wieder verarbeitet werden. Erleichtert schwört Ash, die Dinge genauer im Auge zu behalten und hackt ein kleines Skript, das regelmäßig die Tabelle überprüft und eine E-Mail-Benachrichtigung sendet, sobald etwas Ungewöhnliches passiert. Ash beschließt außerdem, dem Skript einige Strategien zur Entschärfung des Ausnahmefalls hinzuzufügen. Großartig!

Nach all den stressigen Wochen plant Ash, in den Urlaub zu fahren. Aber es stellt sich heraus, dass der Chef nicht allzu glücklich darüber ist, dass Ash geht, denn niemand außer Ash versteht den Tool-Stack, den sie gerade gebaut haben. Noch schlimmer ist, dass der Chef stattdessen eine Liste mit zusätzlichen Anforderungen an den Zahlungsdienst herauszieht, denn einige Geschäftsleute haben von dem unzuverlässigen Kreditkartendienst gehört und wollen genauere Berichte über die Verfügbarkeit und die Reaktionszeiten. Sie wollen auch wissen, ob das vereinbarte Service Level Agreement (SLA) tatsächlich eingehalten wird und wollen das in Echtzeit überwachen. Jetzt muss Ash zusätzlich zu einer Datenbank Berichte erstellen, die ursprünglich nicht notwendig schien. Abbildung 1-1 zeigt das daraus resultierende Chaos in seiner ganzen Schönheit.

Abbildung 1-1. Wildwest-Integration im Spiel - das übliche Chaos, das man in den meisten Unternehmen vorfindet

Leider hat Ash einen viel zu verbreiteten Ansatz zur Automatisierung von Prozessen verwendet, den ich als Wildwest-Integration bezeichne. Es ist ein Ad-hoc-Ansatz, um Systeme ohne jegliche Kontrolle zu schaffen. Es ist sehr wahrscheinlich, dass ein solches System dem Unternehmen als Ganzes keinen guten Dienst erweist.

Hier sind einige weitere Varianten der Wildwest-Integration:

Integration über die Datenbank

Ein Dienst greift direkt auf die Datenbank eines anderen Dienstes zu, um zu kommunizieren, oft ohne dass der andere Dienst es weiß.

Naive Punkt-zu-Punkt-Integrationen

Zwei Komponenten kommunizieren direkt miteinander, oft über REST-, SOAP- oder Messaging-Protokolle, ohne dass alle Aspekte rund um die Fernkommunikation richtig geklärt sind.

Datenbank-Trigger

Jedes Mal, wenn du etwas in die Datenbank schreibst, wird eine zusätzliche Logik aufgerufen.

Spröde Toolchains

Zum Beispiel das Verschieben von kommagetrennten (CSV) Textdateien über FTP.

Ash musste eine Menge Code für Funktionen schreiben, die in eine Workflow-Engine eingebaut sind: den aktuellen Status beibehalten, Wiederholungsversuche einplanen, über den aktuellen Status berichten und langlaufende Prozesse betreiben. Anstatt deinen eigenen Code zu schreiben, solltest du vorhandene Tools nutzen. Es bringt wirklich nichts, wenn du deine eigene Lösung entwickelst. Selbst wenn du denkst, dass dein Projekt die zusätzliche Komplexität einer Workflow-Engine nicht braucht, solltest du es dir noch einmal überlegen.

Tipp

Die Programmierung von Prozessen ohne eine Workflow-Engine führt in der Regel zu komplexem Code; die Zustandsbehandlung wird schließlich in den Komponenten selbst kodiert. Das macht es schwieriger, die Geschäftslogik und den Geschäftsprozess zu verstehen, die in diesem Code implementiert sind.

Die Geschichte von Ash könnte auch leicht zur Entwicklung einer eigenen Workflow-Engine führen. Solche unternehmensspezifischen Lösungen verursachen einen hohen Entwicklungs- und Wartungsaufwand und bleiben immer noch hinter dem zurück, was bestehende Tools leisten können.

Workflow-Engines und ausführbare Prozessmodelle

Was ist also die Alternative zu einer fest kodierten Workflow-Logik oder einer selbst entwickelten Workflow-Engine? Du kannst ein vorhandenes Tool verwenden, z. B. eines der Produkte aus der Liste auf der Website dieses Buches.

Eine Workflow-Engine automatisiert die Steuerung eines Prozesses. Sie ermöglicht es dir, eine Blaupause deines Prozesses, die Prozessdefinition, in einer bestimmten Modellierungssprache zu definieren und einzusetzen. Mit dieser Prozessdefinition kannst du Prozessinstanzen starten, und die Workflow-Engine verfolgt ihren Status.

Abbildung 1-2 zeigt einen Prozess für das zuvor vorgestellte Zahlungsbeispiel. Der Prozess beginnt, wenn eine Zahlung erforderlich ist, wie der erste Kreis im Prozessmodell zeigt (das sogenannte Startereignis, das den Beginn eines Prozesses markiert). Er durchläuft dann die einzige Aufgabe, die durch die Zahnräder gekennzeichnet ist. Diese Serviceaufgabe implementiert den REST-Aufruf an den externen Kreditkartenservice. Wie das geht, erfährst du in Kapitel 2. Stell dir jetzt einfach vor, dass du dafür einen normalen Programmiercode schreibst, den ich Glue-Code nenne. Nach dieser Aufgabe endet der Prozess mit dem Endereignis, dem Kreis mit dem dicken Rand.

Abbildung 1-2. Ein sehr einfacher Prozess, der bereits viele Anforderungen im Kreditkartenbeispiel bewältigen kann

Abbildung 1-3 veranschaulicht anhand von Pseudocode, wie du dieses Prozessmodell zur Implementierung von Zahlungen nutzen kannst. Zunächst schreibst du einen Code, der auf etwas in der Außenwelt reagiert - zum Beispiel einen Aufruf des REST-Endpunkts, um Zahlungen zu sammeln. Dieser Code verwendet dann die API der Workflow-Engine, um eine neue Prozessinstanz zu starten. Diese Prozessinstanz wird von der Workflow-Engine gespeichert; Abbildung 1-3 veranschaulicht dies anhand einer relationalen Datenbank. Du wirst später in diesem Buch mehr über die verschiedenen Engine-Architekturen, Persistenzoptionen und Einsatzszenarien lesen.

Abbildung 1-3. Workflow-Engine

Als Nächstes schreibst du etwas Glue-Code, um die Kreditkarte zu belasten. Dieser Code funktioniert wie ein Rückruf und wird ausgeführt, wenn die Prozessinstanz zu der Aufgabe übergeht, die Kreditkarte zu belasten. Dies geschieht automatisch, nachdem die Prozessinstanz gestartet wurde. Im Idealfall wird die Kreditkartenzahlung sofort verarbeitet und die Prozessinstanz danach beendet. Dein REST-Endpunkt könnte sogar in der Lage sein, eine synchrone Antwort an seinen Client zurückzugeben. Aber wenn der Kreditkartendienst ausfällt, kann die Workflow-Engine in der Aufgabe warten, um die Kreditkarte zu belasten und neue Versuche auszulösen.

Wir haben gerade die beiden wichtigsten Funktionen einer Workflow-Engine angesprochen:

• Behalte den Zustand bei, der das Warten erlaubt.

• Plane Dinge, wie die Wiederholungsversuche.

Je nach Tooling muss der Glue-Code möglicherweise in einer bestimmten Programmiersprache geschrieben werden. Einige Produkte erlauben jedoch beliebige Programmiersprachen. Wenn du also beschließt, deine Wildwest-Implementierung zu bereinigen, kannst du wahrscheinlich große Teile deines Codes wiederverwenden und die Workflow-Engine nur für die Zustandsbehandlung und die Planung nutzen.

Natürlich gehen viele Prozesse weit über dieses einfache Beispiel hinaus. Beim Abrufen von Zahlungen kann das Prozessmodell weitere Geschäftsprobleme lösen. Zum Beispiel könnte der Prozess auf abgelaufene Kreditkarten reagieren und darauf warten, dass der Kunde seine Zahlungsinformationen aktualisiert, wie in Abbildung 1-4 dargestellt.

Abbildung 1-4. Der Zahlungsprozess kann schnell komplizierter werden

Bisher ist der Zahlungsprozess eher ein Integrationsprozess, der nicht die typischste Anwendung für die Prozessautomatisierung ist. Ich beginne gerne damit, weil es dem technischen Publikum hilft, die Kernfunktionen der Workflow-Engine zu verstehen, aber wir werden im nächsten Abschnitt einen typischeren Geschäftsprozess untersuchen.

Ein Business-Szenario

Schauen wir uns ein typisches (aber imaginäres) Projekt an. ShipByButton Inc. (SBB) ist ein technisches Startup. Es bietet einen kleinen Hardware-Knopf an. Jedes Mal, wenn er gedrückt wird, wird ein bestimmter Artikel bestellt. Du könntest diesen Knopf zum Beispiel neben deinem Waschpulver anbringen und wenn du siehst, dass das Pulver fast leer ist, drückst du einfach auf den Knopf und eine Schachtel Waschpulver wird bestellt und an dich geliefert (wenn dich das an den Amazon Dash Button erinnert, ist das vielleicht nur ein Zufall ;-)).

Die SBB möchte ihren wichtigsten Geschäftsprozess, die Auftragsabwicklung, automatisieren. Eine ausführliche Diskussion über die verschiedenen Rollen und ihre Zusammenarbeit findest du in "Ein typisches Projekt". Sagen wir einfach, dass die SBB damit beginnt, den Prozess in Bezug auf die physischen Schritte zu skizzieren, und sich dann bis zu der Detailebene vorarbeitet, die mit einer Workflow-Engine automatisiert werden kann. Dabei kommt ihnen zugute, dass die Prozessmodellierungssprache BPMN unabhängig von der Ebene, auf der du sie anwendest, universell ist.

Das resultierende Prozessmodell ist in Abbildung 1-5 dargestellt.

Abbildung 1-5. End-to-End-Geschäftsprozess, der automatisiert werden kann

Das ist natürlich etwas vereinfacht, denn im wirklichen Leben gibt es mehr Ausnahmefälle, z.B. wenn die Zahlung nicht zurückgeholt werden kann oder die Ware nicht vorrätig ist.

Du kannst sehen, dass dieser Prozess von anderen Diensten abhängt, zum Beispiel von der ersten Aufgabe, die den Zahlungsdienst aufruft. Dies ist ein typisches Szenario bei der Anwendung von Microservices, wie du später in diesem Buch lernen wirst.

Hinweis

Die Modellierung von Geschäftsprozessen führt oft zu einem interessanten Nebenprodukt: unerwartete Erkenntnisse. In einem Kundenszenario, das dem der SBB sehr ähnlich ist, stellten wir fest, dass die "Geschäftsleute" nicht genau wussten, was die "Mitarbeiter im Lager" taten. Das visuelle Prozessmodell half nicht nur, dieses Problem zu erkennen, sondern auch zu lösen.

Langlaufende Prozesse

Prozessautomatisierung hat ein breites Spektrum. Während es dabei oft um unternehmensweite, durchgängige Geschäftsprozesse wie Auftragsabwicklung, Kontoeröffnung oder Schadensregulierung geht, kann sie auch bei viel technischeren Anwendungsfällen rund um Orchestrierung und Integration helfen, wie im Beispiel der Kreditkarte.

Alle diese Beispiele haben jedoch eine Gemeinsamkeit: Es handelt sich um langwierige Prozesse. Das heißt, Prozesse, die Minuten, Stunden, Wochen oder Monate dauern, bis sie abgeschlossen sind. Workflow-Engines eignen sich hervorragend für die Bearbeitung langwieriger Prozesse.

Bei diesen Prozessen wird auf etwas gewartet, z. B. darauf, dass andere Komponenten reagieren, oder einfach darauf, dass ein Mensch eine Arbeit erledigt. Deshalb müssen Workflow-Engines, wie bereits erwähnt, dauerhafte Zustände verwalten.

Man kann es auch so sehen, dass ein langfristiges Verhalten erforderlich ist, wenn die Logik Grenzen überschreitet. Wenn ich Grenzen sage, kann das sehr unterschiedliche Dinge bedeuten. Wenn du einen entfernten Dienst aufrufst, überschreitest du die Grenze deines lokalen Programms, deines lokalen Betriebssystems und deines lokalen Computers. Damit bist du verantwortlich für Probleme mit der Verfügbarkeit des Dienstes oder zusätzliche Latenzzeiten. Wenn du eine andere Komponente oder Ressource aufrufst, überschreitest du ebenfalls die Grenze der technischen Transaktion. Wenn du Komponenten aus anderen Teams integrierst, überschreitest du organisatorische Grenzen, was bedeutet, dass du mehr mit diesen Leuten zusammenarbeiten musst. Wenn du externe Dienstleistungen einbeziehst, z. B. von einer Kreditkartenagentur, überschreitest du die Grenze deines eigenen Unternehmens. Und wenn du Menschen einbeziehst, überschreitest du die Grenze zwischen automatisierbaren und nicht-automatisierbaren Aufgaben.

Die Verwaltung dieser Grenzen erfordert nicht nur langfristige Fähigkeiten, sondern auch ein sorgfältiges Nachdenken über die Reihenfolge der Aufgaben. Fehlerszenarien und die richtige Geschäftsstrategie für den Umgang mit ihnen müssen ernsthaft diskutiert werden. Möglicherweise gibt es auch gesetzliche Anforderungen in Bezug auf Datensicherheit, Compliance oder Audits. Diese Anforderungen sind ein weiterer Grund für grafische Prozessvisualisierungen, die in Kapitel 11 ausführlich behandelt werden.

Moderne Systeme haben immer mehr Grenzen, denn es gibt eine wachsende Tendenz weg von monolithischen Systemen hin zu feinkörnigen Komponenten wie Services, Microservices oder Funktionen. Und Systeme werden oft aus einem wilden Mix aus internen Anwendungen und Diensten, die in der Cloud genutzt werden, zusammengesetzt.

Geschäftsprozesse, Integrationsprozesse und Arbeitsabläufe

Zusammenfassend lässt sich sagen, dass du sowohl Geschäftsprozesse als auch Integrationsprozesse automatisieren kannst. Die Grenze zwischen diesen Kategorien ist oft gar nicht so scharf, da die meisten Anwendungsfälle für die Integration eine geschäftliche Motivation haben. Aus diesem Grund werden "Integrationsprozesse" in diesem Buch nicht als eigene Kategorie behandelt. Stattdessen wird dir in "Modell oder Code?" gezeigt, dass viele technische Details im normalen Programmiercode und nicht in einem Prozessmodell landen, und in "Extrahieren der (Integrations-)Logik in Unterprozesse" wird erklärt, dass du einige Teile des Prozessmodells in Untermodelle extrahieren kannst. Dadurch kannst du technische Details auf eine andere Granularitätsebene verschieben, was dazu beiträgt, dass der Geschäftsprozess verständlich bleibt.

Außerdem wirst du bemerkt haben, dass ich die Begriffe Prozess und Workflow verwende. Um ehrlich zu sein, gibt es kein einheitliches Verständnis für den Unterschied zwischen Prozess- und Workflow-Automatisierung. Viele Leute verwenden diese Begriffe synonym. Andere sehen das anders und argumentieren, dass Geschäftsprozesse eher strategisch und Workflows eher taktisch ausgerichtet sind und daher nur Workflows modelliert und auf einer Workflow-Engine ausgeführt werden können. Ebenso können Prozessmodelle auch als Workflow-Modelle bezeichnet werden; einige Standards verwenden den einen Begriff, andere den anderen. Keiner von beiden ist richtig oder falsch.

Ich empfehle oft, die Terminologie an das anzupassen, was in deinem Umfeld gut funktioniert. Für dieses Buch musste ich jedoch eine Wahl treffen und habe mich einfach für das entschieden, womit ich mich am wohlsten fühle. Als Faustregel gilt:

• Die Automatisierung von Geschäftsprozessen ist das , was du erreichen willst. Sie ist das Ziel. Sie ist das, worum sich Geschäftsleute kümmern. Ich werde in den meisten Fällen den Begriff Prozess (oder Geschäftsprozess) verwenden.

• Ich verwende den Begriff Workflow immer dann, wenn ich über die Werkzeuge spreche, mit denen die Prozesse wirklich automatisiert werden. Ich spreche also zum Beispiel von einer Workflow-Engine, auch wenn damit Prozessmodelle automatisiert werden.

Im echten Leben passe ich diese Regeln manchmal an. Wenn ich zum Beispiel mit Technikern über die Implementierung spreche, bevorzuge ich je nach Kontext die Begriffe Workflow, Workflow-Engine oder manchmal sogar Orchestrierungs-Engine oder Saga(die letzteren Begriffe wirst du verstehen, wenn du in diesem Buch weiter fortgeschritten bist).

Business-IT-Zusammenarbeit

Die Zusammenarbeit von Business Stakeholdern und IT-Fachleuten ist entscheidend für den Erfolg moderner Unternehmen. Business Stakeholder kennen das Unternehmen, den Markt, das Produkt, die Strategie und den Business Case für jedes Projekt. All das können sie in Anforderungen, Funktionen und Prioritäten umsetzen. Die IT-Abteilung hingegen kennt die bestehende IT-Landschaft und die Organisation - Einschränkungen und Möglichkeiten ebenso wie Aufwand und Verfügbarkeit. Nur wenn beide "Seiten" zusammenarbeiten, können sie gewinnen.

Leider sprechen unterschiedliche Rollen oft unterschiedliche Sprachen. Nicht wörtlich - beide können auf Englisch kommunizieren - aber in der Art, wie sie Dinge formulieren und verstehen.

Es hilft, den Geschäftsprozess in den Mittelpunkt der Kommunikation zu stellen. Es macht es viel einfacher, die Anforderungen im Kontext eines größeren Bildes zu verstehen und vermeidet Missverständnisse, die entstehen können, wenn man Funktionen isoliert diskutiert.

Visuelle Prozessmodelle erleichtern dieses Gespräch, vor allem, wenn sie von der Fachabteilung und der IT-Abteilung verstanden werden können. Alle effizienten Anforderungs-Workshops, die ich erlebt habe, waren mit Leuten aus dem Business und der IT besetzt.

Ein häufiges Beispiel dafür ist, dass Geschäftsleute die Komplexität von Anforderungen unterschätzen, aber gleichzeitig einfache Picks vermissen. Ein typischer Dialog geht so:

Unternehmen: "Warum ist die Implementierung dieses kleinen Buttons so viel Aufwand?"

IT: "Weil wir einen gigantischen Knoten in der Altsoftware lösen müssen, um das zu ermöglichen! Warum können wir nicht einfach hier eine Änderung vornehmen und das gleiche Ergebnis erzielen?"

Geschäft: "Was, warte, das können wir da drüben ändern? Wir dachten, das ist unmöglich."

Mit der richtigen Einstellung und einer guten Kultur der Zusammenarbeit wirst du nicht nur schneller vorankommen, sondern am Ende auch bessere Lösungen und zufriedenere Menschen haben. Prozessautomatisierung und vor allem visuelle Prozessmodelle werden dir dabei helfen. In Kapitel 10 wird das genauer erklärt.

Business Drivers und der Wert der Prozessautomatisierung

Unternehmen setzen Prozessautomatisierung ein, um:

• Bessere Kundenerfahrungen schaffen.

• Schneller auf den Markt kommen (mit veränderten oder völlig neuen Prozessen, Produkten oder Geschäftsmodellen).

• Erhöhe die geschäftliche Agilität.

• Treibe operative Kosteneinsparungen an.

Dies kann durch die Versprechen erreicht werden, die mit der Aussicht auf Prozessautomatisierung einhergehen: mehr Transparenz, Effizienz, Kosteneffizienz, Qualität, Vertrauen, geschäftliche Agilität und Skalierbarkeit. Schauen wir uns einige dieser Punkte kurz an.

Geschäftsprozesse bieten direkte Transparenz für die Beteiligten. Ein Geschäftsmann interessiert sich z. B. für die Reihenfolge der Aufgaben, z. B. dafür, dass die Zahlung vor dem Versand eingeht, oder dafür, wie er mit fehlgeschlagenen Zahlungen umgeht. Diese Informationen werden benötigt, um wirklich zu verstehen, wie das Unternehmen derzeit läuft und funktioniert. Die Daten, die Prozessautomatisierungsplattformen liefern, führen zu verwertbaren Erkenntnissen, die die Grundlage für Prozessoptimierungen sind.

Unternehmen legen Wert auf die Effizienz und Kosteneffizienz ihrer automatisierten Prozesse, aber auch auf Qualität und Vertrauen. Ein Online-Händler möchte vielleicht die Durchlaufzeit seines Bestellvorgangs verkürzen, damit ein Kunde so schnell wie möglich ein Paket erhält, nachdem er auf den Bestellknopf gedrückt hat. Und natürlich wollen Einzelhändler auch nicht, dass eine Bestellung durch die Maschen des Systems fällt und sie dadurch nicht nur einen verpassten Verkauf, sondern auch einen unzufriedenen Kunden haben.

Einige Geschäftsmodelle beruhen sogar auf der Möglichkeit, Prozesse vollständig zu automatisieren. Das ist für Unternehmen entscheidend, um Geld zu verdienen, Antworten so schnell wie erwartet zu liefern oder ihr Geschäft zu skalieren.

Geschäftsflexibilität ist ein weiterer wichtiger Faktor. Das Tempo der IT ist zu schnell, um wirklich jeden Trend vorhersehen zu können. Deshalb ist es für Unternehmen wichtig, Systeme zu entwickeln, die auf Veränderungen reagieren können. Der CIO eines Versicherungsunternehmens sagte kürzlich zu mir: "Wir wissen nicht, was wir morgen brauchen werden. Aber wir wissen, dass wir etwas brauchen werden. Also müssen wir in der Lage sein, schnell zu reagieren!" Für viele Unternehmen ist es überlebenswichtig, ihre Systeme und Architekturen so zu gestalten, dass sie sich leicht an Veränderungen anpassen lassen. Die Prozessautomatisierung ist ein wichtiger Baustein, denn sie macht es einfacher zuverstehen, wie die Prozesse derzeit umgesetzt werden, sich in Diskussionen über Änderungen einzubringen und diese umzusetzen.

Nicht die Prozessautomatisierungstools deiner Eltern

Wenn Prozessautomatisierung und Workflow-Engines eine so großartige Lösung für bestimmte Probleme sind, warum setzt sie dann nicht jeder ein? Natürlich gibt es Leute, die sie einfach nicht kennen. Häufiger ist es aber so, dass die Leute entweder schlechte Erfahrungen mit schlechten Tools gemacht haben oder nur eine vage Assoziation mit Begriffen wie Workflow oder Prozessautomatisierung haben und denken, dass sie mit Dokumentenflüssen der alten Schule oder proprietären Tool-Suiten zu tun haben, die sie nicht als hilfreich empfinden. Spoiler-Alarm: Das ist falsch!

Um diese Missverständnisse aus dem Weg zu räumen, ist es gut, sich der Geschichte und der Misserfolge der Vergangenheit bewusst zu sein. So kannst du deinen Kopf frei machen und eine moderne Denkweise über Prozessautomatisierung annehmen.

Eine kurze Geschichte der Prozessautomatisierung

Die Ursprünge der Technologie zur Automatisierung von Prozessen reichen bis in die Zeit um 1990 zurück, als papierbasierte Prozesse durch Dokumentenmanagementsysteme gesteuert wurden. In diesen Systemen diente ein physisches oder digitales Dokument als "Token" (ein Konzept, auf das wir in Kapitel 3 näher eingehen werden), und die Arbeitsabläufe wurden um dieses Dokument herum definiert. So wurde z. B. das Antragsformular für die Eröffnung eines Bankkontos eingescannt und automatisch an die Personen weitergeleitet, die es bearbeiten mussten.

Du kannst diese dokumentenbasierten Systeme immer noch im echten Leben entdecken. Kürzlich habe ich gesehen, wie ein Tool verwendet wurde, mit dem eine Menge Phantom-PDF-Dokumente erstellt wurden, nur um Arbeitsabläufe in Gang zu setzen, die nicht auf einem echten Dokument basieren.

Diese Kategorie von Systemen entwickelte sich weiter zu Tools für das Management menschlicher Arbeitsabläufe, die sich auf die Verwaltung menschlicher Aufgaben konzentrierten. Sie erreichten ihren Zenit um das Jahr 2000. Bei diesen Systemen brauchst du keine Dokumente, um einen Arbeitsablauf zu starten. Diese Systeme wurden jedoch entwickelt, um Menschen zu koordinieren, nicht um Software zu integrieren.

Dann, ebenfalls um das Jahr 2000, entstand die serviceorientierte Architektur (SOA) als Alternative zu großen monolithischen Ökosystemen, in denen herkömmliche Tools zur Integration von Unternehmensanwendungen (EAI) Punkt-zu-Punkt-Integrationen vornehmen. Die Idee war, die Funktionen in Dienste aufzuteilen, die dem Unternehmen in einer mehr oder weniger standardisierten Form angeboten werden, so dass andere sie leicht konsumieren können. Ein Grundgedanke von SOA war es, diese Dienste wiederzuverwenden und so den Entwicklungsaufwand zu verringern. Es entstanden hybride Werkzeuge: Werkzeuge, die auf SOA basierten, aber zusätzlich Funktionen für menschliche Aufgaben enthielten, und Produkte für menschliche Arbeitsabläufe, die Integrationsfunktionen enthielten.

Etwa zur gleichen Zeit gewann das Geschäftsprozessmanagement (BPM) als Disziplin an Bedeutung, die nicht nur diese technischen und werkzeugtechnischen Aspekte berücksichtigte, sondern auch die Lehren aus dem Aufbau skalierbarer Organisationen und dem Business Process Reengineering (BPR).

Diese Entwicklungen sind in Abbildung 1-6 zusammengefasst.

Abbildung 1-6. Historische Entwicklung der Disziplinen

Prozessautomatisierung war ein Hype-Thema in der BPM- und SOA-Ära. Leider gab es einige große Mängel, die zu vielen Enttäuschungen führten, und zwar aus den folgenden Gründen: BPM war zu sehr von den Entwicklern abgekoppelt, und die Tools waren zu herstellergesteuert, zu zentralisiert und zu sehr auf Low Code ausgerichtet. Lass mich das erklären.

BPM im Elfenbeinturm

BPM als Disziplin umfasst Methoden zum Entdecken, Modellieren, Analysieren, Messen, Verbessern, Optimieren und Automatisieren von Geschäftsprozessen. In diesem Sinne ist es ein sehr umfassendes Thema. Leider waren viele BPM-Initiativen zu sehr von der IT abgekoppelt. Lange Zeit arbeiteten die BPM-Verantwortlichen in Silos und berücksichtigten nicht, wie die Prozesse innerhalb der gegebenen IT-Infrastruktur wirklich automatisiert wurden. Das führte zu Prozessmodellen, die in der Praxis nicht funktionierten, und dennoch wurden diese Modelle den IT-Abteilungen zur "einfachen" Umsetzung überlassen. Es überrascht nicht, dass dies nicht sehr gut funktionierte.

Zentralisierte SOA und der ESB

Durch ein unglückliches Timing kollidierte SOA mit der Hochphase sehr komplexer Technologien wie dem Simple Object Access Protocol (SOAP), was es für jedes Entwicklungsteam schwierig machte, andere Dienste anzubieten oder zu nutzen. Dadurch wurde der Raum für Tool-Anbieter geöffnet. Da SOA-Initiativen in der Regel sehr zentralorganisiert und gesteuert wurden, brachte dies die großen Anbieter ins Spiel, die sehr teure Middleware verkauften, die in einem Top-Down-Ansatz im Herzen vieler Unternehmen platziert wurde. Die Werkzeuge wurden als Enterprise Service Bus (ESB) bezeichnet; im Kern handelte es sich um ein Messaging-System, um das herum mehrere Werkzeuge zur Verbindung von Diensten oder zur Transformation von Daten angeordnet waren.

Wenn wir aus heutiger Sicht auf SOA zurückblicken, fällt es leicht, einige der Unzulänglichkeiten hervorzuheben:

Zentralisiert

SOA- und ESB-Tools wurden in der Regel als zentralisierte Systeme installiert und von ihren eigenen Teams betrieben. Das führte dazu, dass du nicht nur deinen eigenen Dienst implementieren und einsetzen musstest, sondern auch mit dem SOA-Team interagieren musstest, um zusätzliche Konfigurationen in diese Tools einzubringen, was zu vielen Reibungsverlusten führte.

Fremde im Entwicklungsprozess

Werkzeuge unterbrachen den Entwicklungsworkflow und machten automatisierte Tests oder Continuous Integration/Continuous Delivery (CI/CD) Pipelines unmöglich. Viele der Tools erlaubten nicht einmal automatisierte Tests oder die Bereitstellung.

Anbietergesteuert

Die Anbieter überholten die Branche und verkauften Produkte, bevor es bewährte Methoden gab, wodurch vielen Unternehmen Methoden aufgezwungen wurden, die einfach nicht funktionierten.

Gemischte Infrastruktur und Geschäftslogik

Wichtige Geschäftslogik landete oft in Routing-Prozeduren, die auf der Middleware implementiert wurden, so dass es keine klaren Zuständigkeiten und Verantwortlichkeiten gab. Verschiedene Teams implementierten verschiedene Aspekte der Logik, die besser an einer Stelle zu finden wären.

Aber was hat das mit Prozessautomatisierung zu tun? Gute Frage! SOA wurde in der Regel zusammen mit BPM-Suiten entwickelt.

Fehlgeleitete BPM-Suiten

BPM-Suiten waren eigenständige Tools, die im Kern eine Workflow-Engine mit Tools drum herum enthielten. Wie ESBs waren auch diese Suiten herstellerabhängig. Sie wurden als zentralisierte Tools eingesetzt, die von oben nach unten eingeführt wurden. In diesen Umgebungen kümmerte sich ein zentrales Team um die Plattform, und dieses Team war oft die einzige Gruppe, die in der Lage war, sie einzusetzen. Diese Abhängigkeit von einzelnen Teams führte zu einer Reihe von Problemen.

Es ist erwähnenswert, dass BPM-Suites zu einer Zeit entstanden sind, als die meisten Unternehmen ihre Software noch auf physischer Hardware betrieben - automatisierte Bereitstellungspipelines waren damals noch nicht wirklich etwas Besonderes.

Die Grenzen von Low Code

BPM-Suites kamen mit dem Versprechen von Zero Code, das später in Low Code umbenannt wurde. Die Idee ist so einfach wie ansprechend für die Geschäftsinteressenten: Prozesse entwickeln, ohne dass die IT-Abteilung involviert ist, so dass eine nichttechnische Person ein ausführbares Prozessmodell erstellen kann, ohne Programmiercode zu schreiben.

Low-Code-Ansätze beinhalten schwergewichtige Tools, mit denen Nicht-Entwickler/innen Prozesse durch Ziehen und Ablegen vorgefertigter Elemente erstellen können. Ausgefeilte Assistenten ermöglichen es den Nutzern, sie zu konfigurieren, so dass es möglich ist, Lösungen zu erstellen, ohne Quellcode zu schreiben.

Dieser Ansatz wird von Beratungsfirmen und BPM-Anbietern immer noch als erstrebenswert verkauft, und der Low-Code-Ansatz hat in der Tat seine Vorzüge. Derzeit gibt es einen Mangel an Entwicklern, so dass viele Unternehmen einfach nicht die Ressourcen haben, um richtige Softwareprojekte durchzuführen, wie sie es gerne hätten. Weniger technisch versierte Menschen (von Gartner als " Citizen Developers" bezeichnet) beginnen, an Softwareprojekten zu arbeiten und brauchen diese Low-Code-Ansätze.

Aber während ein Low-Code-Ansatz für relativ einfache Prozesse funktionieren mag, greift er bei komplexen Geschäftsprozessen oder Integrationsszenarien definitiv zu kurz. Ich stelle immer wieder fest, dass Low-Code-Produkte nicht halten, was sie versprechen, und dass weniger technikaffine Entwickler/innen die Kernprozesse nicht selbst implementieren können. Infolgedessen müssen die Unternehmen auf ihre IT-Abteilungen zurückgreifen und diese bitten, professionelle Softwareentwickler/innen mit der Aufgabe zu betrauen. Diese Softwareentwickler müssen dann eine proprietäre, anbieterspezifische Art der Anwendungsentwicklung erlernen. Die Entwicklung dieser Fähigkeiten dauert lange und ist oft eine frustrierende Erfahrung. Die Folge ist, dass es in den Unternehmen an ausreichend qualifizierten Softwareentwicklern mangelt, so dass die Unternehmen gezwungen sind, nach externen Ressourcen zu suchen.

Diese externen Ressourcen sind Systemintegratoren, die mit dem BPM-Anbieter zusammenarbeiten und von diesem zertifizierte Berater bereitstellen. Diese Berater sind in der Regel entweder nicht so qualifiziert wie versprochen, zu teuer oder einfach nicht verfügbar, oft sogar alles gleichzeitig.

Außerdem:

• Du kannst keine bewährten Methoden aus der Branche verwenden, um Softwarelösungen zu entwickeln, wie z. B. automatisierte Tests oder Frameworks, die du vielleicht für die Integration oder Benutzeroberflächen brauchst. Du kannst nur das tun, was der Anbieter vorgesehen hat, denn es ist schwer oder sogar unmöglich, aus dem vorgezeichneten Weg auszubrechen.

• Du bist oft von Open-Source- oder Community-getriebenen Wissens- und Tool-Erweiterungen ausgeschlossen. Statt dir zum Beispiel ein Code-Beispiel von GitHub zu holen, musst du dir stattdessen ein Video-Tutorial ansehen, das dich durch den proprietären Assistenten führt, der dich durch die Low-Code-Schnittstelle führt.

• Die Tools sind in der Regel sehr schwergewichtig und laufen nicht ohne Weiteres auf modernen virtualisierten oder cloud-nativen Architekturen.

Diese unglückliche Dynamik hat dazu geführt, dass viele Unternehmen den Einsatz von Prozessautomatisierungswerkzeugen aufgegeben haben, auch wenn nicht alle Ansätze diese Art von proprietärer Software oder Low-Code-Entwicklung beinhalten.

Tipp

Anstatt die Softwareentwicklung durch Low-Code-Prozessautomatisierung zu ersetzen, sollte der Schwerpunkt darauf liegen, Softwareentwicklung und Prozessautomatisierung zusammenzubringen!

Es ist wichtig zu verstehen, dass Agilität nicht durch die Implementierung von Prozessen ohne die Hilfe von Entwicklern entsteht, sondern durch die Verwendung von grafischen Modellen, die verschiedene Interessengruppen verstehen und diskutieren können.

Sobald du die Prozessautomatisierung mit "normalen" Softwareentwicklungspraktiken kombinieren kannst, gewinnst du an Entwicklungseffizienz und -qualität, du erlaubst normalen Entwicklern, an diesen Aufträgen zu arbeiten, und du hast ein ganzes Universum an bestehenden Lösungen zur Verfügung, die dir bei allen möglichen Problemen helfen. Außerdem können Workflow-Anbieter die Unterstützung für bestimmte Integrationen bereits vordefinieren, was den Aufwand für die Entwicklung von Lösungen verringert.

BPM-Suiten der alten Schule hinter sich lassen

Die gute Nachricht ist, dass es inzwischen viele wirklich nützliche, leichtgewichtige Workflow-Engines gibt, die sich gut in typische Entwicklungspraktiken integrieren lassen und gängige Probleme lösen.

Diese neue Generation von Tools ist meist Open Source oder wird als Cloud-Service angeboten. Sie richten sich an Entwickler und unterstützen sie bei den Herausforderungen, die weiter oben in diesem Kapitel beschrieben wurden. Sie bieten einen echten Mehrwert und helfen unserer Branche, sich weiterzuentwickeln.

Die Geschichte von Camunda

Ich untermauere diese ganze Entwicklung immer gerne mit der Geschichte des Unternehmens, das ich mitgegründet habe: Camunda, ein Anbieter, der - wie das Marketing heute sagt - die Prozessautomatisierung neu erfunden hat. Wie im Vorwort erwähnt, soll dieses Buch kein Marketinginstrument für das Unternehmen sein, aber seine Geschichte kann dir helfen, die Entwicklung des Marktes zu verstehen.

Ich habe Camunda zusammen mit meinem Mitgründer im Jahr 2008 als Unternehmen gegründet, das Beratungsdienstleistungen rund um die Prozessautomatisierung anbietet. Wir haben viele Workshops und Schulungen durchgeführt und hatten dadurch Tausende von Kundenkontakten.

Dies kollidierte mit den Spitzenzeiten der alten BPM- und SOA-Ideen und -Werkzeuge. Wir konnten beobachten, wie verschiedene Tools in unterschiedlichen Unternehmen eingesetzt wurden. Das gemeinsame Thema war, dass es nicht funktionierte, und es war nicht schwer, die Gründe dafür herauszufinden. Ich habe sie bereits weiter oben in diesem Kapitel beschrieben: Diese Tools waren zentralisiert, komplex, wenig programmierbar undherstellergesteuert.

Also begannen wir mit den damals verfügbaren Open-Source-Frameworks zu experimentieren. Sie waren viel näher an den Entwicklern dran, konnten aber auch nicht überzeugen, vor allem weil sie zu einfach waren, wichtige Funktionen vermissen ließen und zu viel Aufwand erforderten, um eigene Tools dafür zu entwickeln.

Gleichzeitig haben wir an der Entwicklung des Business Process Model and Notation (BPMN)-Standards mitgearbeitet, der eine visuelle, aber auch direkt ausführbare Prozessmodellierungssprache definiert.

Und wir sahen eine große Chance: die Entwicklung einer Open-Source-Workflow-Engine, die entwicklerfreundlich ist und die Zusammenarbeit zwischen Unternehmen und IT durch die Verwendung von BPMN fördert.

Wir überprüften diese Idee mit Kunden und trafen bald die Entscheidung, das Unternehmen umzukrempeln: 2013 wandelten wir Camunda von einer Beratungsfirma in einen Open-Source-Anbieter für Prozessautomatisierung um. Unser Tool war das komplette Gegenteil der damals üblichen Low-Code-BPM-Suiten.

Heute wächst Camunda schnell und hat Hunderte von zahlenden Kunden und unzählige Community-Nutzer. Viele große Unternehmen vertrauen auf unsere Vision und ersetzen sogar Tools von großen Anbietern in ihren Unternehmen. Wir beschleunigen das Wachstum weltweit, da Werkzeuge zur Prozessautomatisierung dringend benötigt werden. Dies wird durch Digitalisierungs- und Automatisierungsprogramme sowie den Trend zu immer feinkörnigeren Komponenten und Microservices angeheizt, die dann koordiniert werden müssen. Kurz gesagt: Uns geht es sehr gut.

Technisch gesehen ist die Camunda Workflow-Engine so aufgebaut, wie Anwendungen im Jahr 2013 aufgebaut waren. Sie ist im Grunde eine Bibliothek, die in Java entwickelt wurde und eine relationale Datenbank zur Speicherung des Status verwendet. Die Engine kann in deine eigene Java-Anwendung eingebettet werden oder als eigenständige Anwendung laufen, die eine REST-API bereitstellt. Und natürlich gibt es eine Reihe von zusätzlichen Tools, um Prozesse zu modellieren oder zu steuern.

Diese Architektur hat Camunda sehr gut gedient und kann die meisten der heutigen Anforderungen an Leistung und Skalierbarkeit erfüllen. Dennoch haben wir vor ein paar Jahren eine neue Workflow-Engine in einer völlig anderen Architektur entwickelt, die man heute am besten als cloud-nativ bezeichnen kann. Diese Workflow-Engine wird parallel entwickelt und unterstützt das Managed Service-Angebot innerhalb der Camunda Cloud. Da sie unendlich skalierbar ist, ermöglicht sie den Einsatz einer Workflow-Engine in noch mehr Szenarien - eine Vision, die uns schon lange vorschwebte.

Fazit

Wie dieses Kapitel gezeigt hat, steht die Prozessautomatisierung im Mittelpunkt der Digitalisierungsbemühungen. Das macht Workflow-Engines zu einem wichtigen Baustein in modernen Architekturen. Glücklicherweise steht uns heute eine großartige Technologie zur Verfügung, die sich deutlich von den BPM-Suiten der alten Schule unterscheidet. Sie ist nicht nur entwicklerfreundlich, sondern auch äußerst leistungsfähig und skalierbar.

Workflow-Engines lösen Probleme bei der Handhabung von Zuständen und ermöglichen es dir, grafische Prozessmodelle zu modellieren und auszuführen, um den Kontrollfluss von Prozessen zu automatisieren. So kannst du Wildwest-Integration vermeiden und die Zusammenarbeit zwischen Unternehmen und IT bei der Automatisierung von Prozessen fördern. Du hast hier ein erstes Beispiel für ein Prozessmodell gesehen, das direkt auf einer Workflow-Engine ausgeführt wird; dies wird im nächsten Kapitel näher erläutert.