Business rules have reached considerable attention from todays businesses. Numerous standards such as the Decision Model and Notation (DMN) have been introduced and adapted in practice in order to model company decision logic. However, standards such as DMN often make strong assumptions about respective decision models, e.g. that of complete information. Here, we see a gap between the solutions proposed in research and the actual industry adaptation. As some assumptions in research seem unfeasible in practice, companies currently face the problem of inconsistent business rules and decision models. Here, companies need to be supported in detecting, understanding and resolving inconsistencies. In this work, we report on current problems for Business Rule Management in the eld and present an approach to analyze actual process executions and corresponding decisions for inconcistencies.
Business rules (BR) are an important counterpart to Business Process
Management (BPM), aimed to ensure that business processes comply to norms and
regulations [
Problems of BR Research in the Field
DMN1 allows to represent business rules in so-called decision tables. Here, columns
are used to denote the input to a rule, resp. the output which can be concluded.
The rows of the decision tables relate to individual business rules. Contrary to
the usage and assumptions envisioned in academia, we identify the following
major problems for companies currently seeking to implement DMN.
1 https://www.omg.org/spec/DMN/About-DMN/
{ Redundant Information. Decision models may contain redundant
information. This could for instance be duplicate rows or columns, distributed
over multiple tables. Based on own experiences gained in industry projects,
such redundant rows and columns can in fact occur in collaborative settings,
contrary to the guidelines of the DMN standard.
{ Incomplete Information. DMN models work under the assumption of
complete information. However, decisions in practice can often be dependent
of underlying domain knowledge [
Supporting Business Rule Management
There is a broad consensus that the management of above problems is a current
issue for BPM [
Our discussion is based on the following main example in Figure 1. Figure 1 shows an exemplary ordering process. We assume that a company uses a process engine to handle this process. A process instance is triggered by a new customer input, i.e. instance data. This customer input is now processed in the context of the shown decision logic. For the given process instance, i.e. the route of the customer data through the process model, every rule which was used for decision making relative to the resp. instance data is highlighted in red. One can observe that there are multiple errors in this decision logic. The FreeShipping table contains contradictory information. Also, the conclusion in the Eligibility table contradicts external domain knowledge. Such problems make it impossible for companies to utilize decision logic as intended. Still, it is essential for companies to warrant a correct process execution. In this report, we therefore show how our approach helps companies to detect and analyze such inconsistencies, fostering correct and compliant business process execution. zess
Check Eligibility
1.2 Process Logic CouInDt:r1y: ES ...
CouInDt:r1y: ES ... dThoeetoscSonpmoatpisnahnipy dThoeetoscSonpmoatpisnahnipy ra rb rc rd
Region Code
Input Country
USA
ES Eligibility
Input Region Reg1
Reg2 Free Shipping
Input
Country re ES rf ES 1.3 Decision Logic rb: ES → Reg2 rd: Reg2 → Eligible re: ES → freeShipping rf: ES → not freeShipping Output Region Reg1 Reg2 Output Eligible
True True
Output Free Shipping
True False
1.4 Domain Knowledge
In order to allow for an analysis of problems such as in Figure 1, a uni ed
representation of business rules and domain knowledge is needed. As a design choice,
we consider the Formal Contract Language (FCL) [
A1; : : : ; An ! B (1) where A1; : : : ; An is the premise of the rule, B can be concluded given that the premise is satis ed, and r is an identi er. Please note that FCL also allows to model defeasible rules, superiority relations and other normative rules, e.g. to express deontic constraints. For simplicity, we will not revisit the syntax of FCL in greater detail and will continue our discussion on the basis of introduced expressivity. Please see Governatori and Maher (2017) for further description.
FCL can consequently be used to represent business rules [
This FCL representation of business rules can subsequently be enriched with domain knowledge. To this aim, background domain knowledge can be captured in FCL, allowing to further de ne the semantics and interrelations of rules.
d1 : ES ! not Eligible A scienti c eld concerned with the analysis of inconsistent information is the eld of Inconsistency Measurement, cf. Grant and Martinez (2018). Here, a central object of study are quantitative measures, which allow to assign a numerical value to (elements of) a rule base, with the informal meaning that a higher value re ects a higher degree of inconsistency. These measures foster the possibility to identify inconsistencies in rule bases, i.e. pinpoint the exact causes, and quantify the amount of blame, that an individual part of a rule base carries in context of the overall inconsistency. Our approach utilizes these quantitative measures to analyze the consistency of decisions. Here, our proposed application of Inconsistency Measurement results in Business Rules Management provides new forms of quantitative insight for companies. Figure 4 shows the approach architecture.
Analysis For Instance t n e m e g a n a
M
Decision
Solver Measures Ranking Instance Data Rule Execution Trace
Domain Knowledge
Legend:
Input
Our approach is geared towards individual process instances. The process logic of a given process instance is de ned in the process layer, manifested by the process model. This process layer in turn relies on a business rules layer, governing process execution. The core of our approach is a uni ed execution representation, comprising instance data, domain knowledge as well as all decisions made relative to the process instance. The latter are all business rules which were executed in the context of the respective process instance. These executed rules are stored in a so-called rule execution trace. To recall, an example of a rule execution trace is shown in Figure 1.5.
Our approach then allows to analyze this execution representation for inconsistencies. In result, companies are supported in monitoring consistent and compliant business process execution. The inconsistency analysis is based on results from the eld of Inconsistency Measurement. Applying these results allows to support companies in detecting and quantifying potential inconsistencies, promoting an understanding of inconsistencies in process execution. The analysis layer comprises one component for nding inconsistencies, and a second component analyzing and ranking the resp. inconsistencies, introduced subsequently. 3.2
Finding Inconsistencies Let an FCL rule base
B = (F; R) (2) where F is a set of facts and R is the set of all rules. Let L(B) be the set of all literals appearing in B. We de ne inconsistency of a rule base B as logical inconsistency, i.e. there is support for contradictory outcomes A and not A at the same time.
De nition 1 (FCL Inconsistency). An FCL rule base B is inconsistent, if there exists an l 2 L(B), s.t. B entails fl, not l g.
To clarify, an FCL rule base is inconsistent if there is a contradiction between facts or active rules. Then, given a rule base B, the minimal inconsistent subsets MIS of B are de ned as
MIS(B) = f B0
B j B0 is inconsistent and minimal g: (3) This de nition of inconsistent subsets can be used to business rule bases. nd inconsistencies in ES rb: ES → Reg2 rd: Reg2 → Eligible d1: ES → not Eligible
MIS1 re: ES → FreeShipping rf: ES → not FreeShipping
MIS2
Fig. 5. Minimal Inconsistent Subsets for Figure 1
We recall the example from Figure 1. An analysis of the execution representation for this example yields two minimal inconsistent subsets, visualized in Figure 5 as MIS1 and MIS2. To solve for these MIS, existing reasoners such as SPINdle2 can be utilized. In this way, our approach allows to exploit results from the eld of logic programming to detect inconsistencies and support companies in decision management. Next to pinpointing problems, quantitative measures to further analyze these inconsistencies are presented in the following. 3.3
Culpability Measures for Assessing the Causes of Inconsistency
So-called culpability measures allow to analyze the FCL rule base from an
element perspective [
C : B
E ! [0; 1) (4) 2 http://spindle.data61.csiro.au/spindle/ which assigns a non-negative number to a mapping of an individual element to a rule base, and can thus assess the culpability that an individual element represents w.r.t. the rule base.
An example is the so-called cardinality based culpability measure Cc [
X M2MIS(B)s:t: 2M jM j 1 : This measure counts the number of minimal inconsistent subsets that an element belongs to, normalized by the cardinalities of the respective subsets. Applying the Cc measure for the MIS shown in Figure 5 results in the following quanti cation: Note that we only compute values for rules, as we focus on an assessment of modeling errors and inconsistencies between rules.
An assessment such as in (6) provides a quanti cation that can be used as
a driver for inconsistency resolution [
De nition 2 (Culpability Ranking). Let a rule base B and a culpability measure C, then de ne the culpability ranking over all rules ri 2 B via hr1; :::; rni, where C(B; r1) ::: C(B; rn).
This ranking sorts all rules in B based on their culpability value. Thus, the user can be presented with a prioritized list of which elements to attend to. Given the example in Figure 1 and the respective values computed in (6), this leads to the following culpability ranking:
hre; rf ; rb; rd; d2i 4
Key Learnings In this report, we presented an approach to analyze the consistency of all decisions made throughout process execution. In case of inconsistent decisions, the company is provided with quantitative insights as a basis for an informed re-modeling strategy.
The rst key learning is that the plausibility of assumptions made in BPM
research should be carefully examined. The adaptation in industry may be subject
to di erent settings, counteracting a correct implementation. This is supported
by a wealth of recent studies analyzing problems in Decision Management [
A second key learning follows Sadiq and Governatori (2015). Those authors state that businesses need to be aided with systems to provide capacity to manage business rules. As a manual analysis is unfeasible in practice, BPM research needs to further focus towards automated approaches helping companies to understand the causes of problems. To this aim, we showed that measures from the eld of Inconsistency Measurement can help companies with such an analysis.
Last, an important key learning gained from this project is the necessity of domain knowledge. Large-scale collaborative modeling is a challenging task for companies. Here, domain experts have to work closely with business rule engineers in order to create plausible decision logic. To this aim, the insights yielded by inconsistency analysis can be used to bridge the gap between these expert groups, fostering business process improvement and sustainable Business Rule Management.