1 Introduction and motivation

The integration of risks on business process level is a research topic that has been investigated by several research groups and has introduced many challenges for Risk-aware Business Process Management (R-BPM), which is considered a new management paradigm  [37, 46, 69, 72]. Some of the most fundamental challenges relate to the decision of introducing either a pure modeling approach or a pure management approach for R-BPM [56]. Most of the existing R-BPM approaches aim to extend the risk integration beyond the functional view in order to capture other process elements that can be affected by risks. This integration consequently results in very complex meta-models that require the simultaneous consideration of risk and business process aspects. Modeling these aspects is thus too of increasing complexity and the different stakeholders involved in R-BPM are likely overwhelmed.

Separation of concerns [23] in general and multi-view modeling in particular are well-established principles by means of which it is possible to tackle meta-model complexity. Multi-view modeling favorably partitions a meta-model into multiple viewpoints, each of which only focusing on individual aspects of the system under study. Consequently, the complexity of the meta-model can be reduced and individual stakeholders with their concerns can be supported by a tailored fraction of the overall meta-model (i.e., a viewpoint) when creating a model (i.e., a view). However, keeping these views consistent is inherently difficult because of the syntactic and semantic overlaps [7, 12, 18, 55, 57].

Indeed, multi-view modeling is a widely accepted methodology toward reducing complexity [7, 11, 18, 55]. By using a multi-view approach, multiple structural and behavioral aspects can be represented using different, interdependent viewpoints. In this context, it is interesting to note, that the majority of existing R-BPM approaches so far did not consider the way a modeler should interact with and navigate through multiple viewpoints and how consistency between these viewpoints is managed. This research gap establishes the motivation for our work.

To address this research gap, this paper introduces a multi-view modeling framework in which all risk and business process concepts are unified and kept consistent at all times. Instead of starting from scratch, we build our contribution on top of our previous works [46, 64,65,66, 72]. In these works, we introduced the Business Process-Risk management—Integrated Method (BPRIM). BPRIM follows a mere management approach focusing on how risk management should be considered during the business process management lifecycle. As most R-BPM approaches, also BPRIM originally considered the multiple viewpoints in isolation and did not consider consistency management.

The paper at hand describes the necessary fundamental extensions to BPRIM in order to conceptualize multi-view support: (1) taking a behavioral perspective on consistency management in multi-view R-BPM modeling, we define a multi-view modeling procedure for BPRIM; (2) using an established formalism, we formally specify the BPRIM modeling language in order to identify semantic viewpoint overlaps; and (3) using the open meta-modeling platform ADOxx, we implement a free modeling tool that features mechanisms & algorithms to manage consistency in multi-view e-BPRIM views. Together, these extensions form e-BPRIM, a multi-view modeling method for R-BPM.

For realizing e-BPRIM, our research follows the five core phases of the Agile Modeling Method Engineering (AMME) lifecycle [39] which are mapped to the generic Design Science Research methodology [78]. In order to evaluate the quality of our contribution, we conducted case study experiments with two groups. One group used our new multi-view e-BPRIM tool whereas the other group, the control group, used a modeling tool that was identical instead of having no multi-view support at all. We will refer to this latter category as diagram-oriented modeling in the following. The evaluation shows, that multi-view modeling outperforms diagram-oriented modeling by means of usability and efficiency of modeling, and quality of models. Thus, this research establishes first theoretical contributions toward design guidelines for multi-view modeling methods and tools. Besides, the developed tool is publicly available, thereby contributing to open science in general [1] and the practice of R-BPM in particular.

This paper is structured as follows: Sect. 2 provides the necessary foundations. A survey of recent risk-aware business process management approaches is then presented in Sect. 3, pointing to inadequacies and research gaps that act as a motivation for our research. The core contribution of this paper is then presented in Sect. 4 where the e-BPRIM approach is discussed in detail following the Agile Modeling Method Engineering lifecycle. We report on an evaluation of e-BPRIM in Sect. 5 before we conclude with lessons learned and an outlook to future research directions in Sect. 6.

2 Foundations

2.1 The research domain of R-BPM

The main concerns of Business Process Management (BPM) is to analyze “how work is performed in an organization to ensure consistent outcomes and to take advantage of improvement opportunities.” [24, p. 1] Traditional BPM systems usually do not properly address the risks that organizations face in their day-to-day operations. Risk is part of every business activity and therefore part of every business process. If a risk occurs it may cause decreased quality, increased costs, time delays, complaints, and legal problems [15]. In the healthcare domain a risk can even cause serious and permanent damages up to death [5]. Such risks need to be managed by applying principles, frameworks, and activities, commonly known as Risk Management (RM).

The Risk-aware Business Process Management (R-BPM) paradigm has recently emerged, aiming to integrate the two traditionally separated fields of risk management and business process management [37, 69]. R-BPM promotes risks consideration in all stages of BPM and enables robust and efficient BPM within an uncertain environment. The importance of this integration has been confirmed in the research community [53], in industry guidelines [21], and in many studies [46, 69, 72]. Furthermore, this integration is a strategic objective of the European Network and Information Security Agency and the European Commission in ICT Trust and Security [74]. Nevertheless, research and practice of R-BPM is still limited and requires highly specialized knowledge in conceptual modeling methods, multi-view modeling, and consistency.

2.2 Conceptual modeling methods

Conceptual modeling reduces complexity of a certain domain by applying abstraction for a specific purpose. Conceptual models consequently only comprise those aspects of a domain that contribute value to a specific purpose. According to [40], a conceptual modeling method contains three building blocks: a modeling language, a modeling procedure, and mechanisms & algorithms. A modeling language can be further decomposed into its constituting parts, i.e., the syntax—the concepts provided by the language and the rules for combining them; the semantics—specifying the meaning of the language concepts; and notation—the graphical representation of each modeling language concept. At the heart of any conceptual modeling language is the syntax which determines the expressiveness and also the utility of the modeling language. Syntactic aspects are commonly specified using a meta-model [14]. The modeling procedure optionally defines the steps to be applied while creating valid models. These steps can be related to modeling actions in one model, or in a wider scope, to the sequence of creating and working with multiple models. Eventually, mechanisms & algorithms realize the automatable steps of the modeling procedure (e.g., model transformation) or provide means of processing the knowledge codified in the models (e.g., simulation).

2.3 Multi-view modeling

When the complexity of a system to be modelled exceeds a certain threshold, it is common to refer to multi-view modeling [12]. By doing so, the overarching model is decomposed into smaller models, representing views, that focus only on certain aspects while ignoring everything else. Each view has a corresponding modeling language, i.e., a viewpoint, which naturally only comprises a subset of the concepts necessary for the overarching model. “Multi-view modeling enables humans and machines to interact from multiple semantically or syntactically dependent perspectives with different views of a modeled artifact” [11, p. 94].

The standard ISO/IEC/IEEE 42010:2011 [35] differentiates between viewpoint and view as follows: “A view is governed by its viewpoint: the viewpoint establishes the conventions for constructing, interpreting and analyzing the view to address concerns framed by that viewpoint. Viewpoint conventions can include languages, notations, model kinds, design rules, and/or modeling methods, analysis techniques and other operations on views” [35].

On this basis, Fig. 1 illustrates the terminological foundations this paper adheres to. We consider the viewpoint concept as a partitioning or restriction of concerns in a system. According to the Model-Driven Engineering (MDE) paradigm [67], it corresponds to a subset of the meta-model. The view concept is then the instantiation of a given viewpoint for a given case. The view is described by a model. Hence, a view and a viewpoint are always related to each other by means of an instantiation relationship. Similarly, each model is an instance of the language meta-model. A view is represented by a model whereas a viewpoint is represented by the subset of the language meta-model.

Fig. 1
figure 1

Terminological foundations of view, viewpoint, model, and meta-model

