👋🏻 🚴🏻 🤾🏼 So migrieren Sie einen großen Prozess von IBM BPM nach Camunda und stoppen die Feature-Entwicklung nicht 🅾️ 🛍️ 📕

Hallo, mein Name ist Denis, ich arbeite bei Tinkoff und mache BPM-Systeme. In diesem Artikel werde ich Ihnen anhand des Beispiels eines großen Prozesses erläutern, wie Sie vom Legacy-System a la IBM BPM auf die Open-Source-Camunda-Prozess-Engine migrieren können. Und am Ende werde ich Sie zum vierten Treffen auf Camunda einladen, das am Abend am 27. Februar in Tinkoff in Moskau (Metro Vodny Stadion) stattfinden wird.

BPMS-Systeme und BPMN als Möglichkeit, sie zu programmieren

Die Idee, dass durch Programmierung programmiert werden kann, ist gut verkauft , der Markt wächst von Jahr zu Jahr. Einige Unternehmen erzielen wirklich coole Ergebnisse.
Um gute Projekte zu realisieren und erfolgreich zu verkaufen, müssen BPMS-Systeme neben dem „Essen“ von BPMN-Dateien auch in der Lage sein:

Identifizieren Sie bestimmte Darsteller in Prozessen
Bereitstellung von Schnittstellen für Benutzer, Implementierer und Administratoren
Rufen Sie externe Dienste an, senden und hören Sie Ereignisse usw. Im Allgemeinen in der Lage sein, in den Code "durchzufallen"
Bereitstellung von Datenmodellierung und -speicherung
Befolgen Sie die Geschäftsregeln
Testen Sie alles, was erstellt wurde

Wir haben IBM BPM BPMS in Tinkoff verwendet, was uns aufgrund seiner Komplexität und akzeptablen Abdeckung dieser Funktionen bei der Entwicklung geholfen hat. Aber wir haben beschlossen, es abzulehnen.

Gründe für die Aufgabe von IBM BPM

Wir haben festgestellt, dass wir aufgrund der großartigen Funktionalität des BPMS-Systems nur Folgendes verwenden:

Interpretation von BPMN-Dateien
In Code fallen

Andere Dinge wurden auf andere Systeme übertragen, zum Beispiel:

, — , , . , BPMS. , — CRM Siebel.
Siebel CRM-. Siebel , — - UI.
Die Datenspeicherung wurde irgendwo nach Siebel verlegt - in Situationen, in denen viele Verbraucher CRUD-Operationen für Daten benötigen, und irgendwo - in separaten Anwendungen. Mit IBM BPM können Sie Daten in einem relationalen Stil simulieren. Er erstellt die Platten für das Modell. Es speichert jedoch alles in einer Datenbank für alle Prozesse, wodurch zusätzliche Konnektivität entsteht und die Datenbank belastet wird.
Für Geschäftsregeln verwenden wir traditionell IBM ODM, und jetzt beginnen wir, unser Kotlin-Framework zu verwenden.
Normalerweise haben wir im Entwicklungsstil nicht gelernt, wie man Anwendungen auf IBM BPM testet.

Es gab allgemeine Fragen, die uns nicht gefallen haben:

Wir sind zu Kotlin und Spring gewechselt, was in IBM BPM schwierig ist.
Sehr wenige Spezialisten oder diejenigen, die mit diesem Produkt arbeiten möchten.
Schwierigkeiten bei der gemeinsamen Entwicklung von Systemen \ Code, im Wesentlichen eine Monopol-Entwicklungsweise.
4 3 ( ~40 ), .

Unabhängig davon ist das Problem der lauten Nachbarn zu erwähnen. Aufgrund von Lizenzbeschränkungen mussten wir viele Produkte in einem Cluster zusammenfassen. Wir haben versucht, den gemeinsamen Code in verschiedenen Geschäftsprozessen wiederzuverwenden, was zu Schwierigkeiten bei der Änderung führte.

Zum Beispiel gab es einen SMS-Sendecode, der von zwei Produkten verwendet wurde - Barabrechnungsdienste und ausgelagerte Buchhaltung. Früher war der Text auf Komponentenebene fest codiert, jetzt wollte der Prozess des „Outsourcings der Buchhaltung“ den Text der SMS aus dem Prozess übertragen. Der CSC-Prozess wollte dies jedoch nicht, sondern muss überall geändert werden.

Oder banale Bugs könnten die gesamte Basis so gestalten, dass viele Produkte nicht funktionieren, obwohl sie nicht schuld sind.

Warum haben sie sich für Camunda entschieden, schrieb mein Kollege Nikolai in einem früheren Beitrag.

Was ist ein großer Prozess

Wir haben uns entschlossen, den großen Prozess von IBM zu übertragen (zunächst haben wir jedoch einen kleinen geschult):

Mehr als 100.000 Instanzen pro Monat.
Mehr als 70 Quadrate
Über 30 Integrationen mit anderen Systemen
Schnell wachsender Rückstand

