BPMN vs Code

Configuratie of code?

Configuratie

Als configurator kom je in de eerste plaats in contact met de BPMN-workflow en configuratie-items zoals formulieren of communicatietemplates. De mogelijkheden van BPMN zijn erg ruim en de uitvoerbaarheid ervan is zo krachtig dat je het gedrag van het proces er vrijwel volledig mee kan aansturen. Dit is het low-code aspect van Skryv.

Code

Als developer zie je dan weer vooral de Spring boot applicatie en is het voor jou de Java-code die allesbepalend is. De workflow engine dient vanuit jouw perspectief vooral voor het formeel uitvoeren van het proces waarbij je de BPMN-workflow graag zo minimalistisch mogelijk houdt. Dit is de developer-friendliness van Skryv.

Het juiste evenwicht

Beide invalshoeken hebben hun sterktes, maar kunnen ook gemakkelijk leiden tot problemen op vlak van leesbaarheid, aanpasbaarheid en operationeel beheer. De kunst bestaat erin het juiste evenwicht te vinden tussen configuratie en code (tussen BPMN en Java). Hierbij staan echter geen regels in steen gebeiteld. Voor elke dienstverlening die je wil digitaliseren, is telkens een afweging nodig.

Leesbaarheid is doel van BPMN

Een goede vuistregel is dat de BPMN-workflow vooral gericht moet zijn op leesbaarheid voor business owners en analisten. Iemand die de dienstverlening niet kent, moet aan de hand van de workflow snel een duidelijk beeld krijgen van hoe alles in elkaar steekt. Bij wijzigingen in de dienstverlening kan een business owner het BPMN-diagram gebruiken om de aanpassingen voor te bereiden. Een goede BPMN-configuratie betekent ook snelle aanpasbaarheid. Een mooi voorbeeld hiervan vormen bedrijfsregels die vervat zitten in DMN’s (beslissingstabellen). Als er binnen de dienstverlening een subsidieregeling is, en er verandert iets in de voorwaarden of de premieberekening, dan kan je dit vlug aanpassen binnen de gepaste beslissingstabel.

Voorbeeld met lage transparantie

In onderstaand voorbeeld voeren we de risicoanalyse uit via een service taak die een stuk code oproept. De regels om het risicoprofiel te bepalen zijn niet zichtbaar.

Voorbeeld met hoge transparantie

Zelfde proces, maar we voeren de risicoanalyse nu uit via een business rule taak. De gekoppelde bedrijfsregels worden geëxpliciteerd via een beslissingstabel. Dit maakt het veel leesbaarder voor een business owner.

Doel van code: efficiënt omgaan met logica en data

Omgekeerd hebben zaken die geen waarde hebben voor de business ook geen plaats in de BPMN-workflow. Vermijd bijvoorbeeld verspreiding van functies, expressies en logica over meerdere elkaar opeenvolgende elementen ('technische coördinatie'), terwijl het voor de business eigenlijk over één enkele activiteit gaat. Dan kan je beter alles in één functie programmeren en dit oproepen vanuit een service taak. Code biedt bovendien het bijkomende voordeel dat het makkelijker te testen is.

Een soortgelijke redenering geldt voor data. Verspreid deze niet zomaar over procesvariabelen of in formulierdata. Als je dit kan vermijden, hou je data best zo veel mogelijk in lokale functies. Enkel data relevant voor het proces (bijvoorbeeld om een gateway aan te sturen) of voor het dossier mag doorstromen naar procesvariabelen of formulieren. Meer info en voorbeelden vind je in de sectie omgaan met data in processen.

Voorbeeld uitvoering logica via expressies

Hoewel ze een duidelijke uitvoerende (technische) waarde hebben, zijn de eerste vier stappen in onderstaand proces overbodige informatie voor de business. Ze bemoelijken dan ook de leesbaarheid van het BPMN-diagram.

Voorbeeld uitvoering logica via code

Voor de business is het enkel belangrijk om te weten dat we als eerste stap automatisch een factuur opmaken en versturen. Vandaar dat we in de service taak een stuk code aanroepen die alle details achter de schermen regelt. Het resultaat is een verbeterde leesbaarheid van het BPMN-diagram en een makkelijk testbare factuurservice.