1 Introduction

The adoption of service-oriented architectures and workflow automation has allowed information systems to become more interconnected, reducing the complexity in digitizing the communication among different organizations. As a result, every business organization operates in digital ecosystems where cooperation is mandatory [5]. Such ecosystems can be conceptualized in terms of multi-party business processes: every party performs some internal tasks and communicates with the other parties if some information is needed to perform the internal tasks or if some results can make the others able to perform their own tasks. While this communication increases the opportunities for the involved organizations, the side effect is that every party is a potential source of failures with impacts on the entire ecosystem. For example, a party could stop working for internal reasons and all the parties which depend on the information that the failing one is responsible for might fail as well, resulting in a domino effect.

In this context, a proper design of resilient business processes becomes fundamental. Resilience concerns the ability for a system to cope with unplanned situations in order to keep carrying out its mission [3]. In particular, making a multi-party business process resilient means to help the organization to cope with the complexity of the process and to avoid or mitigate possible failures that might affect the involved organizational structure [1]. To tackle the above challenge, in our previous works [4, 6], we presented a data-centric approach to improve the resilience of multi-party business processes at design-time. The approach considers data dependencies among the involved parties, and relationships between process tasks/milestones and data are taken into account to identify the sources of possible failures, their impact, and thus improve the process model to make it resilient against these failures. To this aim, a maturity model for resilience awareness was proposed, based on a modeling notation extending OMG CMMN (Case Management Model and Notation). The maturity model is organized in 5 different resiliency levels, which allow designers to: (i) model at an increasing degree of detail how data and milestones should be defined to achieve resilient by-design processes, and (ii) quantify the distance between a process model and the complete achievement of a resiliency level.

In this paper, starting from the rigorous formalization of the maturity model provided in [4], we discuss its concrete implementation through the development of R-CMMN, a modeling tool for designing resilient by-design CMMN process models. R-CMMN not only allows us to precisely quantify the percentage of compliance of a CMMN model with respect to a specific resiliency level, but it is also able to suggest how refining a process model to reduce the possible impact of failures caused by missing or unreliable data at run-time.

The rest of the paper is organized as follows. Section 2 introduces the background to understand the tool functioning, namely an introduction to CMMN, a running example and the rationale of the maturity model. Section 3 provides an overview of the R-CMMN development and features. Finally, Sect. 4 reports some experimental results that demonstrate a good usability of the tool.

2 Background

Short Introduction to CMMN. CMMN provides a set of constructs that help the modeler to design a business process in terms of states in which the tasks can be (or cannot be) performed. The main concept of CMMN is the case that is defined by the case file (data managed in a case), the case plan (how the case evolves), and the case roles (the stakeholders). CMMN does not focus on the order in which the tasks are performed, but on the dependencies between the different states of execution of the process based on information stored in the case file. In more detail, a case plan (represented as a manila folder) is a composition of stages (represented by a rectangle shape with angled corners). The stages represent the episodes of a case which, in turn, could contain other stages or tasks, i.e., atomic units of work. Tasks and stages can be characterized by the entry and exit criteria represented by white and black diamonds. These criteria define when a task or a stage opens and when they can be considered as closed. The milestones (represented by ovals) express that certain intermediate goals in the case can be reached when some condition(s), modeled using entry criteria, are satisfied. Finally, listeners (represented by circles) represent events that might occur during the execution of the case plan and that could determine the start or the end of a task or stage. Concerning the information model, CMMN simply includes the possibility to specify data objects (typical document shape) without any specific restriction on their format or content.

Fig. 1.
figure 1

CMMN diagram of the running example

Full size image

Running Example. Having quickly introduced the main elements of CMMN, we refer to the running example shown in Fig. 1 representing a realistic case study [6] concerning a process that collects data coming from a set of sensors. These sensors monitor the behavior of the customers inside a shop. Every week, these data are analyzed to create a report that constitutes the basis for creating marketing reports useful to identify marketing strategies (e.g., how to better distribute the items in the shelves, etc.). The case plan is composed by three main stages (i.e., Sensor data acquisition, Data analysis, and Marketing analysis). While the data analysis starts every Monday and closes when a report is produced, the other two stages always run as neither entry nor exit criteria are defined. The entire case closes when the conversion rate (the ratio between people entering into the shop with respect to the people that buy some goods) becomes acceptable for the shop owner. Finally, as defined in the sensor data acquisition stage, it is possible to express some dependencies between the tasks. In fact, the sensor reading tasks start only when the sensors have been completely installed. As previously mentioned, the information model provided by CMMN is not so rich. For this reason, we can simply add data objects to the stages to clarify which are the data that are considered when a stage is running.

