Wie blutiges Unternehmen Open Source gewinnt: der Kampf um BPMS

Die Zahnräder einer modernen Bank drehen sich entsprechend den finanziellen Geschäftsprozessen. Sie sind komplizierter als gewöhnlich - diese Regel gilt für alles, zu dem Sie die Definition von „finanziell“ hinzufügen. Einerseits wird alles durch Aufsichtsbehörden, unzählige Zulassungen und Beteiligte kompliziert. Auf der anderen Seite - ungeschicktes monolithisches BPMS (Business Process Management System). In diesem Beitrag erfahren Sie, wie Sie ein solches System erfolgreich aufgegeben und auf ein flexibles und funktionales Open Source umgestellt haben.



Programmierer zeigen Geschäftsprozesse mit unterschiedlichen Notationen an. Jetzt ist der Standard BPMN (Business Process Model and Notation) - dies sind XML-Dateien mit angehängten Bildern. Um mit dieser Notation zu arbeiten, werden BPMS-Produkte erstellt - monolithische proprietäre Systeme, die versuchen, die maximalen Tools für die Entwicklung von BPM zu berücksichtigen: vom Benutzeroberflächen-Editor bis zum Versionskontrollsystem.

Nur Entwickler, die schon lange mit diesen Systemen arbeiten, können sie erweitern. In Enterprise BPMS wird eine REST-API bereitgestellt, dh auf Systeme kann als Antwort zugegriffen und diese empfangen werden. Es ist jedoch fast unmöglich, BPMS selbst zu modifizieren und zu optimieren. Es ist möglich, mit einem solchen BPMS nur mit einem begrenzten Satz von Tools des Herstellers zu arbeiten - einem proprietären Versionskontrollsystem, Compiler, Deployer - normalerweise wird für jedes große BPMS ein ganzer Satz entwickelt. Diese Tools entwickeln sich langsam, die gleichen Probleme können von Release zu Release bestehen bleiben, da nicht so viele Personen an der Arbeit beteiligt sind, wie dies bei Open Source der Fall ist. Im Allgemeinen stimmen die Fähigkeiten von BMPS für Unternehmen und die Bedürfnisse ihrer Benutzer sehr selten überein.

Bei der Werbung für solche Systeme geht es um End-to-End-Workflows. Sie sagen, dass das Unternehmen selbst BPM-Prozesse im laufenden Betrieb ändern kann. Aber selbst Analysten können dies nicht - nur Entwickler können damit umgehen.


Ein Geschäftsprozess besteht aus Benutzer- und Serviceaufgaben, deren Abläufe zum endgültigen Stopp führen. In BPMS können Sie mithilfe solcher Schemata die Ausführungszeit von Geschäftsprozessen sowie verschiedene Geschäftsindikatoren verfolgen, z. B. den KPI.

Wir müssen häufig Änderungen unterschiedlicher Größe an Geschäftsprozessen vornehmen. Früher hatten wir einen BPM-Prozess für Kundenmanager, die in zusätzlichen Büros sitzen. Im Jahr 2015 haben wir einige Büros geschlossen und Manager in die Feldarbeit versetzt. Dies erforderte große Änderungen in den BPM-Prozessen. Es war notwendig, andere Rollen und Aktionen einzuführen. Oder zum Beispiel hat sich die Regulierung des Dienstes für wirtschaftliche Sicherheit geändert, und statt zwei Koordinatoren gibt es jetzt drei.

Zunächst haben wir Änderungen über das IBM Lombardi BPMS vorgenommen. Nachdem es die typischen Mängel der Systeme seiner Klasse gesammelt hatte, zeichnete es sich auch durch das Fehlen einer geordneten Dokumentation aus. Es schien, dass der Software-Riese nach dem Kauf von Lombardi Software die amorphe Wolke der Begleitartikel betrachtete und beschloss, nichts anzufassen. Und selbst nach dem Lesen der gesamten Dokumentation war es unmöglich, viele Dinge zu tun. Rufen Sie beispielsweise eine REST-Anforderung mit HTTPS-Authentifizierung mithilfe eines Benutzerzertifikats auf. Glücklicherweise war die Suche nach einer Alternative ein Erfolg.

Camunda löst Probleme

Nach der Arbeit mit IBM BPM kamen wir zu dem Schluss, dass verschiedene Benutzergruppen in der Lage sein sollten, Geschäftsprozesse zu ändern. Etwas Unbedeutendes im Online-Modus kann von normalen Mitarbeitern von Geschäftsbereichen beigesteuert werden. Systemanalysten ändern die Reihenfolge der Aufgaben in Geschäftsprozessen. Neue Integrationen, Änderungen in der Benutzeroberfläche und im Programmcode bleiben auf der Seite der Entwickler. Um diese Flexibilität aufrechtzuerhalten, müssen alle BPMS auf Microservices bereitgestellt werden.

Wir können diesen Ansatz mit Open-Source-BPMS Camunda bereitstellen. Es ist eine Abzweigung des Activity-Projekts, das das Entwicklungsteam beschlossen hat, mehr zu verkaufen. Sie ordneten die Dokumentation und begannen, Camunda separat zu entwickeln, sie verdienen mit dem Verkauf von Support.