Full size image

Multi-view modeling is not exclusively applied in the enterprise modeling [10, 26, 34] and enterprise architecture [35, 45] domains, but also in requirements engineering [79]. In the context of this paper, we employ integrated multi-view modeling by relating model-based risk management with model-based business process management. The aim of the multiple viewpoints is to reduce the complexity of the domain and to separate the different concerns of stakeholders involved in the different phases of the R-BPM lifecycle.

2.4 Multi-view consistency

As the different viewpoints in multi-view modeling represent the same system to be modeled, requirements for managing consistency amongst the views are inherent. Different kinds of viewpoint relationships can be differentiated. In the following, we will refer to the relationship classification proposed in [55]: Orthogonal/Independent: No direct semantic or syntactic relationships exist between two viewpoints. Syntactic: Two viewpoints share at least one syntactic concept whereas they also have mutually exclusive concepts. Semantic: Two viewpoints have a semantic relationship between each other, but this relationship is not based on a shared syntactic concept. Refinement/Abstraction: One viewpoint can be considered a more abstract and generalized representation of a different viewpoint. Thus, one viewpoint further abstracts/refines the other. Association: Association viewpoints are used to connect two or more other viewpoints with each other.

Figure 2 shows the different viewpoint relationships.

Fig. 2
figure 2

Viewpoint relationships in multi-view models [55]

Full size image

Multi-view consistency has thus far only been considered on a static basis. However, consistency also needs to be considered on a dynamic basis. In [55], the dynamics of multi-view modeling is described by looking at different kinds of modeling operations that can be performed on views: Composition: A new view is created by combining the semantics of two or more other views. Specialized composition operations are: Communication and Merging. The former relates to heterogeneous views that are communicating with each other (e.g., a process view and an organization view), whereas the latter refers to the composition of homogeneous views that might reflect different states of the modeled system. Projection: A reduced view is derived by removing (i.e., filtering) syntactic concepts. Extension: The opposite of the projection operation, i.e., adding syntactic concepts to a given view. Analysis: This operation processes the information contained in a view in order to create an analysis view of the results. A special kind is the diffing operation which compares different versions of the same view. Synthesis: Synthesizes the information of several views.

3 Related works

As previously mentioned, R-BPM integrates risk aspects into business process management in order to increase the risk-awareness of an organization’s business processes. An extensive general review of R-BPM approaches can be found in [37, 46, 69, 72].

In this work, we have established a set of specific criteria to guide the selection of relevant related works to be analyzed. As a consequence, a number of related works have been excluded. A brief explanation of the scope and the selection criteria of the search are detailed in Sect. 3.1. Those works that did meet our selection criteria were subsequently grouped and described in Sect. 3.2. Section 3.5 then provides an analysis of the selected works and points to gaps and inadequacies that motivate our research.

3.1 Search strategy

As a general rule, in this paper, we consider only R-BPM works. Therefore, works that focus only on risk management aspects and do not demonstrate strong links to business process management are excluded. Examples of risk-management-focused work, which we excluded, are the CORAS method [48], the Committee of Sponsoring Organizations of the Treadway Commission (COSO) Enterprise Risk Management framework [21] and many others (cf. e.g., [6, 16, 25]). Similarly, works that interpret business processes in an isolated sense are excluded. Examples of works in this category include [32, 49, 61].

The need for organizations to comply with legislative regulations has highlighted the need to address risks of regulatory noncompliance. Consequently, research in business process compliance increasingly has been linked to risk management. However, business process compliance is distinct from R-BPM: the former seeks to provide solutions to ensure the compliance of business processes to regulations, while the latter seeks to reason about the likelihood and the impacts of the occurrence of various types of risks, one of which is the risk of business processes violating some legislative regulations. Our search is concerned with the latter, and, thus, we have excluded many works in the core area of business process compliance.

Similarly, information security is another specific risk factor in BPM. In this respect, our search focuses on works that attempt to facilitate the reasoning about security risks in BPM, rather than those that attempt to provide solutions to security management problems. Thus, a large number of works concerning core security management were excluded, such as the Optimised Risk Analysis Method (MONARC) [51].

While all these works may seem relevant, they do not properly attempt to integrate and/or reason about risks in business process management.

In this paper, we concentrate our search on recent R-BPM approaches that concentrate on the design-time stage of the BPM life cycle (cf. [46]). Obviously, managing risks in business process starts by a convenient representation of risks and their characteristics in business process models. This representation allows for an understanding of the risk origins in business processes, their impact on these processes, and the control and mitigation strategies in place.

The design-time R-BPM approaches could also be classified into two categories with regard to the risk modeling consideration: (1) those that introduce new risk-related constructs in order to incorporate risk information into the business process model; and (2) those that attempt to reason risks using risk analysis techniques without the introduction of new constructs. In this work, we focus our search on the first category, as related approaches do not provide enough support for design activities.

3.2 Analysis framework

In the following, we introduce an analysis framework which will be used in Sects. 3.3 and 3.4 to analyze current single-view and multiple-view design-time R-BPM approaches, respectively. The framework comprises criteria that are derived from the five core phases (i.e. create, design, formalize, develop, and deploy) of the Agile Modeling Method Engineering (AMME) lifecycle [39] (AMME will be introduced in detail in Sect. 4.1). The framework aims to elevate the presentation of the related works toward a less subjective and more comprehensive level. The analysis framework comprises the following criteria:

  • Requirements whether requirements are specified;

  • Requirements format which requirements specification format is used;

  • Modeling Language which modeling language is used to represent risks and business processes;

  • Meta-Model whether a meta-model is specified;

  • Modeling procedure whether the steps for creating models are specified;

  • Proposed viewpoint(s) the number of proposed viewpoints;

  • Integration formalism whether the approach uses a formalism to specify models and the relationships between them;

  • Inter-dependencies types whether inter-dependencies between models or model elements are defined;

  • Tool support whether a supporting tool is available.

The benefits of using this analysis framework are threefold. First, it structures the presentation of related approaches along a generic modeling method engineering framework (i.e., AMME). Moreover, it eases the transition from the comparative analysis of existing approaches (Sect. 3.5) to the proposal of the multi-view BPRIM extension throughout Sect. 4 which is also structured along the sequential flow of the five core phases of AMME. Third, the framework clearly shows need for conceptualizing multi-view support for our previous works [46] which we contribute with this paper.

3.3 R-BPM approaches with one viewpoint

In [19, 20], a semi-formal extension of risk-related modeling constructs to the Business Process Model and Notation (BPMN) standard is proposed. The approach uses one viewpoint, the extended BPMN. Similarly, in [50], one BPMN-extended viewpoint for risk handling is proposed. In particular, identified risks are assigned to affected processes, sub-processes, or activities by using an extended error event. The standard BPMN language was furthermore extended with the modeling construct of risk factor, characterizing a potential risk in terms of type, likelihood, and impact on a whole business process. Risk factors are assigned to BPMN sequence flows.

In [3, 4], an extension of BPMN for the IS Security Risk Management is proposed. The approach expresses assets, risks, and risk treatment regarding asset confidentiality, integrity, and availability in one BPMN-extended viewpoint. Their proposal allows system analysts to design security requirements to secure important assets.

In [47], an EPC-extended approach for analyzing business process models using an adaptation of the HAZOP (HA-Zard OP-erability) method is proposed. Similar to the three previous approaches, HAZOP neither specifies any requirements, nor does it propose a modeling procedure or a supporting modeling tool.

3.4 R-BPM approaches with multiple viewpoints

In [80], the Semantic Business Process Modeling Language (SBPML) for banks [8] is extended by a risk viewpoint for modeling and analyzing operational risks. The core constructs of this language are domain-specific process building blocks which connect and integrate a process viewpoint, a business object viewpoint, an organizational viewpoint, and a resource viewpoint. This approach is domain-specific and therefore limited in its applicability to other domains.

