Last modified by Keith Swenson 7/16/2009
Public Description (Wiki Format)
Business Process Modeling Notation (BPMN)
See WfMC effort on page XPDL2.2/BPMN2.0 Projects
BPMN 2.0
The BPMN 2.0 Webinar the submission team gave on June 9, 2009 has been posted to the BPMN 2.0 RPF page: http://www.omg.org/techprocess/meetings/schedule/BPMN_2.0_RFP.html
BPMN 1.2 available January 2009
See http://www.omg.org/spec/BPMN/1.2/
BPMN 1.1 available January 2008
Business Process Modeling Notation (BPMN), v1.1: http://www.omg.org/spec/BPMN/1.1/
BPMN General Information
BPMN is quite famous now, so for basic information please look at:
Documents
BPMN 1.1 January 2008
BPMN 1.0 OMG Final version adopted after BPMI merged with OMG, February 6, 2006 (PDF 2,968K)
BPMN 1.0 BPMI Final : May 3, 2004 Specification from the original BPMI group (PDF 2,705K)
WfMC Initiatives for BPMN
- Assignee indicators is a way to indicate the role that is assigned to a particular activity node.
- Stateful BPMN is a standard set of icons used to indicate the state of a running process
- Script Indicators embellishment to indicate which nodes have scripts, and whether they are pre- or post- scripts.
- Remote Subprocess Node a standard notation for this
What Does BPMN Lack?
- Roles ? Pools and Swim Lanes give an indication of which function will undertake work, they are lacking the rigor required for defining roles to be used in a deployable process. There is often a requirement to assign work to an individual in a department rather than the department as whole. Which individual may depend upon the category of work that the particular item of work in the process is about. It is not an infrequent requirement that the department in which the work is undertaken at a stage will vary according to the definition of the work. This can be achieved with Swim lanes but requires splitting the process diagram with decisions and adding a route for each different type of work to the process flow. Aggregating multiple functions into a single lane results in a misleading process model and incomplete understanding of what functions perform what activity. Without the concept of roles it is also difficult to capture the real world scenario where there are multiple performers ? such as the case where a Claims Adjuster, Claims Adjuster Manager, an Auditor, and the Customer may all be able to take action at the same stage in a process. Using BPMN it is not easy to capture the fact that at a single point in the process all of these people may take have different tasks assigned or available to them.
- State ? Activities, tasks, events, and messages are all important components of a business process and these are basically captured when using BPMN. What is not captured is process state. State can be considered a delay - it is frequent in long running business processes that there are points in the process where items are delayed, typically no one is available to work on the item. Consider an in-tray on a worker?s desk. This is a delay. BPMN provides no way for modeling or indicating such a delay. State is a most basic principle of human processes where people are adding value to the process through intellectual and professional input, or via real-world personal interactions (i.e.: a meeting, interview, or investigation). BPMN provides no way for clearly modeling or indicating such work.
- Forms - Forms are essential for interacting with a user. The more user intensive a process is, the more essential forms become.
- Integration ? Any but the most trivial of processes will involve integration with other systems. There is no way of building (or defining) integration with other systems in BPMN. There is also no way to graphically indicate that an activity is to be performed by a system and not a human although once can add annotation to the diagram. It is likely that adding significant amount of annotation would serve only to complicate the diagram.
- Sub Processes ? BPMN has no way of indicating that multiple sub processes should be undertaken concurrently. Common and ?Utility? Activities - In most deployed business process there basic activities that are used repeatedly throughout the process. Editing a form, manually sending a reminder, or adding a comment or note are all good examples. When using BPMN, these types of activities are difficult if not impossible to capture without using sub-processes or adding unnecessary complexity to the process model. These supporting activities may not directly affect the process fl ow but are often very important to understanding the common activities involved in the real-world execution of the process. Capturing these supporting activities as first order activities also allows their execution to be controlled by the same roles mechanism that controls process flow, work assignment, and information security.
(above five from Greg Carter, Chief Technology Officer and Vice President of Product Development and Neil Hudspeth, Director of Product Management from Metastorm)
- No way to indicate CHOICE of a user. You can indicate branching conditions, but no way to indicate the choices that person has. See Representing Choice in a BPMN Diagram
- BPMN lacks a full business context, but does address organizational structure, functional breakdowns, strategy and rules.
- BPMN lacks a formal semantics and many of its features are subject to interpretation. One construct of BPMN that has an ambiguous semantics is the OR-join. Several formal semantics of this construct have been proposed for similar languages such as EPCs and YAWL. However, these existing semantics are computationally expensive.
- Along the control-flow perspective, BPMN lacks support for the Multiple Instances without a priori runtime knowledge and for the Milestone patterns while the Synchronising merge, Discriminator and Interleaved parallel routing patterns are only partially supported. The limitations in capturing the Milestone and Interleaved parallel routing patterns stem from the lack of an explicit notion of ?state?. States can only be captured indirectly through event-based decision Gateways. As for the Synchronising merge, partial support is provided by BPMN?s OR-join Gateway but the semantics of this construct needs generalisation to cover unstructured process models. Finally, the concepts available to describe discriminator and tasks and sub-processes with multiple instances require extensions to properly capture the corresponding patterns. ref
Can XPDL to be compatible to BPMN 2.0?
Of course, as each new version comes out, BPMN and XPDL (or whatever format) would have to be kept in sync. BPMN 1.1 was release in January 2008 and XPDL 2.1 which supports it was available in February 2008. XPDL has been tracking BPMN, and there is no reason to believe that it could not track BPMN 2.0 when that starts to firm up.
Except, of course, if BPMN 2.0 is radically different and incompatible with BPMN 1.x. Such a radical departure would risk a failure to adopt the new version. Given the assumption that 2.0 is "compatible" with 1.x, it is reasonable then to assume that XPDL could be fairly easily extended to handle the new parts of 2.0.
XPDL defines quite a bit more than BPMN can express, and given that XPDL semantic came for the real needs of workflow products, it is even likely that some of the BPMN extensions will be to support things that XPDL already has.
What the question comes down to is "upgrade path". Currently more actual products use XPDL than any other persistance standard. If you want to be able to "migrate" those users to the new standard BPMN, then you will want in any case to provide a way to bring XPDL files along to the new standard. XPDL has always supported backward compatibility: an XPDL 2.0 tool can always read XPDL 1.0. This is a element of a successful standard. Any file format to support BPMN 2.0 must have an upgrade path from existing file formats. It is very unlikely that BPMN 2.0 can add a new file format "out of the blue" and have it be successful.