Many organizations use business process and business decision management to handle their processes and decisions. Therefore, industry and academics have an increasing interest in exploring and developing solutions for BPM. This leads to di erent approaches such as open standards and proprietary process engines which in turn lead to discrepancies in terms of supported constructs, best practices, and much more. This paper assesses the model quality of a BPM project implemented by Allianz Deutschland by investigating how the open OMG Decision Model and Notation (DMN) standard and a subset of the decision management capabilities of the propietary BPM software Pega can be related. Our comparison will cover established DMN concepts as well as latest research results on the standard.
BPM software vendors o er solutions for companies to manage their business processes. Therefore, the requirements for this software are elicited in industrial settings. Consequently, latest research results may be overlooked in practice. We investigate the gap between academic research on decision management and decision management in the BPM software Pega by assessing the model quality of an implemented decision-heavy Pega project.
The analyzed Pega project is part of a larger project used to determine the reimbursement of a health care service led by an insured customer. The goal of this project is to increase the rate of automation of processing customer requests. This should lead to faster processing times which entail higher customer satisfaction. Also, a more comprehensive view on a customer's history is o ered. In general, the project contains a deterministic and stochastic component, both of which execute the processes fully automatically or in some exceptional cases with the help of a case worker.
The deterministic component is implemented based on a subset of the decision management functionalities of the Pega 7 software platform by Pegasystems, a platform for the model-driven development of BPM applications3. The functionalities implemented in Pega include checking the led requests for correctness according to formal and legal requirements and calculating the reimbursement amount according to the tari of the customer. The use case was chosen because of the frequency of decisions in the determination process. The project contains two major ways of representing decisions for which we propose a mapping to DMN concepts to enable a comparison and to assess model quality. Moreover, it contains 65 distinct decision tables, which we analyzed for properties established in the academic decision management community. These properties include table completeness, separation of concerns from the processes and other metrics.
The remainder of this paper is organized as follows. Section 2 introduces the open DMN standard and the proprietary Pega software. In Section 3 we will compare the concepts of decision tables in Pega and DMN. Afterwards, in Section 4 we will present our analysis results regarding the quality of the Pega project's decision tables. Subsequently, in Section 5 we turn to the other method of representing decision logic in the project|when-rules|and show how they are related to DMN. Finally, in Section 6 we will conclude with the most important insights and lessons learned from this project. 2
This section brie y introduces the open DMN standard for designing and implementing decisions and the proprietary BPM software o ered by Pegasystems. 2.1
Decision Model and Notation
The Decision Model and Notation [
DMN allows to design decisions on two levels, called decision requirements and decision logic level. Decision requirements diagrams are displayed as a directed graph with di erent kinds of nodes, and edges representing dependencies (or requirements) between these nodes. An abstract requirements diagram consisting of the two basic node types is shown in Fig. 1. The rectangular nodes labeled D1 and D2 represent decisions that need to be taken, whereas the elliptic nodes show what input data is necessary to make those decisions. Note that a decision's input can also be another decision, e.g., D2 is a sub-decision of D1. Additionally, the decision elements are associated with decision logic that prescribes how the decision must be taken, i.e., which combinations of input values lead to a speci c output value. The most common and standardized way of representing decision logic is through decision tables, discussed in more detail in Section 3. 4http://www.omg.org/spec/DMN/
D1 D2
In1 In2
In3 With the Pega platform, the American software company Pegasystems o ers proprietary software for business process management, case management and decision management. It is considered a leading vendor of BPM software since eleven years.5 Business processes in Pega are designed in a top-down manner. First, one de nes a case, which is a piece of work that delivers a business outcome. This case is then structured into stages, representing high-level milestones of that case. Lastly, stages can be implemented with process ows, representing operational steps to accomplish the milestone of the respective stage. To implement the decisions required to make during process execution, Pega o ers a variety of decision making functionalities. The most common are when-rules and decision tables, but there are also other concepts such as decision trees, predictive analytics, and prioritization. The concepts used in the project of our investigation are decision tables and when-rules, which are described in more detail in Sections 3 and 5, respectively. 3
This section investigates the relation between DMN's and Pega's decision
management concepts regarding decision tables. This enables us to compare the
two approaches. We focus on decision tables since they are standardized in the
speci cation [
Both Pega and DMN allow decision logic to be represented as tables, consisting
of rows and columns. Each column is associated with an input or output variable,
and each row denotes a rule of how to combine certain values for the input variables
to arrive at a value of the output variable(s). Given this general description of
decision tables, a mapping from Pega to DMN might appear straightforward.
However, there are some fundamental di erences in design philosophy that need
to be considered, as we will we discuss later in this section.
An example of a Pega decision table taken from the investigated project is
shown in Fig. 2. As mentioned in the previous paragraph, Pega and DMN agree
on the basic way of designing decision tables. Both approaches also allow to
specify how to deal with overlapping rows, i.e., rows that match for the same
inputs. In Pega, the rules can be evaluated from top to bottom until the rst
matches whose output is then returned, or all rules are evaluated and the outputs
of all matching rules are returned. These options can be directly mapped to
DMN's rst and rule order hit policies, that return either the output of the rst
matching rule, or the outputs of all matching rules in order [
An important di erence between Pega and DMN is that Pega does not allow to specify the set of possible values the input and output variables of the table can take on. Rather, it assumes that only those values that are actually used in the table are the values that the variable can assume. For example, for the input RECHPRUEERG it is not clear whether or not 5400 and 5500 are the only admissible values. DMN, however, allows to specify a set of possible values for the variables as part of the column de nition for that variable. This distinction is important when checking the completeness of the table, as discussed in Section 4.
The other major di erence between Pega and DMN is that the former allows to de ne decision tables that are not free of side e ects. This means that it is possible to design tables that directly act on the state of the system or the process instead of just representing a function whose sole purpose is to return a set of outputs given a set of input|a constraint that DMN requires. Fig. 3 shows such a non-functional Pega table. As you can see the result column of this table does not just set a value but calls the external function setBusinessDataValue() to in uence the state of the system outside of the table itself. 4
The Pega project of our investigation contains 65 distinct decision tables that
are evaluated in 143 di erent situations. We analyzed these tables to assess the
project's model quality regarding decision management and to compare it to the
principles of decision management according to DMN. Therefore, we examined
established correctness metrics such as table completeness and output coverage.
Furthermore, we explored how often concepts are used that are not allowed in
DMN such as non-functional decisions that do not only depend on the inputs
but also on the system's state.
A decision table is considered complete if for every possible combination of input
values at least one rule is matched [
According to DMN, however, this table is not complete, since given that RECHPRUEERG is of type integer, there can be many more values for this variable than in the table. We applied both completeness notions to the project's 65 decision tables and found out that according to Pega 48 (74%) of the tables are complete, but according to DMN only 5 (8%), as visualized in Fig. 4. 4.2
Usage of the Otherwise-Rule As mentioned above, Pega allows the designer of decision tables to specify an otherwise-rule that is the last rule of the table, and that only matches when none of the previous rules have matched. We analyzed all tables of the project that contain such an otherwise-rule to nd out in which situations they are used. For example, one might assume that they are only used in error situations, such as in in the table in Fig. 2, where the last rule returns an Error value. However, we also
5 # DMN complete
48 # Pega complete found tables such as the one in Fig. 5 where the otherwise-row is used to return a \normal" decision result. Consequently, there seem to exist inconsistencies regarding the usage of the otherwise-row and it is unclear in general whether or not its behavior is intended and expected to happen or whether such a situation can actually never occur.
Having analyzed the decision tables of the project regarding this matter, we found out that in 36 (55%) of the cases, the otherwise-row returns an unexceptional result, in 21 (32%) it returns an error value and in 8 (13%) cases the result is unde ned. This is summarized in the pie chart in Fig. 6. 4.3
Overlapping and Unreachable Rules As explained in Section 3, given a set of inputs, Pega will evaluate the rules of the table from top to bottom. If the rules of the table overlap, depending on the con guration, only the rst matching rule will be considered, or all matching rules. This means that there may be cases in which a rule is overlapping with another (previous) rule and will thus never be executed because the previous rule is always matched rst.
In total we found 52 overlapping rules, 14 (27%) of which can never be executed because of the reasons explained. While unreachable rules are not unexceptional error undefined necessarily harmful, it may be the case that the modeler did not recognize that the rule will never be executed and thus the table will never return the respective value although it is supposed to in certain situations. Pega does not o er an automatic check regarding overlapping and unreachable rules. The results are summarized in the chart in Fig. 7.
60 50 40 30 20 10 0
52 # Overlapping rules
14
# Unreachable rules
When integrating decision tables with process models that act on the outcome of
the table, it must be ensured that the process can actually handle every possible
output. Otherwise, a deadlock will occur. To prevent such a situation, the output
coverage criterion can be applied [
The analyzed Pega project contains 86 processes like the one in Fig. 9 which
calls a decision table from a split gateway and then processes the output with
two or more outgoing edges following the gateway. Out of these 86 processes, 26
(30%) violate the output coverage criterion and may therefore lead to deadlocks.
As explained in Section 3, Pega allows to design tables that are non-functional
or side e ect free. This means that Pega tables are not guaranteed to behave
like a function, which given a speci c input will always return the same output
and will not change the state of the system in any way. In the analyzed Pega
project we found that 13 (20%) of the 65 tables are non-functional. One of these
tables we already showed above in Fig. 3. Decision tables like these violate the
principle of the separation of concerns of process and decision logic, leading to
lower readability, maintainability and changeability [
When taking a closer look at the table in Fig. 3, one can see that the output di ers only by the rst parameter with which the function setBusinessDataValue() is called. Tables like these can be easily refactored into functional tables that have the same decision logic but are side e ect free. Table 1 shows the refactored table as a DMN decision table. The table now only outputs the parameter for the function call. The call itself should then be done by the process that receives the decision result. 5
Besides decision tables, very many decisions of the analyzed Pega project are implemented using when-rules. When-rules in Pega are used to represent simple U Boolean decision logic. A when-rule consists of one or more variables connected by logical or and and operators. Each variable represents a Boolean expression, such as a string or integer comparison, a boolean value, or another when-rule. Fig. 10 shows an example of a Pega when-rule from the use case, which consists of three variables, A, B and C. The truth values for A and B are each determined by other when-rules, while C is given by a comparison testing for an empty string. At the bottom of the gure, you can see the Boolean expression that must be ful lled in order for the when-rule to be true: (A or B) AND C.
Table 2 shows the resulting DMN decision table. The derived DMN decision table is shown in Fig. 10. The mapping underlying this derivation is straightforward, as discussed in the following. The number of input columns of the table is determined by the number of variables of the when-rule, while the number of rows is given by the number of disjunctions in the when-rule. Therefore, each row of the decision table is an assignment of truth values to the variables such that the when-rule becomes true. The table has a rst-hit policy, meaning that the rows are evaluated from top to bottom until one becomes true. Therefore, if none of the conditions of the when-rule are ful lled, the last row of the table will return false, irrespective of the inputs.
Since the variables A and B each refer to another when-rule, their values are also determined by decision tables whose outputs will be used as inputs for the table in Fig. 2. This leads to the DMN decision requirements diagram (DRD) shown in Fig. 11. In general, simple DRDs consist of two elements, namely rectangular decision shapes and elliptic input data shapes. The decision shapes are associated with decision logic such as a decision table and the input data shapes correspond to the inputs that are required by the decision logic.
Hence, in the diagram in Fig. 2, the top-level decision is associated with the decision table in Table 2, which was derived from the when-rule in Fig. 10. The top-level decision has three inputs, corresponding to the variables A, B and C of the when-rule. Since A and B each refer to another when-rule, they are also represented as decision elements. These decisions are associated to the decision tables derived for these when-rules, the details of which are not shown here. All other elements of the DRD are \primitive" inputs and therefore represented as ellipses.
isGOZ (A) aezus_art
ChebcekFrRoerFceReoNwum((A or B) and C) de1_aezusar tnr_erm (C) isGOAE (B)
The visual presentation of decisions and their dependencies in DRDs allows to introduce an abstraction from the implementation. This means that dependent decisions implemented separately can be brought back together in the DRD. In the same regard, DRDs can support the implementation of decisions by disclosing their dependencies. With such information made obvious, duplicating decision logic can be avoided. 6
In this paper, we presented our results from a model analysis project conducted on an IT project of Allianz Deutschland developed to improve the automatic reimbursement of health care service bills. We showed that there is a di erent understanding of model quality and correctness in the academic and the industrial BPM community. Still, both worlds agree on the fact that BPM is a useful concept to achieve business goals in an organized manner.
Through working with Allianz' Pega project we got valuable insights on working with industrial BPM projects. The most important lesson we learned is the necessity of domain knowledge. Without a certain amount of domain knowledge it is not that easy to understand the processes and decisions implemented in the system. This is especially true when labels of activities or decision inputs/outputs are based on domain-speci c vocabulary and abbreviations. Moreover, only a few simple concepts for designing and implementing decisions o ered by Pega are used in the project. These are decision tables and when-rules. When-rules are even simpler ways to express decision logic than decision tables. They consist of one or more variables connected by logical or and and operators. However, Pega o ers other, more advanced means of specifying decision logic such as decision trees and predictive analytics. Yet, these concepts are not applied in the project at hand, hinting that they are not really necessary to implement decision management applications.