Keywords

1 Introduction

The modelling of business processes and business rules has been an important topic of Information Systems and Computer Science research over the last two decades [1–3]. Traditionally, business rules are modelled in a standalone fashion using rule modelling notations. In more recent years, as new modelling languages and methods have been developed [3], researchers have argued that business rules can be modelled independently or integrated into business processes [4, 5]. Several researchers have motivated integrated modelling of business processes and business rules [6, 7]. Such integration is posited to result in improved model understanding, increased interoperability capacity, better change propagation of new requirements and increased capacity for compliance management [8–10]. Previous research has made several contributions towards this end through analyzing the representational capacity, deficiency and overlap of process and rule modelling languages [11], with a view towards their integrated use. Several initial approaches for the integration of business process models and business rules have also been proposed [12].

Empirical findings [13] indicate that process designers often have the need to represent in a process model business rules that go beyond control flow rules. Although all process models contain some business rules in the way of control flow, other rules may be, and often are, documented separately. Representing process models graphically without all relevant rules or operational constraints can result in flawed decision making and non-compliant process execution. It is also a roadblock to achieving a holistic understanding of the process, and thus affects shared understanding of requirements between stakeholders. In turn, incomplete requirements lead to incomplete system implementation, in which business processes might be executed without necessary constraints and monitoring mechanisms and, thus, might lead to high costs due to operational and compliance risks.

We argue, along the lines of [3], that there are situations under which a business rule is better modelled independently from a business process model, and situations under which it is more appropriate to integrate the rule with a business process model. It follows then that an important aspect of integrated modelling is the understanding of such situations and how they influence business rule representation. While the decision in regards to how a rule should be modelled is not a straightforward one, little guidance exists that can help modelers make such a decision. This shortcoming results in fragmented and inconsistent business process and rule models. In our earlier work [14] we identified the factors that are likely to affect such decisions. In this paper, our aim is two-fold: (1) to empirically evaluate the factors; (2) to identify guidelines for better business rule modelling decisions.

This paper unfolds as follows. The next section provides an overview of business process and business rule modelling, as well as prior efforts to identify factors that influence integration in the context of modelling. Section 3 overview the methodology used earlier for factor identification, and presents the methodology for empirical evaluation of the factors. Section 4 summarizes the factors and Sect. 5 discusses the empirical evaluation. Section 6 provides an empirically-grounded discussion on how these factors should affect rule modelling. Finally, we summarize the results of our study in terms of the evaluation results and provide some guidelines for modeling of business rules. We conclude the paper with a discussion of the findings and future outlook.

2 Background Concepts and Related Work

A business process model is a structured collection of activities that accomplishes a specific goal that will create value for an organization. Such structures also involve business rule models, which describe the constraints and requirements guiding and controlling the behavior of business activities, and can be integrated into related business process models or modelled independently. Business process modelling and business rule modelling both focus on creating a representation of the organization’s current and future practices. They are complementary approaches as they address distinct aspects of organizational practices. However, the two approaches evolved separately over the last few decades and failed to integrate into a more powerful approach.

Three types of methods for integrated business process and rule modelling have been developed in literature viz. annotation, encapsulation and extension [12]. Annotation is the use of additional textual elements to represent other aspects that are beyond the representational capacity of the selected modelling language. The textual elements are typically attached to graphical symbols within the process model to represent extra information. Encapsulation is the embedding of related business rules into a specific element in business process models. The embedded rules can be folded and unfolded, thus allowing users to easily switch focus between the overall structure and detailed parts of a process model. Extension either creates new elements or combines existing meta-elements from other languages to increase the representation capability of the underlying language to represent both business activities and business rules. Figure 1 is a simplistic illustration of a business process model with rule integration, using annotation, encapsulation, and extension methods.

Fig. 1.
figure 1

Illustration of a business process model with rule integration

Full size image

