Manifesto for BPMN 3.0

Dear Readers,
   Having worked extensively for 6- 7 years on BPMN 2.0 specification, and its amazing success, I would love to see more work to address the requirements of more real life processes being added to BPMN. The first prototype of .bpmn file was written in second half of Dec 2004 on a late night, using little more than XML and a XML editor. Its great to see the success of the standard and it speaks volumes about the hard work done by the entire team. Steve big kudos to you!!! Any estimate how many person years were invested, my guess is about 200 person years at-least.

   Here is my set of recommendations for BPMN 3.0 -
1. Global Event support
An event, of critical importance,  can occur at anytime during the execution of a process instance. e.g. Pardon the extreme: Death of a loan applicant while the loan application is being processed.
It would be painful to model every task to be aware of such an event occurrence. Therefore, it should be possible to have a global event(s) defined which all activities in a given process are aware of and can react to if needed.

2. Make Process Artifacts first class.
Current support for notes, documents etc is restricted to association with activities. There are scenarios where several activities in a process may result in updating a document or based on some content of the document, might influence the decisions made during a process. Therefore, Documents should be treated as a first class citizen similar to data objects.

3. Refine Execution semantics in cases of Signal and Global events
Taking a cue form 1, we need to refine the execution semantics to support such events.

4. Allow for rework
Often times, process instances may need rework of certain steps. This is especially true for human tasks but is equally common for service tasks, the specification should specifically allow for rework of process instances from specific tasks.

5. Allow for Skip
As in 4, there are cases where certain activities may be skipped both in normal cycle as well as during rework cycle, so execution semantics need to provision for skipping certain tasks.

6. Allow partially defined processes
To support design by doing paradigm, and also allow lazy folks like me :), it is important to allow users to model processes which may not be complete.

7. Runtime Modification - Change the state of instance -
Execution of process needs to allow for change of state of any given instance, including go back and restart a task or skip some tasks in some instances, or activate certain branches - branches that were never activated given the conditions at that time but need activation now.

8. Runtime Definition Modification -
Change the definition of executing business process and instances thereof. A common use case, where processes can never be right the first time and often times there are inflight instances already when we discover the discrepancy. Allow the definition to be changed while instances are already in flight.

9. Digramming should support layering
There can be multiple level of detail in a BPMN diagram. One specific to Executive users, one to department heads, one to business and one that actually executes on the wire. Since BPMN supports diagram - there should be support for layers of diagram. I see the level of detail, I want to see. I know this can be left to tool vendors but this can probably be the non-normative part of the spec. "Non-normative" is the OMG speak for not mandatory and binding - but dont quote me on this definition.

10. Bubble up user participation in activities and consequent decision management.
Currently decision making is made based on condition expressions with data variables. However, process participants and their decisions are equally critical and there should be first class support for these decisions.


11. Pre and post execution rules support.
There should be pre and post conditions for execution of each task. Before we assign a task to a user, or even create a task, we should allow for user defined rules as an entry condition to the task; similarly before a task is considered to be done there can be exit criteria defined.

12. Add checklist for activities including ad-hoc
As a post condition for ad-hoc tasks - there should be an option to add a checklist, one which can be modified by users when needed.

13. Milestones - Add a notion of milestone.
Since several business processes can be long running and may even take months to finish, and also for supporting intermediate signpposts, we should add the concept of a milestone. Yes one can argue that even today this can be modeled as an association but it makes sense to make it first class member of the process definition.