One of the drivers of success in the BPM world has been BPMN – the Business Process Modelling Notation – developed under BPMI before it got absorbed into OMG, and probably a bigger success than any other modelling standard – and now as BPMN 2.o (beta, at this time) slightly reconfigured in name as the Business Process Model And Notation. BPMN is used to provide a “process” perspective (versus, say, a data or an event perspective) of a system and shows the flow or orchestration of process tasks and activities. It is made up of (per the excellent bpme.de BPMN2 summary poster):
- 2 flow subtypes: sequence is the normal flow, with default and conditional conditional subtypes
- 7 task types: send, receive, user, manual, “business rule” (really decision), service, and script
- 6 activity markers: sub-process, loop, parallel, sequential, ad-hoc and compensation
- 7 gateways: exclusive, event-based, parallel, inclusive, exclusive event-based, parallel event-based, and complex
- 6 types of data: input, output, object, collection, store, and message
and - 63 types of event…
OK, “63 types of event” needs a bit of explanation (and justification). These consist of:
- 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate
… across 8 situations classified by location in a process:
- Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
- Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
- End
… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving 58 63 event types defined [*1].
Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.
So let us analyse these event types from an event processing perspective:
- Message and timer events: these are probably most familiar with to those with an event processing perspective, with a message relating to what we consider either a source or a derived event.
- Escalation: this is really a deferal to a different process (e.g. a supervisory process), and can be handled by some internal message in event processing.
- Conditional: this is “reacting to conditions becoming true” – in other words equivalent to a rule-firing (or event query) success. In a rule system this might be handled just by setting some fact or data, which in an inferencing rule system will use some internal event to signal to the rule engine that other rules may “fire” – however there is no need to explicitly model this behavior. I may also of course create an event (or in a query system, insert / update some event), which is again is not explicitly modelled as “conditional” per se…
- Link: some means of connecting models: this is more a “page break” than a business event!
- Error: I prefer the term “exception” here, which of course is a local context – an error event in one process is a normal event in an error-handling process, etc.
- Cancel: this is more a transaction-specific event: if dealing with transactions then some events may indeed be “cancel transaction X” requests, which may or may not be satisfiable, etc.
- Compensation: this is where some process route may require some compensatory process – for example in relation to a “cancel” event.
- Signal: signalling information across processes: this is might be used as a control event, such as in controlling a choreography.
- Multiple: one of a set of events is “caught” or provides the cue to continue the process.
- Parallel Multiple: all of a set of events is “caught” to continue the process.
- Untyped events are used for start and state changes. Typically, though, a state change is the main event we are interested in (in event processing)!
- Terminate event – process complete! From an event perspective this (process end) might never happen of course…
The extra detail might be explained by the fact that in BPMN you are detailing *how* to implement a process, and the “event symbol” is providing you with some specific context for that event. In event processing languages, you usually describing “what* is to be processed, and where all events contribute to some situation or context. It will be interesting to see how these 58 symbols work out in practice, as a hindrance or a help for process designers…
Note:
*1: the table of events above, from the BPMN2 poster from bpmb.de, has 63 event symbols, and is slightly re-organised from the equivalent table in the BPMN2 beta specification (Table 10.93 pp 269-270, in 10-06-04.pdf). Interestingly the specification document also includes a table to detail the event symbols (Table 12.23 ppp 405-411, in 10-06-04.pdf) but this shows only 58 symbols! Let’s just say “lots of event types” in BPMN2 then…
just to inform you:
I put your post and your discussion with Brian into the last version 0.6 of our Ghent draft documentation and I hope you agree with that
http://forum.complexevents.com/viewtopic.php?f=13&t=275
On the basis of this material and the results of the table discussions of our WorldCafe we’ll write the final version of the documentation/proceedings volume until end of January, allegedly. OK?
Actually I thought that my post above was canceled because when I tried to submit it some days ago, I got an error (maybe that was my addition result wrong…lol)and I have not seen it when I checked your blog. But now I have just uploaded some ideas on David Luckham’s website http://forum.complexevents.com/viewtopic.php?f=13&t=278, because David asked me for a while to “air” our stuff related to the Ghent workshop on his forum. And when I checked the link to your post again, now it’s there:-)
Hi Rainer – apologies, for some reason your comment was “awaiting approval” courtesy of the spam filter… and yes I will post up the announcement for the Ghent event…
Doing well – thanks Paul. I do see an important relationship emerging between business process flows and CEP. This is especially true with the emergence of cyber security as a focus in the federal space. I am finding that traditional BPMN based products are simply not adequate to express the complexity with data-driven, dynamic business processes in the federal space. Non-technical users are also overwhelmed by BPMN so we are still building custom UI’s coupled with BE. BE Decision Tables are a big step in the right direction to allow non-technical users to interact. It will be interesting to see where TIBCO takes this interaction in the future to inlude edBPM.
Thanks Brian – interesting but unsurprising that (full) BPMN is proving overwhelming to non-technical users (hence the blog post – who wants to learn 63 types of events? etc).
Notwithstanding that, of course, BPMN 2 is a fine effort and very important to the IT world. I suspect it will evolve profiles for business analysts, replace concepts like ruleflows in BRE’s, enable standardised decision graphs, and so forth. And of course it will evolve to include / be more useful for event processing and high performance / high productivity computing.
Which reminds me… there is an edBPM workshop I need to post about…
Cheers
Hi Paul,
Do you envision an integration of BPMN and CEP? For example, do you see value in making Business Events state models BPMN compliant or do you see calling out to a separate IProcess engine.
Regards,
Brian
Hi Brian – how’s it going? I see you are still doing good work in the CEP space in government!
Regarding BPMN’s value in CEP: that is certainly the subject for a future blog post, but my quick 2c would be:
- BPMN does have value as an orchestration standard to complement state models (consider tasks like orchestrating decisions a.k.a. ruleflows)
- event processing applications can have a notion of an “event processing network” which might be well described in BPMN (either as a developer model or as a generated report)
- event processing applications can range from pure event pattern detection (and nothing else) through to event-perspective business processes, and for the latter BPMN may be suited
- there is some interest in “event driven BPM” or edBPM in the EP community, which is mostly around extending the ideas of BPMN to provide better notions of CEP and/or use CEP to augment BPM – in both cases with a role for BPMN.
In terms of design patterns, though, it is still the case that (a) BPMN is mostly focussed on BPM and supporting workflow (manual) processes, and (b) as such technologies like TIBCO AM BPM and iProcess can provide workflows to provide manual handling of exceptions etc discovered during event processing (such as in BusinessEvents).
pv
Hi Paul,
do you remember how many event types the former – at least in German speaking countries – de facto standard eEPK from IDS had? Hundreds. Typically each adopter defined a subset of event types really needed for his use case or application.
Could we forget some event types if we intend to make the process executable? Could the process model be mapped to a BPEL or XPDL or another executable language? What would be the consequences regarding flexibility, adaptability, maintenance etc. of BP’s if we shift some handling of events in the “hard coded” EPL or even Java or a 3GL part? Already 2007, we had great “events”/Expert Meetings about this stuff, where we discussed whether a BPMN or eEPK modeled process could be executed at all and whether there would be a way to adapt a model after a process was made executable. Was a great time actually, I liked these events very much:-)
http://www.citt-online.com/include/6-ExpertGespr/6-bpm-bam-cep-soa-eda-agenda-v1.htm
http://www.citt-online.com/index.php?id=veranstaltungen&id3=exp06&id4=more
http://www.citt-online.com/index.php?id=lehre&id3=course_bpa&id4=more
http://www.citt-online.com/index.php?id=veranstaltungen&id3=eire08-1&id4=more
After DEBS’10/Cambridge Opher told in his blog that he was asked in his workshop why he did not realized the FastFlowerDelivery application by BPMN, because in his and Peter Niblett’s book it is implemented by EPL code and modeled in a more or less own or special notation. And I commented that the question was actually not so bad, let’s try to realize it in BPMN and then let’s see what event types etc are missed. Because we should use a standard as far as it makes sense before inventing the next notation. My 2 cents.
Actually this would be the subject of table 1 of our Ghent workshop 13 Dec 2010 “Grand challenges for Modelling of Complex Dynamics and for execution platforms of U-CEP”. We’re looking for the role of a table host, you would be the right guy for this job, will you do it? First draft of the later documentation: http://www.citt-online.com/downloads/Docu-Workshop-edBPM-UCEP.doc