In [9], XMLNets, a variant of Petri Nets, are proposed to model risk-related information in business process models. This work proposes a procedure comprising four steps: modeling the original business process; assessing, parameterization, and linking of risks to the activities; simulation of different process variants; and transformation of the most satisfying process variant into an improved business process model. A tool supporting the procedure is also proposed.

The Risk-Oriented Process Evaluation (ROPE) approach [37, 38] proposes three viewpoints to capture risks within business process models: A business process viewpoint that consists of activities; a CARE viewpoint that is derived by decomposing the activities into their corresponding Condition, Action, Resource and Environment elements; and a Threat Impact Process viewpoint that captures various threats that may affect the corresponding CARE viewpoint elements and the counter measure activities. A novel formal description for modeling threats, detection, counter, and recovery measures, their inter-dependencies, as well as the impact on the attributes of affected resources is introduced in [36, 73]. A simulation process was then described for assessing the impact of threats on the process activities. However, these works neither define a meta-model nor do they specify any formalism or requirements. A tool has been partially implemented.

In [27, 56], the Semantic-based Modeling Framework for Information Systems (SemFIS) is proposed. The authors used semantic annotations for assigning risks from a frame ontology to a business process. The annotated models were processed via Java with JESS rules, enabling the execution of a capacity simulation to assess the impact of risks.

In [30, 68], RiskM, a modeling method for IT risks which is based on the Multi-Perspective Enterprise Modeling method (MEMO) [31], is proposed. RiskM allows to model processes, IT assets, strategies, and goals. The core RiskM modeling procedure comprises two steps. First, the IT-assets are modeled. Second, concrete risks are assigned to affected IT assets. In [30, 68], high-level requirements and key concepts of RiskM are defined which have been further enriched in [31], and prototypically implemented in [10].

In [62, 63], a performance measurement and management framework based on value and risk is proposed. The framework is organized in four phases, each of which is instrumented with different analysis methods. This work proposes four viewpoints: objectives viewpoint, activity viewpoint, risk viewpoint and risk-aware business process viewpoint. To express requirements, the authors propose a value-driven objectives viewpoint reflecting stakeholder expectations. Following the Value-Focused Thinking framework (VFT) [42], the latter provides a structured approach to elicit objectives from higher-levels stakeholder values. Moreover, mathematical theory is used to describe inter-dependencies between some viewpoint components. No tool support for the framework has been proposed, yet.

In [74, 75], the OPBUS (OPtimization of BUsiness process Security) framework for security-quality requirements in business processes management is proposed. OPBUS includes security issues from design to execution stage of the BPM lifecycle. The framework provides mechanisms for model-based diagnosis and constraint programming to carry out risk assessment and automatic conformance checks of security requirements. A tool supporting the OPBUS framework is proposed, it integrates: (i) a transformation engine that enables risk-extended business process models to be translated into Constraint Satisfaction Problem (CSP) models; (ii) support of various constraint solvers; and (iii) automatic conformance checks by means of CSP executions.

Table 1 Comparative overview of recent R-BPM approaches
Full size table

In [59], a risk-extended EPC modeling language is presented. This work depicts a meta-model to specify the modeling language. The proposed approach shows how R-BPM can be formalized on the atomic level of elementary e-EPC functions by extending the Value-Focused Process Engineering (VFPE) formalism [52]. Consequently, a formal specification of: (a) objects (such as goals, functions, events, etc.); (b) inter-dependencies between objects (including assignment and decomposition); (c) relationships between levels of processes and risk objectives decomposition structures; and (d) guidelines for synchronized movement between levels of the process and risk objectives viewpoints is enabled. Requirements are not explicitly defined and neither a procedure nor a tool exist.

[46, 64,65,66] introduce and further develop the Business Process-Risk Integrated Method (BPRIM) comprising: a conceptual unification between the business process conceptual-model proposed by the ISO/DIS 19440 and a risk conceptual-model; a modeling language extending the ISO/DIS 19440 constructs with constructs for risk modeling; and a synchronized lifecycle that forms a procedure for integrated business process and risk management. The BPRIM lifecycle phases are supported by eleven viewpoints. A prototypical modeling tool is available [72]. However, this work does neither provide modeling requirements and formalization, nor a complete modeling procedure describing inter-dependencies between the proposed viewpoints.

3.5 Comparative analysis and solution overview

Table 1 provides a comparative analysis of the related approaches using the previously introduced criteria. Four out of 13 design-time R-BPM approaches integrate risk and business process concepts in a single viewpoint whereas the other nine approaches propose multiple viewpoints. Most of the latter approaches use two to four viewpoints whereas RiskM [68] with five and BPRIM with eleven viewpoints stand out. None of the analyzed approaches comprises a specification of modeling requirements, a pre-defined modeling procedure, and a formalized specification of viewpoints and their relationships. Only three approaches specify requirements at all, but only on an informal level using natural language (cf [13]). Six approaches have at least prototypical tool support whereas only three tools are freely available. Based on the previous comparative analysis, we identify the following research gaps e-BPRIM aims to address:

  1. a

    Only three approaches explicitly specify requirements.

    We will address this shortcoming in Sect. 4.2 by formally specifying the requirements of our approach using an i* Strategic Dependency model.

  2. b

    Although nine approaches propose multiple viewpoints, these approaches did mostly not specify a modeling procedure and how consistency between these viewpoints is managed.

    These shortcomings will be addressed in Sect. 4.3 by precisely specifying the multiple viewpoints, their corresponding modeling languages, and the procedure employed by modelers working with the multiple views. Moreover, Sect. 4.5 describes the implementation of the consistency mechanisms required for efficiently and simultaneously working with multiple views.

  3. c

    Most approaches (8 out of 13) did not specify meta-models, viewpoints, and the relationships between viewpoints. Only few of them used formalisms and inter-dependency types for a precise specification.

    We will address this shortcoming in Sect. 4.4 by formally specifying all viewpoint relationships.

The identified research gaps offer great potential to advance the R-BPM domain. Our contribution builds upon our previous works on BPRIM [46]. In previous research on BPRIM all eleven viewpoints were treated in isolation and no means of consistency management were in place. Considering this and the gaps identified in related works, the research at hand is guided by the following research objectives: (i) Defining an overarching modeling procedure that frames the multiple e-BPRIM viewpoints along the different R-BPM lifecycle phases and thereby guides the modeler during the modeling process, (ii) Formally specifying the e-BPRIM modeling language and multi-view relationships, and (iii) Implementing a free multi-view modeling tool that features mechanisms & algorithms to manage consistency.

All these objectives adhere to the overall aim of realizing a multi-view R-BPM approach with high efficiency and usability. The following sections will report on how we addresses these objectives. Eventually, the evaluation will consider to which extend the Extended BPRIM approach fulfills the aim of efficiency and usability.

4 Meta-modeling for extended BPRIM

4.1 Research methodology

This research generally follows the design science research (DSR) methodology [78]. The artifact we are proposing as a result of the DSR project is the extended BPRIM modeling method and tool (e-BPRIM). In the following, we extend the DSR design phase [54] by the Agile Modeling Method Engineering (AMME) lifecycle [39]. AMME includes steps to be performed when conceptualizing a modeling method. The lifecycle comprises five core phases (see Fig. 3), each of which focusing on selected aspects of modeling method conceptualization:

  • 1. Create: Concerns the specification of requirements of a modeling method \(\rightarrow\) see Sect. 4.2.

  • 2. Design: Design of a meta-model addressing the identified requirements \(\rightarrow\) see Sect. 4.3.

  • 3. Formalize: Formally specifying relevant parts of the modeling method \(\rightarrow\) see Sect. 4.4.

  • 4. Develop: Actual development of a corresponding modeling tool \(\rightarrow\) see Sect. 4.5.

  • 5. Deploy: Deployment of the modeling tool \(\rightarrow\) see Sect. 4.5.

