BPM und Microservice Architekturen

Microservices spielen in der heutigen modernen IT Landschaft eine immer wichtiger werdende Rolle. Das Konzept einer Microservice Architektur basiert dabei nicht nur auf technischen, sondern auch auf organisatorischen Aspekten. Diese erlauben es, Software schneller zu entwickeln und robuster gegenüber sich ändernden Anforderungen zu machen. 

Aber wo finden sich in diesem Architekturstil die Ideen von BPM wieder?

Microservices bestimmen heute nicht nur die Softwareentwicklung im Allgemeinen, sondern gewinnen auch für die Entwicklung von Geschäftsanwendungen immer mehr an Bedeutung. Dabei stellen Microservices nicht nur eine Technologie für die Entwicklung von Software dar, sondern stellen auch Prinzipien auf, die es erlauben auch komplexe IT Systeme in einer sich immer schneller entwickelnden Geschäftswelt abzubilden.
Ich möchte zu Beginn kurz auf die wichtigsten Prinzipien dieses Architekturstils eingehen, da diese die Bedeutung der Microservice Architektur gegenüber bisherigen Lösungsansätzen verdeutlichen: 

Single Responsibility Principle 

Microservices bilden einen klar abgegrenzten Funktions- und Verantwortungsbereich ab. Die Größe und der Umfang eines Microservices ist dabei natürlich subjektiv und letztlich vom Gesamtsystem abhängig. Als Grundregel gilt jedoch: Ein Microservice sollte klein genug sein, um von einem einzelnen Entwicklerteam verstanden, entwickelt und betreut zu werden. Jeder Microservice und damit auch das Entwicklerteam, sollte nur für diesen Funktionsumfang innerhalb des Gesamtsystems verantwortlich sein. 

Separation of Concern 

Die Anforderungen an einen Microservice sollten sich möglichst nicht mit Anforderungen aus anderen fachlichen Domänen überschneiden. Ein Microservice sollte so geschnitten sein, dass dieser immer nur Objekte und Funktionen abbildet, die in derselben fachlichen Domäne liegen. Das Hauptziel ist es hier, die Interaktion zwischen den Services möglichst zu reduzieren, so dass Änderungen an einem Service keine Auswirkungen auf andere Services haben.

Die API eines Microservices ist dabei so gestaltet, dass diese die interne Implementierung vor externen Systemen verbirgt. Diese Kapselung verringert die Komplexität und verbessert die Flexibilität des Services.
Microservices können dadurch als eigenständige Applikationen innerhalb der Gesamtarchitektur verteilt werden. D.h. ein Microservice kann auf einer eigenen unabhängigen Serverumgebung laufen. Die Geschäftslogik, das Datenmodell, sowie die API (auch UI) sind dabei Teil des Services. 

Zustandslos und Unabhängig 

Ein Microservice sollte keine Zustände in einem sogenannten Session Context vorhalten. Jede Anfrage sollte nur mit den in der Anfrage selbst enthaltenen Informationen verarbeitet werden können. D.h. ein Microservice muss in der Lage sein, eine Anfrage zu beantworten, ohne auf vorherige oder nachfolgende Aufrufe Rücksicht nehmen zu müssen.

Darüber hinaus sollte jeder Microservice möglichst unabhängig von anderen Services innerhalb desselben Gesamtsystems ausführbar sein. Dabei kann ein Microservice durchaus selbst andere Services nutzen. Ein Beispiel hierfür ist ein Reporting Service, der nach Abfrage anderer Services einen zusammenfassenden Bericht oder einen aggregierten Datensatz zurückliefert. In diesem Szenario sind dann die jeweils aufgerufenen Systeme aber selbst wieder unabhängige Services. Man bezeichnet dieses Prinzip auch häufig als lose Kopplung.
Werden diese Prinzipien verletzt, führt dies unweigerlich zu einer höheren Komplexität. 

Microservice & BPM 

Die Idee einer Microservice Architektur besteht also darin, die fachlichen Anforderungen in kleine, voneinander unabhängige Dienste aufzuteilen, um so die Entwicklung flexibler zu gestalten und ein robusteres Gesamtsystem zu schaffen. Eine Frage, die sich jedoch nach dieser kurzen Einführung in die Microservice Architektur stellt, lautet:
Was passiert eigentlich mit den Geschäftsprozessen innerhalb einer solchen Architektur?

Betrachten wir dazu zunächst einmal die bekannten monolithischen IT-Systeme. Geschäftsprozesse bilden in einem solchen IT-System organisatorische Abläufe und Geschäftsregeln auf einer technischen Ebene ab. Diese haben meist eine steuernde Funktion innerhalb einer Unternehmensanwendung.
Bei einem monolithischen Anwendungsdesign sind die einzelne Module technisch eng miteinander verknüpft und bilden so allein durch ihre Beziehungen zueinander den dahinter liegenden Geschäftsprozess ab. Häufig wird dieser dabei gar nicht explizit modelliert, sondern wird über Regeln und Konfigurationsparameter programmatisch abgebildet. Durch den Einsatz einer Workflow Engine können solche Abläufe flexibler gestaltet und modelliert werden. Änderungen am Geschäftsmodell können dann auch zu Laufzeit innerhalb des Softwaresystems durchgeführt werden. Die Workflow Engine wird dazu in das Gesamtsystem eingebettet.

