De vertaling van bedrijfsnoden in bedrijfsprocesen en vervolgens in een vorm van ict-ondersteuning, blijft een moeilijke zaak. Bij JBoss biedt het jBPM van Tom Baeyens een uitkomst met een slag om de arm.

Een kleine 20 jaar geleden vierde een nieuwe hype hoogtij in de bedrijfswereld, en bij uitbreiding ook in de ict-wereld. Business Process Re-engineering, ofte BPR, werd door Michael Hammer en co. aan de wereld kond gedaan in artikels, boeken en adviezen van consultants. BPR zou de werking van bedrijven efficiënter te maken door taken die geen waarde toevoegen te elimineren of te automatiseren. Daardoor droeg het overduidelijk bij tot het groeiend succes van erp-pakketten, die precies zo’n automatisering en efficiëntieverhoging beloofden. Bedrijfsprocessen bleven helaas een moeilijke noot om te kraken en een aantal van de erp-beloften werden dus nog steeds niet ingevuld. Zeker is wel dat ‘bedrijfsprocessen’ sindsdien nooit meer aan belangstelling hebben ingeboet.

De moeilijke vertaalslag

Bedrijfsprocessen in kaart brengen is één zaak, die processen – inclusief wijzigingen -vertalen naar ict-oplossingen is van een heel andere orde. Zo spreken bedrijfsanalisten en informatici niet alleen verschillende talen, de notitiesystemen waarin ze hun bevindingen neerpennen verschillen vaak ook grondig van elkaar. Bovendien zijn de tools om die twee werelden makkelijker te laten dialogeren niet dik gezaaid.

“Vroeger werd er gewoonlijk een grafisch plaatje van het proces getekend, om die diagrammen vervolgens uit te voeren,” stelt Tom Baeyens, ‘lead’ van jBPM bij JBoss. Daar gingen ontwikkelaars dan mee aan de slag, maar daarbij werden vaak al te beperkende beslissingen genomen. Gewoonlijk werden workflow engines gebouwd die wel succesvol waren in hun niche, zoals het creëren en beheren van de document-werkstromen.

Voor Tom Baeyens leek het logischer een gemeenschappelijk onderliggend mechanisme te hebben, waarop de diagrammen met de verschillende activiteiten, naargelang het domein, konden worden geënt. “We onderzochten wat die werkstroom-engines gemeenschappelijk hadden.” Het resultaat daarvan werd jBPM.

Voor het beschrijven van de activiteiten creëerde hij evenwel eerst jPDL, een process definition language, die ‘task management’ gericht is en sterk geïntegreerd met Java. Zo kan je Java-klassen in de activiteiten configureren, of een beroep doen op Java-objecten voor informatieuitwisseling in plaats van bijvoorbeeld XML. “jPDL lijkt een deel van de Java-taal zelf te zijn,” klinkt het.

Maar het is niet de enige taal die in jBPM kan worden aangewend, benadrukt Baeyens. Verschillende talen kunnen verschillende doelen hebben, zoals meer technologisch of businessgericht zijn. Maar jPDL heeft wel een plaats in beide werelden, waarbij de beide werelden ontkoppeld worden.

jBPM en PVM

De essentie van het jBPM is dan ook de mogelijkheid om op basis van een onderliggend mechanisme de meest aangewezen taal ‘native’ te draaien. Dat mechanisme is de ‘process virtual machine’ (PVM), in principe vergelijkbaar met de Java Virtual machine (JVM). Het is met de PVM dat de beperkingen van de klassieke monolitische en ‘single language’ workflow engines worden aangepakt. Tom Baeyens omschrijft het als een ‘conceptueel model dat in het repertorium van elke ontwikkelaar zou moeten zitten’. Op dat mechanisme worden dan de verschillende blokjes van activiteiten geplugd, zodat deze beschrijvingen uitdrukkelijk gescheiden zijn van het onderliggende werkstroom/bpm/orchestratie systeem. “We zijn open naar boven,” herhaalt Tom Beayens nog es, onder meer omdat “er geen enkele procestaal is die op haar eentje alle omgevingen en nodige capaciteiten inzake BPM aankan.”

Naast het process engine omvat jBPM ook een process monitor, een procestaal en interactieservices (om bestaande toepassingen als functies of data aan te wenden bij het uitvoeren van processen).