Fig. 3
figure 3

Agile modeling method engineering lifecycle [39]

Full size image

It needs to be noted again, that the following e-BPRIM presentation focuses exclusively on the multi-view modeling aspects. A comprehensive introduction to BPRIM is given in [46] where the requirements and rational for the meta-model and the viewpoints are elaborated in great detail. We therefore concentrate the presentation of all AMME phases on how they relate to the conceptualizing of multi-view modeling for BPRIM.

In a first step of our research, the e-BPRIM framework creation consists on the representation of the modeling requirements. Then, an integrated R-BPM meta-model is designed which describes the multiple viewpoints. The meta-model is represented using a UML class diagram by applying the meta-model slicing technique [14]. In the third step of our research, the formal specification of e-BPRIM meta-model and models is described. The e-BPRIM develop step aims to produce a supporting modeling tool. Eventually, the e-BPRIM deploy step concerns making the developed tool publicly available.

This research methodology enables smooth transitions from informal requirements through semi-formal and formal specifications toward the implementation of a modeling tool [39]. The next sub-sections will follow this step-by-step approach to consecutively and comprehensively describe not only the resulting e-BPRIM artifact, but also the process it derived from.

4.2 e-BPRIM creation

The first phase of the AMME lifecycle centers the elicitation of requirements for a modeling method. Thus, this section elucidates the requirements for conceptualizing multi-view modeling for the BPRIM modeling method. It must be emphasized, that introducing multi-view modeling to BPRIM not only affects the modeling language. In contrast, multi-view modeling thought until the end, also raises requirements on the modeling procedure, the mechanisms & algorithms, and the modeling tool of e-BPRIM. We thus follow a top-down approach for requirements elicitation by starting with the top-level requirements: Define multi-view modeling procedure, Specify multi-view modeling language, Design multi-view modeling mechanisms & algorithm, and Realize a multi-view modeling tool. In a next step, a total of 11 high-level tasks were defined and categorized. Table 2 provides an overview of the e-BPRIM requirements and the corresponding tasks.

Table 2 Overview of high-level e-BPRIM multi-view modeling requirements
Full size table
Fig. 4
figure 4

e-BPRIM multi-view modeling requirements as simplified i* Strategic Dependency model

Full size image

The Define multi-view modeling procedure requirement (Rq1) comprises two tasks which are organized in a hierarchical manner. First, sequential and informational ordering of the modeling steps needs to be defined (Task 1.1). In this respect, the Task 1.2 needs to be conducted to identify viewpoints according to the BPRIM phases and steps. By considering the modeling procedure first, one naturally derives at a level of granularity that enables the identification and differentiation of relevant viewpoints.

The Rq2 Specify multi-view modeling language requirement comprises two tasks. First, the BPRIM modeling language needs to be decomposed to derive the individual viewpoint languages (Task 2.1). This decomposition is not necessarily disjoint, i.e., it is very likely that modeling language concepts become part of multiple viewpoints. Thus, Task 2.2 is concerned with the specification of all overlaps between meta-models of different viewpoints which are of pivotal importance for the design and implementation of consistency.

Rq3 aims at the design of mechanisms & algorithms to model with multiple views. Task 3.1 is concerned with the design of view-consistency mechanisms, i.e., concepts and functionality that help the modeler to simultaneously work with multiple views (cf. [12]). Another way of working with multiple views is by enabling navigation operators. Therefore, Task 3.2 defines references between viewpoints. Eventually, all modeling operations need to be aligned to the individual viewpoints (Task 3.3).

Tool support is essential for the utilization and adoption of e-BPRIM. Therefore, Realize a Multi-view modeling tool requirement (Rq4) comprises four high-level tasks. First, all mechanisms & algorithms for consistency management need to be implemented (Task 4.1). Task 4.2 concerns the implementation of semantic traceability across multiple viewpoints. Task 4.3 and Task 4.4 then consider non-functional aspects of the modeling tool by assuring flexibility, usability, understandability, and learnability.

Table 2 provides an overview of the e-BPRIM requirements and the corresponding tasks. We refer to existing techniques for graphical non-functional requirements specification in order to also specify task relationships. Several works have been proposed to model requirements such as KAOS [22], MAPS [58], i* framework [83, 84], and the Non-Functional Requirements framework [17]. Due to its simplicity and wide adoption, we will refer in the following to the i* framework [84]. Figure 4 shows an i* Strategic Dependency model of the core e-BPRIM requirements. It can be derived, that Task 2.1: Specify meta-models of viewpoints is further decomposed into the Task 1.2: Identify viewpoints originating from Rq1 and Task 2.2: Specify overlaps between meta-models from Rq2. Explicating and formally specifying these and other relationships helps deriving at a coherent and comprehensive modeling method specification.

4.3 e-BPRIM design

In the second phase of AMME, we concentrate on the design of the multi-view modeling language for e-BPRIM. We will first introduce the e-BPRIM modeling procedure (Sect. 4.3.1) and then derive the requirements for viewpoints, which need to be reflected in the e-BPRIM multi-view modeling language (Sect. 4.3.2). The latter will also consider the specification of viewpoint overlaps.

4.3.1 e-BPRIM modeling procedure

Fig. 5
figure 5

e-BPRIM multi-view modeling procedure

Full size image

The original publication of BPRIM [46] proposes an integration of the two lifecycles of risk management and business process management. The BPRIM lifecycle identifies eleven viewpoints which should be managed in a common repository. Table 3 provides an overview of these viewpoints (Rq1 \(\rightarrow\) Task 1.2). However, BPRIM did not specify in detail the temporal & informational ordering (Rq1 \(\rightarrow\) Task 1.1) between viewpoints.

Table 3 Overview of e-BPRIM viewpoints
Full size table
Fig. 6
figure 6

Overview of e-BPRIM multi-view modeling meta-model, highlighting the meta-model of each viewpoint

Full size image

To fill this gap, we propose in Fig. 5 the e-BRPIM multi-view modeling procedure that illustrates the collaborative process supporting our integration approach with an emphasis on temporal ordering of the proposed viewpoints (Rq1 \(\rightarrow\) Task 1.1). The upper viewpoints are related to the structure of information while the lower ones are more dedicated to business dynamics. The procedure structures viewpoints according to the BPRIM lifecycle phases “Contextualize”, “Assess”, “Treat & Monitor”. We differentiate two modeling viewpoint relations: a Precedence relation, denoting that the second viewpoint contains output data from the first one; and an Information relation, denoting that two viewpoints share information. These multi-view relations inevitably lead to overlaps between viewpoint concepts.

The Contextualize phase starts with a “Discover” step leading to the definition of the value-added processes of the system under study by means of the “Process Landscape” viewpoint. Next, a model of the organization’s structure is defined in the “Design” step by means of the “Organization Chart” viewpoint which aims to identify roles and expectations, thereby establishing a greater understanding of the organizational environment. In addition, this definition serves to define the business process model by means of the “Business Process” viewpoint, then enabling the analysis of the context by means of the “Context” viewpoint.

