From OMG last week, it looked like the BPDM versus BPMN debate was “beginning to end” (although pundits are finding plenty to comment about: for example see EDS’ Fred Cummins’ comments, and Bruce Silver’s response) [*1]. The latest news is that the debate seemed to be mostly settled in favor of a pragmatic solution (which will presumably be announced at their next meeting in Sept 08).
From a CEP perspective, BPMN represents “simple-event flows”, and could in theory be used as the starting point for a set of standard semantics for continuous event processing (and, by extension, complex event processing or CEP). But simple “process flows” are to business processes like “decision trees” are to business rules – a very useful representation, but not in any way the only, nor necessarily the best, way to represent every process. There is a good reason why BPMN is commonly associated with “workflow” (modelling human-oriented business processes) [*2]. There is also a good reason why BPDM is potentially a very useful cross-process (including CEP) metamodel (and ergo why it should not be directly tied / restricted to just BPMN) [*3]. Conrad Bock‘s (NIST) BPDM tutorial at the OMG meeting was well attended, and indicated that BPDM, as intended, shows scope to be a generic process metamodel that could be used to relate different process modeling styles, including continuous and complex event processing. Definitely something for EPTS / OMG / CEP researchers [*4] to look into in future.
Meanwhile, in the real world, we are finding (1) an event-driven approach to modeling enterprise (inter- and intra-departmental as well as B2B etc) processes and (2) the use of executable event-driven models to drive workflows (as commented earlier) are being recognised as very useful capabilities. At TIBCO, for example, the use of standard modeling constructs (concepts / classes, state models, production / inference rules [*4] and queries) and best practices (event-awareness, decision management) with a high-performance distributed execution engine allows for dynamic process definitions that can effectively drive BPMN/BPM (iProcess etc) workflows.
As a heads-up, the relationship between CEP and BPM is a round table topic at the BPMI Think Tank later this year [*4].
Notes
[1] For the record, TIBCO’s BPM team already supports the defacto BPMN persistence mechanism (WfMC’s XPDL), and is a member of the BPMN2 submission team that includes IBM, SAP, Oracle, etc.
[2] Consider a large decision tree where you need to insert a new rule that affects more than 1 decision path. Oops, you now have a maintenance problem (did you update all necessary decision paths? when this rule changes, will you find all the necessary paths? etc). BPMN and orchestration diagrams / activity diagrams all suffer from the same representation scalability problem, which is why declarative forms of behavior are often needed (e.g. alongside or to augment orchestrations).
[3] BPDM was designed, originally, to handle all types of processes, not just BPMN orchestrations, and including event-driven ones. It may yet be considered by EPTS for potential CEP metamodel standardization …
[4] It seems that BPDM might be compatible with existing and proposed CEP and CEP-relevant standards (such as PRR), and even Opher’s proposal for an Event Processing (EP) meta-language (research topic / future standard). BPDM provides a general structure for organizing components of processes, including an emphasis on events, but it remains to be seen if it can handle (or be readily extended to handle) declarative process models, continuous process models, etc.
[5] Disclaimer: TIBCO are chairing said round table.
