Active Knowledge Modeling

Though BPMN has emerged as a dominant business process modeling standard, the jury is still out on whether it is suitable for business people. Even for IT people, some argue that the number of constructs you need to understand in order to build a process model is too large. Future standards for adaptive case management will require even greater end user participation in process modeling.  

Consequently, the requirements for a simple, robust, extensible, and flexible modeling framework are growing. Over the years, we have developed a few principles for making modeling languages simpler to use. These principles represent a move away from the prejudice that everything should be defined as classes, which so dominates OO and MDA.  

The results of applying these principles to BPMN 2.0 could be a reduction of its size by up to 50%. The resulting framework would also handle typical evolution scenarios better, by removing the need for a lot of type change of individual elements. Finally, it would better support complementary visualizations of the process, like the 12 different process views we described earlier.

Most modeling frameworks are based on software engineering concepts, and function as visual programming. Principles that are important in programming are adhered to, like strict metamodeling where every element is created from a single type, and remain controlled by that type throughout its lifespan.  

The most common kinds of software modeling focus on the nouns (data modeling, object oriented structures) or verbs (process modeling) of natural language. Natural language works in a more contextual and compositional manner, where sounds are represented by letters, which are composed to form words. Words are put together into sentences. Both pronunciation of letters and the meaning of words can depend on the context in which they are placed.  

Principles

1. Features that can always be derived from the context of a model element, should not lead to definition of specialized subtypes.
2. Features that may evolve during the lifecycle of a given element, should be represented as properties, not as types.
3. Multi-dimensional classification is more efficiently represented by properties than by types.
4. Pure notational differences should not be reflected in the data model.

The most common example of principle 1, is the difference between atomic and composite elements. Principle 2 deals not only with situations where the real world phenomenon represented by the model element evolves, but also with situations where the representation itself evolves as the modeling progresses towards more detail and precision. This principle is thus crucial for evolution, for avoiding having to perform lots of unnecessary type change operations.   

Principle 3 points out that when elements are distinguished according to more than one aspect, the number of classes required will grow exponentially with the number of dimensions. The same information encoded as properties will only grow linearly in complexity.  As an example, we can look at the modeling of resources associated with a process. Resources may be atomic or composite, abstract (role) or concrete (individual), responsible or just participating. These 3 properties, each with two different values, would have to be represented by 8 types (2x2x2) if they were to be reflected in the type hierarchy. (Person, Team, Role for Person, Role for Team, each as Responsible or Participant). This example is further extended with more dimensions, leading to hundreds of specialized types, or just 7-8 properties.  

Principle 4 reflects the need for separating between the visual view and the underlying conceptual model that it represents. Some elements, like diagrams and annotations, are just visual. Another complicating factor is elements that are shown in different ways in different views, e.g. depending on whether they are part of the main concern of a view, or its context or boundary. An interface connector is a typical example of this. Of course, BPMN is primarily a notation, so the view aspect should be included in the standard. At the same time, the pure notation elements should be kept out of conceptual metamodels, model data interchange and process execution semantics.  

BPMN 2.0

BPMN 2.0 (beta 1) has a core set of constructs, grouped into packages for Infrastructure, Common elements, and Services. The next layer defines extensions for the three diagram types Process, Choreography, and Collaboration. A third layer defines extensions for Data, Activities, Humans and Conversations. Our discussion will not focus on the general definition of modeling constructs found in the Infrastructure and Foundations, but on the process modeling constructs.  

BPMN 2.0 does take some care to limit the complexity of the notation, e.g. by defining different conformance levels covering limited subsets of the constructs. Each level is typically applied by a certain group of users for a certain purpose, e.g. separating high level business modeling from the technical details of executable processes.  

BPMN is a process modeling standard. In a full framework for enterprise modeling, other business and IT aspects like organization, product, information, location, applications etc. would also have to be covered. Some constructs are better imported from related standards. BPMN 2.0 does for instance “designate XML Schema and XPath as its default data structure and expression languages”. It has however been argued that its complexity makes BPMN better suited for modeling the process in its own silo, than as a language for the process aspect in a complete enterprise modeling framework.

Simplification

We find the concept of modeling language efficiency proposed by Goguen highly useful. He defines efficiency loosely as the expressiveness of the language divided by its size, the number of different modeling types. We find that a lot of modeling frameworks are unnecessarily complex, in particular UML, where OMG rejected the much more efficiently structured clear, clean, concise proposal for UML 2. With version 2.0, BPMN appears to be moving in the same direction as UML, becoming more complex, more technical, and less user friendly.  