The Assess phase starts with an “Identify” step that defines and classifies potential risks by means of the “Risk Taxonomy” viewpoint. The latter with the “Business Process” viewpoint assigns previously modeled risks to individual activities of the business process model, thereby identifying activities that are exposed to risks by means of the “Risk-extended Business Process” viewpoint. The “Analyze” step starts with an individual risks assessment by means of two viewpoints: “Risk Analysis” and “Risk”. The former depends on information specified in the “Risk-extended Business Process” viewpoint and the “Context” viewpoint. It includes: underlying risk causes and consequences, risk analysis by risk level calculation, and qualitative/quantitative risk evaluation. Then, critical activities can be identified in the “Risk-extended Business Process” viewpoint, according to risks level to which they are exposed. The “Risk” viewpoint is generated from information specified in the “Risk-extended Business Process” viewpoint and the “Risk Taxonomy” viewpoint. It describes an overview of all existing risk relationships in all viewpoint instances. The risk level is also defined according to information derived from the “Risk Analysis” viewpoint. Based on information flow from individual risks assessment results, risks relationships can be inferred by means of the “Risks Relationship” viewpoint. “Risk-extended Business Process”, “Risk Analysis”, and “Risk” viewpoints are required to capture the dynamic risks characteristics and generate the “Risks Mapping” viewpoint in the “Evaluate” step. This view is a two-dimensional risk matrix showing the risk level of each analyzed risk.

The Treat & Monitor phase aims to identify the most critical risks from the “Risks Mapping” viewpoint and to treat these risks by defining control mechanisms by means of the “Risk Treatment” viewpoint. Once control mechanisms are defined, process changes and improvements may be implied by means of the “Business Process” viewpoint, thereby closing one walk-through of the e-BPRIM multi-view modeling procedure.

4.3.2 e-BPRIM meta-model

Along the e-BPRIM modeling procedure, eleven interdependent viewpoints are identified. These viewpoints are described with a common modeling language of both risk and business process, the e-BPRIM modeling language. An integrated meta-model called e-BPRIM meta-model is at the core of a formal specification of the modeling language. It has been built using both literature analysis and experience feedback (Rq2 \(\rightarrow\) Task 2.1).

The e-BPRIM meta-model extends the specification in Table 3 by means of the relationship cardinalities and the integration of the different viewpoint meta-models. Figure 6 visualizes the meta-models of eleven e-BPRIM viewpoints. From the figure can be derived, that some viewpoints have syntactic overlaps (e.g., “Value” which is part of the “Context” and the “Risk Analysis” viewpoints) while others have semantic overlaps that cross viewpoints (e.g., the relationship between “Stakeholder” in the “Risk Analysis” viewpoint and “Operational Role” in the “Organizational chart” viewpoint). These overlaps are referred to as “inter-model-references (INTERREFs in short)” in the following (Rq2 \(\rightarrow\) Task 2.1 and Task 2.2). Each viewpoint comprises a subset of the e-BPRIM modeling language.

Identification and specification of viewpoint relationships are a prerequisite to the design and implementation of consistency mechanisms (Rq3 \(\rightarrow\) Task 3.2 and Task 3.3). Therefore, in the following, we will specify the different e-BPRIM viewpoint relationships in detail (Rq2 \(\rightarrow\) Task 2.1 and Task 2.2) by applying the characterization introduced in [55]:

  • Syntactic overlaps: indicated as blue dotted arrows describe a relationship when a meta-model concept is represented in two different viewpoints by the same syntactic element. For e-BPRIM, we identified twelve syntactic overlaps (R1 to R12 in Fig. 6).

  • Semantic overlaps: indicated as purple dotted arrows. Semantic overlaps arise when a meta-model concept is represented in two different viewpoints by different syntactic elements but the semantics of the two concepts overlap. In e-BPRIM, we identified four semantic overlaps (R13 to R16 in Fig. 6).

  • Refinement/Abstraction: indicated as red dotted arrows describe a relationship between viewpoints where one viewpoint is a more abstract representation of the other. In e-BPRIM, we identified two such overlaps (R17 and R18 in Fig. 6).

  • Association: indicated as green dotted arrows describe a relationship where an association viewpoint is used to connect two or more base viewpoints. This relation either binds the viewpoints together, or constrains the shared semantics. For e-BPRIM we identified one association overlap (R19) as shown in Fig. 6.

Table 4 provides a detailed description of each e-BPRIM viewpoint relationship in Fig. 6. The description uses the notion of an overlapping concept ’OC’ introduced in [7]. An OC refers to meta-model elements that form part of two or more different viewpoints by either a syntactic or a semantic overlap. For further information about the e-BPRIM viewpoint relationships, we propose in Fig. 7 one example of each kind of them.

Table 4 Description of e-BPRIM viewpoint relationships by means of Overlapping Concepts
Full size table
Fig. 7
figure 7

Example of some e-BPRIM viewpoint relationships

Full size image

4.3.3 e-BPRIM mechanisms and algorithms

According to [40], algorithms and mechanisms support the semi-automated steps of the modeling procedure. Moreover, they provide functionalities to use and evaluate views. Based on the defined viewpoint relationships and the e-BPRIM modeling procedure, until now, multi-view consistency has only been considered on a static basis. However, multi-view consistency also needs to be considered on a dynamic basis. To this end, in this section, we propose a new way to describe the dynamics of multi-view modeling by looking at different kinds of modeling operations that can be performed on views (Rq3 \(\rightarrow\) Task 3.3). These operations emphasize the e-BPRIM mechanisms and algorithms. All of them are semantics-preserving (Rq3 \(\rightarrow\) Task 3.1 and Task 3.2).

Fig. 8
figure 8

Overview of the multi-view modeling operations between e-BPRIM views

Full size image

Figure 8 together with Table 5 provide a comprehensive overview of the main multi-view modeling consistency operations designed in e-BPRIM. The following description extends the multi-view modeling operations as introduced in Sect. 2:

  • Decomposition (\(Op_{1}\)): indicated as red dotted arrows refer to Refinement/Abstraction relationships in Fig. 6. Decomposition deals with breaking down a system into progressively smaller subsystems that are responsible for some part of the problem domain. With this operation, a new view is considered as a more abstract representation of a given view. Thus, one view further abstracts the other.

  • Extension (\(Op_{2}\)): indicated as blue dotted arrows refer to some syntactic overlap relationships in Fig. 6. With this operation, a new view is created by extending an existing view with additional syntactic concepts.

  • Reuse (\(Op_{3}\)): indicated as black dotted arrows refer to some syntactic and/or semantic overlap relationships in Fig. 6. With this operation, a new view is created by reusing one or several syntactic and/or semantic concepts from one or more existing views.

  • Merging (\(Op_{4}\)): indicated as blue solid arrows refer to some syntactic overlap relationships in Fig. 6. With this operation, a new view is created by combining some syntactic concepts of two of more existing views. The provided view can also add new syntactic concepts specific to the viewpoint of the new created view.

  • Synthesis (\(Op_{5}\)): indicated as green dotted arrows refer to Association relationships in Fig. 6. With this operation, a new view is created by gathering the information of several views and then generating a synthesis view. This operation can also integrate different kinds of sub-operations to gather the different knowledge amassed from other views and to structure them in a coherent whole.

  • Synchronization (\(Op_{6}\)): not indicated in Fig. 8 because this operation keeps consistency between all views. This operation ensures the propagation of any modifications (i.e. create, edit or delete) performed on an overlapping concept in one view to be propagated in semantically equivalent operations that need to be automatically performed on all other views. This operation refers to all relationships presented in Fig. 6.

Table 5 Description of multi-view modeling operations designed in e-BPRIM
Full size table

4.4 e-BPRIM formalization

In this section, we introduce a formal specification for the meta-model and selected e-BPRIM multi-view modeling operations.

4.4.1 Formal specification of the e-BPRIM meta-model

To comprehensively and unambiguously specify the e-BPRIM meta-model, we introduce some assumptions inspired from the FDMM formalism (Formalism for Describing ADOxx Meta Models and Models) [28, 29].

Let VP be the set of viewpoints of a meta-model MM which can be expressed by:

$$\begin{aligned} VP = \{VP_{1}, VP_{2}, \ldots , VP_{N}\} \end{aligned}$$
(1)

Each viewpoint can be then specified by a set of objects and attributes which can be expressed by :