Vandaag is jBPM toe aan versie 4.1, met jPDL als eerste taal. Als volgende stap komt ook een ‘native’ uitvoering van BPMN 2.0 – Business Process Modeling Notation, terwijl vroeger ook aan BPEL werd gewerkt. De PVM heeft in ieder geval bewezen dat ze die talen, inclusief XPDL (XML Process Definition Language) aankan. Nog een taal is ‘pageflow’, voor het beschrijven van de navigatie tussen pagina’s door gebruikers. Hierbij wordt ook een beroep gedaan op JBoss SEAM – een applicatie framework dat EJB 3 en JavaServer Faces combineert, eertijds begonnen door Gavin Boss (die ook aan de bais van Hibernate lag).

In jBPM tref je nog andere elementen aan, zoals een identity component. “Producten waarmee je meteen aan de slag kan gaan, hebben nu eenmaal het meeste succes,” merkt Baeyens op, en dus biedt de identity component een beheerfaciliteit van gebruikers, groepen en dies meer. Maar bedrijven kunnen natuurlijk zonder meer een beroep doen op hun huidige identity componenten. Sinds versie 3 was er ook al een Eclipse-gesteunde designer tool in jBPM voorzien, maar vanaf versie 4.1 is er nu een webgesteunde designer opgenomen. Dat is het resultaat van een samenwerking met het Duitse Signavio, dat zijn Oryx webgesteund modelleringstool integreerde met jBPM.

Toekomst

De fundamentele openheid van jBPM laat nog heel wat ruimte voor toekomstige ontwikkelingen, “zoals tooling om alles nog nauwer met elkaar te koppelen. Er zijn vandaag heel wat ISO-documenten die werden aangemaakt maar nu een beschimmeld bestaan lijden, omdat ze niet worden gebruikt.” Een verwijzing naar onder meer de ISO900x certificaten die werden toegekend in de voorbije jaren, en goed gedocumenteerde processen moesten beschrijven, die evenwel niet altijd overeenstemmen met de werkelijkheid (ook al omdat er vaak geen mogelijkheid is om de realiteit te toetsen aan die documenten of die realiteit met stevige hand vanuit die documenten aan te sturen).

In de toekomst ware het mooi als bedrijfsmensen de modellen van de processen kunnen bouwen, waarna die modellen uitvoerbaar worden gemaakt, zonder dat de software artefacten zelf worden blootgegeven. De ontwikkelaar bouwt die artefacten, waarna de businessanalist op basis van die artefacten ziet dat alles ook echt gebeurt zoals gepland. “In tegenstelling tot het ISO-gebeuren waar het proces gedocumenteerd is, maar de implementatie ervan gebeurt door een ontwikkelaar en alles dus afhangt van diens implementatie, wordt de uitvoering gestuurd.” Zo is er verzekerde mapping van de werkelijkheid op het oorspronkelijke model. Je zou dit haast een “what you want is what you get” (WYWIWYG) toestand voor de bedrijfsanalisten kunnen noemen, althans als alles naar behoren werkt. Die analisten kunnen in ieder geval de reële gang van zaken monitoren en daarover duidelijk rappporteren aan de andere betrokkenen binnen het bedrijf, wat dan weer perfect past in ontwikkelingen als ITIL (Information Technology Infrastructure Library, bestemd voor een gestructureerd en gegarandeerd aanbod van diensten). Of om aan te tonen dat een ‘secure’ werkwijze ook echt wordt nageleefd. Of zoals Baeyens het stelt: “Er wordt gerapporteerd op basis van wat er echt gebeurt en je krijgt meer dan alleen maar de kaft van een dossierklapper te zien.” Niet alleen kan dat alles worden aangewend voor het optimaliseren van de processen, maar op basis van jBPM kan ook aan ‘business intelligence’ en ‘business activity monitoring’ worden gedaan.

Een product als jBPM is overigens niet beperkt tot een Java-omgeving, benadrukt Baeyens nog, want “een zelfde aanpak kan ook op .Net.” Het huidige product is wel in Java-code geschreven, maar een vertaalslag met behulp van Mono – een opensource-implementatie van .Net – zou mogelijk zijn. Je kan het ook altijd herschrijven in C#, klinkt het nog.

Guy Kindermans

De essentie van het jBPM is dan ook de mogelijkheid om op basis van een onderliggend mechanisme de meest aangewezen taal ‘native’ te draaien