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…

There is an EU Project proposal to look at Event-driven Business Process Management, and that drove the title and interest in this panel (following neatly on from the edBPM09 workshop a few weeks back) chaired by CITT’s Rainer von Ammon.

The brief for the panel was to cover particular aspects of  “edBPM” such as:

• What is meant by edBPM? Compared with, for example, the “edBPM  Reference Model” presented at the 1st EPTS symposium in 2006?
  • TIBCO of course talks about “edBPM” as either a part of “BPM+” (from a BPM perspective) or as automated rule- and event-driven processes (from a CEP perspective). Either way, customers regularly combine complex event processing and (orchestrated, BPMN-based) workflow as well as (orchestrated, XML processing) SOA.
  • The main issues with the supplied edBPM model was that it simply combined event processing with BPEL processes. TIBCO’s edBPM customers invariably never use BPEL (why should they?), and indeed some don’t use BPMN for process models (defining models in terms of states and rules). So the main suggestion here is to go up a level in abstraction:
    • Multiple engines (that could include BPEL if you were so hindered inclined) as well as event processing algorithms or even analytics.
    • An event server (or bus).
    • Some kind of generic state store (for process states, persisted events, etc).
    • More generic models (for business control) and dashboards (cockpit or otherwise).
• Who will be the first “market mover” in exploiting the term “edBPM”?
  • This might have been disappointing to the edBPM pundits, but the vendors basically agreed that this term had no formal “legs” yet: no one had a marketing campaign around event driven BPM, no one had tried to persuade an analyst to take up (or define) the term, and the large BPM vendor and consultant community would not want their “BPM” mindshare asset diluted.
• Do we need new/enhanced standards for edBPM? And what is the challenge to insert/combine Complex Events in BPM? Versus say an example model for non-deterministic approaches like Smart Fraud Management in Banking?
  • The new BPMN2 standard has started the process of adding interesting event extensions to BPMN, while there are existing standards for other models (PRR for production rules, UML State for entity lifecycles, BMM for motivations, PMML for analytics, the proposed DMN for decision models, and so forth).
  • The Fraud example shows how some existing fraud products might work, but again is too specific - what if other event pattern detection and event pattern discovery techniques are desired?
• Related to the above point was the proposal for new standards at the domain level for edBPM…
  • “The good thing about standards is that there are so many to choose from” comes to mind here: effort would be better spent event-enabling the existing standards (what are the relevant loads and what combinations of the domain data models are relevant as payloads?)…
• Although the panel did not progress to the next question, it is interesting nontheless: what is required to set up edBPM projects and/or what aspects of edBPM need to be researched further?
  • Probably there is some methodology work to be done on when to use processes, rules/queries or states and how to combine them…
  • Areas of outstanding research in edBPM are probably joint semantics (a.k.a. the promise of BPDM) across different process types (including CEP), CEP-enabled BPMN, and mergers of event operations with (some aspect of the voluminous domain of) the SOA service standards.

The original CITT proposal can be found at http://www.citt-online.com/downloads/EDBPM-IP-proposal.ppt .