Dies ist der Prozess der Eröffnung eines Girokontos in Tinkoff Business. Es war nicht möglich, einen solchen Prozess in einem Ansatz zu übertragen. Eine Pause von 3-4 Monaten in der Entwicklung wäre erforderlich, was für das Tempo der Geschäftsentwicklung nicht sehr geeignet ist.
Wir haben uns entschlossen, alles in Stücke zu zerlegen und umzugestalten. Und um das Problem der lauten Nachbarn zu lösen, haben wir einen separaten Antrag gestellt, der nur für Anträge auf Barausgleichsdienste zuständig war.

Auf der obersten Ebene sieht der Prozess folgendermaßen aus:
Bild

Übergangsregeln

Nr. 1: Aufgehört zu graben

Wir haben beschlossen, keine neuen Funktionen in der alten Anwendung mehr zu entwickeln. Als die Aufgabe im Backlog angezeigt wurde, haben wir versucht, die Box \ component \ service zu identifizieren, auf die sie sich bezieht, und diese Sache in Camunda von Grund auf neu geschrieben. Manchmal zu einem Preis war es 1,2x (x - wenn sie bei IBM waren), manchmal - 3x oder 5x.

# 2: Camunda weiß nichts über IBM

Nach dem Refactoring wollten wir nur die alte Anwendung deaktivieren, und beschlossen, neue Funktionen in Camunda zu erstellen, damit überhaupt nichts über IBM bekannt ist. Zwei Dinge haben uns geholfen:

In Siebel gespeicherte Geschäftsdaten
Vorgefertigte APIs von Camuda, mit denen Sie vollständig verstehen, wie und wie der Prozess endete.

Als Ergebnis haben wir bei IBM einen Prozess erstellt, der das Ergebnis von Camunda startet und erhält:
Bild

Nr. 3: Lange „manuelle Aufgaben“ und Klebevorgänge

Zuerst haben wir einfache, einstufige synchrone Anrufe nach Camunda verschoben, und alles hat gut funktioniert. Danach haben wir begonnen, diese Dinge in normale „Geschäftsprozesse“ zu integrieren, in denen Erwartungen von Benutzern auftauchten.
Benutzer können ihre Aufgaben jahrelang erledigen, daher hatten wir eine Reihe von Aufgaben, um Prozesse aus dem Papierkorb manuell zu reparieren. Wir haben auf diese Weise gewonnen - wir haben gerade damit begonnen, die Art einer bestimmten Aufgabe in Camunda zu berücksichtigen und nicht den Papierkorb für Aufgaben, bei denen ein langes Warten möglich ist.

Nr. 4: Umschalten der Funktion an der Gabel

Einige Codeteile waren so verwirrt, dass es einfacher war, von Grund auf neu zu schreiben und zu prüfen, ob es gut funktionierte. Zu diesem Zweck wurde die in IBM eingeführte Funktion zum Umschalten zwischen Gateways eingeführt. Wir haben einen kleinen Strom von Bewerbungen an Camuda geschickt und uns die Stifte angesehen, alles ist in Ordnung.
Bild

Migrieren von Instanzen von IBM nach Camunda

Letztendlich bestand der Prozess bei IBM nur aus Anrufen bei Camunda, und bei Camunda wurden drei Prozessebenen gesammelt. Die Geschäftsprozesse selbst haben sich nicht wesentlich geändert, sodass wir die alten Instanzen von IBM nach Camunda an dieselben Wartepunkte übertragen konnten. Und IBM herunterfahren.
Bild

Was tun, wenn Sie eine ähnliche Situation haben?

Wenn Sie mit dem BPMS-Erbe nach Camunda ziehen möchten, dann:

Verschieben Sie den Kontext in eine separate Datenbank.
Verschieben Sie Benutzeroberflächen in eine separate Anwendung.
Beenden Sie die Codierung neuer Funktionen in der alten Anwendung.
Verwenden Sie Einweganrufe, damit Camunda nichts über das alte System weiß.
Beginnen Sie mit kleinen Kästchen, aber vergessen Sie nicht lange benutzerdefinierte Aufgaben.

Dieser Ansatz hat uns geholfen, die Anzahl der Vorfälle um das 14-fache, die Regressionszeit um das 4-fache zu reduzieren, die tägliche Freigabe zu ermöglichen und die Kosten für manuelle Tests um das 4-fache zu senken. Jetzt arbeiten 5 Personen an dem Projekt und erledigen die gleiche Menge an Arbeit wie 9 Personen bei IBM. Ich hoffe, Ihre Ergebnisse werden nicht schlechter sein.

Einladung zu Mitap Nr. 4 von Camunda

27. Februar 2020 (Donnerstag) um 19:30 Uhr in Moskau, Golovinskoye Shosse 5A, Vodny Business Center, werden wir ein weiteres Treffen auf Camunda abhalten. Sie können sich unter dem Link registrieren und über die Lautsprecher lesen . Kommen Sie!

So migrieren Sie einen großen Prozess von IBM BPM nach Camunda und stoppen die Feature-Entwicklung nicht