Although the benefits and methods of integrated business rule modelling have been well studied as stated Sect. 1, there is a paucity of research that examines or consolidates factors that are relevant for business process model and business rule integration. zur Muehlen et al. [3] were the first to argue the need for guidelines to inform such integration. They identified five potential factors expected to influence the representation of a business. However, without proper evaluation, the validity of each factor cannot be fully established. Investigation and validation of each factor’s decision-influence on the representation of a business rule is also needed, which is the aim of our work as presented in the following sections.

3 Methodology

Our study involves two phases, viz. factor identification and factor validation. The first phase is based on a review and analysis of existing literature and is documented in [14], while the second is an empirical study of business rule experts in the form of academics and practitioners. In the following sub-sections, we outline our methodology.

3.1 Factor Identification

In our earlier work we embarked on a systematic identification of factors [14]. To identify these factors, we conducted a systematic literature review based on a comprehensive set of well-regarded Information Systems and Computer Science journals and conferences (see www.aisnet.org and www.core.edu.au) published between 1990–2013, a period of time after the initial proposal of integration of the two approaches [2]. Our data set consisted of 43,021 full-text articles (see Table 1). Each article was prepared (with OCR) for a full-text search. Subsequently, a full-text search was conducted using the term ‘business rule’. We regarded a paper as relevant if the keyword ‘business rule’ occurred 3 times or more within the body of the text and only selected those papers for the next round of analysis that met this criterion. Based on this elimination process, 255 relevant papers were identified. For each of the 255 papers, we read the abstract, the introduction of the paper, and each paragraph where the term “rule” occurred to determine if the paper was relevant to our purpose. A paper was identified as relevant if a characteristic of a business rule like change frequency, reusability or impact is discussed or mentioned in the paper. This step resulted in the identification of 78 papers.

Table 1. Dataset of 1990–2013 publications
Full size table

The set of 78 relevant papers was then read in full and manually coded with a dedicated coding protocol implemented via an Excel spreadsheet. The coding protocol was designed and agreed by the three researchers after an initial coding of several articles to refine the protocol and contained a field for a factor, the title of the paper, context, and other comments. One researcher carried out the initial coding exercise through iterative coding of the papers to identify all relevant factors and then refined the result with the two researchers. The refinement included (1) selecting business rule characteristics that had the potential to be factors and excluding unrelated characteristics, (2) identifying and clustering synonymous factors and (3) selecting a representative label for each factor and clarifying its definition. The result was refined over three iterations until all three researchers were satisfied with the selection and definition of each factor. Twelve factors were identified in total through this process, as summarized in Sect. 4 and detailed in full in [14].

3.2 Empirical Evaluation

To validate the identified factors for relevance and investigate their relative importance, we designed an empirical evaluation instrument. The authors of the 78 papers relevant for the factor identification were the target participants of the empirical evaluation. These academics and professionals were invited to participate in an online survey through invitation emails. In the invitation email, participants were informed about the background and nature of the study, for which no incentives were offered. We used QualtricsFootnote 1 as the platform to deliver the survey and collect data.

The survey was designed, pilot-tested and revised through two iterations. In the first round of pilot testing, 3 PhD students with knowledge of conceptual modeling were asked to complete the survey and provide feedback on clarity of factor definitions and questions. In the second round, the revised survey was pilot-tested with 2 PhD students and a Master student by research, with knowledge of conceptual modelling and an international expert in requirements modelling. The revisions as a result of the pilot studies included changes to the definitions of factors and to questions so as to improve clarity as well as research rigor (e.g. randomization of questions was introduced through the pilot study). With our finalized survey instrument, we collected (1) the importance of factors, (2) an importance ranking of the factors from each participant and (3) expert opinions on how rules should be modelled given each factor.

We sent invitations to 112 authors of the 78 papers, and received 35 responses in total, of which 13 were incomplete and had to be removed. Thus, we received 22 usable responses, which represents a response rate of 23.08 % when calculated as responses per paper. While low, it is hard to achieve high response rates in empirical research and many consider any response rate of approximately 20 % to be usable [15–17].

4 Business Rule Modelling Factors

