Hoe passen BPMN modellen in je CI/CD pipeline?
Kunnen citizen developers en business users zelf processen updaten in productie?
Moeten aanpassingen aan processen wachten op de volgende software-release of niet?
We bekijken je opties in deze blogpost.

BPMN modellen in software
Overwegingen
    BPMN - Business of Development artifact?
    Analytische vs uitvoerbare modellen
    Testen van business processen
    Coherentie tussen code en modellen
Mogelijke benaderingen
    Optie 1: Modellen als Configuratie
    Optie 2: Modellen als Data
    Optie 3: Modellen als Code
Conclusies

BPMN modellen in software ontwikkeling

Als je software bouwt waarin een BPM Engine een rol speelt, word je al snel met de vraag geconfronteerd hoe dit alles in je typische CI/CD pipeline past.  Technisch gezien allemaal niet zo spannend, maar de verwachtingen die er tegenover een proces-gebaseerde aanpak leven maken een en ander allicht een stukje complexer.

De belofte die vele BPM engines maken of die minstens leven rond dit soort systemen klinken vaak veelbelovend:

• Wijzigingen aan processen kunnen door niet-IT'ers (business, analisten) gebeuren
• Wijzigingen aan processen staan los van de software en hoeven niet dezelfde build-test-deploy cycle door te maken
• Wijzigingen aan processen kunnen onmiddellijk at runtime gebeuren en hoeven niet de volgende software release af te wachten

In deze blogpost bekijken we de verschillende mogelijke manieren om dit in te richten en te verwerken in je projectaanpak.

Overwegingen

Alvorens de verschillende mogelijke ideeën te overlopen, laten we even stilstaan bij enkele belangrijke bedenkingen.

BPMN - Business of Development artifact?

Het aanpassen van modellen door business users wordt vaak in één adem genoemd met het snel uitrollen van deze nieuwe modellen.  Dit zijn echter twee duidelijk verschillende zaken.

Er zijn veel goede redenen om met een BPM Engine aan de slag te gaan in je software ontwikkeling, directe betrokkenheid van business is daar zeker één van.  Door business experten op te nemen in je software team zorg je dat de nodige kennis en inzichten ineens renderen naar de opgeleverde modellen en software toe, zonder een extra vertaalslag via een analyse of specificatie.

Het feit of deze modellen ook effectief direct worden uitgevoerd, dan wel nog verder verwerkt worden door development is een losstaande beslissing, de tweede optie is vaak de enige realistische.

Analytische vs uitvoerbare modellen

BPMN modellen die in een BPM engine geladen worden zijn niet zomaar de getekende BPMN modellen, deze moeten eerst ook uitvoerbaar gemaakt worden door technische parameters in te vullen en te koppelen aan de applicatie- of integratie-code die erbij hoort.
Elke activiteit in het proces moet gekoppeld worden aan een stukje programmatuur, en elke beslissing moet zeer concreet op basis van beschikbare data automatisch genomen kunnen worden.

