BPMN kurz erklärt

Die BPMN (Business Process Model and Notation) ist ein Industriestandard zur graphischen Spezifikation von Geschäftsprozessen. BPMN-Diagramme können dabei mehr als nur rein visuelle Darstellungen sein: Sie können in Workflow-Engines auch automatisiert ausgeführt werden. Dadurch wird es möglich, Geschäftsprozesse in Software-Produkten so umzusetzen, dass der jeweilige Prozess nicht nur für Software-Entwickler nachvollziehbar ist, sondern auch für Fachabteilungen. Mit BPMN-Diagrammen, die automatisiert ausgeführt werden, ergibt sich so eine gemeinsame Grundlage zwischen Fachabteilung und Software-Entwicklung – und damit neue Möglichkeiten für das Business-IT-Alignment.

Die wesentlichen Bausteine der BPMN sind Aktivitäten, Ereignisse, Sequenzflüsse und Gateways. Das folgende Beispiel definiert einen Prozess, der aus einem Startereignis, einer Aktivität und einem Endereignis besteht:

Die Beschriftungen sind optional, denn die BPMN verfügt über eine eindeutige Formensprache: Ereignisse sind immer kreisförmig (Startereignisse mit normaler Strichstärke, Endereignisse mit dicker Strichstärke), Aktivitäten sind stets Kästen mit abgerundeten Kanten und Sequenzflüsse zeigen als Pfeile die Verbindungen und Richtungen des Prozessablaufs an. Doch zur besseren Lesbarkeit ist es gute Praxis, die Elemente zu beschriften.

Was bewirkt dieser einfache Prozess? Nicht viel. Er hat einen Start und ein Ende und führt eine Aktivität aus. Interessanter wird es, wenn Gateways ins Spiel kommen. Mit Gateways sind u. a. Fallunterscheidungen möglich. Gateways sind als Rauten notiert, wie im folgenden Beispiel zu sehen:

Interessant an diesem zweiten Prozess ist das Exklusive-Gateway, das durch eine optional mit X gefüllte Raute dargestellt wird: Es handelt sich um eine Entweder-Oder-Fallunterscheidung. Je nachdem ob Bedingung A oder Bedingung B erfüllt ist, folgt der Prozess entweder dem oberen Pfad und führt zu Aktivität 2a oder dem unteren Pfad und führt zu Aktivität 2b. Danach werden die beiden Pfade wieder zusammengeführt und der Prozess endet.

Dieses Beispiel ist zwar sehr einfach und zeigt nur einen Bruchteil der Möglichkeiten mit BPMN – die BPMN kann im Detail durchaus komplex sein. Dennoch sind BPMN-Diagramme in der Regel auch für Menschen verständlich, die keine tiefer gehende Erfahrung mit der Notation haben. Daher eignet sie sich hervorragend als Bindeglied zwischen verschiedenen Abteilungen und stellt gewissermaßen ein verständliches, visuelles Vokabular zur Beschreibung von Geschäftsprozessen zur Verfügung.

Microservices und Domain Driven Design

In dieser Schnittstellenfunktion sind BPMN-Diagramme auch eine sehr gute Ergänzung zum Domain Driven Design. Beim Domain Driven Design handelt es sich um eine häufig verwendete Herangehensweise zur Entwicklung von Software-Produkten. In ihrem Zentrum steht eine gemeinsame, fachlich motivierte Sprache für eine abgegrenzte Domäne. Es bietet sich an, dass in den BPMN-Diagrammen eine fachliche Sprache verwendet wird, die die der Domäne im Sinne des Domain Driven Designs entspricht.

Häufig wird Domain Driven Design verwendet, um Microservices zu entwickeln. Microservices sind in der heutigen Software-Entwicklung eine gängige Architektur, um Verantwortlichkeiten aufzuteilen. Die so entstehenden Services sollen technisch unabhängiger, robuster und besser beherrschbar sein. Mit Blick auf das Domain Driven Design sollte ein Microservice nicht mehr als eine Verantwortlichkeit, eine fachliche Domäne, einen sogenannten Bounded Context implementieren. Die fachliche Sprache im Sinne des Domain Driven Designs bezieht sich nur auf diesen Kontext. Für die mit BPMN modellierten Prozesse, die dieselbe Sprache verwenden, ergibt sich so ebenfalls ein sprachlicher Kontext. Da sich dieser auf einen Microservice bezieht, entspricht das BPMN-Modell ebenfalls einem Microservice. Letztlich folgt daraus, dass die Geschäftslogik pro Microservice modelliert werden sollte und ein Microservice ein BPMN-Diagramm implementiert.

Im Sinne der Microservice-Architektur handelt es sich bei der Ausführung der BPMN-Diagramme um ein Implementierungsdetail: Die technischen Implementierungen der Services sollten möglichst unabhängig voneinander sein. Mit einer Workflow-Engine, die sich in die Implementierung eines Microservice einbetten lässt, ist das ohne Weiteres möglich. Eine solche Engine, die wir z. B. bei Interhyp verwenden, ist Camunda BPM. Es gibt dadurch also keine zentrale Stelle, die alle BPMN-Diagramme ausführt. Stattdessen kann jeder Microservice seinen eigenen Geschäftsprozess ausführen – ob dieser mit den Vorteilen von BPMN modelliert ist oder auch kein BPMN verwendet.

Damit unterscheidet sich diese moderne Verwendung der BPMN grundlegend von den in der Vergangenheit häufig umfangreichen BPM-Diagrammen, die als BPM-Monolithen schnell groß und unübersichtlich wurden.

Fallbeispiel: Antragsverteilung