Activities

The first simplification we can make to BPMN without decreasing the expressiveness of the language, is to remove superfluous activity types. Though it makes perfect sense to define concepts like task and process in a terminology, they are not needed as core language types. Instead, they can be defined as derived types according to the following rules:  

• A task is an activity that does not consist of other activities.
• A sub-process is an activity that consists of other activities, which is also part of another activity.
• A process is an activity that consists of other activities, which is not part of another activity (though it may be called from one).

This simplification follows principle 1 above.  

In poorly designed model editors the separation between tasks and sub-processes also creates problems for typical evolution scenarios. If something is modeled as a task, but you want to add subtasks to it later, the type of the element must also be changed. There is however one opportunity that is lost with our simplified scheme, the ability to say that you expect to fill in a sub-process later, by defining the activity as a sub-process even though no subtasks have been added yet. This kind of temporary expression of intent is however a general issue that is common to any kind of element, not just the activities, and it is better handled in a general manner, independently of the core language, using the same mechanisms to say that “more will be added here”, regardless of which type of element the details will be added to. The modeling language SeeMe pioneered an interesting approach to these problems.    

Events

Events in BPMN are classified in four dimensions:  

1. Extended in the flow dimension, distinguishing between Start, Intermediary, and End events.
2. Extended in the type dimension, into None, Message, Timer, Error, Cancel, Escalation, Compensation, Conditional, Link, Signal, Terminate, Multiple and Parallel multiple.
3. Extended in the “coordination” dimension, into Throwing and Catching.
4. Extended in the “control” dimension into Interrupting and Non-interrupting.

In such structures, the potential for simplification is especially great, due to the multiplication effects of multi-dimensional classification, cf. principle 3 above, which results in the 28 subtypes below, further extended into 63 subtypes in total in the specification (page 237).  

Some of the event types in BPMN

Wisely, the specification takes a factored approach to handle this complexity. The Event types are specialized according to the horizontal axis in the figure, covering the flow and coordination dimensions. The vertical axis is handled by different EventDefinition types, which are associated with each Event object. The difference between interrupting and non-interrupting events is defined by a boolean attribute. This structure thus mostly follows our principles; avoiding having to specify all 63 subtypes as separate constructs.   

Further simplification is still feasible. The difference between start, end, and intermediate events could be derived from the context, according to these rules:     

• Start events have no incoming flows,
• End events have no outgoing flows,
• Intermediate events have both incoming and outgoing flows.

Turning these specializations into derived types would also make the models more easy to restructure, in cases where the boundaries of processes needs to be adjusted. Start and end events fill the roles of initial capital letters and closing punctuation marks in sentences, or maybe the symbols that define the beginning and end of a block of program code is a better analogy. These symbols improve readability of text, but in a visual model they are most often redundant. No human or machine reader would have a problem interpreting this model

the same way as this

In general, we are in most cases able to determine the first and last activities of a process as the ones without incoming or outgoing flows. There are some flow structures where it is not straightforward, e.g. a loop involving all activities, but such special cases should not stand in the way of simplifications that work in the great majority of cases. A general event construct could be used to define where the process ends and exits in any scenario, like this:     

Alternatively, flow links could be defined from the surrounding sub-process to the first tasks, and to the surrounding process from the final tasks:     

Flows

The difference between Sequence Flow and Message Flow is yet another core feature that can be derived from the context. A message flow crosses pool boundaries, while a sequence flow does not. There are semantic differences between these two constructs, but these differences can just as easily be expressed with derived subtypes. By removing these specialized subtypes of flows, we would also make it easier to move a task between pools, because none of the flows connected to it would need to have their type changed. Finally, a common way to represent flows would allow you to remove some of the redundant flows inside each pool in a choreography, which is one reason why people don’t use BPMN.

There are some more differences between sequences and messages. Sequence flows can be defined as conditional and defaults, but these features are not available for messages. These constructs seem meaningful for messages as well, but in case they violate some semantic constraints, rules could be added saying that these features are only available for flows that do not go between participants.  

The underlying principle here is that contextual semantics should be tolerated and utilized. Interpretations can be just as clearly specified with derived types as with basic types. The BPMN specification partially follows this approach by stating that the default semantics of a sequence flow depends on the kind of model that contains it.     

Gateways

The gateway constructs of BPMN are rather well defined. Though it is recommended to separate a many-to-many gateway into a merging and a branching gateway, it is not mandatory, and definition of separate gateway types for merging and branching has been avoided, even though their semantics is of course different. In this area,  UML Activity diagrams are more complex than BPMN.

