Low-Code BPM-Suites vs. BPM-Frameworks - welche Lösung wann nutzen?

In vielen Unternehmen leisten Process Engines heute einen großen Beitrag zur Digitalisierung von Geschäftsprozessen. Am Markt haben sich viele Anbieter von Lösungen zur Prozessdigitalisierung etabliert, teilweise verfolgen deren Produkte aber sehr unterschiedliche Ansätze. Wir als viadee unterscheiden zwischen zwei Arten: BPM-Suites und BPM-Frameworks. In diesem Artikel möchten wir eine Einordnung vornehmen, eine Übersicht über deren Funktionsumfang geben, Gemeinsamkeiten und Unterschiede beleuchten und Empfehlungen abgeben, wann welche Art von Produkt sinnvoll ist.

Einordnung

Bei BPM-Suites handelt es sich um große, ganzheitliche Softwarelösungen, die eigene Umgebungen zur Entwicklung und Ausführung von Prozessanwendungen mitbringen. Dabei handelt es sich in der Regel um proprietäre Software. BPM-Suites verfolgen Low-Code-Ansätze - das bedeutet, dass die Entwicklung von Prozessanwendungen in Teilen mittels grafischer Benutzerdialoge anstatt durch das Schreiben von Quellcode erfolgt. Der Einsatz geführter Wizards soll IT-affine Fachanwender ohne Entwicklungshintergrund (sog. Citizen Developer) dazu befähigen, zumindest Teile von Prozessanwendungen eigenständig umzusetzen. Eine Übersicht über viele Hersteller liefert hier das amerikanische Marktforschungsunternehmen Gartner.

Unter BPM-Frameworks auf der anderen Seite verstehen wir leichtgewichtige Softwarekomponenten, die lediglich die wesentlichen Grundfunktionen einer Process Engine mitbringen und durch umfangreiche APIs in verschiedensten architekturellen Szenarien einsetzbar sind. Diese Lösungen sind oft als Open Source Software verfügbar. BPM-Frameworks richten sich an klassische Softwareentwickler - weite Teile von Prozessanwendungen werden mit klassischen Programmiersprachen wie z.B. Java implementiert ("Pro Code").  Beispiele für bekannte BPM-Frameworks sind Camunda BPM, JBoss jBPM, Activiti oder Flowable.

BPM-Suites

Schauen wir uns zunächst den Funktionsumfang von BPM-Suites genauer an. Dabei unterscheiden wir zwei Sichten: die Entwicklungsumgebung, in der Prozessanwendungen implementiert werden, sowie die Endanwendersicht.

Entwicklungsumgebung

Die Entwicklungsumgebungen von BPM-Suites bringen eine Vielzahl von Komponenten mit, dazu gehören in der Regel Tools zur:

• grafischen Prozessmodellierung
• Datenmodellierung
• Geschäftsregelmodellierung
• dem Formular Design - letzteres nach dem WYSIWYG-Prinzip (what you see is what you get),
• Benutzerzuweisung und Berechtigung (u.a. für die Zuweisung von Aufgaben)
• und der Integration von Schnittstellen.

Bei der Prozessmodellierung orientieren sich einige BPM-Suites an Standards wie der BPMN 2.0 (Business Process Model and Notation), andere bringen eigene Notationen oder individuelle Erweiterungen des BPMN 2.0 Standards mit. Die einzelnen Komponenten sind meist sehr eng miteinander verzahnt, sodass man z.B. im Formular Designer oder in den Dialogen zur Schnittstellenintegration direkten Zugriff auf das zuvor modellierte Datenmodell hat. Insbesondere die Formular Designer sind oft sehr mächtig und erlauben z.B. auch das dynamische Ein- und Ausblenden von Dialogelementen oder komplexere Feldvalidierungen. Es kann auf eine Vielzahl von vorgefertigten UI Komponenten zurückgegriffen werden. 

