BPM Think Tank

I was a panelist and roundtable moderator representing W3C and Adobe at this years BPM Think Tank 2007, hosted by the OMG. As per the web page:

BPM Think Tank's unique gathering of experts and its highly interactive format make it a can't-miss event. You'll rub elbows with some of the world's leading experts on BPM. Most importantly, you'll be a part of the action during moderated roundtable discussions broken out by topics of interest to business and technical audiences.

I panelled for the BPM Standards Organizations Panel which was largely dominated by the question of how to drive greater co-operation between OMG, W3C, OASIS and WfMC toward a plan for using the various different BPM languages together, along with the indefatigable, wistful desire for "one language to rule them all" (my twist on the quote). Despite two interruptions by fire klaxons and a bald-faced product pitch by one of the participants, the panel carried on quite well. One idea that John Evdemon (who well represented OASIS) and I were particularly keen was to have a Workshop, much in the vein of the WS-Policy Workshop held in 2004, but as a cross-organisational meeting on BPM languages/technologies and how we can present an unified message on using them together.

Why use them together? For the large part, these languages serve different purposes. The WfMC attempted a "one language to rule them all" approach in the late 90s which has failed to gain any traction. In the meantime we have standards organisations promoting different languages targetted at different stages of process architecture, design and development, as well as different audiences, which, as the panel illustrated, confuses most users.

What I attempted to make apparent in the panel was that each audience and state of BPM requires a different *perspective*:

• High-level, abstract, Visio-esque diagramme for executives, management
• Annotated model for business analysts
• Global-view description for technical analysts, architects, technical/IT management
• Executable processes/code for developers

Business management understands the business flows, and thus uses diagramming to describe those flows. Business analysts then marry these boxes and arrows diagrammes to a model which more richly explains and annotates what actually happens from a business perspective - this is critical to being able to translate these abstract business activities to something that can be coded. From this drops a choreography, a peer-to-peer description of what interactions are taking place between parties from a neutral perspective, their roles, responsibilities and relationships, whether these are binary or multi-party. From this description, executable processes/code can be written, whether as a single process/service or multiple processes and services.

There are technologies which are well-placed to serve each audience and stage of BPM:

• Notation: BPMN
  • Status: Still work to be done, but largely adaptable to a number of perspectives of BPM. A large number of products support BPMN.
•   Meta-model: BPDM
  • Status: Still under development, but at this stage, BPDM can be reliably developed from both BPDM and CDL.
• Description/Choreography: CDL
  • Status: The core of "testable architecture", CDL is quite adaptable as it supports description, provision of hooks for monitoring/management/auditing, validation and simulation. Formally based on pi-calculus, Available in several products. Presently a W3C CR.
• Execution/Orchestration: WS-BPEL
  • Status: Well designed and targetted as a platform-independent, interoperable executable/orchestration for Web Services. WS-BPEL's focus, constraints and semantics provide the foundation of process execution. WS-BPEL is presently a published OASIS standard.

It really seems so clear how each of these languages fit together. BPMN and BPDM can drop out a choreography, in CDL, which can then generate endpoints for its interactions in WS-BPEL. WS-BPEL's Abstract BPEL and associated profiles enable not only for the contracts for processes and services to be formalised, but also roundtripping from WS-BPEL to CDL and then to BPMN/BPDM. CDL provides the global, technical view from which operations which are driven by BPM are described, validated, simulated, monitored and managed. And BPMN and BPML provide the higher-level, business view of these processes.

In the roundtable that I moderated with Ismael Ghalimi, "Why is BPEL relevant and what is its future?", we talked through this, but as well as why WS-BPEL is not intended for business management, business analyst or even technical analyst use. It is a programming language for developers, full stop - one well suited to removing one's concerns w.r.t. the platform (e.g., while one can use CDL to generate Java, C#, etc., generating to BPEL is useful for encapsulating the platform concerns of these languages) - as our Oracle participant mentioned, you really now have WORA. Portability is still a concern with BPEL, but the idea is that you don't use BPEL to express the interchanges, but to define the execution logic. You would rather use CDL for interchange expression.

We also discussed the role of BPEL4People, which was quite interesting as it is still working its way to a standards body, but the above also highlighted the role of BPEL4People w.r.t. workflow. We also discussed XPDL but I was disappointed as I was seeking more from our WfMC participant on what XPDL can actually do (especially that other workflow languages, not to mention BPEL4People, do not).

After the sessions I was able to meet with a number of industry representatives - most importantly end-users, and the consultants who build BPM apps for them. With few exceptions, everyone I spoke to sought tools which supported the above model, but in particular supported the monitoring, auditability, validation, simulation and endpoint generation strategy that is espoused in the "testable architecture" enabled by CDL.

More on "testable architecture" in a subsequent entry. :-) Many thanks to Steve Ross-Talbot for connecting me with the folks at OMG and the BPM Think Tank.