In einer Microservice Architektur fehlt dieser zentrale Ansatz einer Prozesssteuerung. Wie eingangs erwähnt, ist es hier ja gerade das Ziel einzelne Services möglichst unabhängig voneinander zu entwickeln und zu betreiben. Zwar kann auch innerhalb eines einzelnen Microservices eine BPM Engine zum Einsatz kommen, um Teile einer Prozesslogik abzubilden, jedoch würde hier ein zentraler Ansatz der Prozessteuerung, im Sinne einer Orchestrierung verschiedener Services, zu einer Verletzung der oben genannten Prinzipien führen. 

Geschäftsprozesse managen 

Betrachten wir hierzu als Beispiel eine Unternehmensanwendung zur Auftragsabwicklung aus einem Online Shop. In einer Microservice Architektur können hier die zentralen Funktionen wie “Ordering”, “Invoicing” und “Logistik” in einzelne voneinander unabhängige Services aufgetrennt werden. Man bezeichnet diese Services dann auch als Verticals, da diese sowohl die Business Logik als auch den Data Store enthalten. Die Steuerung untereinander erfolgt dabei entweder durch direkte Aufrufe oder das Versenden von Nachrichten. (Abb. 1)  

Abb 1.

Wird nun von einem Kunde aus dem Online Shop eine neue Bestellung über den Order Service ausgelöst, kann von diesem über ein entsprechendes Event sowohl die Rechnungserstellung (Invoice Service) als auch die Auslieferung der Artikel (Logistic Service) angestoßen werden.

Abb. 2

Aus Sicht des Geschäftsprozessmanagements besteht nun zwischen dem Order Service und den, den beiden benachbarten, Services eine Abhängigkeit, wo hingegen die Services Invoice und Logistic weiterhin voneinander entkoppelt sind. (Abb. 2) 

Ändert sich nun aber der Geschäftsprozess so, dass die Auslieferung des Artikels künftig erst nach der Rechnungsstellung erfolgen soll, ändern sich auch die Abhängigkeiten zwischen den einzelnen Services. (Abb. 3)  

Abb. 3

Es entsteht hier also das Problem einer direkten Kopplung zwischen den einzelnen Services. Die hier vorgenommenen Änderungen am Geschäftsprozess ziehen also unweigerlich Änderungen an mehreren Services nach sich. Der Grund ist, dass die Prozesslogik nun über alle Serviceschichten verteilt ist. Wie kann nun dieses Problem einer engen Kopplung vermieden werden? 

Die Business-Process-Service-Architektur

Um das hier beschriebene Problem zu lösen, verbindet die Idee einer Business-Process-Service Achtitektur – kurz BPSA – die Konzepte von Microservices und BPM. Dazu wird der Geschäftsprozess selbst als ein eigenständiger Microservice mit Hilfe einer Workflow-Engine umgesetzt und in die bestehende Architektur eingebunden.

Nach Außen stellt der Business Process Service dazu eine einheitliche REST-API zur Verfügung, welche es den einzelnen Services erlaubt, den Status des Geschäftsprozesses abzufragen und Änderungen des eigenen Zustandes an diesen zu kommunizieren.
Damit wird in dieser Architektur die direkte Kopplung einzelner Services untereinander aufgehoben. Änderungen am Geschäftsprozess können nun an einer einzigen Stelle abgebildet werden. 

BPMN 2.0 

Geschäftsprozesse werden heute meist mit Hilfe der Business Process Model and Notation – kurz BPMN 2.0 beschreiben. BPMN wurde ursprünglich entwickelt, um einen Geschäftsprozess rein fachlich, also ohne die technischen Details eines Softwaresystems zu beschreiben. Ein BPMN-Diagramm ist daher sehr leicht zu verstehen und ein guter Ausgangspunkt für Management und Entwickler, um gemeinsam über einen Geschäftsprozess zu diskutieren. Neben der allgemeinen Beschreibung eines Geschäftsprozesses kann ein BPMN-Modell seit Version 2.0 auch von einer Prozess- oder Workflow-Engine ausgeführt werden. Ein Workflow-Managementsystem kann damit einen Prozess ausführen und überwachen. So können zum Beispiel mit Hilfe von Imixs-BPMN fachliche Modelle mit den technischen Details eines Workflows ergänzt werden, um so ein Modell innerhalb eines Microservices ausführbar zu machen. Das Open Soruce Projekt Imixs-Workflow stellt dazu eine human centric workflow engine bereit, die über eine REST-API sehr einfach in eine Microservice Architektur eingebunden werden kann. 

Unternehmensprozesse 

