BPMN 2.0 Extensions: Data, Content, Rules and Goals

We use a subset of BPMN 2.0 graphic modeling concepts for our adaptive process visualization in Papyrus ACM. To shorten this post and keep the principle discussion about flowcharts product-independent I moved it to ‘The Problem with Flowcharts’. Here I focus on how we are able to reduce the limitations of BPMN within the Papyus Platform.

Flowcharts are like all models: THEY ARE WRONG, but some models are still useful. The usefulness of BPMN for adaptive processes lies in its artifact representation, pools, swimlanes and the extensibility. While we avoid flowcharts as a must, it makes sense to add data, content and rules while organizing the process around GOALS in BPMN. Mostly, because the notation is reasonably well known by BPM experts.  Once all goals and related tasks and rules have been defined, the case can also be looked at in the BPMN flowchart, which is editable and does graphically show the actual state of the case execution. All the data, content, rules and GUI forms are displayed as well as comment stickers and can be directly edited by a skilled person. While we can export the BPMN formats in XPDL, there is no standard for the extensions. We can however export them in any XML format if so desired. The complete process with all elements is stored, version controlled and deployed within the domain network of the Papyrus Platform.

For the business user we use a ‘Case Builder’ GUI where users can select GOALS from a library and drag them into a case. Incoming content events do not have to be predefined. Classification will assign the content/message to the right case and/or activity.  Users can select or create new GOALS to deal with it. The goal-orientation is a powerful ‘KEEP-IT-SIMPLE’ approach. The User-Trained Agent (process mining) will recommend to add a certain goal for a type of message, if users have done this before in similar situations. Goals can contain goal-rules and authorized business users can add or modify goal, global or local business rules using a Natural Language Rule (NLR) editor that shows all data in the context and verifies rule validity.

Creating or editing rules in the LIVE case with data context in any language.

Why extend BPMN 2.0 for business user presentation?

Despite the progress from 1.1, the enhanced and additional definitions still are prone to very ambiguous models. An ‘Activity’ can still represent any number of different functions and the new event types are lacking in detail on how they interact with the flow. There is still no artifact method, attribute and state modelling and no business rules. The proposed UML-like data modeling is non-existent. All inbound and outbound content, as well as GUI artefacts and rules will still have to be done outside the BPMN model. Hence, no model preservation, no roundtrip, no usability by the business and thus a lot of project management bureaucracy.

Because of the above, the BPMN 2.o Standard can only represent a small part of a complete process and it is neither usable as-is for very dynamic processes, nor is it easy enough to use for the business users to describe their processes. Especially the interaction of various processes is extremely difficult to design and coordinate. Business users cannot create event handling exceptions for intersecting processes. Therefore the intersection has been moved away from sending and receiving events to asyncronous goals.

BPMN View for Process Goals in Swimlanes and Groups

A standard BPMN model has only the acting agents (users) as real world entities whose decisions to perform functions on artifacts can’t be modeled. BPMN 2.0, as all flowchart models, is STILL functionally blind to the inner function of the major elements of a business process (content data, context and related rules) and therefore to its decision logic. Because of the programmed data, content and rule functions this requires long projects to implement, and thus orthodox flowcharts reduce the agility of a business rather than improve it.

We extended BPMN 2.0 to support a bottom-up modeling approach, where knowledgable or skilled actors assign real-world entities with state-changes and rules to process goals that are linked to top-down business targets, to produce a much more realistic and most of all adaptable model.  Users find it much easier to interact with real world entities and their states than with abstract flows. Rather than to enforce agents to perform in a certain way, the system simply enforces basic rules of the game and creates substantial transparency and therefore flexibility and adaptability. Process management has to offer complex real world models of people acting as a social group on business entities. Socializing to define flowcharts still creates the above limitations.

While BPMN is not a tool for business people to design large complex process networks, the representation can be helpful for understanding once the processes are organized around business goals and mostly controlled by rules and not gateway flow-logic.