As an ISO/IEC 19510:2013 standard and de-facto standard for business process modeling, the Business Process Model and Notation (here in after referred to as BPMN) defines a graphical notation for representing business processes in the form of business process diagrams.
The notation is both complex and simple enough for modeling any kind of processes – from a pizza delivery service, to the Nobel Prize awards (both these examples are provided in the official specification). Such modeling can be achieved with as little as a piece of paper and a pen, but that is not a common practice, nor is it encouraged.
In order to take the full advantage of the standard, the use of modeling tools is highly recommended. They enable easier and faster modeling, because they support a wide variety of features, such as enforcement of syntactic and semantic rules, support for team modeling, business process simulation, export and import in different formats etc… A comparison between a hand drawn process and a process modeled in a BPMN tool is represented in Figure 1.
When can a Tool Claim BPMN Compliance?
Before BPMN 2.0, any tool could claim BPMN compliance, since there was no official criteria. Consequentially, many BPM tools that provided “boxes and arrows” for modeling claimed to be compliant with BPMN.
Besides many additional changes, BPMN 2.0 now also defines several applicable compliance points in it’s specification. The standard states that the software “can claim compliance or conformance with BPMN 2.0 if and only if the software fully matches the applicable compliance points as stated in the International Standard”.
However, if the software only partially matches the applicable compliance points, it can only clam “that the software was based on this International Standard, but cannot claim compliance or conformance with this International Standard”.
Furthermore, the specification introduces four types of conformance: 1) Process Modeling Conformance, 2) Process Execution Conformance, 3) BPEL Process Execution Conformance, and 4) Choreography Modeling Conformance.
Any tool that claims Process Modeling Conformance must support the elements and attributes of three subclasses, namely Descriptive, Analytical and Common Executable. The Descriptive and Analytical subclasses address the non-executable models and provide the information, necessary for visual representation of the diagrams (e.g. icons, markers, border styles, shape types). Any description of the data and the corresponding XML and meta-model is part of the Common Executable subclass. A study card of Process Modeling Conformance is available on the Good e-Learning website.
A Process Execution Conformance tool must fully support and interpret the semantics and activity life-cycle, as well as underlying meta-model. Besides, importing process diagrams must also be fully supported.
Tools, claiming BPEL Process Execution Conformance must firstly fully support Process Execution Conformance. Furthermore, it must completely support mapping from BPMN models to BPEL, as defined in the specifications.
Finally, tools that claims to support Choreography Modeling Conformance must provide BPMN Choreography types, elements, visual appearance, semantics and interchange in accordance with the BPMN specification.
Which Tool to Choose?
As of 2014, the official BPMN homepage lists 74 BPMN compliant tools. There are of course many more on the market, but are not formally enlisted. Therefore, selecting the most appropriate BPMN modeling tool for a Business Process Modeling (BPMo) project can be difficult. Besides, such projects can have high stakes in terms of time and cost.
While smaller modeling teams should have a less formal and more agile tool selection process, it is advised that medium-to-large sized projects conduct an extensive study for the selection. To this end, many methods and steps are introduced. In this chapter, we will present one of the suggested approaches, summarized in six steps.
Step 1: Specify Objectives and Requirements
Step one, we need to specify objectives and requirements. Both functional and non-function requirements of a tool in question need to be specified. An example of functional requirements can be as advanced as syntax check or as basic as the popup menu (Figure 1).
Non-function requirements should address user interface, documentation, performance characteristics, hardware considerations etc…
Step 2: Define Selection Criteria
Step two, selection criteria must be defined to determine which BPMN tools satisfy our requirements. Besides, we need objective criteria for measuring such characteristics and a threshold, beyond which BPMN tools are not appropriate for our needs.
Table 1 represents an example of selection criteria along with the corresponding definitions. As can be seen from the table, each of the criteria is ranked from 0 (does not support) to 10 (supports completely). However, these values can take any given numerical range, depending on the decision maker’s preferences.
Step 3: Define Weights
Step three, relative weights to selection criteria must be assigned (Table 2), which quantify the selection criteria importance and reduce bias. Such weights usually take values from 0 to 1 and are estimated based on our objectives and requirements.
Step 4: Identify Candidate BPMN Tools
Step four, identification of candidate BPMN tools must be performed. As already mentioned, the official BPMN homepage alone lists as many as 74 BPMN tools. Evaluating each of those would be too time-consuming.
One of the method that addresses this issues was proposed by Kannengiesser. Author introduced a number of filters, which reduce the input to the full evaluation process. The method can be summarized as follows:
- Obtain a demo or free version of a tool on the list.
- Evaluate the ease of installing the selected tool in light of installation or configuration problems.
- Evaluate the operability problems, in accordance with the ISO/IEC 9126-1 quality model.
- Analyse the minimum support for BPMN in the tool. This is an essential precondition for accepting the tool for further evaluation.
After the initial input of BPMN tools has been reduced, the BPMN tool requirements are applied, which additionally filter the number of tools. The list of potential candidates should be reduced to a five or fewer tools (Table 3).
Step 5: Evaluate Best Candidates
Fifth step, when a short list of candidates has been conducted, we can furthermore evaluate the tools. In this step, we systematically apply the weighted evaluation criteria.
To ensure consistency across the selected tools, the same BPMN testing model should be used. It is recommended to use a model with moderate complexity, which consists of at least 100 activities, 20 data objects and 10 swim-lanes.
Additionally, all BPMN diagram types defined in the specification should be exercised. If all steps are conducted in accordance with this approach, we will end up with a list of utmost three tools.
Table 4 represents the evaluation process of the five candidate tools, each rated in accordance with selection criteria (values from 1 – 10, see Table 1). The top three ranked tools are bolded.
Step 6: Select the Winner
Final step, the selection of the most appropriate tool is performed. To achieve this, a fine-tuning of requirements and weighted evaluation criteria should be performed and applied to the existing list of potential candidates. In our example, the winner in Table 4 is BPMN tool 4.
However, should we decide that syntax check is more important to our project than process execution, a fine-tuning of weights is necessary. This is represented in Table 5, where we increased the weights of syntax checking (from 0.7 to 0.8) and decreased the importance of process execution (from 0.5 to 0.3), both represented in cells with grey background.
Consequentially, the winner is the BPMN tool 3 (bolded text in the table), as oppose to previous case, where BPMN tool 4 had a slight advantage.
The complete selection process is summarized in Figure 2.
Conclusion
Regardless of the scope of the modeling project, the use of modeling tools is highly recommended. With the introduction of the BPMN 2.0 standard, such tools can claim compliance with BPMN 2.0 if and only if the software matches the compliance points.
This was adopted by many vendors and the selection of an appropriate BPMN modeling tool has become increasingly challenging. In this paper, we abridged a method for choosing an appropriate BPMN tool, which consisted of six steps. If performed correctly, an ideal BPMN tool for our purposes is identified.
However, it should be stressed that this is just one of many methodologies and ways for selecting a modeling tool.
