Kategorie: Prozessgesteuerte Anwendung

Die digitale Transformation ist stark von der Prozessautomatisierung geprägt. Dazu hat sich zur Modellierung von Prozessen mittlerweile der weltweit anerkannte Standard BPMN (Business Process Model and Notation) etabliert. Die Notation erlaubt gleichzeitig die Ausführung derartiger Modelle durch BPMN-basierte Process Engines. Abgerundet wird dieses Paket bestehend aus BPMN als Notation und Process Engines zu deren Ausführung durch den Prozessgesteuerten Ansatz, einer Methodik zur Entwicklung vollständiger Prozessanwendungen inklusive einer dazu passenden Softwarearchitektur. Dieser Ansatz stellt die erfolgreiche Umsetzung von Prozessanwendungen einschließlich ihrer langfristigen Wartung sicher.

Der Prozessgesteuerte Ansatz, so ehrlich muss man sein, steht und fällt allerdings mit der Qualität der genutzten Process Engine. Also musste ich mich zu Beginn meiner Lehrtätigkeit an der Technischen Hochschule Ingolstadt (THI) im Jahre 2016 für eine Process Engine entscheiden. Es war also schon damals eine aufwändige Entscheidungsfindung notwendig, die schließlich in der Wahl einer Open Source-Lösung mündete. Seit 2016 setzte ich diese Process Engine also nun in meiner Lehre ein und es bestand wahrlich keine Not für einen Wechsel. Um es kurz zu sagen: Ich war mit meiner Wahl mehr als zufrieden. Allerdings wurde vom Hersteller meiner in der Lehre genutzten Engine die Weiterentwicklung aufgekündigt. Grund war, wie könnte es anders sein, der Wechsel in die Cloud. Die Parallelen zu SAP Process Orchestration sind offensichtlich. SAP Process Orchestration ist dabei die Ablauf- und Entwicklungsumgebung (inklusive Process Engine) für Prozessanwendungen, für die ich lange Jahre im Produktmanagement bei der SAP tätig war.

Durch diese Ankündigung hatte ich jedenfalls auf einmal ein Problem. Auch wenn der Wechsel nicht unmittelbar bevorsteht, so stört das Wissen darum und dass man auf einem „Auslaufmodell“ lehrt. Also stellte ich mir einen für meine Belange wichtigen Kriterienkatalog zusammen, aus dem ich im Rahmen dieses Artikels ein paar Punkte herausgreifen möchte. Die Liste meiner Kriterien sieht dabei wie folgt aus (Erläuterungen zu den einzelnen Punkten folgen im Anschluss):

1. Hersteller muss seine Engine als eine Infrastrukturkomponente sehen
2. Leichtgewichtiges Framework und keine schwergewichtige BPM-Suite
3. Kein Vendor Lock-in
4. Keine Konnektoren
5. Enterprise-Qualitäten
6. Geeignet für Universitäten, Hochschulen, aber auch für Startups und KMUs
7. Niedrige Einstiegshürde (Ziel: Leicht zu installieren und gleich loslegen)
8. Komplikationsloser Zugang
9. Keine Abhängigkeit von einer bestimmten Programmiersprache
10. Keine (zu hohen) Kosten
11. Nutzt der Hersteller seine Engine selbst produktiv, z. B. für eigene Produkte und/oder Dienstleistungen oder ist der Hersteller ein Trockenschwimmer?
12. Gute BPMN- sowie DMN-Unterstützung und -Abdeckung
13. Hohe Entwicklerproduktivität
14. Komfortables Debugging

Gehen wir kurz auf die einzelnen Punkte ein.

Ich beginne mit der Forderung, dass der Hersteller seine Engine als eine Infrastrukturkomponente ansehen sollte. Warum ist dieser Punkt, der so wenig intuitiv ist, so entscheidend? Er ist deshalb so wichtig, weil ich vermeiden möchte, dass eine Process Engine zu einer eierlegenden Wollmilchsau verkommt. Doch alles der Reihe nach. Zunächst einmal muss geklärt werden, was ich unter einer Infrastrukturkomponente im Gegensatz zu eine Now-Code-/Low-Code-Plattform verstehe. Eine Infrastrukturkomponente zeichnet sich durch ihre Fokussierung auf genau eine Aufgabe aus. Diese Aufgabe muss sie dafür umso professioneller umsetzen. Ich nutze als Beispiel immer gerne Datenbanken. Datenbanken sind für mich der Klassiker einer Infrastrukturkomponente. Sie konzentrieren sich auf die transaktionale Verwaltung von Daten unter Verwendung einer standardisierten Sprache (SQL). That’s it. Mehr soll sie nicht tun. Dasselbe wünsche ich mir für Process Engines. Wie Datenbanken sollten sie sich auf eine Kernfunktionalität konzentrieren, nämlich auf die transaktionale Steuerung von Prozessabläufen basierend auf einer standardisierten Sprache (BPMN). That’s it. Was Datenbanken für Daten sind, sind Process Engines für Prozesse. So einfach ist das.

