© Copyright 2015 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd.

An Introduction to Measuring BPMN Modelsby Gregor Jošt

IntroductionA lot of research was done on complexity in Business Process Model and Notation (BPMN). The results were always conclusive, BPMN is generally perceived a complex notation, with lots of different elements and many possible connections between them. As such, complexity coping mechanisms started to emerge. To this end, it is vital to measure the process model complexity, since it can help to understand and modify the model. Consequentially, the process quality improvement is more likely to occur. As stated by Lord Kelvin: “To measure is to know”.

When measuring the business process diagram (hereinafter referred to as BPD) complexity, there was a huge challenge of how to define the metrics. Fortunately, the field of software development has already established a sound set of metrics for measuring the applications and its corresponding structures. Since there are several analogies between software programs and BPD, it does not come as a surprise that the majority of suggested BPD metrics copy the already established metrics for software evaluation. The similarities between software programs and BPD are as follows:

1 Both software programs and BPD have logical structures with inputs, operations and outputs.

2 The software products logically match business processes.

3 The functions of software products logically match activities of business processes.

4 A business process modeled with an execution language (e.g. BPEL or BPMN 2.0) can be viewed as a traditional program, which has been divided into modules (activities).

5 Threads in programs are used to implement concurrency, whereas in models, we can use AND-splits.

6 The “If-then” sentence can be mapped to OR-split in a BPD.

Based on the presumptions above, a detailed comparison between BPMN and object-oriented (OO) software was performed by Khilf et al. in 2010. The results are summarized in Table 1.

Now that we’ve established similarities between BPD and software programs, we can apply metrics from software development to BPD.

BPMN Series #16 | ATL001:16

Object Oriented Software BPMN

Class/package Process, sub-process

Method Task

Variable/constant Data object

Comment line Annotation

Interface of a class Set of tasks in a process which send or receive a message flow.

Local data in a class Data objects, related to process tasks by associations. Vastly improved in BPMN 2.0.

Data used by a class Data objects associated with message flows going into tasks.

Method invocation Reception of a sequence or message flow by a task.

Table 1: Similarities between OO software and BPMN

© Copyright 2015 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd.

Metrics for Measuring BPDTaking the above comparisons between software programs and BPD into consideration, many researchers made an attempt to apply software metrics to BPD. In this article, we focus on the research by Gruhn and Laue. Their set of metrics are summarized in Table 2 above, where each metric is defined by their original name in the software field, corresponding name for BPD, as well as usage and significance in both software and BPD field.

As can be concluded from the table above, the software metrics can be applied to BPD seamlessly. In the following chapter we will test the metrics on a basic BPMN model.

BPD Metrics in ActionFor the sake of a practical demonstration of BPD metrics, we used a process model from the official BPMN 2.0.2 specification. It demonstrates a procurement process, as shown in Figure 1.

When applying the aforementioned BPD metrics to our example model, we can conclude the following.

Figure 1: Procurement Process Example

Software Complexity Metric

Corresponding Metric for BPMO Usage, Significance in Software Usage, Significance Applied to PBMO

Lines of code (LOC) Numbers of activities The degree to which a system or component has a design or implementation that is difficult to understand and verify.

Number of activities in the model can be regarded as an equivalent to the number of executable statements in a piece of software. Does not take into account the control-flow.

Cyclomatic number Control-Flow Complexity (CFC) of processes

The cyclomatic number measures the number of all possible control flows in a program. A low cyclomatic number indicates that the program is easy to understand and to modify.

Measures the number of possible control flow decisions in the model. CFC does not take into the consideration the information about the model's structure.

Max. / mean nesting depth

Max. / mean nesting depth

The mean and maximum level of nested control statements (e.g. if, while, for etc.).

Information about structure: the nesting depth of an action is the number of decisions in the control flow that are necessary to perform this action. Can be used complementary to the CFC metric.

Knot-count Number of handles Metric for measuring undesirable jumps out of and into a structured control flow.

Measure of "well-structuredness". A model is well-structured if the split/join constructions are properly nested. Can be used complementary to the CFC metric.

Cognitive weight Cognitive weight (tailored for BPM)