$$\begin{aligned} O^{VP}&= \{O_{1}, O_{2}, \ldots , O_{M}\} \end{aligned}$$
(2)
$$\begin{aligned} A^{VP}&= \{A_{1}, A_{2}, \ldots , A_{P}\} \end{aligned}$$
(3)

Based on the previous assumptions, the set of viewpoints of the e-BPRIM meta-model \(MM_{e-BPRIM}\) can be then expressed by:

$$\begin{aligned}&VP_{e-BPRIM} = \{VP_{PL},VP_{OC},VP_{C},VP_{BP},VP_{RTa},\nonumber \\&VP_{RA},VP_{R-BP},VP_{R},VP_{RR},VP_{RM},VP_{RTr}\} \end{aligned}$$
(4)

As outlined in Sect. 4.3.2, e-BPRIM is composed of a large number of viewpoints that are all tightly interconnected. The formal specification presented in the following covers only certain aspects of e-BPRIM to show the expressive power of the formalism on the one hand while respecting the limited added value or showing the complete formal specification in this paper. We selected four core viewpoints of the e-BPRIM meta-model: Business Process \(VP_{BP}\), Risk Taxonomy \(VP_{RT}\), Risk-extended Business Process \(VP_{R-BP}\), and Risk \(VP_{R}\).

The available objects and attributes of the Risk-extended BP viewpoint \(VP_{R-BP}\) can be specified as shown in Equation 5 and Equation 6:

$$\begin{aligned}&O^{VP}_{R-BP} = \{Activity, Resource, Product, Event, Risk, \nonumber \\&Logical Operator, XOR, AND, OR, Process Interface, \nonumber \\&Operational Role, Performance Indicator, Capability, \nonumber \\&Objective, Risk Factor, Risk Situation \} \end{aligned}$$
(5)
$$\begin{aligned}&A^{VP}_{R-BP} = \{Name, Id, Synch\_List, Activity\_Ref, \nonumber \\&Process\_Interface\_Ref, Risk\_Ref \} \end{aligned}$$
(6)

Similarly, the available objects and attributes of the Risk Taxonomy viewpoint \(VP_{RT}\) can be then specified as shown in Equation 7 and Equation 8:

$$\begin{aligned} O^{VP}_{RT}&= \{Risk, Risk Class \} \end{aligned}$$
(7)
$$\begin{aligned} A^{VP}_{RT}&= \{Name, Id, Synch\_List, Risk\_Ref \} \end{aligned}$$
(8)

4.4.2 Formal specification of e-BPRIM operations

In the same way, we start with introducing some assumptions to present a formal description of selected modeling operations designed in e-BPRIM. As outlined previously, each viewpoint can be represented by views, then each view can be also specified by a set of objects :

$$\begin{aligned} O^{V} = \{O_{1}, O_{2}, \dots , O_{K}\} \end{aligned}$$
(9)

Let \(OI^V_{i}\) be the objects instances set of a view \(V_{i}\) which can be expressed by:

$$\begin{aligned} OI^V_{i} = \{OI_{1}, OI_{2}, ..., OI_{L}\} \end{aligned}$$
(10)

Then, the instances set of a specific object \(O_{j}\) in a specific view \(V_{i}\) can then be expressed by:

$$\begin{aligned} I^V_{i}(O_{j}) = \{I_{1}, I_{2}, \ldots , I_{X}\} \end{aligned}$$
(11)

Based on these assumptions, we will constrain our focus by exemplifying the formal specification of selected e-BPRIM operations on views that play a central role in enabling consistency. We will show how these operations ensure consistency in the event of: i) generation of a “Risk-extended Business Process View” (Algorithm 1); ii) an attribute value change (Algorithm 2); and iii) an instance deletion (Algorithm 3).

figure a
figure b

Algorithm 1 represents the formal specification of the automated creation of the Risk-extended BP view \(V_{R-BP}\) using the Reuse operation (\(Op_{3}\)). The algorithm first creates an empty R-BP view and then retrieves all objects of the corresponding BP view \(V_{BP}\). Then, for each object in \(V_{BP}\), a new instance of the same type in the \(V_{R-BP}\) is created, attribute values are copied, and the element is initially positioned with the same x/y coordinates as the object in \(V_{BP}\). Moreover, the id of the new instance is stored in a synchronization map that is used later to synchronize attribute value changes (see Algorithm 2). The algorithm then searches for all risks in the Risk view and assigns them in a final step to the corresponding objects in the R-BP view \(V_{R-BP}\).

Algorithm 2 describes how consistency is ensured in the event of an attribute value change of an overlapping concept. More particularly, the algorithm shows, how changing the value of an instance in one view triggers change propagation in other affected e-BPRIM views. Starting from the view of the instance with the changed value is modeled in, the algorithm queries the synchronization list in order to identify affected instances in the other views and propagates the new value.

As modeling concepts are used in several views, see Fig. 6, the deletion of an instance in one view might jeopardize the overall consistency of the e-BPRIM views. To prevent such inconsistencies, the deletion needs to be handled appropriately. Algorithm 3 shows the algorithm to handle such scenarios.

figure c

4.5 e-BPRIM development and deployment

The fourth phase of the AMME lifecycle focuses the development of a modeling tool. In the following, we will thus concentrate on the realization of a multi-view modeling tool for e-BPRIM, called adoBPRIM. For this purpose, we utilize the meta-modeling platform ADOxx [2]. ADOxx provides an integrated development environment for developing graphical modeling tools. A comparative analysis of ADOxx and other meta-modeling platforms can be found in [46, 72, 77]. The decision to choose ADOxx was motivated as follows:

  • ADOxx is a multi-user platform that provides a meta-model and model repository based on a relational database.

  • ADOxx enables the definition of modeling languages, their graphical representations, and required mechanisms & algorithms without any advanced programming experience. For instance, ADOxx Library Language (ALL) serves the specification of classes, relationclasses and model types defining the meta-models of the modeling languages. The GRAPHREP language serves to define their graphical representation. The ATTRREP language serves the specification of the attribute visualization. Finally, the AdoScript language serves the implementation of mechanisms & algorithms working on the models.

  • ADOxx supports the implementation of a multi-view modeling tool by providing features like automated model creation and algorithms for analysis, query, and transformation of models.

  • In the past twenty years, tool support for more than 50 domain-specific modeling languages has been successfully realized with ADOxx both in academia (see [41] for an overview) and industrial projects.

Fig. 9
figure 9

Excerpt of the implemented e-BPRIM modeling language (syntax and notation)

Full size image

To implement the e-BPRIM multi-view modeling tool, the e-BPRIM meta-model as shown in Fig. 6 was first transferred to corresponding ALL specifications and the graphical notations of the e-BPRIM concepts were implemented with the GRAPHREP language. The most challenging part was the realization of the operations between e-BPRIM views (shown in Fig. 8) as executable AdoScript algorithms.

As can be derived from Fig. 9, the Risk concept forms part of three e-BPRIM viewpoints: Risk-Extended BP, Risk, and Risk Taxonomy. Each of these viewpoints is realized as one model type in ADOxx. Depending on the e-BPRIM view the risk has been deleted from, different automatism have been implemented to ensure consistency. Generally, two cases need to be differentiated as shown in Algorithm 3. Either the Risk was deleted in the Risk Taxonomy view, or it has been deleted in the Risk view or the Risk-extended Business Process view. In the former case, all occurrences of the deleted risk need to be deleted in all other e-BPRIM views, and, if existing, a corresponding Risk view for the deleted Risk needs to be deleted. In the latter case, only the synchronization list needs to be updated by removing the instance id of the deleted risk, and, if existing, also a corresponding Risk view needs to be deleted.