Het gebruik van BPMN vind je in de literatuur (bv; https://methodandstyle.com/three-levels-of-process-modeling-with-bpmn/) vaak beschreven op 3 niveau's:

• Niveau 1: Beschrijvende  modellen - het spreekwoordelijke "bierkaartje" waarop BPMN modellen een handige gemeenschappelijke taal zijn voor iedereen om gewenste werking te bespreken
• Niveau 2: Analytische modellen, die een goede basis zijn als formele specificatie voor uitwerking in software, maar ook voor analyse en optimalisatie van de processen zelf
• Niveau 3: Uitvoerbare modellen, die voorzien zijn van de nodige technische parametrisatie om ze in een BPM Engine te kunnen uitvoeren

De technische parametrisatie is sowieso engine-specifiek en kan in praktijk vaak enkel door een IT-technicus uitgevoerd en getest worden.  Typisch is er na elke modelerings-ronde door de analist of modeler dus ook een extra ingreep van een ontwikkelaar nodig.

Voor veelgebruikte componenten (integraties met bestaande systemen om informatie op te zoeken, manuele taken klaarzetten voor gebruikers, template-mails versturen, enz...) is het allicht realistisch om end-user-proof componenten te voorzien die in een proces gebruikt kunnen worden door niet-IT gebruikers.  Voor veel andere (eenmalige) functionaliteiten gaat dit echter niet op en zal een ontwikkelstap nodig zijn.

Testen van business processen

Voor een kwalitatieve software-ontwikkeling voorzie je geautomatiseerde testen die de correcte werking van het systeem aftoetsen, zowel bij het bouwen als bij latere aanpassingen.
Als een deel van de werking je software bepaald wordt door business processen (wie doet wat, wanneer, in welke volgorde, welke beslissingen worden genomen, enz...) dient zich al snel de vraag aan of en hoe je deze aspecten mee wil gaan testen.

Een éénmalige manuele test van een gewijzigd proces genereert op termijn mogelijk een groot probleem naar efficiëntie én kwaliteit toe, aangezien deze test-effort niet herhaalbaar is, en telkens opnieuw zal moeten gebeuren bij elke wijziging om regressie te voorkomen.
Business processen zijn meestal ook niet vlot in een unit test te vangen, je zal meestal gebruik moeten maken van end-to-end integratie-testen om hun correcte werking te valideren - iets wat typisch een stukje complexer is dan een eenvoudige unittest.

Coherentie tussen broncode en BPMN modellen

BPMN modellen en de code waarmee ze interageren moeten naadloos op elkaar aansluiten.  Als je in je proces specifieke procesvariabelen nodig hebt om tot een beslissing te komen, moeten die ook effectief een waarde krijgen, en Service Tasks die een activiteit binnen een proces uitmaken moeten een concrete invulling krijgen.

Daarnaast maakt ontwikkeling in een aantal parallelle tracks (feature branches, meerdere versies of releases naast elkaar, ...) een en ander een stukje minder evident: plots word je dan geconfronteerd met twee versies van een model die nadien terug tot één finale versie moeten samenkomen.  Bij ontwikkelaars is de techniek van versioneren, branchen en mergen goed ingeburgerd, voor procesmodellen ligt dit vaak moeilijker - zowel in werkmethode bij analisten als bij de ondersteuning die BPM tools hiervoor (vaak helemaal niet) voorzien.

De modellen in een versioneringssysteem beheren samen met de codebase - inclusief branching en merging - is vaak de meest pragmatische en kwalitatieve oplossing, maar beschouwt de procesmodellen dan de facto als een artefact van een (weliswaar multi-disciplinair) ontwikkelteam.

Mogelijke benaderingen

In de praktijk zien we drie belangrijke scenario's verschijnen, bepaald door de rol die je de BPMN procesmodellen toedicht:

• Beschouw je deze modellen als configuratie die in productie aanpast om de werking van het systeem bij te laten sturen door business (parametrisatie)?
• Beschouw je deze modellen als data die los staat van de applicatie maar die je - net zoals bijvoorbeeld content voor een website  - op een staging omgeving voorbereidt en controleert, om deze dan te publiceren naar de live omgeving? 
• Beschouw je deze modellen als code, die je door de hele CI/CD pipeline meeneemt en via een release door de ontwikkelstraat tot aan productie brengt?
  
  

We bekijken de aanpak én consequenties van elk van deze drie mogelijkheden in detail.

Optie 1: BPMN modellen als Configuratie

In de ideale wereld levert je software team de nodige bouwstenen op, waarmee business users (citizen developers) aan de slag kunnen om processen samen te stellen, en deze in één beweging in productie te nemen.
Veel vendoren positioneren hun tools dan ook op deze manier, met de belofte om niet-IT profielen rechtstreeks aanpassingen aan de werking van productie-systemen te kunnen laten uitvoeren.

Hierbij wordt een versie van de software opgeleverd in productie, met daarin de processen zoals op dat moment bekend en gewenst, nadien worden die als configuratie bijgestuurd waar nodig, zonder aparte software release.
Al bij al is dit scenario meestal weinig realistisch, tenzij in de meest triviale cases of voor een zeer beperkte set aan wijzigingen (bijvoorbeeld wijziging van toewijzing van taken, grenswaardes voor beslissingen, e.d.)

Optie 2: BPMN modellen als Data

Door BPMN Modellen als data te beschouwen, ga je in feite op dezelfde manier te werk als bij web content: je gaat er van uit dat het systeem werkt zoals het hoort, maar specifieke data (in dit geval de procesmodellen) introduceer én verifieer je op een aparte staging-omgeving die vormelijk gelijk is aan je productie-omgeving.  Als daar alles naar behoren werkt, propageer je naar je productie-omgeving, maar in principe staan al deze wijzigingen los van de releases van je software.
Aangezien de procesmodellen een belangrijk aspect vormen van het productie-systeem, wordt best een feedback voorzien waarbij elke software-release bijbeent met de laatste procesdefinities uit productie.  Zo vermijd je om niet-representatief te werk te gaan van development tot acceptatie en alsnog met onvoorziene problemen in productie geconfronteerd te worden.

Optie 3: BPMN modellen als Code

Bij deze aanpak behandel je de BPMN modellen net als broncode.  Je modeleert de processen in een BPMN tool, en de resulterende BPMN files check je samen met je broncode mee in in je SCM (git, ...).
Vanaf dat punt gaan de modellen over de hele CI/CD pipeline mee door de ontwikkelstraat, van development omgeving (DEV) tot en met productie (PRD).  Modelers (business users, analist) gaan in nauwe samenwerking met ontwikkelaars iuitvoerbare modellen opleveren als deliverable vanuit een multi-disciplinair ontwikkelteam.  Wijzigingen aan procesmodellen verwerk je op dezelfde manier binnen je team als elke andere activiteit - bv als een backlog ticket of sprint item in een agile werking.

Conclusies

Bij XTi hebben we de beste ervaringen met de aanpak waarbij BPMN modellen samen met de code geversioneerd, getest en gedistribueerd worden.
Als je deze aanpak combineert met een vlotte Continuous Delivery pipeline dan slaag je er in om een positieve balans te vinden tussen de belangrijkste aandachtspunten: BPMN modellen die in nauwe samenwerking tussen business en IT tot stand komen, procesmodellen die samen met de broncode een gedegen testing doorlopen door de volledige ontwikkelstraat, én aanpassingen die gecontroleerd maar op zeer beperkte doorlooptijd naar productie geraken.

Hou je daarbij zeker aan volgende best practices:

1. Integreer business experten en modelers in je projectteam, en laat hen zelf wijzigingen aan procesmodellen aanbrengen, maar versioneer ze samen met je code
2. Zorg voor een goede set automatische end-to-end testen die de correcte werking van én de programmatuur én de business process modellen aftoetst
3. Voorzie een volledig geautomatiseerde CI/CD straat, zodat wijzigingen in een zeer korte doorlooptijd van development tot in productie uitgerold kunnen worden.  Continuous deployment is hier zeker te verkiezen boven klassiek release management