Maturity Model. With the aim to classify multi-party business processes in terms of their degree of resilience awareness, the main contribution of our previous work [4] is the rigorous formalization of a maturity model that organizes 5 increasing levels of resilience awareness in a coherent framework where the actions to be taken in order to enhance the by-design resilience are identified.

  • Level 0 – No resilience awareness. At this level, a process is designed without taking into account the data unavailability/unreliability that might cause failures during the execution. As a result, no countermeasure in case of such situations is defined. The process shown in Fig. 1 belongs to this level.

  • Level 1 — Failure awareness. At this level, failure-aware processes are designed to have a clear map of which relevant data are subject to failures, as well as the impact of these failures.

  • Level 2 — Data resilience. At this level, on the basis of the information about the sources of failures and their potential impacts, the designer can specify if there are alternative data sources and how to reach them.

  • Level 3 — Milestone resilience. At this level, the designer defines, for each milestone, a new alternative milestone that represents a status that can terminate process execution in a reasonable way.

  • Level 4 — Process resilience. At this level, based on the information about alternative data and milestones, the designer can embed in the process a recovery strategy indicating how these alternatives could be managed to improve their quality to a level that is equivalent to the original service.

3 R-CMMN

From a technical perspective, R-CMMN has been developed as a plugin of cmmn-jsFootnote 1, an open source rendering toolkit and web modeler provided by Camunda to design CMMN 1.1 modelsFootnote 2. R-CMMN is written in JavaScript, thus it can run into any modern browser requiring no server back-end. While cmmn.js provides basic features to model a CMMN process, i.e., it is based on a drag-and-drop palette to move and combine CMMN constructs into a visual workspace, with R-CMMN we have extended cmmn.js with additional features that allow designers to: (i) systematically increase the level of resilience of a process model, and (ii) quantify the distance between a process model and the complete achievement of a resiliency level. The resilient aware version of the process in Fig. 1, modeled with R-CMMN, is shown in Fig. 5. The features introduced by R-CMMN are:

Fig. 2.
figure 2

Connecting tasks to case file items (a) and setting criticality values to them (b)

Full size image
Fig. 3.
figure 3

Connecting alternative case file items/milestones to their primary counterparts

Full size image

  • the ability to connect case file items to tasks or event listeners (that was not possible in traditional CMMN) and specify the nature of the operations on them (e.g., create, read, predicate on, etc., cf. Fig. 2(a)). For example, in the process of Fig. 1, a designer can express the fact that the Marketing actions task leads to the creation of a new marketing report that predicates on the event listener acceptable conversion rate (cf. the resilient process in Fig. 5).

  • the possibility to define a criticality value (ranging among five values, from “none” to “critical”) for each case file item, to identify the data that might have more impact in case of their unavailability. For example, a designer can express that the lack of sensors data in the process of Fig. 1 would have a high impact on the other parties by selecting the ‘H’ option from the context pad of the case file item in question, which can be opened clicking on the lighting bolt icon, as shown in Fig. 2(b). The criticality value of a case file item is graphically provided through an integer number in the top left corner of its icon, with ‘1’ meaning “maximum criticality”, and ‘0’ meaning “no criticality”. Note that associating any case file item having a not-null criticality to a task is sufficient to achieve Level 1 of the maturity model.

  • two additional constructs to specify alternative case file items and alternative milestones, which can be connected to their primary counterparts (with a shape identical to them, but with a dashed border) to enable the achievement of levels 2 and 3 of the maturity model, respectively (cf. Fig. 3(a) and (b)). If the designer is aware that no alternative case file item/milestone is possible for a primary one, than its icon will be explicitly labeled with an ‘X’. For example, in the process of Fig. 1, two alternative sources can be defined: public data as an alternative to sensors data and the Data mining task, and market analysis to be used instead of the report produced by the Marketing actions task. Similarly, an alternative milestone low quality report can be coupled with the primary milestone report available (cf. Fig. 5).

  • the possibility of defining priority chains of alternatives attached to a primary case file item or milestone. The priority of an alternative element within the chain is graphically provided through an integer number in the bottom left corner of its icon, with ‘1’ meaning maximum priority.

  • a new type of event listener, called error event listener (having a lightning bolt marker within the event shape), that represents the situation in which the use of an alternative case file item having a not-null criticality causes the enactment of a recovery strategy embedded in a novel type of stage, namely the recovery stage (having the same shape of a traditional stage, but with a dashed outline). In the resilient process of Fig. 5, in case the quality of public data is not considered sufficient, a recovery strategy – defined by a recovery stage – is required. In our example, the goal of the recovery stage is to support the achievement of the alternative milestone low-quality report by providing a Data fixing task able to increase the low-quality public data in a set of revised public data which will be used by the Data mining task.