In total, twelve factors were identified. For further discussion of the factors, and the sources/papers in which they were identified, please refer to [14]. In the following we provide as a summary the definition of each factor, with arguments collected from the literature review. Only the definitions (in italics) are used in the survey and the argument statements or examples are excluded to avoid possible introduction of bias in the responses.

Accessibility. Accessibility refers to the user’s need to view and manipulate a business rule. If a stakeholder can easily view or manipulate a rule in a format that is suitable to his or her need, then the rule has high accessibility, otherwise, the rule has low accessibility. Making business rule repositories accessible to stakeholders whenever required, as well as in a format that is suitable to their needs, is a basic requirement of information systems [18]. Separating the rules can make rules easily accessible to business users, and potentially reduce the complexity and waiting times in making changes required in response to specific external or internal changes in requirements [19].

Agility. Agility refers to how quickly a business rule can be adapted to a change. Rate of change deals with how frequently the rule needs to be changed, and agility deals with how long will it take for each change to be modelled in a rule. Some business rules are required to take effect immediately to ensure the agility of the system [19]. Similarly, there can be others that may not have strict constraints on time of initiation [20–22].

Aspect of Change. Aspect of Change refers to the component of the rule that can be changed. The components of a rule that could change are the trigger condition, the reaction, or the values of parameters, as well as rule phrases and design elements [23]. Depending on the component, the change might be simple or complex. While a graphical process model may expose some simple configuration to business users, more complex business rule changes may only be possible at a deeper level that may need a business rule language representation.

Awareness of Impact. Awareness of Impact refers to how comprehensively the implications of a business rule, or its revisions, are understood. Some business rules have a direct and clear impact, while other rules may have an indirect or unclear impact. Thus, the impact may or may not be clear to the stakeholders. Business users may have to bring to bear their additional external knowledge to understand the implications of a business rule [24]. If the impacts of a business rule are not comprehensively understood, e.g. a change in one department’s business practices is necessitated by a change in another department and the effects cannot be safely predicted, then the deployment and implementation of the rule may need justification or re-engineering in the future [3]. The advantage of rule models is “easier and faster implementation in case adjustments needs to be made” [3].

Complexity. Complexity refers to the level of difficulty in defining or understanding a business rule. Some rules are simple and some rules can be complex in nature. Thus, the clarity and simplicity of business rules may differ based on the chosen representation [25]. Certain kinds of business rules cannot be clearly expressed in a business process modelling language due to language representation limitations, while others may be easily modelled as a standalone rule due to the more precise representation capability [26].

Criticality. Criticality refers to the importance of the rule. Violation of critical rules can lead to severe consequences for the organization, while violation of non-critical rules may be less severe. Integrating a business rule into a business process model can ensure that the business rule is implemented enterprise-wide. A standalone business rule, on the other hand, has a risk of being overlooked when users perform manual tasks relying on process models as guidelines for operations.

Governance Responsibility. Governance Responsibility refers to who ensures that business activities are in accordance with business rules. Rules can be governed automatically by programs/systems, or manually by humans [27, 28]. If the business rule is to be checked automatically in the system, machine readability and execution will be a basic requirement, while context availability and user-friendly representation will be more important if the rule is to be checked by a human.

Implementation Responsibility. Implementation Responsibility refers to who is charged with implementing or updating the business rule. Both business users and technical users could be responsible for the implementation of a business rule. Business users generally have the configuration responsibility over business rules in business rule repositories [3] and may not have process modelling expertise, whereas technical staff or the IT department may be responsible for the implementation of business processes [29].

Rate of Change. Rate of Change refers to the frequency at which a business rule requires modification. Business rules can change in response to changes in regulations and policies. Frequent business rule change requires mechanisms that support easy modification and propagation. It is possible that frequently changed business rules could be modelled in a stand-alone fashion, rather than being integrated into graphical process models where they could be labor-intensive and cumbersome to update [30], while stable business rules could be integrated into a business process model.