To measure the effort required for comprehending a piece of software. Cognitive weights are defined for basic control structures.

Measures the cognitive effort to understand a model, can indicate that a model should be redesigned.

(Anti)Patterns (Anti)Patterns for BPM Well-documented patterns have been found highly mature and using them helps to improve code quality, understandability and maintainability. If an anti-pattern (commonly occurring solutions to a problem that are known to have negative consequences) is found in the code, this can be regarded as a sign of bad programming.

Can help to detect poor modeling. In particular, finding anti-patterns should be very useful in order to uncover bad modeling style.

Fan-in / Fan-out Fan-in / Fan-out The fan-in and fan-out is measured for every module, where fan-in is a count of all other modules that call a given module and fan-out is a count of all other modules that are called from the model under investigation.

Can indicate poor modularization: if a sub-model of a BPM has a high structural complexity (according to the fan-in/fan-out metric), they will be difficult to use and are most likely poorly designed.

Table 2: Complexity metrics as defined by Gruhn and Laue

© Copyright 2015 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd.

Numbers of Activities

As already mentioned, this is a pretty straightforward metric. In case of BPD, the number of activities in the model is an equivalent to the number of executable statements in a software program. In our case, number of activities metric equals to five, namely: 1) Handle Quotations, 2) Approve Order, 3) Handle Order, 4) Handle Shipment and 5) Review Order.

Control-Flow Complexity (CFC) of Processes

Generally speaking, CFC metrics represent as follows:

number of binary decisions + 1

In our example, we have both AND and XOR gateways, which are calculated slightly differently, based on their respective behaviors. Since all transitions going out of AND gateways must be executed, AND gateways add 1 to CFC. On the other hand, XOR gateways with n outgoing transitions and only one can be processed. For this purpose, every XOR-split with n outgoing transitions adds n to the CFC.

In our case, CFC number is calculated as follows:

2 (one XOR gateway with two outgoing transitions) + 1 (one AND gateway) + 1 = 4

Max. / Mean Nesting Depth

Maximum and mean nesting depth represent the number of decisions, required to complete an action. So, for example, the maximum nesting depth to perform “Review order” Task is 1, since we only have one XOR gateway.

Number of Handles

This metric addresses the correctness of the split/join nesting. It simply counts the number of not well-structured constructs in the model. In our case, the number of handles metric is 0, since all split/join nesting is done properly.

Cognitive Weight and (Anti) Patterns for BPD

These complementary metrics are rather complex, and are used in combination to measure the effort, required for comprehending a piece of software. In our case, we only have one

XOR gateway that is not merging. Consequentially, we cannot measure the number of control flow paths between XOR-split and XOR-join, which is necessary to define cognitive weight. Additionally, finding well defined (anti) patterns in our existing models might also provide an insight of the cognitive weight of our model.

Fan-in / Fan-out

This is a typical modularization of the model, which is supported by all major notations for process modeling. Fan-in represents the count of other modules that call a specific module and fan-out is the count of other modules that are called from a specific model. A large fan-in may indicate small sub-modules, which are doing a simple job, needed by other modules. Modules with a large fan-out, on the other hand, are large modules on a higher layers of the design structure. This translates well to BPD, since a sub-model that has a high structural complexity according to the fan-in/fan-out metric, is most likely poorly designed. In our case, we did not have any Sub-Processes, so fan-in and fan-out metric results to zero.

ConclusionBPMN is the de facto standard for business process modelling, which enables users to model from completely basic to advanced business process models. As such, it provides a rich notation with a well over 100 symbols, covering from basic modelling to advanced execution requirements. Consequentially, it shows the fives signs of complexity and has been reported as such by many business users. Much of research was done in light of exploring the theoretical and practical complexity of the notation and the results consistently indicate that BPMN is indeed a complex notation, especially not understood well by beginners. However, it has been shown that in practice, not many elements are used, displaying that the theoretical complexity is much higher than the practical one. Still, in light of successfully addressing the complexity, Saltzer and Kaashoek proposed four complexity management techniques, namely modularity, abstraction, layering and hierarchy, which will be discussed in following papers.