Fig. 4.
figure 4

Measuring the percentage of compliance with a resiliency level

Full size image

In addition, for any resiliency level formalized in the maturity model, the tool enables to quantify the percentage of complianceFootnote 3 of a process model with respect to the resiliency level of interest, taking into account the different values of criticality of the modeling elements. Pushing the button “Check Level”, located in the left bottom side of the workspace (cf. Fig. 5), a dialog box is shown that reports a percentage value that measures the distance between the model and the complete achievement of the next resiliency level, together with some suggestions to refine the process model towards achieving it (cf. Fig. 4).

The complete source code to setup and run R-CMMN, and a video tutorial of the tool in action, are available at: https://github.com/bpm-diag/R-CMMN.

4 User Evaluation and Conclusion

To the best of our knowledge, R-CMMN is currently the only implemented tool that allows to design process models taking into account the concept of resilience, thus no comparison was possible against other process modeling tools, being them not resilience-driven. For this reason, we opted to measure the degree of usability of the user interface (UI) developed for R-CMMN. To this aim, we employed the SUS (Software Usability Scale) questionnaire, which is one of the most widely used methodology to measure the users’ perception of the usability of a tool [2]. In SUS, any statement is evaluated with a Likert scale that ranges from 1 (“strongly disagree”) to 5 (“strongly agree”), and at the end of the computation an overall score is assigned to the questionnaire. The score can be compared with several benchmarks presented in the research literature to determine the degree of usability of the tool being evaluated. In our test, we made use of the benchmark presented in [7], which associates to each range of the SUS score a percentile ranking varying from 0 to 100, indicating how well it compares to other 5,000 SUS observations performed in the literature.

Fig. 5.
figure 5

The resilient aware version of the process in Fig. 1, modeled with R-CMMN

Full size image

The evaluation was enacted with a group of 16 Master students in Management Engineering during the last lecture of the course of Processes Management and Mining held in the academic year 2019/2020 at Sapienza University of Rome. Many of the students involved in the test declared to be knowledgeable (50%), skilled (12.5%) or expert (12.5%) in modeling processes with BPMN and CMMN (both the languages were covered during the course), while only the remaining 25% consider themselves as novice in process modeling.

After a preliminary short training session to introduce the concept of resilience in process modeling and describe the usage of R-CMMN, starting from the (not-resilient) process shown in Fig. 1 and its informal description, the students were requested to systematically increase its resiliency level using the features and feedback provided by the tool. All the students were able to complete their tasks within the maximum available time (20 min). As soon as a student completed the task, we administered her/him the SUS questionnaire, consisting of the traditional 10 statements typical of the original SUS [2].

Fig. 6.
figure 6

Computation of the SUS overall score

Full size image

The collection of the ranks associated to any statement of the SUS is reported in Fig. 6, together with the SUS Final Score and the associated percentile, calculated following the procedure discussed in [7]. Since the average SUS score obtained by the tool was 79.8, according to the selected benchmark [7], the usability of the tool corresponds to a rank of A-, which indicates a degree of usability among very good and excellent.