Reusability. Reusability refers to the potential for a rule to be used in new contexts. An existing business rule may be adapted or modified to fit new contexts and scenarios to reduce the resources required in developing new rules. Scattered [26, 31] and duplicated [23] rules make it difficult to evaluate and maintain the integrity and consistency [32, 33]. If a reusable business rule is integrated into a business process model, the development, testing, and maintenance efforts may be increased when that rule changes and requires update [23, 34]. On the contrary, modelling such a rule in a business rule notation and storing it in a business rule engine could ease maintenance efforts.

Rule Source. Rule Source refers to the origin of the business rule. Rule sources could be external or internal – e.g. laws and regulations or internal policies and standards. Requirements defined by external regulatory bodies can be “critical to the organization, while being outside the scope of their control. Particularly when the changes pertain to compliance with regulations” [3]. According to [3] modelling external business rules as part of a business process ensures that an audit trail is created, and thus facilitates compliance management and audit.

Scope of Impact. Scope of Impact refers to the breadth of the impact of the rule. The impact of a business rule can be focused on an activity, an entire process, a department or the entire organization [3]. If an organization-wide business rule is integrated into a large number of business process models any update to the rule will lead to a change in a large number of models, thus triggering re-work and risk of inconsistency [3, 35]. If the same business rule resides in a business rule repository, the update effort will be limited to an individual business rule instance, while being linked to potentially several process models.

5 Empirical Evaluation

In this section we present the empirical validation of the twelve factors. The main aim of the empirical study was to derive a ranking of factors based on their perceived importance by experts and capture expert indications as to how these factors affect modelling business rules in practice. To this end, in the following we first present a discussion of the relative ranking of the twelve factors, considering also the level of expert agreement in their ranking lists, and then explore the indications as to how these factors affect modelling of business rules.

5.1 Demographics

Our survey was aimed at academics and practitioners who authored the 78 papers relevant to this study. Table 2 shows that the overall business process modelling experience of our participants is higher than in other similar studies, e.g. [13]. However, the experience of standalone rule modelling is slightly lower than that of processes modelling, indicating that less participants are familiar with standalone rule modelling.

Table 2. Participant demographics
Full size table

5.2 Factor Importance

To distinguish the relative importance of each factor, we asked the participants to select at least 5 most important factors and rank them according to their relative importance. As current top-k ranking comparison algorithms require a constant k across all rankings [36], only the top-5 factors are calculated in the ranking and agreement analysis. We note that one participant selected 6 factors and two participants selected 7 factors in this question, but these factors are already in top 50% of factors based on importance (see Table 5).

To calculate consensus between the participants, the rankings provided by all participants are aggregated into a single score. Consensus ranking [37] is used as it can help minimize the overall distances between rankings. Since this is an NP-Hard problem, some relaxed methods are used to find the approximate closest distance [37]. We adopted the classical positional Borda’s method [38] to calculate the aggregated ranking, which is well adopted in literature [37, 39].

Following this method, for a factor which ranked i <=5 in an individual ranking, we assign 5-i points to the factor. For a factor which is not ranked within the top 5, we assign 0 points. The total points of each factor are a sum of the factor’s points in each individual ranking.

As shown in Table 3, agility is ranked as the most important factor, with 42 points, and criticality is a close second. The factors rate of change and reusability are jointly ranked third, with 37 points. Accessibility, awareness of impact, complexity, governance responsibility and scope of impact follow in that order. The lowest ranked three factors are found to be those of aspect of change, implementation responsibility and rule source.

Table 3. Aggregated ranking using Borda’s method
Full size table

While Borda’s method allows us to identify the relative ranking, it is important to determine whether there is an adequate level of agreement between experts’ individual rankings. The concordance of the rankings is an indicator of such agreement. We use compactness, defined in [40], to calculate the degree of agreement as suggested in [41].

$$ compactness = \sqrt {\frac{{\mathop \sum \nolimits_{i = 1}^{m} \mathop \sum \nolimits_{j = 1}^{m} \left( {r_{i} - r_{j} } \right)^{2} }}{{m\left( {m - 1} \right)}}} $$
(1)