Das Ergebnis dieser Anforderung ist das Gegenteil von dem, was ich aktuell am Markt beobachte. Die Hersteller überbieten sich geradezu mit immer neuen exotischen Features fernab der Kernfunktionalität, die die jeweiligen Process Engines zu komplexen BPM-Suiten anwachsen lassen. Dies gilt es allerdings zu vermeiden (Anforderung 2). Warum? Weil Kunden sich zunehmend von dem jeweiligen Hersteller abhängig machen, dem berühmt berüchtigten Vendor Lock-in. Je mehr proprietäre Funktionalitäten des jeweiligen Herstellers genutzt werden, desto größer die Abhängigkeit. Ist die Abhängigkeit bei betriebswirtschaftlichen Standardlösungen noch zu rechtfertigen, sind sie für Entwicklungsumgebungen und Automatisierungsplattformen aber ein No-Go (Anforderung 3). Schließlich hängt die Wettbewerbsfähigkeit der Unternehmen im Zeitalter der digitalen Transformation maßgeblich von der Freiheit, Flexibilität und Anpassungsfähigkeit im Bereich der Softwareentwicklung ab. Sich aber genau in diesem sensiblen Bereich von einem Hersteller abhängig zu machen, ist für mich rational nicht mehr nachzuvollziehen. Man beraubt sich zukünftiger Alternativen und ist auf Gedeih und Verderb dem Hersteller ausgeliefert. Ein Beispiel, anhand dessen man diese Entwicklung sehr gut erkennen kann, ist die Nutzung von spezialisierten Verbindungen zu bestimmten Systemen wie SAP oder Salesforce. Diese sogenannten Konnektoren erlauben das schnelle Anbinden von Systemen direkt aus den BPMN-Modellen heraus. Was nach einer großartigen Idee klingt, zeigt sich bei genauerem Hinsehen als böser Bumerang. Durch deren Verwendung holt man sich komplexe Schnittstellen in die Prozesse. Während des Modellierens müssen diesen Schnittstellen konkret Daten zu deren Aufruf zugeordnet werden, das sogenannte „Mapping“. Nur: Dieses Mapping ist eine klassische Integrationsanforderung und hat in einer Process Engine nichts verloren. Aus diesem Grund habe ich den Verzicht auf Konnektoren explizit in meine Liste aufgenommen (Anforderung 4).

Anforderung 5 adressiert die Fähigkeit einer Process Engine, im anspruchsvollen Unternehmenskontext eingesetzt werden zu können. Schließlich wollen wir komplexe Prozessanwendungen entwickeln und keine Micky Maus-Prozesse umsetzen. Von daher muss die Engine natürlich Enterprise-Qualitäten wie beispielsweise Zuverlässigkeit, Verfügbarkeit, Performance, Sicherheit und Skalierbarkeit genügen. Idealerweise ist sie „cloud-ready“.

Anforderung 6, also die Eignung der Process Engine für Universitäten, Hochschulen, aber auch für Startups und KMUs, kann als große Klammer für die Anforderungen 7 (niedrige Einstiegshürde), 8 (komplikationsloser Zugang), 9 (Programmiersprachenunabhängigkeit) und 10 (keine zu hohen Kosten) gesehen werden. Ich habe damit insbesondere die Eignung der Engine für Experimentier- und Proof-of-Concept-Szenarien im Kopf. Aber auch Startups und Unternehmen mit nur kleinem Budget soll der Zugang zu DER Schlüsseltechnologie der digitalen Transformation ermöglicht werden, um damit viele innovative Geschäftsmodelle am Markt ausprobieren zu können. Diese Wege werden durch schwerfällige und dabei gleichzeitig sündhaft teure BPM-Suiten verhindert. Daher liegen mir die genannten Anforderungen besonders am Herzen. Wenn ich gerade an meine Studierenden denke, so sollen sie mit einem Klick die Engine runterladen und nach dem Auspacken einer ZIP-Datei oder der Ausführung eines Docker-Pulls sofort mit dem Modellieren und Ausführen ihrer Prozesse beginnen können (Anforderung 7 und 8). Bitte keine Registrierung und ein Tag später steht der Vertriebler auf der Matte, um einen Deal abzuschließen. Auch nicht viel besser sind spezielle Verträge, die man als Ausbildungsstätte abschließen kann und den uneingeschränkten Zugriff auf die Software eröffnet. Das alles will ich nicht. Außerdem will ich mich bei der Wahl der Programmiersprache nicht einschränken lassen (Anforderung 9) und natürlich muss die Engine auch von der finanziellen Seite her stemmbar sein (Anforderung 10). Sechsstellige Beträge, wie sie teilweise aufgerufen werden, sind nicht kompatibel zu dem Budget kleiner und mittelständischer Unternehmen sowie Startups. Natürlich sollen die Hersteller von Process Engines gutes Geld verdienen. Aber es gibt sicherlich kreativere Wege, wie sich auch KMUs und Startups Process Engines leisten können. Mir tut es persönlich weh, wenn eine gute Geschäftsidee einzig daran scheitert, weil ein Hersteller auf seine üppigen Preise besteht. So wird ein potenziell lukrativer Markt für neue Geschäftsideen basierend auf Prozessautomatisierung im Keim erstickt.