Mit BPMS Camunda können Sie Geschäftsprozesse mit Standard-Java bearbeiten und die gemeinsame Nutzung von Mikroservices unterstützen. Die Umstellung von BPMS auf Microservices bietet mehrere Vorteile gleichzeitig:

• Den Monolithen loswerden. Wir können Geschäftsprozesse nach Segmenten unterteilen und sie mithilfe von Rabbit MQ oder Kafka über die Warteschlange miteinander verknüpfen. Geschäftsprozesse können isoliert voneinander geändert und geändert werden, ohne auf eine vollständige Freigabe zu warten.
  
• Einen Geschäftsprozessserver loswerden.
  
• Skalieren. Wenn unter Last ein Server herunterfällt, kann er geklont werden. Bei Spitzenlasten können Sie die Produktivität leicht steigern, indem Sie mehrere Instanzen von Geschäftsprozessen in verschiedenen Diensten ausführen.
  
• Versionierung Wenn Sie beispielsweise die Java-Version aktualisieren müssen, können Sie mehrere Microservices mit unterschiedlichen Java-Versionen abrufen und die neue Version parallel ausführen. Jeder Microservice kann nicht nur verschiedene Softwareversionen haben, sondern auch verschiedene Sprachen.
  

In Zukunft planen wir, einen unserer größten Geschäftsprozesse auf Camunda zu übertragen - Corporate Lending. Hier ist alles viel komplizierter als bei Einzelpersonen und sogar bei kleinen und mittleren Unternehmen. Es handelt sich nicht um ein Produkt, sondern um ein begrenztes Kreditsystem. Die zeitlichen Grenzen sind begrenzt, die Kreditnehmer sind normalerweise Teil größerer Organisationen wie Beteiligungen, und die Beteiligungen haben etwas anderes zu tun. Die Grenzwerte werden für jede dieser Strukturen separat festgelegt, und jede Struktur hat ihre eigenen übereinstimmenden, deren Zusammensetzung sich ständig ändert. Wir erhalten einen Geschäftsprozess aus Hunderten von Phasen. Wir konnten es mit Camunda ändern und beschlossen, dabei zu bleiben. Selbst wenn die Entwickler jetzt beschließen, das Projekt zu schließen, werden die aktuellen Funktionen des Systems weitere drei Jahre dauern.

Unsere erste Version von Camunda basierte auf Websphere und unterschied sich kaum von IBM Lombardi. Wir haben beschlossen, die Anwendungen zu schreiben, auf die der Dienst bei Spring Boot zugegriffen hat. Sie wurden auf Tomcat bereitgestellt und arbeiteten nicht alleine. Dann stellte sich heraus, dass Camunda an Tomcat arbeiten konnte, eine Version für Spring Boot wurde entwickelt. Dort ist bereits eine vollständige Microservice-Architektur verfügbar. Alle Anwendungen, mit denen der Geschäftsprozess funktioniert hat, wurden auf einer auf Spring Cloud basierenden Microservice-Architektur implementiert.

Dann stellte sich heraus, dass Sie die Funktionalität nicht nur in Diensten, die den Geschäftsprozess bedienen, schnell ändern können. Die BPM-Engine selbst kann als Bibliothek mit jeder Springboot-Anwendung verbunden werden.

Camunda als Microservice

Es stellte sich die Frage: Wie viele Mikrodienste müssen angehoben werden? Es war möglich, einen Server für jeden Prozess zu erstellen und dort alle Microservices zu platzieren oder für jede Aufgabe einen eigenen Microservice und darin einen separaten Geschäftsprozess zu erstellen. Die zweite wäre bequemer, aber es wäre notwendig, die Interaktion von Prozessen zu organisieren, die über einzelne Mikrodienste verteilt sind. Wir haben verschiedene Optionen ausprobiert und uns für eine Lösung entschieden, wenn mehrere Microservices für ein bestimmtes Thema verantwortlich sind und dort mehrere Prozesse gruppiert sind. Die Kommunikation erfolgt entweder über REST oder über Rabbit MQ. Jetzt haben sie einen Piloten auf Kafka gestartet.

Perspektiven für BPMS

Geschäftsprozesse zeigen nicht nur den Geschäftsworkflow an, sondern reagieren auch auf Ereignisse, die in anderen Systemen auftreten. Wir haben diese Ereignisse durch eine separate Abteilung von Big Data akkumuliert. Basierend auf der Analyse dieser Ereignisse werden neue Geschäftsprozesse erstellt oder bestehende geändert - dies geschieht nachträglich mit einer Häufigkeit von beispielsweise einmal am Tag.

Im Idealfall sollten sich Geschäftsprozesse online ändern. Wenn beispielsweise die Nachfrage nach bestimmten Diensten steigt, priorisieren sie automatisch ihre Implementierung und weisen Ressourcen neu zu. Dies kann durch Automatisierung, Interaktion, zum Beispiel Kafka und Camunda, erreicht werden, dies ist jedoch eine Frage von mindestens mehreren Jahren. Vielleicht ist die vollständig online verfügbare englische Monzo Bank in Richtung Änderungen im Online-Modus am weitesten fortgeschritten. Und wir arbeiten auch daran.