Als het gaat om standaarden in de wereld van Business Process Management (BPM) wordt het er allemaal niet eenvoudiger op. Zo is in januari van dit jaar BPMN 2.0 uitgekomen en tussen versie 1 en 2 zit een groot verschil. Daarnaast zijn er andere standaards zoals XPDL en BPEL. In dit stuk duik ik in de wereld van bpm-standaarden en de verschillende visie’s van tool leveranciers in relatie tot business-it alignment.
In Business Process Modeling Notation (BPMN) versie 1 was een standaard gedefinieerd om bedrijfsprocessen te kunnen tekenen. Het doel van BPMN is om een schrijfwijze (in de vorm van stroomdiagrammen) te bieden welke leesbaar is voor iedereen die met bedrijfsprocessen te maken heeft, met name de businessanalist die initiele bedrijfsprocessen modelleert, maar ook business en it-medewerkers die de processen technisch uitwerken en monitoren.
Het hebben van mooie plaatjes is heel fijn, maar om de plaatjes op een gestandaardiseerde wijze tussen verschillende modelleeromgevingen (BPM suites?) te kunnen uitwisselen is een taal nodig die de computer kan begrijpen. De Workflow Management Coalition (WfMC) kent hiervoor de standaard taal XPDL. Veel tools in de bpm-markt ondersteunen BPMN voor de grafische weergave van diagrammen en XPDL voor de opslag hiervan in xml formaat.
Intussen was de BPMN standaard overgedragen aan het machtige OMG, Object Management Group, bekend van it-standaards zoals UML. Bij OMG werd vanaf 2009 BPMN 2.0 ontwikkeld. Het eerder genoemde doel van BPMN staat nog fier overeind, maar de standaard is uitgebreid met een formeel model voor uitwisseling van tekenmodellen. BPMN is nu een acroniem geworden voor Business Process Model and Notation. Het hebben van een model (denk aan xml-schema’s) zorgt ervoor dat XPDL feitelijk een concurrent erbij heeft gekregen. Je zou zelfs kunnen zeggen dat XPDL overbodig is geworden, ware het niet dat XPDL al een grote installed base kent en gewoon doorontwikkeld wordt.
Het bieden van diagrammen die voor een ieder begrijpbaar is, is in BPMN 2.0 slechts één van de twee doelen. Het andere doel is om XML-talen welke bedoeld zijn voor de executie van bedrijfsprocessen, zoals BPEL, te kunnen visualiseren met een ‘business-oriented notation’ (zie specs).
BPEL
De Business Process Execution Language (BPEL) is een standaard uit de koker van de hele soa-beweging. Officieel is het dan ook WS-BPEL en zonder de bijbehorende BPEL4People en WS-HumanTask is BPEL mijns inziens eigenlijk niet zo interessant voor de modellering van bedrijfsprocessen (hier zal ik nog eens een apart stukje over schrijven).
De BPEL standaard (WS-BPEL 2.0 kwam uit in 2007) wordt beheerd door Oasis, gespecialiseerd in Web Services standaards. BPEL richt zich puur op de executeerbaarheid van processen en kent dus geen standaard notatiewijze in de vorm van een diagram. Verschillende tools laten BPEL processen verschillend zien en meestal lijkt dit wel op zowel een UML activity diagram als een BPMN diagram. De focus op web services en de executeerbaarheid van de processen, tezamen met de (oneigenlijke?) inzet van BPEL als integratie broker, heeft ervoor gezorgd dat BPEL enkel bij de it-afdeling is gebleven en bij de business meestal niet meer dan een abstract begrip is. In mijn optiek is dit overigens niet zo erg, maar wel jammer voor de communicatie.
Verschillende visies en strategieën
Zoals vaak in IT wordt de richting waarop we met z'n allen gaan bepaald door enerzijds de verschillende standaards zoals die gespecificeerd worden en anderzijds, nog belangrijker, de ondersteuning die software leveranciers bieden.
Hierin onderscheid ik vier visies zoals ik die in de BPM wereld terug zie komen:
1 .BPMN voor analist, BPEL voor programmeur
BPMN zal gebruikt worden door de business modeler/analyst en hoewel software engineers weliswaar de modellen kunnen lezen, zullen ze pas beginnen bij een niveau verder, namelijk een BPEL process server. De initiele BPEL kan eventueel gegenereerd worden, maar roundtripping (BPEL weer terugleiden naar BPMN) is hierbij niet nodig, want BPEL kent een ander abstractieniveau dan BPMN. Dit was in principe altijd de strategie van een speler als IBM.
2. De opportunist
In deze visie zijn BPMN en BPEL twee technologieen die je gewoon kunt ‘mengen', dwz. in een moderne service georienteerde omgeving kun je het ene component in BPMN maken en het andere in BPEL en dan in dezelfde process server laten draaien. Dit lijkt de visie van bijv. Oracle te zijn.
3. BPMN 2.0 maakt BPEL overbodig
Aangezien BPMN 2.0 ook een executeerbaar model specificeert, zou het mogelijk moeten zijn om zonder BPEL direct vanuit BPMN processen te draaien. In deze visie is BPMN 2.0 dus de opvolger van BPEL, waarbij je je dan meteen moet afvragen of dit het ultieme middel is om het business-IT gat te dichten. Wat ik me in deze ook afvraag is of de problematiek die BPEL heeft opgelost niet opnieuw wordt bedacht. De nieuwe open source tool Activiti zit in ieder geval op dit spoor.
4. BPMN en BPEL samen
In deze visie zijn BPMN en BPEL twee zijden van dezelfde munt. Je hebt BPMN nodig om een BPEL proces te visualiseren. BPEL zal hierbij altijd een standaard op zichzelf zijn welke door vele engines vandaag de dag ondersteund wordt. Deze visie lijkt een beetje op de eerste, maar verschilt in die zin dat, evenals in 2 en 3 de verschillende medewerkersrollen in een bedrijf niet duidelijk benoemd worden. De BPMN 2.0 standaard houdt duidelijk rekening met deze vorm van toolondersteuning. Een voorbeeld van een bedrijf in deze hoek is Active Endpoints.
De beste strategie is wellicht afhankelijk van de grootte en scope van het te ontworpen systeem, maar persoonlijk ben ik een voorstander van een duidelijke scheiding tussen de modellering en de executeerbare programmatuur. Komende uit de IT en de historie op het gebied van UML en MDA kennende, ben ik er nog steeds van overtuigd dat het onderkennen van verschillende abstractieniveau's essentieel is. Net zoals UML handig is om een stuk software te modelleren op een whiteboard of in visio ten behoeve van communicatie, alsmede om een stuk code achteraf te visualiseren, zo is BPMN fijn als standaard taal voor proces modellering. Maar anders dan UML is BPMN ook geschikt voor businessanalisten, wat nog niet wil zeggen dat een businessanalist met BPMN een software systeem kan maken.
Conclusie
Er zit veel beweging in de bpm-markt op het gebied van standaards en leveranciersondersteuning. Voor het modelleren van bedrijfsprocessen zijn standaards onmisbaar en bpm-suites ondersteunen ze op verschillende wijze. De echte discussie gaat echter over de visie op business-it alignment. Hierbij laten volgens mij de ontwikkelingen op de bpm-markt zien dat die hele business-it alignment een non-discussie is omdat business en it eigenlijk één zijn.