Darüber hinaus bieten sie meist eine Vielzahl kleinerer Wizards zur Ausgestaltung der Logik einzelner Prozessschritte, wie z.B. zum Versand von E-Mails oder der Generierung von PDFs. Komplexere Programmlogiken, wie etwa mathematische Berechnungen, werden mit Hilfe von Skriptsprachen implementiert - eine Script Engine kann die damit geschriebenen Scripts dann interpretieren. Zum Erstellen der Scripts bringen BPM-Suites in der Regel eingebaute Editoren mit, die zwar im Zusammenspiel mit den anderen Komponenten gut harmonieren, deren Funktionsumfang allerdings nicht vergleichbar mit dem leistungsfähiger Code-Editoren oder IDEs ist. Zumindest grundlegende Produktivitätsfeatures wie eine einfache Autovervollständigung sind meist vorhanden.

Bei der Integration von Schnittstellen stößt der Low-Code-Ansatz vieler BPM-Suites schnell an seine Grenzen. Zwar bieten diese für Standardsoftware wie z.B. SAP, Excel oder UiPath oft umfangreiche vorgefertigte Integrationsmöglichkeiten an, welche unserer Erfahrung nach auch gut funktionieren. Bei der Integration unternehmensinterner Individualentwicklungen reichen die Bordmittel zur Webserviceintegration aber oft nicht aus, da die internen Webservices der Unternehmen oft Eigenheiten aufweisen - manche benötigen zusätzliche HTTP-Header, eine spezielle Art der Authentifizierung oder liefern die Response im CSV-Format zurück - nicht immer sind diese Eigenheiten mit den Funktionen der BPM-Suites abbildbar. Relativ schnell landet man dann an dem Punkt, an dem der Webservice-Aufruf mit einem Script programmiert werden muss oder die Implementierung eines Konnektors bzw. Adapters mit einer klassischen Programmiersprache erforderlich wird, um die Schnittstelle in der BPM-Suite nutzbar zu machen. Daten-Mappings für den Aufruf von Schnittstellen erfolgen oft über grafische Mapping-Tools, in denen per Drag & Drop Pfeile von der Quell- zur Zieldatenstruktur gezogen werden. Das mag für einfache Mappings funktionieren, komplexere Transformationen erfordern dann aber oft eine Nachbearbeitung per Script oder müssen in den Konnektoren erfolgen.

BPM-Suites bieten oft Schnittstellen (APIs) an, die von anderen Anwendungen aufgerufen werden können (z.B. via REST oder SOAP) um mit der Process Engine zu interagieren. So lassen sich über diese APIs z.B. Prozesse von außerhalb starten. Unserer Erfahrung nach ist der Umfang dieser APIs je nach Hersteller sehr unterschiedlich und deckt nicht immer die benötigten Funktionalitäten ab.

Für das Software-Testing ist man von den Möglichkeiten abhängig, die der jeweilige Hersteller anbietet. Viele BPM-Suites bieten z.B. keine Funktionalitäten für das Erstellen von Unit-Tests für implementierte Scripts an. Jeder Hersteller bietet einen unterschiedlichen Umfang an Werkzeugen zur Qualitätssicherung. Es besteht allerdings immer die Möglichkeit manuelle/automatisierte Oberflächentests durchzuführen. 

Das Deployment von Prozessanwendungen ist im Vergleich zu den Deploymentprozessen in der klassischen Software Entwicklung (CI/CD Build Pipelines, Dependency Checks, Unit Tests, Docker/Kubernetes, ...) stark vereinfacht, was auf Kosten der Flexibilität und Individualität des Deploymentprozesses geht. Bei manchen Herstellern läuft das Deployment über den Export einer einzigen Datei, die dann händisch in einer Zielumgebung hochgeladen werden muss, andere bieten ein vollumfängliches Deploymentkonzept über geführte Oberflächen an. Die meisten BPM-Suite Hersteller bieten unterschiedliche Hostingoptionen (on-premise oder SaaS) an, so dass dann gezielt aus der Entwicklungsumgebung der BPM Suite auf diese Umgebungen deployed werden kann.

Endanwendersicht