Ein Aspekt bei der Bewertung von Process Engines ist die Nutzung der Engine und der dazugehörigen Entwicklungsumgebung durch den Hersteller selbst (Anforderung 11). Im Englischen gibt es dafür den herrlichen Ausdruck „Eat your own dog food“. Wie soll ich einem Anbieter vertrauen, der sein eigenes Produkt nicht einsetzt? Ergibt für mich keinen Sinn. Dieser Hersteller wird stets auf das Feedback seiner Kunden angewiesen sein, wie er das Produkt weiterentwickeln soll. Auf der anderen Seite hat der Eigennutzer einen intrinsischen Ansporn, das Produkt zu verbessern, da er ja selbst als erster davon profitiert. Diesen Sachverhalt merkt man einer Process Engine samt zugehöriger Entwicklungsumgebung deutlich an. Von daher ist dieser Aspekt tatsächlich eminent wichtig.

Schließlich muss die Process Engine eine sehr gute BPMN-/DMN-Abdeckung aufweisen (Anforderung 12) und eine signifikante Steigerung der Entwicklerproduktivität gewährleisten (Anforderung 13). Zur Entwicklerproduktivität zähle ich zum einen die Produktivität bei der erstmaligen Erstellung einer Prozessanwendung, zum anderen natürlich die ständige Weiterentwicklung durch Erweiterungen, Änderungen, Bugfixes, Anpassungen bei Releasewechseln, kurz alles, was im Laufe eines Software-Lebens an Arbeiten anfällt. Dabei ist die Pflege für mich von der Priorität her bedeutsamer als die Erstimplementierung, da die Pflege ständig stattfindet, die Erstimplementierung, wie der Name schon ausdruckt, aber nur einmalig. Hier ist grundsätzlich Vorsicht geboten, da Hersteller in ihrer Werbung primär die Schnelligkeit bei der Erstellung neuer Lösungen hervorheben. Dabei verschlingt die kontinuierliche Pflege über die Gesamtlaufzeit der Software betrachtet sehr viel mehr Geld. Folglich ist der Pflege von Prozessanwendungen bei der Auswahl einer Process Engine eine wesentlich kritischere Betrachtung einzuräumen.

Last but not least ist das zeiteffiziente Auffinden von Fehlern insbesondere in Produktivumgebungen für den Betrieb von Prozessanwendungen durch bestmögliche Debugging-Unterstützung überlebenswichtig (Anforderung 14). Gerade dieser Punkt ist bei der Nutzung von Aufrufaktivitäten und Kollaborationsdiagrammen in BPMN für mich von entscheidender Bedeutung, zumal der Prozessgesteuerte Ansatz deren intensive Nutzung empfiehlt. Denn ich muss in Fehlersituationen oft unter hohem Zeitdruck in die Szenarien eintauchen und erkennen können, wie eine spezielle Fehlersituation im Prozessablauf entstanden ist. Folglich muss ich ausgehend vom fehlerhaften Zustand schrittweise rückwärts durch meinen Prozess steppen können. Eine Anforderung, an der die meisten Engines und Entwicklungsumgebungen scheitern.

Soweit also die Erklärung einiger meiner für wichtig erachteten Aspekte, die ich bei der Auswahl einer Process Engine heranziehe. Welche Kriterien sind für Dich bei der Process Engine-Wahl entscheidend? Gerne kannst Du meine Liste ergänzen. Nutze dazu einfach die Kommentarfunktion.