In Prozessautomatisierungsprojekten ist es nichts Neues, dass man sich bei langlaufenden Prozessen um die Migration von Prozessinstanzen kümmern muss, wenn sich während der Lebensdauer einer Instanz das zugrunde liegende Prozessmodell ändert und in einer neuen Version zur Verfügung steht.
Seit kurzem gibt es die Version 2.1.2 des Camunda Spring Boot Starters. Mit der Community Extension lässt sich Camunda BPM mit wenig Aufwand in eine Spring-Boot-Applikation einbetten. Mehr Informationen zu Camunda Spring Boot gibt es auf der GitHub-Seite oder hier im Blog.
Neu in der aktuellen Version ist ein erweiterter Gradle-Support. Damit können jetzt Nutzer der Camunda-Enterprise-Edition ihre Spring-Boot-Applikationen jetzt auch einfach mit Gradle bauen und trotzdem in den Genuss der Enterprise Webapps kommen.
Wer hat das nicht schon mal erlebt? (Gern und besonders schlimm in großen Projekten): Der Fachbereich formuliert Wünsche und weil die IT diese ja niemals verstehen würde, gibt es diverse Proxies, die das Geschwafel des Fachbereichs übersetzen. Dieses ist natürlich viel zu unkonkret und oberflächlich. Es gibt Business Analysten, die Fachkonzepte schreiben, Modellierer und Architekten, die alles genau durchdenken und in Modelle (häufig UML) gießen, so dass die Entwickler nur noch programmieren müssen. Im Gutfall gibt es dann noch Tester, die die Ergebnisse der Entwickler verifizieren und an den Fachbereich zurückmelden. Im Schlechtfall geht die Kommunikation die ganze Kette vom Entwickler über Architekten und Business Analysten zurück zum Fachbereich. Denn natürlich versteht dieser das Entwickler-Kauderwelsch ebensowenig.
Klingt irgendwie unagil und falsch? Ist es auch. Warum es gerade bei BPM-Projekten so nicht laufen muss, erkläre ich im Folgenden.
Wer schon mal in Projekten mit räumlich verteiltem Setup gearbeitet hat, kennt das vermutlich: Remote-Meetings laufen immer gleich ab: Menschen treffen sich in unterschiedlichen Städten oder Länden in Videokonferenzräumen (bestenfalls) oder jeder sitzt an seinem Rechner mit Headset (schlimmstenfalls) und macht nebenbei etwas anderes. Die Beteiligung ist eher gering. Manchmal unterhalten sich die Teilnehmer eines Standorts untereinander und die anderen hören zu (bestenfalls). Auch beliebt: einzelne Standorte schalten ihre Mikrofone aus und unterhalten sich zeitgleich (schlimmstenfalls) oder zwei Teilnehmer in unterschiedlichen Standorten führen einen Dialog und der Rest dämmert langsam weg.
Die meisten Dinge fangen klein an. Es geht ja nur darum, einen Arbeitsauftrag von einem Mitarbeiter zum anderen zu senden. Das ist ja gar kein richtiger Prozess. OK, ein kleiner Prozess ist es schon, handelt es sich doch um in sich geschlossene Geschäftsfunktionen, von denen jede für sich wertschöpfend ist.
(Du hast keine Ahnung, wovon hier die Rede ist? Dann lies noch einmal unser letztes Antipattern!)
Also einverstanden, es ist ein Prozess und der gehört nicht eingebettet in die Fachlogik. Separation of concerns habe ich schließlich verstanden. Aber es ist ja nur ein Schritt und mehr wird da auch nicht kommen. Dafür ist eine Process Engine nun wirklich die sprichwörtliche Kanone, mit der auf Spatzen geschossen wird. Wir müssten erstmal eine Tool-Evaluierung durchführen. Aus der letzten Produktpräsentation des Anbieters mit den drei blauen Buchstaben erinnere mich an diese riesige BPM-Suite, sowas brauchen wir doch alles nicht.