Eine Stärke von BPM-Suites sind die ausgereiften Portale für die Endanwender, die in der Regel gut abgestimmt auf den Funktionsumfang der BPM-Suites sind. Dabei handelt es sich meist um Weboberflächen, die über eine Vielzahl von Features verfügen, darunter: 

• Prozesse per zuvor definiertem Formular starten
• User verwalten und berechtigen
• Prozessinstanzen administrieren
• Übersicht über zu bearbeitende Aufgaben (Task List)
• Übersicht über historische Prozessinstanzen
• zugewiesene Aufgaben in Prozessen bearbeiten (dazu werden die im Formular Designer erstellten Formulare für User Tasks gerendert)
• Reporting- und Analysefeatures.

Die Portale lassen sich in der Regel gut mit standardisierten Verzeichnisdiensten (z.B. Active Directory) bzw. Identity & Access Management-Lösungen integrieren, so dass Nutzer sich mit ihren bestehenden Unternehmensaccounts anmelden können. Die Integration mit UI-Eigenentwicklungen oder bestehenden Task Management-Lösungen ist allerdings oft nur eingeschränkt oder gar nicht möglich.

BPM-Frameworks

BPM-Frameworks bestehen meist aus einem Artefakt, das in den Quellcode einer Prozessanwendung als Dependency geladen werden oder eigenständig deployed werden kann. Viele Anbieter von BPM-Frameworks bieten auch Tools zur Prozessmodellierung an, dabei bewegt man sich in der Regel sehr nah an dem von der OMG spezifizierten BPMN Standard. Die Implementierung der Datenstrukturen und der Weboberflächen für User Tasks erfolgt mittels klassischer Programmierung.

Ebenfalls Bestandteil der meisten BPM-Frameworks sind mitgelieferte Webanwendungen zur Administration und dem Betrieb von Prozessanwendungen (z.B. Monitoring der Prozessinstanzen, Prozessdaten bearbeiten, Tokens verschieben, ...). Meist ist auch eine einfache Aufgabenverwaltung zur Bearbeitung von User Tasks enthalten. Letztere sind allerdings nur für sehr einfache Anwendungsfälle zu empfehlen, die Formulare zur Bearbeitung von User Tasks müssen mit den Methoden der klassischen Webentwicklung implementiert werden.

Die APIs der BPM-Frameworks sind in der Regel sehr umfangreich und erlauben die Kommunikation mit der Process Engine in nahezu allen Belangen. So können z.B. User Tasks per API abgerufen und abgeschlossen werden, historische Informationen zu Prozessinstanzen abgefragt werden, neue Prozessversionen oder Geschäftsregeln deployed werden und vieles mehr. Das ermöglicht insbesondere auch eine vollständige Entkopplung der Endanwendersicht von der eigentlichen Process Engine (z.B. durch eine Individualentwicklung einer Webanwendung). Auch grundlegende infrastrukturelle Anforderungen, etwa an Autorisierung und Authentifizierung, sind so vollständig individuell und flexibel implementierbar.

Die Ausimplementierung der einzelnen Prozessschritte erfolgt vollständig in einer klassischen Programmiersprache (z.B. Java). Dadurch können beliebige Code Bibliotheken verwendet werden - sei es für den Versand von E-Mails, den Aufruf von SOAP-/REST-Services oder der Ausführung anwendungsfallspezifischer Geschäftslogiken. BPM-Frameworks harmonieren meist auch gut mit großen Applikationsframeworks wie z.B. Spring Boot. Insgesamt sind BPM-Frameworks sehr entwicklerfreundlich, da Entwickler alle gängigen Tools der Softwareentwicklung verwenden können: Build-Tools, Versionskontrollsysteme, IDEs wie IntelliJ IDEA, Docker/Kubernetes, etc.

Die Qualitätssicherung kann mit allen klassischen Tools der Softwareentwicklung erfolgen: Unit Tests, statische Code-Analysen, Integrationstests usw.

Fazit

Mit beiden Arten von BPM-Lösungen lassen sich Prozesse erfolgreich digitalisieren. Je nach Art der Prozesse ist aber der eine oder der andere Ansatz besser geeignet. Vor diesem Hintergrund kann sich unter Umständen sogar eine Einführung beider Arten von BPM-Lösungen in einem Unternehmen lohnen. 