Mit Hilfe der BPMN 2.0 Notation können solche übergreifende Unternehmensprozesse, unabhängig von einzelnen Services modelliert und beschrieben werden. Die Geschäftsprozesse bilden dabei sämtliche Arbeitsabläufe innerhalb einer Organisation ab, die mit dem System implementiert werden sollen. Ein einzelner Microservice selbst muss dazu keine eigene Geschäftsprozesslogik mehr implementieren, sondern kann über die API des Business Process Services den Status des Gesamtprozesses feststellen und den eigenen Prozessfortschritt an diesen melden. Dazu können innerhalb des Business Process Services auch unterschiedliche Prozessmodelle hinterlegt werden, die dann beispielsweise nur von einzelnen Services verwendet werden. Dadurch kann eine weitere Entkopplung der Prozesse geschaffen werden, die Auf Modellierungsebene aber stets ein vollständiges Bild der einzelnen Abläufe widerspiegelt (Abb. 4).  

Abb. 4

Prozesse überwachen und steuern

Mit Hilfe einer Business Prozess Service Architecture können Geschäftsprozesse innerhalb einer Microservice Architektur also auf unterschiedlichen Ebenen überwacht und gesteuert werden. Durch die Vergabe von Zugriffsrechten sowie die Modellierung von Verantwortlichkeiten und Benachrichtigungen kann sicher gestellt werden, dass die technischen wie auch fachlichen Abläufe innerhalb eines Microservices sich stets an den Geschäftsregeln und Unternehmensprozessen orientieren.

Eine Workflow Engine überwacht dabei die einzelnen Prozesse und stellt den strukturierten Ablauf innerhalb der Unternehmensprozesse sicher.
Durch die übergreifende Modellierung eines Unternehmensprozesses erhalten darüberhinaus auch die einzelnen Mitarbeiter einen Gesamtüberblick über den Geschäftsprozess und können im Bedarfsfall steuernd eingreifen. So kann beispielsweise eine Eskalation ausgelöst werden, wenn die Bearbeitung einer bestimmten Aufgabe innerhalb eines festgelegten Bearbeitungszeitraums nicht erfolgt (Eskalation).

Aber auch der Eingriff von Prozessverantwortlichen in einen laufenden Workflow ist durch die Modellierung entsprechender Aktivitäten jeder Zeit möglich. So kann ein Workflow-Management-System beispielsweise einem Vertriebsleiter Statusinformationen über aktuelle Aufträge zur Verfügung stellen und diesem erlauben, einen Prozess an einer bestimmten Stelle zu stoppen. Der Vertriebsleiter muss dazu nicht die Details einzelner Microservices kennen und besitzt in der Regel auch nur eine High-Level-Sicht auf den Prozess.

An diesem Beispiel wird deutlich, dass ein Business Process Service eine weit umfangreichere Rolle in der Prozessarchitektur spielen kann, als nur die Verwaltung von Zuständen. Je nach Aufbau des Prozessmodells können damit – ausgehend vom Unternehmensprozess – einzelne Services aufgerufen, gestartet und überwacht werden. Aber auch innerhalb eines einzelnen Services können so Teilprozesse gesteuert und kontrolliert werden. Im Bedarfsfall können einzelne Mitarbeiter in den Prozess aktiv eingebunden werden, ohne dass diese innerhalb eines Microservices selbst implementiert werden muss. Das Prozessmodell kann leicht mit zusätzlichen Tasks oder Events erweitert werden, um so den Gesamtprozesses an die unterschiedlichen Anforderungen eines komplexen Prozesses anzupassen. 

Fazit 

Mit Hilfe der Business Process Service Architecture können nun Prozessmodelle in eine Microservice Architektur übertragen werden, ohne dabei die Prozesslogik selbst auf einzelne Microservices zu verlagern. 

Neben der Kontrolle des Geschäftsprozesses stellt der Business Process Service einzelnen Microservices, wie auch den beteiligten Akteuren, einen Überblick über den Prozessfortschritt zur Verfügung. Damit wird der Business Process Service innerhalb einer Microservices-Architektur zum Central Point of Information und hilft so, die Synchronisationsprobleme zwischen einzelnen Services aufzulösen. Änderungen am Prozessablauf lassen sich unabhängig von einzelnen Microservices durchführen. 

Für die Umsetzung einer solchen Architektur sind natürlich auch Erfahrungen in der Geschäftsprozessmodellierung erforderlich. Die Auswirkungen dieser Architektur können jedoch beeindruckend sein, vor allem, wenn die Workflow Engine selbst bereits viele Funktionen der Businesslogik abdeckt. So können z. B. mit dem Open-Source-Projekt Imixs Workflow, E-Mail-Nachrichten versendet oder Aufgaben an verschiedene Akteure im Unternehmen verteilt werden. Auch die Überwachung von Abläufen und die Protokollierung einzelner Prozessschritte kann mit einer Workflow Engine erreicht werden.

Also – auch in Zeiten moderner Microservice-Architekturen lassen ich mit Hilfe von BPM & BPMN fachliche und technische Anforderungen verbinden und so komplexe Softwaresysteme schneller und flexibler entwickeln.

 

Autor: Ralph Soika ist Projectlead im Open-Source-Projekt Imixs-Workflow und Geschäftsführer der Imixs GmbH