ProcessModeling.info

The BPMN 2.0 specification adds a number of improvements and fixes to the BPMN 1.2 spec. Up until now I haven’t been watching it closely because there were too many changes going on, and it won’t be until July 2010 before BPMN 2.0 is final and released to the public. Due to my recent introduction and collaboration with one of the coauthors of the spec, Vishal Saxenda, I got an insiders look at what’s changing.

The new specification is over 500 pages long, which is much more than most of us have time to digest.  Furthermore, the specification is heavily laden with XML and references to mapping BPMN to the BPEL runtime. This is quite useful for standardizing BPM systems but might be more technical than the average process modeler wants to hear about.  Over the next few posts on this blog I will be highlighting some of the most important changes, and what it means to you as a process modeler.

In this post I will describe the new BPMN 2.0 task and activity types.

Activity Category

Often in my BPMN class I have a student who asks “how can I tell if the activity is a person or a system task?”.  Prior to BPMN 2.0 the only way to tell was to look at in the lanes in the pool, if you are using this style. Otherwise you would have to use a text annotation to clarify the intent of the digram.  BPMN 2.0 adds new icon annotations to the tasks. These icons are optional, but I encourage you to use them because it brings a lot of clarity to a diagram.

BPMN 2.0 Task Shapes

For example, there is now a manual task and a human task.  The difference is that the human task is meant for a BPM system or an application such as CRM where a task can be assigned to a person.  A manual task could mean many things, all of which are outside the scope of a typical system interaction diagram.  For example, a postal worker who sorts letters, a factory worker who assembles product, or a bicycle courier who delivers a package.  Manual tasks are sometimes just as important to an organization as tasks in a BPM system.  Therefore you should model these activities, and show a clear differentiation between the two types of human activity.

Messaging

The message task is something new, and solves a problem from the previous BPMN 1.2 specification.   Often, communications are not necessarily a one-way message.    The spec allows for either a task for a message event to send and/or receive messages. Students in my classes often ask me when should a task be used, and when should it be an event.  This usually results in a half hour lesson on the semantics and style of using task vs. event.  Thankfully, the 2.0 spec helps solve this problem.  The main intent here is to use a task for blocking communication, also known as synchronous.  In Synchronous communication, the initiator must wait for a reply before continuing with the next activity in a process.  This means that the initiator has a very active role in the communication, and a task should be used instead of an event.   In BPMN 1.2 I used the intermediate message event with a two-way message.  This was somewhat against the spec, but in order to illustrate the nature of the process, it was necessary.  So now we have a shape to solve this problem.

System Activity

System tasks were always a bit of a mystery in BPMN.  Often you would see a task that simply stated it was performed by the system, or an application.  The problem is that there was no way to tell what the system is actually doing.  The usage of rules, services, and scripts is very common in a BPM system.  But without a shape to differentiate which category of activity, the reader of the BPMN diagram was left to guess.  Again, the only way around this problem was to use a text annotation.  BPMN 2.0 adds three new icon annotations to activities, which helps cut down on text, and speeds the creation and interpretation of diagrams.

The service activity is a much welcome addition because now the business analyst who creates a process diagram can easily show where services are being consumed.  IT architects can now more easily justify the usage of BPMN instead of UML for process oriented projects.  This is a tiny change, but I think it will make a giant leap forward in terms of business and IT collaboration.

Scrips or Services

Not every system task in a BPM system is a service.  In an SOA system (service oriented architecture) this might be the case, but again, not always true.  Many tasks are simple scripts, which could be JavaScript, XPath, or other languages.  Often these scripts are proprietary to the BPM system that implements them.  But to communicate in a vendor neutral way, we must use shapes that are generic.  Often a higher level diagram will specify “a system task” but gives no reference on how it should be implemented.  So now with BPMN 2.0 you have a clear differentiation of service task verses script task.

Business Rules

Rules and process work together closely in a BPM system.  Prior to BPMN 2.0 there was no clear way to illustrate a rule activity.  The condition event didn’t quite work, because a rule is not actually an event.  Rules more closely resemble services, but a rule is a very specific type of service, often maintained by business people instead of IT.  Most BPM systems have their own BRE (business rules engine) or decision table system.  The rule shape represents the execution of a business rule.  This is quite useful in process modeling when you are working in a higher level multi-tier diagram structure and you are not yet ready to show the full details of a business rule.

Multi-Instance Activities

In a previous post Ins and Outs of Process Loops I pointed out a problem in the BPMN 1.2 specification related to multi-instance process loops.  The annotations state that the activity occurs multiple times.  However the spec says that the execution could be either in parallel, or in series.  But there was no way to tell which was which unless you looked at the “properties” which is unique to the BPMN system or the modeling tool.

BPMN 2.0 Multi-Instance Activity

My advice at the time was to use a text annotation to clarify the diagram.  This has now been fixed in BPMN 2.0.  The shape on the left is the parallel execution, which means all instances will execute simultaneously.  The subprocess on the right is the serial execution, meaning that all instances will occur one following the other.    Both of these shapes describe a “for-each” behavior because there is a set number of iterations.  In contrast, “do-while” and “do-until” loop types do not have a defined limit before the activity starts.   But a for-each normally would have a set number of iterations (for x = 1 to 5…).

Note that the looping subprocess and task shapes are still valid (no changes).

Next Post:  Artifact Shapes in BPMN 2.0

- Rick Geneva

Tags: BPMN, BPMN 2.0