#JCON2017 #BusinessProcessManagement #WorkflowManagement
Workflow Management oder auch Business Process Management (BPM) kann handfeste Probleme lösen, z.B. Reihenfolge, Zustand, Timeout- und Fehlerbehandlung oder Sagas, und dadurch erheblich zum Projekterfolg beitragen. Trotzdem hat es unter Entwicklern oft einen schlechten Ruf, was nach Ansicht des Autors auf 7 Sünden beruht, die es zu vermeiden gilt.
Sünde 1: Zero-Code Suites
BPM wurde lange Zeit von großen Herstellern dominiert, die entsprechend große Software-Suiten unters Volk bringen wollten. Diese Hersteller verfolgten überwiegend eine Zero-Code-Idee, also dass man Geschäftsprozesse ohne Softwareentwicklung umsetzen kann, am besten indem man bestehende Services,
i.d.R. aus der passenden SOA-Suite (Serviceorientierte Architektur) des Herstellers, per Drag-and-Drop neu zusammensetzt. Die Idee verkauft sich immer noch gut, da Entscheidern suggeriert wird, die Abhängigkeit von der IT würde sich reduzieren.
In der Praxis funktioniert Zero-Code aus Erfahrung des Autors nicht bzw. nur für triviale Prozesse, wie den viel zitierten Urlaubsantrag. Denn echte Kernprozesse, wie beispielsweise die Bestellabwicklung bei Zalando, Antragsprozesse bei der Allianz oder Aktivierungen bei T-Mobile, sind nun mal komplex. Diese Komplexität muss abgebildet werden. Das schaffen Fachbereiche meist aber nicht selbst, was dazu führt, dass die Lösungen, welche die IT eigentlich überflüssig machen sollten, genau an diese weitergereicht werden. Softwareentwickler sind nun aber von proprietären und schwergewichtigen Lösungen vor den Kopf gestoßen, da sich diese kaum in ihr normales Entwicklungsvorgehen einbetten lassen. Die Klassiker sind:
- Copy-and-Paste aus Musterlösungen ist nicht möglich, stattdessen müssen Tutorial-Videos geklickt und Einstellungen in Mammut-Dialogen gesucht werden („death by properties panel“).
- Die Modelle können nicht sauber und schon gar nicht zusammen mit anderen Artefakten versioniert werden.
- Das Deployment erfolgt proprietär über die IDE oder Web-Oberflächen des Herstellers und ist schwierig automatisierbar.
- In Java einfach abbildbare Prozesse müssen mit „Zero-Code“ sehr aufwendig „hinten herum“ gelöst werden – oder stellen eine unüberwindbare Hürde dar.
- Das automatisierte Testen von Prozessen ist nicht oder nur mit proprietären Mitteln möglich und kann nicht in den Continuos-Integration-Prozess eingehängt werden.
Die meisten Entwickler, die einmal eine Zero-Code-Suite vor der Nase hatte, werden daher mit Fug und Recht behaupten: „BPM funktioniert nicht“.
Sünde 2: Keine Engine
Das wirklich fatale daran ist, dass schlechte Erfahrungen meist dazu führen, dass Entwickler lieber auf den Einsatz einer Engine verzichten. Zusätzlich werden die Anforderungen auch häufig unterschätzt. Typische Aussagen sind: „Ich brauche nur ein kleines Zustands-Flag in der Datenbank“ oder „ich kann auch mit reinen Event-Notifikations-Ketten arbeiten“. In allen Projekten, die der Autor begleitet hat, war dies leider ein Irrtum. Sobald ein Zustand gehalten wird, erwachsen sofort Anforderung an die Sichtbarkeit und Überwachung des Zustandes oder an Maßnahmen bei Zeitüberschreitungen.
Am aktuellsten sind Beispiele rund um Microservice-Architekturen, wo Gesamtsysteme in viele kleine miteinander kommunizierende Einheiten zerlegt werden. Ende-zu-Ende Geschäftsfunktionen oder Prozesse involvieren nun verschiedene Services, was neue Anforderungen an Orchestrierung, Fehlerbehandlung oder
Kompensation stellt. Dies wird häufig übersehen oder ignoriert, so dass Projekte jede Menge Infastruktur-Code entwickeln, statt sich auf die Businesslogik zu konzentrieren. Schlimmer noch:
Sünde 3: Selbstgebaute Engines
Aus der beschriebenen Not heraus haben viele Kunden enormen Aufwand betrieben, um eine eigene Engine zu bauen, oft mit vielen Features und sogar grafischen Workflow-Beschreibungen. Die meisten Betroffenen wollen diese Engines loswerden, da die Wartung oft ein Alptraum ist und das Ergebnis trotz aller Aufwände erfahrungsgemäß immer dem Markt hinterherhinken wird. Ganz zu schweigen davon, dass oft die klügsten Köpfe des Unternehmens gebunden werden.
Gegenmittel: Entwicklerfreundliche Engines
Ein alternativer Ansatz der helfen kann diese Sünden zu vermeiden ist: Entwicklerfreundliches Business-Process-Management. Bei der Gelegenheit darf man auch gerne von Workflows oder gleich von Flows sprechen, denn das Akronym BPM hat seine besten Zeiten hinter sich. (Listing 1) zeigt wie in wenigen Zeilen Code, beispielsweise die Open-Source-Engine von Camunda
- konfiguriert und
- gestartet wird,
- eine Flow-Definition mit Java-DSL erzeugt und
- deployed wird sowie
- eine Flow-Instanz auf den Weg geschickt wird, die auch
Daten enthalten kann.
Listing 1
public class AllInOne {
public static void main(String[] args) {
StandaloneInMemProcessEngineConfiguration conf = new StandaloneInMemProcessEngineConfiguration();
ProcessEngine engine = conf.buildProcessEngine();
engine.getRepositoryService().createDeployment() //
.addModelInstance(„flow.bpmn“, Bpmn.createProcess(„flow“).executable() //
.startEvent()
.serviceTask().name(„Step1“).camundaClass(SysoutDelegate.class)
.serviceTask().name(„Step2“).camundaClass(SysoutDelegate.class)
.endEvent().camundaExecutionListenerClass(„end“, Sysout-Delegate.class)
.done()
).deploy();
engine.getRuntimeService().startProcessInstanceByKey(„flow“,Variables.putValue(„someData“, „someValue“));
}
public static class SysoutDelegate implements JavaDelegate {
public void execute(DelegateExecution execution) throws Exception {
System.out.println(„hello from activity „ + execution.getCurrentActivityId());
}
}
}
Die Engine selbst ist also eine Library. Sie kann embedded im eigenen Java-Projekt betrieben und z.B. über Spring oder Spring-Boot gestartet werden2. Sie bietet alle Funktionen auch als REST-API an und hat eine Web-Oberfläche sowie einen grafischen Modeler, falls man dies der Java-DSL (Domain-Specific-
Language) vorzieht, was spätestens bei komplexeren Flows meist der Fall ist. Als Notation wird der ISO-Standard BPMN 2.0 verwendet. Das grafische Layout wird auch bei der Java-DSL spätestens im Monitoring angezeigt (Abb. 1). Neben Camunda gibt es mit Activiti oder JBoss jBPM weitere Engines, die einen ähnlichen Ansatz verfolgen. Die Open-Source-Projekte werden auch kommerziell supported, wodurch der Einsatz auch in geschäftskritischen Bereichen möglich ist.
Dieser entwicklungsfreundliche Ansatz, ein funktionierendes BPM, dass den Bedürfnissen des Entwicklers gerecht wird, ist aus Sicht des Autors die einzig sinnvolle Art von Business-Process- Management. Damit gehören auch Sünde 1 bis 3 der Vergangenheit an.
Sünde 4: BPM Monolith
Monolithen sind heiß in der Diskussion. In Bezug auf BPM können unterschiedliche Gesichtspunkte gemeint sein: Große BPM-Suiten sind Monolithen in sich. Hersteller versuchen den Vendor-Lock-In zu maximieren, so dass nur dann produktiv gearbeitet werden kann, wenn die gesamte Logik in der Suite abgebildet wird. Einzelne Komponenten können nicht extrahiert werden, so dass auch der interne Service-Bus, die Taskliste oder die IDE genutzt werden müssen. Des Weiteren haben BPM-Projekte eine Tendenz dazu, (zu) groß zu sein und wasserfallartig durchgeführt zu werden, da man Prozesse ganzheitlich betrachten will – und wer kann schon ohne eine vollständige Prozesslandkarte anfangen die Steuerung eines Prozesses zu automatisieren?
Aber das größte Problem ist, dass BPM-Suites oft als zentrale BPM-Systeme etabliert werden, die dann die Spinne im Netz sind oder zumindest sein wollen. Dies geht dann Hand in Hand mit einem Enterprise-Service-Bus (ESB). Das führt dazu, dass für das Deployment einer Funktionalität oft Artefakte auf die BPM-Suite, den ESB und den Java-Application-Server ausgebracht werden müssen, was in der Praxis zu viele Stolperfallen beinhaltet.
Mit dem Erfolg des Microservice-Ansatzes lernen wir, dass es für verschiedene Teile des Systems – den Microservices – unterschiedliche Zuständigkeiten gibt und man die Systemgrenzen, den so genannten Bounded-Context, ernst nehmen muss. Ein Team betreut nun einen Microservice und kann dieses ohne Abhängigkeiten von anderen Teams weiterentwickeln oder neu deployen.
Für Geschäftsprozesse ist dies aus zwei Gründen hoch spannend:
- Typische Ende-zu-Ende Geschäftsprozesse überschreiten die Grenze mehrerer Microservices. In diesem Fall muss der Geschäftsprozess in mehrere Teile zerschnitten werden, die dem Bounded-Context entsprechen. Jeder Microservice ist für seinen Teil des Prozesses verantwortlich und das Team frei in der Entscheidung wie es diesen implementieren möchte. Dementsprechend kann jeder Microservice bei Bedarf seine eigene Engine mitbringen.
- Durch die Zerlegung eines Systems in Microservices steigt der Bedarf, die Kommunikation dieser Services erfolgreich umzusetzen. Oft müssen verschiedene andere Services in einer Reihenfolge aufgerufen, bei asynchroner Kommunikation auf eine Antwort gewartet, Fehler sauber behandelt und Business-Transactions mit Kompensation abgebildet werden. Dabei können Workflow-Engines helfen.
Sünde 5: Granularitäts-Schnitzer
Kaum gibt es grafische Prozessmodelle, versucht man in Projekten auf Teufel komm raus zu modellieren. Heraus kommen oft viel zu detaillierte Modelle die keinen Nutzen haben, weil man den Wald vor lauter Bäumen nicht mehr sieht. Zero-Code- Suites katalysieren diese Tendenz, da vieles irgendwie in Modelle gepresst werden muss. Der Autor empfiehlt deshalb, entwicklerfreundliche Engines zu verwenden Teile der Logik einfach in Java zu codieren. Dadurch lässt sich bei Prozessmodellen eine Granularität wählen, die fachlich motiviert ist. Wer das richtig macht, schafft ein Modell, das alle wichtigen Stakeholder (Fachbereiche,
Dev-und-Ops) lesen und verstehen können.
Sünde 6: Habitat-Verletzungen
Fachbereiche und IT geraten regelmäßig aneinander. Bei BPM-Projekten erlebt man entweder eine IT-follows-Business-Haltung, bei der Fachbereiche sich einschließen, analysieren, modellieren und Prozesstapeten produzieren, nach dem Motto: „Das muss man nur noch so bauen“. Worauf eine typische IT erwidert, dass das aber so nicht geht. Oder schlimmer nach dem Motto: „Probieren wir“. Manchmal erlebt man auch umgekehrt, dass die IT den Ton angibt und selbständig Software entwickelt, über die keiner mehr einen fachlichen Überblick hat. Beides ist unproduktiv, da sehr viel Potential verschenkt wird. Dabei wird alles sehr viel einfacher, wenn beide Parteien sich und ihre Eigenarten respektieren und gemeinsam ein sinnvolles Modell erstellen, das sowohl Kommunikationsgrundlage ist, aber dann auch direkt für die Ausführung verwendet wird. Die IT kann ihre Bedenken bereits bei der Definition eines Geschäftsprozesses einbringen und sinnvolle Optimierungen vorschlagen, welche dann aber auch fachlich bewertet werden. Das Modell ist folglich
auch die Grundlage für die iterative Weiterentwicklung der Software.
Sünde 7: Over Engineering
Dieses generelle Problem ist auch im BPM sehr präsent. Häufig wird bereits vor der Umsetzung des ersten Workflows eine hauseigene BPM-Plattform definiert, eine Prozesslandkarte aufgesetzt oder „eben mal“ alle Prozesse und Services aufgenommen. Wie immer sollte dagegen gelten: Agil, lean, Schritt für Schritt. Man sollte immer mit einem konkreten Prozess beginnen, diesen von Anfang bis Ende umsetzen und keine Abstraktionen einführen, bevor man nicht ein paar Prozesse gebaut hat.
(Abb. 2) zeigt beispielhaft, wie einfach bei langlaufenden Flows Timeouts, Fehlerbehandlung und Kompensation abgebildet werden können. Bei der Kompensation werden automatisch für alle bereits erfolgreich ausgeführten Aktivitäten kompensierende Aktivitäten ausgeführt.
[well]
Autor – Bernd Rücker
Bernd Rücker entwickelt seit über 15 Jahren Software und hat zahlreichen Kunden dabei geholfen, langlaufende Flows umzusetzen, so z.B. der Bestellprozesse bei Zalando, Auftragsprozesse bei T-Mobile oder Patenanträge in der Schweiz. Außerdem hat Bernd das „Praxishandbuch BPMN“ geschrieben, aktiv an der Entwicklung verschiedener Open Source Workflow Engines mitgearbeitet und die Camunda mitgegründet.
Er spricht regelmäßig auf Konferenzen. Seit geraumer Zeit beschäftigt sich Bernd mit Flows in neuen Paradigmen rund um Microservices, Domain Driven Design, Event Driven Architecture und Reactive Systems.
camunda – github #1 – github #2 – Blog – twitter – xing – LinkedIn – mail [/well]
