Business Process Modeling Notation (BPMN)
web site: www.bpmn.org
BPMN was developed as part of the BPMI consortium. The work is now done at the OMG.
On may 3rd 2004, the working group has published its 1.0 specification.
The latest specification was published by the OMG in February 2006.
Updates:
- 12/08/2007: I have publish an article "The 7 Fallacies of Business Process Execution" which explains how BPMN and BPEL relate with each other
- 10/21/2007: I have published the BPMN 1.0 metamodel here.
Stephen White, the main author and driver behind the specification has written an introduction to BPMN.
Commentary
The goal of BPMN is to provide a business process modeling notation that is readily usable by business analysts, technical developers and business people that manage and monitor these processes. One of the goal of BPMN is also to be able to generate execution definitions (BPEL4WS) that will be used to implement the business processes. As such BPMN positions itself as a bridge between modeling and execution and between people that run the business and implementers of systems that support the business.
BPMN allows us to create a Business Process Diagram which represent the activities of the business process and the flow controls that define the order in which they are performed.
BPMN has tried to find the best tradeoff possible between an intuitive notation, using familiar constructs, and a complete set of business rules common to the business processes.
IMHO, a business process is modeled by 4 irreducible concepts: Actors, Activities, Events and States (as shown in the picture below) and I was happy to find that BPMN is not just a graphical veneer on top of pi-calculus: it supports Activities, Events and Actors (as both participants and performers).
Figure 1. My proposal for a Business Process Metamodel
I however do not view events completely the same way. In BPMN Events and Messages are separate: events are flow objects, while messages represented by two types of objects -a message flow and optionally the associate data flow which are both connecting objects. As Stephen confirmed, in BPMN it is the activity of receiving or sending a message which is an event in BPMN. So this is how BPMN will represent the events of sending/receiving a message and the associated data flow (incidentally in the stencil I used, it was possible to associate a state to a data object):
Figure 2. BPMN representation of a business message
IMHO, I don't see why a message is not categorized as an event. Of course a message may contain multiple documents just like an ebXML BPSS document envelope, but from the business process point of view a message should have the semantics of an event.
It seems so far that most specifications in the BPM space have overlooked the notion of "state". The W3C WS-Choreography group has just introduced that concept. The ebTWG has also talked about it in the Business Entity Type specification.
BPMN specifies four categories of objects:
• Flow Objects
• Connecting Objects
• Swimlanes
• ArtifactsFlow objects are made up of events, activities and gateways.
Events are for instance timers, or start and completion events. An activity is a generic term for work being performed. An activity can either be a task (atomic) or a sub-process. Atomic activities can be of type: service, send, receive, user task (workflow), script task or manual task. A user task may have a performer. BPMN allows you to specify a very useful business rule: a for-each on activity. So you can express subprocesses for an unknown number of participant (An example is a request for quote process sent to n suppliers that all respond at a different time or many not respond at all). BPMN also supports activity looping which is another construct often in business processes but absent from execution languages. A gateway is interesting because it groups all "branching types" (decision, fork, join) into one concept. It makes a lot of sense.
Connecting objects are: a sequence flow (simple transition), a message flow (a transition guarded by a message event) or an association (that is used to associate data, text, ... to flow objects). Frankly this is the part of BPMN I like the least as it groups very different concepts: transition, messages and associations. These concepts seem to have little in common except from the fact that they all connect flow objects together. Note that a data object association is used to show whether this data object is an input or output to an activity. It is also important to note that a message flow is only possible across pools.
Swimlanes represent participants. A Swimlane can either be a pool or a lane. A lane is a sub partition in a pool and allows us to group activities which are logically related to each other (e.g. when they are performed by the same department). It is surprising that the notion of "role" performing an activity was not introduced in BPMN.
Artifacts are mainly data objects. Data objects are typed and represent the input and output of activities.
BPMN is supposed to be able to model both B2B collaboration and internal business processes. As the editor of the ebXML BPSS 1.1 specification, I must admit I disagree with this statement. BPMN is capable of modeling the message interchanges by the sequencing of these interchanges (the collaboration) can only be inferred from the model of the private processes that support the collaboration. Here is a tutorial on BPSS. You can also refer to the specification itself (I am the editor of this specification).
Surprisingly there is no XML Schema associated to BPMN. Since the goal has been to create a uniform notation that everyone would know and use, why not creating an interchange format such that all BPMN tools can create BPDs that can be exchanged?
BPMN offers a direct mapping to BPEL4WS 1.1. If this represents an desirable goal, I must admit that I am puzzled by what appears to me as conflicting concepts. The mapping between BPEL and BPMN maps "invokes", "receive" and "send" activities. These BPEL concepts should be mapped to message exchanges not activities. A "send" does not represent work being performed, it is rather the work that has resulted in a message event.
The reason for this artificial mismatch is twofold (again, IMHO):
a) we are slowly understanding that BPEL is not a business process execution language but rather a programming language that is used to write business logic that can participate in a business process. If we map this to BPEL, it means that BPEL is used to model a BPMN activity not the flow of activities. Now of course, BPEL could also have its own notation and BPMN could be used to represent an orchestration definition specified in BPEL, but this OD is not a business process, it is rather an activity of the business process.
b) At the time BPMN was being worked on there was no web-service choreography specification available. BPMN as its stands today is very much aligned with WS-CHOR, a lot more than with BPEL4WS.
If you are not familiar with my approach to business process modeling please read my 2002 paper or take a look at this presentation or this article on BPEL-J.
BPMN is a lot more sophisticated and expressive that I can convey in such a short analysis. I strongly recommend that you take a look at the specification. If you have visio, you can even start using it today.
All things considered, BPMN represents a major step forward in the BPM space and I am confident that its usage in production will quickly lead to adjusting its semantics wherever necessary (B2B, State,...). I believe that BPMN should become the catalyst that will federate the 3 other specifications of BPM:
- BPEL (business logic that can participate in a business process),
- WS-CDL (Choreography is the foundation of business process definitions, it is very apparent in BPMN),
- BPSS (B2B semantics).
Jean-Jacques Dubray
6/10/04
References
Visio stencil (from Orbus Software)
BPMN and BPM (Popkin Software)