Schauen wir uns die Modellierung eines Service am Beispiel der vereinfachten Version einer Antragsverteilung an. Der Geschäftsprozess, den wir modellieren wollen, gibt Finanzierungsanträge von Kunden an Finanzierungsberater zur Bearbeitung weiter. Letztlich wollen wir diesen Prozess automatisieren und durch einen Microservice ausführen lassen. Grundsätzlich sollte der modellierte Prozess dennoch auch von einem Menschen bearbeitbar sein. Dieser Hintergedanke erleichtert es, den Prozess so zu modellieren, dass er sich auf die Fachlichkeit fokussiert und sich nicht in technischen Details verliert. Dadurch ist der modellierte Prozess auch für Fachabteilungen leichter nachvollziehbar und überprüfbar.

Die erforderlichen fachlichen Schritte sind zunächst die folgenden:

• Der ausführende Microservice – oder der bearbeitende Mensch – erhalten eine Nachricht, dass ein neuer Antrag erstellt worden ist. Dies lässt sich in BPMN explizit als Startereignis modellieren:

• Danach muss festgestellt werden, welche Berater anwesend sind und Anträge grundsätzlich bearbeiten können. Ein Mensch, z. B. eine Führungskraft, kann diese Information erfragen. Unser automatisierter Prozess soll sie dagegen von einem externen System der Personalabteilung wie z. B. Workday beziehen. Die erste Aktivität ist demnach „Verfügbare Berater ermitteln“:

• Im nächsten Schritt stellt sich die Frage, wie gut die verschiedenen Berater zu dem neuen Antrag passen. Ein menschlicher Bearbeiter kann sich dabei auf Vorwissen und Erfahrung verlassen und die Kandidaten entsprechend sortieren. In unserem automatisierten Fall möchten wir diese Aufgabe dagegen an ein externes System delegieren, welches mit Methoden der künstlichen Intelligenz eine Sortierung vornimmt. In diesem Schritt erhalten wir so ein Ranking der Berater:

• Was machen wir mit diesem Ranking? Wir werten es aus. Der erste Berater des Rankings, also der am besten zum Antrag passende Berater, wird für den Antrag vermerkt. Ein menschlicher Bearbeiter trägt diesen Berater vielleicht in eine Papier-Akte ein. Unser automatisiertes System aktualisiert stattdessen einen Datenbankeintrag. Logisch erhalten wir so zwei weitere Schritte: Berater-Auswahl und Berater-Zuweisung:

• Im letzten Schritt des Prozesses müssen wir die neue Zuordnung kommunizieren. Ein menschlicher Bearbeiter ruft das Prozessergebnis vielleicht nur in den Raum. Unser automatisierter Prozess verschickt stattdessen eine entsprechende Nachricht – z. B. mit Apache Kafka. Wie auch beim Startereignis kann die BPMN auch dieses Ereignis „Ende mit Nachricht“ explizit modellieren:

Damit ist unser grundlegender Prozess modelliert. Natürlich ist der hier vorgestellte Prozess stark vereinfacht. In der Praxis gibt es eine Vielzahl weiterer Punkte, die zu berücksichtigen sind. So macht es unter Umständen Sinn eine geographische Verteilung und Organisationsstruktur zu berücksichtigen. Vielleicht gibt es auch vertragliche Vereinbarungen, die eingehalten werden müssen. Mit Sicherheit sollte auch die gewünschte und reale Arbeitsauslastung der Berater bei der Verteilung berücksichtigt werden. Es macht Sinn, diese und weitere Punkte explizit im Prozess zu modellieren, um sie einerseits zu fixieren und andererseits auch als Diskussionsgrundlage für und Diskussionsergebnis aus der Fachabteilung nutzen zu können.

Mehr Möglichkeiten

Dieser vereinfachte Prozess ist bisher eine lineare Abfolge von Aktivitäten. In der Realität sind derartige Prozesse, wie angedeutet, nicht nur fachlich komplexer, sie können zudem auch fehlschlagen oder ganz allgemein in Probleme laufen. Die BPMN bietet verschiedene Möglichkeiten, um auch diese Situationen zu modellieren. Darüber hinaus erlaubt sie die Modellierung von u. a.:

• Kompensationen: Für den Fehlerfall können Kompensationen definiert werden, um ausgelöste Nebeneffekte rückgängig machen zu können,
• Parallelität: Aktivitäten können nicht nur der Reihe nach, sondern auch gleichzeitig ausgeführt werden,
• Teilprozesse: Prozesse können weitere Prozesse enthalten oder auf diese verweisen; Teilprozesse können sequenziell oder parallel zum übergeordneten Prozess ausgeführt werden,
• Angeheftete Ereignisse: Aktivitäten können von Ereignissen unterbrochen werden oder ereignis-gesteuert parallele Abläufe starten,
• Eskalationsstufen, Benutzer-Aktivitäten, datengetriebene Geschäftsregeln und manches mehr …

Mit der BPMN können so eine Vielzahl von Geschäftsprozessen modelliert und automatisiert ausgeführt werden. Diese weiteren Möglichkeiten sind nicht zuletzt mit Blick auf eine Automatisierung besonders interessant. Denn eine ausführende Workflow-Engine arbeitet nicht einfach nur der Reihe nach die modellierten Aktivitäten ab, sie erweckt insbesondere auch die Semantik der einzelnen Elemente zum Leben. So löst sie zum Beispiel zeitgesteuerte Ereignisse aus, führt Aktivitäten parallel aus oder setzt Kompensationen um, ohne dass Entwickler dafür weiteren Code schreiben müssten. In den nächsten Blog-Artikeln zum Thema BPMN werden wir einige dieser Möglichkeiten weiter beleuchten.