Normalized compactness ranges from 0 to 1, where 0 means the ranking lists are identical with each other (i.e. participants agree with each other) while 1 means they share nothing in common. Since for normalized concordance, 1 represents total agreement and 0 represents total disagreement semantically, concordance has an inverse relationship with compactness. Thus we use 1 – compactness to measure concordance.

In formula (1), m is the number of factors, compactness is the average coupled distance between all factors, and r i – r j is the distance between two rankings r i and r j . Weber et al. [36] provide a detailed classification of ranking distance measures in different dimensions according to the nature of the rankings. The dimensions are (1) conjoint and unconjoint ranking, (2) tied and untied ranking and (3) partial and full ranking. In our case, each ranking is selecting top-5 factors from all 12 factors, thus the ranking is a partial and conjoint ranking without ties. So we adopt the widely used Kendall’s tao method introduced in [42] to calculate r i – r j . Kendall’s tao distance is calculated using formula (2). x, y are elements in the set P which consists of elements in ranking r i and r j . \( p \) is assigned ½ as the neutral approach. The detailed algorithm to calculate \( \bar{K} \) is described in [42].

$$ r_{i} - r_{j} = \sum\nolimits_{{\left\{ {x, y} \right\} \in P\left( {r_{i} , r_{j} } \right)}} {\bar{K}_{i,j}^{\left( p \right)} \left( {r_{i} ,r_{j} } \right)} $$
(2)

Combining formulas (1) and (2), the compactness of all the rankings is 0.36, resulting degree of agreement among the participants’ rankings is 0.64, which is deemed acceptable [41]. In addition to the compactness of all rankings, we can reason about the compactness, or agreement, of the importance of each individual factor by considering the standard deviation of its ranking position. Accordingly, Table 3 also shows the standard deviation for each factor to provide an indication of the level of agreement on that factor.

6 Factors Informing Business Rule Modelling

In the first part of our empirical analysis we were able to identify a relative ranking of the factors. While this ranking provides an indication as to which factors should be considered when modelling business rules, it does not provide any guidance as to how a rule should be modelled given a particular factor. To carry out such an analysis we must first determine the set of factors that had consistency of responses in terms of their effect on business rule modelling. Thus, we first distinguish between ‘affecting’ factors and ‘non-affecting’ factors. A factor is considered to be non-affecting if there is no significant difference in expert opinion as to how that factor affects modelling. For example, experts are asked to indicate for the aspect of change factor, which has two circumstances: simple and complex, if the rule (to be changed or added) should be modelled in an integrated manner or modelled separately (see Table 4).

Table 4. Vote distributions for non-affecting factors (When a participant indicated that a factor is not important (importance rated as 1 or 2), this question was not applicable (N/A).)
Full size table

The decision distributions are identical regardless of the complexity of change, thus the factor aspect of change is considered to be a non-affecting factor because regardless of the circumstance (i.e. simple or complex), experts favor independent modelling. We use the difference of votes across the two opposite values of a factor as the metric of factor effect. If the differences of votes are within or equal to 3 (the roundup integer of 10% of the number of participants) both for integrated and independent modelling, then the factor is considered non-affecting.

We combine the importance and effect of factors in Table 5 (factors in each cell are ordered by their rankings in Table 3). The table shows that 4 factors in the 6 top 50% are affecting, and 5 factors in the 6 bottom 50% are not affecting. Criticality and awareness of impact are not affecting although ranked high on importance, and rule source is affecting although ranked lowest of importance.

Table 5. Factor importance and effect matrix
Full size table

In the following we will analyze the affecting factors to determine modelling guidance given the factors’ circumstances.

In Table 6, ‘vote difference’ is the difference between the number of votes for independent modelling and for integrated modelling, which is used as an indication of modelling decision. A modelling decision for either type of modelling can be derived if the difference in votes is at least 3 (the roundup integer of 10% of the number of participants), otherwise the data can be interpreted as not providing any dominant view of the type of modelling that is appropriate (noted in Table 6 as “Either”). For example in Table 6, for the agility factor, where the need of agility is high, there are 13 more votes for independent modelling than for integrated modelling, so independent modelling is the dominant view for modeling.