Data Objects, Inputs and Outputs

A lot of different constructs can hold the data that influences and/or is manipulated in a process. The Data Object is the primary construct for modeling data within the process flow. It represents single or multiple objects. A Property is similar to a data object, but it is attached to another element rather than being visible in the diagram as a separate object. This distinction violates our principle 4, and we’d propose to remove it.     

Data Inputs and Data Outputs are associated with the interface specification of an activity. Here we find that the difference between these constructs and ordinary data objects is already represented by the fact that they are referred to by an InputSet or an OutputSet. There is thus no need to also represent them as specific types, cf. principle 1. Similarly, the specific relationship types DataInputAssociation and DataOutputAssociation seem superfluous when there is a generic DataAssociation. The differences between Message and DataObject could also be removed, following the alignment of Message Flow and Sequence Flow above. Finally, the difference between a persistently available Data Store and a local Data Object could be more flexibly expressed with an attribute than as different types. Often the value of this attribute should be derived from the context in which the data object is placed.  

Resources and Participants

The distinction between the resource type Performer and the general construct Participant seems unclear. The Performer class defines the resource that will perform or be responsible for an Activity, while a Participant is responsible for the execution of the Process enclosed in a Pool. There can be a difference in levels between these concepts, in that participants tend to be organizations that consist of performers. This can however also be seen as more of a difference in perspective than a difference in essence, in that an actor which is represented as a participant in one model could be regarded as a performer in another, cf. principle 4.     

Specialized Activity Subtypes

A Call Activity is a placeholder for a reusable sub-process or a global task. Again we are dealing with concepts that are better represented with one relationship type (e.g. calls), than by introducing new activity subtypes. Any activity could be reusable, and the existence of a library of reusable templates is more of a model management issue than a modeling language concern.     

Tasks and global tasks can take on subtypes like Service, User, Manual, Script, and Business rule. True, these can be regarded as different types of activities, but it more reflects a specialization that is derived from the relationship to the performer of the task, be it a human or an automatic agent. Early on in typical modeling projects, it will not be known how each task is supposed to be performed or controlled. It seems more flexible to add this information later as relationships to different types of performers, than to change the type of the activities. If you want to have a flexible rather than fixed automation boundary, you may even delay the selection between manual and automatic control to run time. Again, we are here applying principle 1 to achieve a more suitable separation of concerns between the process and other enterprise aspects    

Separating Models and Views

According to the specification, a BPMN Diagram is a visual representation associated with a single model element. Different diagrams reflect different types of high level elements like processes (public or private orchestrations), collaborations, choreographies, or conversations. These concepts seem to be distinguished more by the viewpoint they reflect, than by the essence of the underlying concepts represented (cf. principle 4).

In BPMN the differences between types of diagrams are represented only in the model concepts, and not as subtypes of Diagram, cf. Figure 13.1 in the specification. This solution follows our principle 1, and utilizes multiple instances rather than classes to define the different characteristics. However it appears that Collaboration, Choreography and Conversation are better described as different views on the same phenomenon (a process with multiple parties), than as different phenomena. It would thus make sense to move these classes out of the modeling language definitions, and into the diagram definitions. 

Pool and Lane are also primarily visual concepts, which may be used to represent different kinds of underlying concepts, e.g. participant and performer roles. BPMN specifies that a pool always represents a Participant, while a Lane can represent anything that is reasonable for subdividing a process. Again, we’d prefer these concepts to be part of the visual definition of diagrams, rather than included in the conceptual definition of the process modeling language.     

Summary

The simplifications discussed above would reduce the number of constructs in the Simple variant of BPMN from 7 to 4, and the descriptive variant from 24 to 13 or 14. For the richer DoDAF and complete variants, similar reductions in size can be achieved. This would make the language easier to learn, remove confusion about which type to use where, and remove several rules for consistency checking, all without decreasing the expressiveness or precision of the notation.   

Templates

Though we propose to remove several redundant types from the core modeling language definition of BPMN, this does not imply that they need to be removed from the tool palettes of a modeling editor implementing BPMN. By letting the tools create new elements from templates rather than classes, we can insulate the tool layer from the underlying language. This makes it easier to define different modeling interfaces for different purposes, around a lean and efficient core language. A template could add specific symbols, predefined property values, and possibly constraint rules, to the basic type definition. This approach also breaks up one of the most troubling underlying assumptions of BPMN, that modeling occurs at the class level and never at the instance level. This prejudice is reflected e.g. in the separation between ordinary attributes and instance attributes. For adaptive business processes, instance level and even run time modeling is required.