BPM-Suites spielen ihre Stärke vor allem bei der Entwicklung von Prozessanwendungen aus, die sehr stark formulargetrieben sind, für die nur ein geringes Maß an Programmlogik erforderlich ist und die hauptsächlich Schnittstellen zu Standardprodukten integrieren, für die es bereits bestehende Adapter/Konnektoren gibt. Ein typisches Beispiel sind mehrstufige Freigabeprozesse für Dokumente. Bedingt durch den Low-Code-Ansatz kommt man bei dieser Art von Prozessen sehr schnell zu Ergebnissen und die Ausbildung von Citizen Developern führt zu einer noch engeren Zusammenarbeit zwischen Fachbereichen und IT. Daraus ergeben sich vielfältige neue Zusammenarbeitsmodelle - diese werden wir zu gegebener Zeit in einem weiteren Blogartikel beleuchten. Insbesondere das meist sehr ausgereifte Zusammenspiel von Prozessmodell-, Datenmodell- und Formulareditoren sowie die sehr niedrigschwelligen Deployments führen bei dieser Art von Prozessen zu einer höheren Entwicklungsgeschwindigkeit. Das geht allerdings auf Kosten von Wartbarkeit, Robustheit und Flexibilität. Man sollte auch die Menge an herstellerspezifischem Spezialwissen berücksichtigen, dass Citizen Developer sich aneignen müssen, um mit einer BPM-Suite arbeiten zu können. Da Spezialisten für BPM-Suites rar sind, hat die Einführung einer BPM-Suite also auch nicht zu unterschätzende Konsequenzen hinsichtlich Ausbildungsaufwänden und Personalakquise. 

Werden hingegen komplexe (Kern-)Geschäftsprozesse entwickelt, die hochgradig auf die Integration von Schnittstellen zu Individualentwicklungen angewiesen sind, sind leichtgewichtige BPM-Frameworks das Mittel der Wahl. Ein typisches Beispiel dafür sind die Antragsprozesse in Versicherungsunternehmen. Mit BPM-Frameworks entwickelte Prozessanwendungen bieten alle Freiheiten der klassischen Softwareentwicklung, lassen sich hervorragend in die eigene Anwendungslandschaft integrieren und ermöglichen durch die Nutzung gängiger Entwicklungstools einen geringen Einarbeitungsaufwand für klassische Softwareentwickler, einen hohen Qualitätsstandard sowie ein hohes Maß an architektureller Flexibilität.

Denkbar wären auch Szenarien, in denen beide Lösungen zusammenspielen: So könnte ein recht formulargetriebener Prozess, der mit einer Low Code BPM-Suite umgesetzt wurde, einen hochintegrativen, nachgelagerten Prozess starten, der mit einem BPM-Framework umgesetzt wurde. Anders herum könnten auch formulargetriebene Teilprozesse, die mit einer BPM-Suite umgesetzt wurden, von einem übergeordneten Gesamtprozess gestartet werden, der von einem BPM-Framework orchestriert wird.

Ausblick

Momentan ist viel Bewegung auf dem Markt, so hat Camunda als Anbieter eines BPM-Frameworks jüngst eine Offensive zur Entwicklung von "Smart Low Code"-Features gestartet - schaffen es Anbieter von BPM-Frameworks in Zukunft, die Vorteile von Low-Code-Ansätzen mit denen klassischer Softwareentwicklung sinnvoll zu vereinen? Den ersten vielversprechenden Grundstein hat Camunda mit der Entwicklung eines eigenen Formulareditors und Konnektoren zu gängigen RPA-Lösungen zumindest gelegt. Auch die Verbindung von Low-Code-Entwicklungsframeworks (kein BPM) mit BPM-Frameworks ist denkbar, wie in diesem auf der Camunda-Website veröffentlichten Blogartikel. Mit Einführung der neuen Camunda Version 8 wird auch erstmalig eine Cloud-Dienstleistung angeboten (ähnlich wie bei vielen BPM-Suites).