Table 6. Dominant modeling preferences
Full size table

Based on this analysis, the modelling decision is analysed for each circumstance of a given factor. While there are three situations in which the experts could not agree on a modelling decision, modelling guidance can be derived for the following seven situations:

  1. 1.

    When a rule has relatively high agility, it should be modelled independently.

  2. 2.

    When a rule changes frequently, it should be modelled independently.

  3. 3.

    When a rule changes infrequently it should be integrated in a business process model.

  4. 4.

    When a rule is highly reusable, it should be modelled independently.

  5. 5.

    When a rule’s reusability is low, it should be integrated in a business process model.

  6. 6.

    When a rule requires relatively high accessibility, it should be modelled independently.

  7. 7.

    When a rule comes from an external source, it should be modelled independently.

To provide further insights into the rationale of the responses, in the following we briefly highlight relevant insights for non-affecting factors, which were collected through open-ended comment sections for each factor in our survey. We use the symbol P and a number to represent the participant number.

Criticality. The opinions on factor criticality are conflicting. Participants argue that “it’s obviously more important that critical business rules are modelled in safe and reliable ways than for less critical roles” (P20) and “criticality is important for the enforcement or monitoring of rule violations” (P11), but “that doesn’t tell us anything about whether the rule can be embedded in the business process or not” (P20), and “whether this is done through a BRMS or a BPMS or manually does not matter, as long as it is effective.” (P11).

Awareness of impact. Awareness of impact “could not always be estimated and could not be easily represented” (P10), and “a rule may impact a process or something else” (P11), thus it is considered as a less important factor.

Complexity. Since “BPMN is not suitable for BR modelling” (P17), simple and complex rules can be easier to handle in a dedicated rule representation than integrated into a business process.

Governance Responsibility. The importance of governance responsibility is challenged as “a business rule can be modelled separately and be embedded in a business process at the same time” (P20), and “it depends on if the process model executed by a BPMS or will a rulebook be used”. (P16).

Scope of Impact. Participants admit that “it might be easier to see which swim lanes are affected by the rule change and how a separately modelled and maintained BR scopes is hard to understand from a single BR out of context” (P17). However, they believe this factor “has more to do with governance and documentation than with modelling” (P17).

Aspect of change. “If the rule logic changes, it’s easier to handle in the dedicated rule representation. If a single parameter changes, it’s still easier to handle in a dedicated rule representation” (P11). So the preference is independent modelling regardless of whether the change is complex or simple.

Implementation Responsibility. Participants argue that “business and technical users have different responsibilities for the same set of rules” (P12), with the underlying assumption that modelling process and implementation process are separated.

7 Conclusions and Future Work

This paper recapped twelve factors that are thought to potentially influence decisions on whether a business rule is modelled independently or modelled in a business process model [14]. We explored empirically the relative importance of the identified set of factors with academic experts and identified agility as the most important factor, followed by criticality, rate of change and reusability. Accessibility, awareness of impact, complexity, governance responsibility and scope of impact, with aspect of change, implementation responsibility and rule source being the least important factors. We also explored expert indications of how a business rule should be modelled given each factor, which lead us to derive seven guidelines for business rule modelling.

Our work is not without limitations. First, this study focuses on the factors which have a relatively high level of influence. Different modelling languages, tools and integrated modelling methods will affect these factors differently and will be a promising topic for future research. Second, we limit our scope of rules to those that can be both modelled independently as well as modelled with a business process. The rules that do not have the capability to be modelled into processes are beyond our discussion since there is no option for an alternative modelling decision. Although semantics and types of rule can be used to distinguish these rules in some cases, modelers still need to judge each rule individually according to its characteristics. Last, our study participants are predominantly academic experts in the field. The views of common practice are also critical to understand and are the next step in our study. Following that step, we plan to develop a decision framework and prototype to guide business rule modelling decisions. We expect that further empirical study will help to extend the decision framework through deeper insights into the decision processes.