A considerable amount of time during the development of the e-BPRIM tool was dedicated to the automated positioning of modeling objects that where created during the execution of multi-view operations. As such, Algorithm 1 in Sect. 4.4.2 exemplified the positioning of the new elements in the target view by copying the x/y coordinates of the corresponding objects in the source view. This copying approach is implemented for all extension and reuse e-BPRIM operations (see Table 5). In other scenarios, for example, the synthesis of the Risk Model, a meaningful initial positioning is proposed by using default horizontal and vertical offsets for all concepts. Although automated positioning might appear trivial or even unimportant, such functionality has a strong influence on efficiency and ease of use of the modeling tool.

The last phase of the AMME lifecycle focuses the deployment of a modeling tool. In the e-BPRIM case, the prototypical implementation will be transitioned from the development environment into a stand-alone tool, which will be provided as an installation package through the OMiLABFootnote 1.

5 Evaluation

The following section comprehensively describes the evaluation of the e-BPRIM modeling tool. Section 5.1 first describes the different research questions and maps the corresponding evaluation experiments. The results of the evaluation are then presented in Sects. 5.2 and 5.3. Eventually, threats to validity will be discussed in Sect. 5.4.

It is important to stress that, consistent to the focus of this paper, which is on the conceptualization of multi-view modeling for BPRIM, the following evaluation also focuses on how multi-view modeling compares to diagram-oriented modeling based on aspects of usability, quality of models, and efficiency of modelingFootnote 2. The results gained from this evaluation are primarily significant for BPRIM whereas they also establish a first theoretical contribution toward a generic comparison of the two different ways of working with multiple views.

5.1 Research questions

Overall, this paper aims to answer the research question How to conceptualize multi-view modeling for e-BPRIM? This question is further decomposed into the following three research questions, aiming to justify the use of the multi-view e-BPRIM modeling approach, to compare it with a diagram-oriented approach [12], and to argue about the quality of the created models and the efficiency of their creation. A dedicated evaluation technique has been used for testing each hypothesis. The evaluation is based on a comprehensive modeling case study which was conducted by two groups. One group, comprising 21 participants, used a diagram-oriented e-BPRIM tool without any multi-view modeling support. The second group, comprising 20 participants, used the multi-view e-BPRIM modeling tool as described in the previous sections.

  • RQ1 Usability: Is there a difference in the usability of multi-view modeling tools compared to diagram-oriented modeling tools? To respond to this research question, participants needed to solve a modeling case with the two e-BPRIM tools. Afterward, we used the standardized SUMI (Software Usability Measurement Inventory) questionnaire [43, 60] to compare the usability of both tools.

    The hypothesis underlying this RQ is: H-1: Modeling with the multi-view modeling e-BPRIM tool is perceived more useful compared to using a diagram-oriented one.

  • RQ2 Model Correctness: Is there a difference in the quality of created models with a multi-view modeling tool compared to a diagram-oriented one? To evaluate whether participants utilizing the multi-view e-BPRIM tool produce models in better quality with respect to correctness, we validated the semantic consistency of the created case study models of both groups independently.

    The hypothesis underlying this RQ is: H-2: Models created with the multi-view e-BPRIM modeling tool have less semantic inconsistencies compared to using a diagram-oriented one.

  • RQ3 Modeling Efficiency: Is the modeling process with a multi-view modeling tool more efficient compared to a diagram-oriented one? To respond to this research question we measured the time spent by the participants of both experiment groups to solve the exact same case study.

    The hypothesis underlying this RQ is: H-3: Modeling a complex system with the multi-view e-BPRIM modeling tool is more efficient compared to using a diagram-oriented one.

Fig. 10
figure 10

Sample Business Process View (a), Risk Taxonomy View (b), Risk-extended Business Process View (c), and Risk View (d) for the modeling case study in the e-BPRIM tool

Full size image

5.1.1 Modeling case study

The Medication-Use Process (MUP) ensures medications are used and secured in the most appropriate manner in complex health care environments [76]. The MUP is a multidisciplinary process, involving numerous practitioners and is composed of several stages (i.e., prescribing, dispensing, administration and medication monitoring). Indeed, it may involve up to 46 activities from the moment a doctor considers prescribing medication to the moment when this medication is actually administered or taken by the patient.

The complexity of this process increases the likelihood and number of occurrences of Medication Error (ME) risks. These risks may occur during any stage of the MUP from prescription to medication administration and can be at the origin of Adverse Drug Event (ADE) with potentially severe clinical consequences for the patient [33]. Due to this complexity and the aim to design the case study in a way that it is complex enough to be expressive with respect to the multi-view aspects while being solvable in approximately 60 minutes, the case study focuses on the Contextualize and Assess lifecyclce phases of e-BPRIM. Participants were asked to create a Business Process View, a Risk Taxonomy View, a Risk-extended Business Process View, and a Risk View.

The modeling case study centers the first stage of the MUP, the prescription of medication. The Prescribing stage is the action of a legitimate prescriber to issue a medication prescription/order which can be described as follows: The process begins when a patient comes to a health care system. A legitimate prescriber then performs an assessment that varies in comprehensiveness according to the circumstances and may include a review of the medical history, physical examination, and review of medications. Once a patient assessment is finished, a decision is made to initiate a new medication, change the current regimen, continue therapy as prescribed, and/or discontinue a medication. This decision represents a key transition point in the prescribing stage. Finally, the legitimate prescriber must write a medication prescription/order and an administration plan. The latter will be sent to the care unit and the medication prescription/order will be sent to the pharmacy and subsequently recorded in the patient’s medical folder. Lack of knowledge of the prescribed medication, its recommended dose, and of the patient details exemplify only a few risks, the medication prescription process is exposed to [81]. Such risks include the dose, quantity, indication, and prescription of a contraindicated medication.

The modeling case study consists of the following steps (corresponding to an excerpt of the e-BPRIM modeling procedure in Fig. 5):

  1. 1.

    A \(V_{BP}\) should be built that corresponds to the medication prescription process. It should describe operational roles, required data, and a set of related and collaborative activities to prescribe a medication for a patient. A sample solution is provided in Fig. 10a by means of the \(VP_{BP}\).

  2. 2.

    A \(V_{RTa}\) should be built that provides an inventory and a classification of potential ME risks related to the medication prescription process. A sample solution of a Medication Errors taxonomy is provided in Fig. 10b by means of the \(VP_{RTa}\).

  3. 3.

    A \(V_{R-BP}\) should be built that relates the risks introduced in the Risk Taxonomy view to the prescription process described in the Business Process. A sample solution of a Prescribing process extended to Medication Errors is provided in Fig. 10c by means of the \(VP_{R-BP}\).

  4. 4.

    A \(V_{R}\) should be built that describes all relationships of a selected risk in all e-BPRIM views. A sample solution of the Overdosage ME risk is provided in Fig. 10d by means of the \(VP_{R}\).

Figure 10 shows a sample solution to the case study. The solution shows all four models as screenshots of the developed e-BPRIM modeling tool and highlights the syntactic overlap relationships (indicated as blue dotted arrows) identified for the case study. For example, the Improper Dose Risk Class forms an OC between the Medication Errors Taxonomy view (b) and the Overdosage view (d). This OC refers to the (R11) syntactic overlap relationship identified in Fig. 6 and described in Table 4. Also, the Overdosage Risk forms both an OC between the Medication Errors Taxonomy view (b) and the Prescribing process extended to Medication Errors view (c), referring to the (R4) syntactic overlap relationship and an OC between the Medication Errors Taxonomy view (b) and the Overdosage view (d), referring to the (R10) syntactic overlap relationship.

Table 6 e-BPRIM evaluation results differentiated by type of modeling support
Full size table

5.2 Evaluation results

Table 6 summarizes the results of our comparison between the multi-view e-BPRIM tool and the diagram-oriented tool. Results show, that the former significantly outperforms the latter in all three evaluation criteria.

