BPMN

BPMN v. 1.1 (January 17, 2008) was defined by Object Management Group (OMG). (The latest specification of BPMN is located at http://www.omg.org/spec/BPMN/Current). The members of OMG include, e.g. IBM, Sun Microsystems, Unisys, Borland, W3C, to list a few.

It is a model which tries to be able to express abstract (or generic) workflows. It uses graphical notations as well as supplementary Attributes. The notations are Activities (e.g. Subprocess, Loop, Multiple, Compensation), Events (e.g. Message, Timer, Rule, Link), Gateways, Connections (Sequence flow, Message flow, Association), Artifacts (Group, Data, Annotation), and  Swimlanes (Pools and Lanes). See below. Note that all activities are alled Task, which is probably a bad naming since it has a strong link with BPEL and BPEL4People, which use the word Task as posted/scheduled human "task".

BPMN Notations v. 1.0 ( This section needs to be updated to v. 1.1)

These fugures are taken from OMG Web site.

Activities

Events

Gateways

Connections

Artifacts

Swimlanes

Control Flow, Resource Flow and Data Flow in BPMN

Workflows can be modeled in different ways by deciding what aspect it chooses to express as a central concept. In the BPMN, a Business Process diagram represents the "control flows" of workflow. A Pool represents a discrete Participant and a Lane represents a sub-category of  activities which are assigned to different Roles within the Participant.

Message flows are represented by Message Flow Connections (dashed line arrows) between flow objects but only across Pools (i.e. between Participants). Artifact Data Objects can be used to indicate input and output data and the flows are indicated by Associations (dotted line arrows), but the use of Association seems to be limited to be within the same Pool (Participant). Group assignment or its flow is represented by Group Artifact.

The control flows (Sequence Flows) can go across Lanes but not across Pools, since Pools are regarded as independent and discreet processes, belonging to different business entities, such as trading partners. As described before, the activities in different Pools can be connected with Message Flows. This may mean that the Control Flow may be handled by one mechanism of the BPMN workflow engine and that the Message Flow may be handled by another mechanism. (Obviously both are in the same design on the engine, so it must be dealt with the same einge.

In the control flow, it introduced Timed Activity or Loop Activity to represent waiting activities such as Human Activity. The Loop Task is different from an ad-hoc loop which can be formed with branching and looping back the flow with a Connection (and merging). It also introduced Link Event that is a trigger for another flow.

The Loop Activity does not seem to spawn new instances of the Activity (that is a possibility) but probably the same instance is re-used while the execution is on the Loop Activity. Also, the behaviour of Multi-instance Activity inside a Loop is a question, i.e. does it start the process all over again (i.e. start creating new instances from scratch and discard old ones), continue spawning additional instances or reuse the old instances until it requires more in the subsequence loops? Also, how such variations should be indicated in the specification?

A related matter is whether the "completed" Activity within a workflow is allowed to be revisited without a mechanism such as Loop, and also what would be the behaviour of the Activity when it is revisited.  This requires a sense of the "workflow in which one is in" and modes such as "do", "view" or "review". Or, can one revert to some previous point in time? E.g. such as "undo". This may be an alien concept for a model where one Role may have an interaction only with an Activity at a time to which the Role is assigned, i.e. a Role has no "view" for the whole workflow.

Multi-instance Sub-process: Although BPMN has a concept of Multi-instance Sub-process, it has no concept as to notations that can act on the multi-instance aspect of the Task, i.e. notations that can operate on different threads (or execution tokens) within the Sub-process. An example of this is Group-based operations and and thread gating or synchronisation.

Resource Flow: This is expressed as Siwmlanes and Pools in BPMN.

Data Flow: In BPMN, the Data Object (an Artifact) is a reference object associated with a main Control Flow between two Tasks. Therefore, there is no concept of an independent Data Flow that is not a Control Flow. This is contrast to something like Grid Flows where data may flow between Activities via the Control Flow, but also data may flow with independent path, i.e. Data Flow arrow may connect two Activities, which are not adjacent to each other with regard to the main Control Flow.

History and relationship to other specifications

BPMN was developed in response to the recognition for the need to have a standard and more generic workflow model (easy to understand) to connect business entities which are in the form of web services and are expressed in the form of WS-BPEL(EBEL v 2.0 was approved by OASIS WS-BPEL Technical Committee on 2007-01-31).  The BPMN v 1.0 Introduction document from BPMN Org also states that UML lacks elements to map to BPEL and, therefore, BPML was needed.

Another motivation seems to be: It has been recognised that the necessity of basic research in workflows. Such research effrots produced distinctive workflow patterns that are now commonly recognized. BPMN specification mentions the considerations and adoptation of the Workflow Patterns. In that sense, it is a parallel standard to YAWL (Yet Another Work Flow), which also uses those Workflow Patterns.

XPDL (WfMC) states that BPEL is an execution language whereas XPDL is a process design format (e.g. it has X-Y coordinates). XPDL v.2.0 tries to express every elements of BPMN. For this reason, it is commonly regarded as "BPMN-XPDL-BPEL", i.e. use BPMN to produce XPDL, to produce BPEL.

Although BPMN seems to aspire as a general workflow modeling lanuguage, the primary aim is to be able to express a Business Process in workflow modeling, i.e. it seems to have some bias towards the business process modeling.

Finally, it aims to be a generic modeling for business processes but also want to be executalbe model at the same time in conjuction with an execution language such as BPEL.

Implementations

BPMN Org lists some 41 commercial implementations as of 2007-01-23.

BPMN Editors

(There may be other free modeller/editor).

• Intalio BPMN Designer (can produce XPDL and BPEL).
• EMC BPMN Whiteboard (not tried)

Limitations

Although BPMN claims that it can model global communications between businesses, it seems that it lacks an ability to model connections between black box entities, i.e. the workflows of each entity must be known in BPMN diagrams . It is not a mechanism to connect port-to-port between entities in which the internal workings are not known. WS-CDL may be good at such a work.

Also, as ebXML claims the business exchane may requie more than being able to describe/model a Buisness Process but to decribe the interactions/collaborations themselves without going into details of the Business Processes themselves involved (leaving such parts as blockboxes). Although BPMN can describie interactions between two (or more) Busniness Processes, it does not focus on interactions only. This means that even if you want to model only one Buisness Process only, you need to describe the other Business(es) as a part of the model. This may be an unnessary effort.

BPMN has the ProcessType=Collaborative (either WS-CDL or ebXML is intended). This option, however, is provided only as a provision and a full implementation was not provided in the current specification.

Finally, many details related to its execution were left to the execution language, currently BPEL is srongly favoured and described in the standard, to which the BPMN is expected to downcoded. Many capabilities that we may be concerend with may be implementation-dependent on the execution launguage level.

Consideration from Human Workflow aspects

BPMN is a Buiness Process modeling language. In most of the business processes things may be run automatically without human intervention or interactions. Although it has a provision for human activities (TaskType=User) in a generic way, the standard lacks considerations for (1) Multi-user flow (with same Roles and unspecified numbers), (2) human collaborative Activities, (3) sub-Grouping and Group dependent Activitites, (4) re-visiting completed Activities by humans (not from Monitor), (5) dynamic and adaptable workflow.

More details of these point would be discussed in Human workflow section. 

Author Notes

Handling multiple instances in a BPMN workflow is based on the Multiple-instance Activity Use Cases of the Workflow Patterns. All cases seem to merge at the end and must be syhcronized. Also, the each instance within the Multi-instance Activity may be known from the parent Multi-instance Activity point of view, i.e. you can trace them from the parent at runtime, but whether each instacne of children Activities belonging to the same parent can know each other (e.g. to form some collaboration) does not seem to be clear.

Ad-hoc Activity is either prallel or sequential (still ad hoc to choose which one to do?) of multiple tasks not connected by Connectors. It also needs to define the Task completion condition.

In the specification, it is not clear whether data object associations can go across Pool boundaries.

For critical analysis, it needs to be investigaed as to what Workflow Patterns it can or cannot do. For example, Uses Cases of Human Activities should be applied to it.

There are criticisms as to some limitations in translating BPMN to BPEL. (To be described in more details later).