With respect to H-1, we can state, that the usability of the multi-view e-BPRIM tool is \(42.68\%\) higher in total and also higher in all five usability subscales of the SUMI questionnaire (see [60, p. 190f.]). Interestingly, the biggest differences are in the subscale Affect and Learnability. Affect evaluates whether the general emotional reaction [60, p. 190] to the e-BPRIM tools whereas Learnability evaluates the speed and facility with which users feel they mastered the system or learned to use new features [60, p. 190]. The smallest gap, but still a gain of \(15.31\%\), is for the subscale of Controlability indicating that participants for both tools felt that they are in control of the software. This is an important aspect, as the multi-view support automates several manual tasks and one could suggest that as a result, inexperienced participants would feel not in control compared to conventional diagram-oriented modeling where every action is triggered by the modeler.

Based on these evaluation results, we can confirm H-1—the multi-view e-BPRIM tool has a higher usability compared to a diagram-oriented e-BPRIM tool. Following the evaluation schema of SUMI, the multi-view e-BPRIM tool is generally performing very well, i.e., significantly above the threshold of 50 in each scaleFootnote 3 Thus, even this first prototype of the multi-view e-BPRIM tool is evaluated very positive.

With respect to H-2, the correctness of the models, the authors analyzed the created case study models of each participant individually and compared the results. Two different categories of errors have been differentiated: modeling errors, and semantic errors. A modeling error is given when a wrong relation type is used or when the direction of a relation is wrong. A semantic error on the other hand only concerns the semantics encoded in an e-BPRIM model. Semantic errors are given when two overlapping concepts have different names in different models, or when the R-BP model does not contain all aspects of the underlying business process model it is supposed to extend.

Models created with the multi-view e-BPRIM tool have on average only 0.315 modeling errors compared to 5.476 for the diagram-oriented e-BPRIM tool (a decrease of 94.23%). What concerns the semantic errors, the models created with the multi-view e-BPRIM tool have zero errors, whereas models created with the other tool have on average 1.19 semantic errors. In total, 61.90% of the case study solutions created with the diagram-oriented e-BPRIM tool had semantic errors—a serious deficit with respect to practical readiness of the tool and a limitation regarding the value of the models. The fact, that the multi-view e-BPRIM tool has zero semantic errors shows, that the implemented multi-view support mechanisms & algorithms work correctly.

Based on the evaluation results, we can confirm H-2—the multi-view e-BPRIM tool creates semantically correct models and significantly decreases the number of modeling errors compared to a diagram-oriented modeling approach.

With respect to H-3, the efficiency of modeling, we tracked the time required by the participants to solve the modeling case study with the two tool versions. Looking at the data, we can conclude, that the average modeling time using the multi-view e-BPRIM tool was 35 minutes and 13 seconds whereas participants using the diagram-oriented e-BPRIM tool took in average almost 48 minutes.

Based on the evaluation results, we can confirm H-3—the multi-view modeling decreases the time required for modeling by 26.54% compared to diagram-oriented modeling. This is even more interesting as we recognized that most of the participants using the diagram-oriented tool copy & pasted some of the overlapping concepts.

5.3 Qualitative feedback

After the participants finished the case study and concluded the SUMI questionnaire, they were also able to provide some feedback on aspects they liked and disliked the most. Interestingly, more than one fourth (28.57%) of the participants using the diagram-oriented e-BPRIM tool disliked the usability of the provided tool and stressed some linkage between the models or some means of synchronization would be meaningful.

25% of the participants using the multi-view e-BPRIM tool explicitly mentioned the synchronization between the models and the modeling support, e.g., in automated R-BP generation as the things they liked the most. Potentials for further improvement were also provided, e.g., a proper documentation, more informative pop-up messages during the modeling process, and with the most mentions, 20% stressed they would have liked more modeling languages integrated into the e-BPRIM tool.

5.4 Threats to validity

Aside from the multi-view modeling support both tools were identical with respect to the underlying meta-model, the look & feel of the platform, the user interaction etc. Also, the modeling case study and all other parameters potentially threatening the validity of the results were controlled to ensure an identical setup. This research is of course still not free from threats to validity. In the following, we will discuss how we addressed the four generic threats to validity in empirical software engineering research [82].

“Threats to construct validity refer to the extent to which the experiment setting actually reflects the construct under study.” [82, p. 103f.] In order to address this threat, we decided not to design a questionnaire but instead use the standardized and well established SUMI questionnaire for the usability evaluation. The other constructs, i.e., the time as a measurement for efficiency and the number of modeled errors for model correctness are well documented in the literature (cf. [44]) and widely adopted.

“Factors that impact on the internal validity are how the subjects are selected and divided into different classes, how the subjects are treated and compensated during the experiment, if special events occur during the experiment etc” [82, p. 102] In our experiments, we mostly relied on students (bachelor, master, and PhD) at the institutions the first author is affiliated to. All participants had at least some prior knowledge in process modeling and received a proper introduction to Risk-aware Business Process Management (R-BPM) as well as to e-BPRIM as a methodology. Participation was voluntary and no compensation was provided. Moreover, we used different groups to test the two e-BPRIM tools independently and assigned the participants to the groups randomly. As a last threat to internal validity, we also made sure that the participants of both groups were not aware of the core evaluation focus, i.e., comparing multi-view modeling from diagram-oriented modeling. To omit some language barriers, we provided the SUMI questionnaire in the mother tongue of the participants.

External validity concerns “the ability to generalize experiment results outside the experiment setting.” [82, p. 104] In our case, the gained results are based on R-BPM as a domain and e-BPRIM as one concrete method. However, we are confident that some of the evaluation results can be generalized to a level of comparing different types of modeling support—independent from any modeling method. We present the first research, to the best of our knowledge, that empirically evaluates the influence of the type of modeling, i.e., multi-view vs. diagram-oriented modeling, on usability, efficiency, and quality of models. Consequently, we believe our results indicate that multi-view modeling is a very promising approach toward handling complexity in modeling and can be applied to other domains, such as requirements engineering and enterprise architecture management, as well.

One threat to the reliability of the results is the limited sample size. We perceive this evaluation as a milestone concluding the first design cycle. Motivated by the positive feedback gained, we will continue equipping further e-BPRIM model views with multi-view support in future design cycles and also involve more participants in the evaluation.

6 Conclusions

Being one of the fundamental aspects of the R-BPM domain, the integration of risk and business process concepts in models requires a very complex meta-model comprising many concepts to be considered simultaneously. Modeling these aspects is of increasing complexity due to diversity of risk and business process aspects and the different concerns of involved stakeholders. By reverting to multi-view modeling, this complexity can be reduced.

In this paper, we conceptualized a multi-view modeling R-BPM framework based on the BPRIM method, called e-BPRIM. Following the Agile Modeling Method Engineering lifecycle, we reported on the requirements, the design, the formalization, and the development and deployment of a new multi-view modeling method and tool for e-BPRIM. An extensive evaluation was then conducted to assess the quality of our contribution by comparing the multi-view e-BPRIM tool with a diagram-oriented one.

This research theoretically contributes first empirical insights that indicate, that multi-view modeling could outperform diagram-oriented modeling in specific contexts. Concretely, we show that the e-BPRIM tool outperforms the diagram-oriented version by means of the efficiency of modeling, the quality of the created models, and the perceived usability.

We are currently in talks with our practice partners in the health care sector that also evaluated the previous BPRIM method and tool [46, 70, 71] in order to involve them in a comprehensive practical effectiveness evaluation of e-BPRIM. Furthermore, we aim to generalize the theoretical contribution toward design guidelines for multi-view modeling methods. The practical contribution of this research is the developed AdoBPRIM modeling tool which is made openly available to R-BPM practitioners.