Keywords

1 Introduction

Collaborative processes are recursive ones where two or more people or businesses work together toward an intersection of common goals by sharing knowledge, learning, and building consensus, according to Wikipedia. Business Process Management Notation (BPMN), well-known for its structural philosophy, is not efficient for modeling such processes, as BPMN work-flows are designed to be strict, unadaptive to changes as well as not supportive to decision-making and collaboration [12]. On the other hand, alternative-to-BPMN languages such as Case Management Modeling and Notation (CMMN) tend to facilitate and support organizations that would prefer to view their process as cases, where participants exchange data and ideas to fulfill a specific goal, e.g to “close” the case, while there are no strict rules restricting their interaction [8]. One of the main differences between CMMN and languages like BPMN is the paradigm shift from prescriptive to declarative [2]. This differentiation in modeling philosophy was the major issue we faced when requested to participate in a project to consult a public organization on exploring a collaborative process and develop the appropriate software to support it.

More specifically, we were involved in ReWeee Initiative employed by Appliances Recycling SA, alongside with more the twenty of its collaborators both Greek and foreign, to promote electronic product exchange and consequently reduce electronic waste. We were assigned the design and implementation of a collaborative platform to promote electronic equipment exchange. Our first task constituted of the user requirements analysis stage, where we should identify how the electronic equipment exchange should take place and the way a software platform may promote the overall process. All the partners involved were participating in the requirement analysis process and apparently argued on the way exchange should be performed. Thus, we identified the need to provide them with a model of the process to promote discussion. For the purpose, we decided to employ Case Management Modeling and Notation as an alteration to BPMN, an attempt also made in [10].

According to its standard, CMMN, was primarily designed supplementary to BPMN, in order to model and analyze parts of a process, better suited to be handled as Cases. Such an attempt of combining BPMN with CMMN in order to model highly flexible and variable processes was done in [13]. In our case, the goal was to utilize CMMN as a standalone methodology for modeling a collaborative process, like electronic equipment exchange. However, with being a new standard, there currently was some uncertainty about the applicability of CMMN in real-world scenarios as is also claimed in [5].

The rest of the paper is structured as follows. In Sect. 2, details about the ReWeee Project and the collaborative platform that we had to develop are provided, presenting the requirements that should be satisfied referring to both user-to-user interaction and user-platform interaction. In Sect. 3, the modeling notation for Case Management is briefly presented, namely, its core features and how these can be combined in order to model a process. In Sect. 4, we discuss the modeling process using CMMN. Different modeling teams designed alternative models for the exchange process. Their different perspectives were identified and the design philosophy of each model is annotated. In Sect. 5, the questions set to the modeling teams are presented, along with the answers given, while further discussion takes place identifying issues that need further exploration towards CMMN adoption. The final section refers to the conclusions that can be drawn from this experience report, setting future work for further research and exploration by the authors.

2 ReWeee Initiative

The LIFE ReWeee Initiative aims to prevent the creation of Waste Electrical and Electronic Equipment (WEEE) and is co-ordinated by employed by Appliances Recycling SA. This initiative includes a major action promoting the donation and exchange of EEE in a national-scale fashion, while a web-based collaborative platform, namely the ReWeee platform, should be developed to bring together organizations and individuals participate in this action [1]. The main goal of the platform to facilitate and promote Electrical and Electronic Equipment exchange and donation among households or households and public/private bodies. Its success lies within the social communication between volunteers and their collaboration in order to achieve the best possible result.

2.1 Case Description: EEE Exchange

We considered the EEE exchange process as a case to be completed with the collaboration of all interested parties. Our first task was to obtain an abstract description of the case from Appliances Recycling SA. When talking about a collaborative platform, our client had in mind a short of social application or wiki, thus, this is the first-level description of EEE exchange case as provided to us. When described by ReWeee management team, a user-centered approach was followed [11], based on the assumption that their were prescribing what different kinds of participants should do in the context of a collaboration environment.

“First of all, there are two types of users. These are guest and registered users that differentiate themselves in the permissions that they get granted as far as the use of the platform is concerned.

More specifically, when any unregistered user visits the web platform for the first time, he gets prompted to register, by creating a user account. This account can be created either by signing up via an email and a password or by signing up via a social network account, which requires his/her giving to the platform the necessary permissions for using personal data. After a successful registration, the, from now on, registered platform user, is able to submit an advertisement donating or exchanging an item, to declare interest for an existing EE product and propose an offer to acquire it, as well as to communicate with any other user who owns a desirable electric device.

Moreover, a registered user is not only able to search a product based on some conditions, namely, filters like item categories, item state, donating-user region, but also to either suggest changes regarding the item’s category for which he/she is searching, or even to comment in an advertisement that he/she had expressed interest for. That way, the appropriate users will be notified for either the category change proposal or the commenting in an advertisement.

Finally, registered users have a profile in which they are able to be notified for any recycling actions taken via a news-feed as well as being informed for general topics regarding recycling and its benefits. Within each user’s profile, a calendar exists via which a user can be informed for any recycling events taking place.”

3 CMMN Language

The focus of the CMMN specification is the notation, the meta-model, interoperability between tools, and minimum execution semantics [7]. The main objective of Case Management Modeling and Notation is to define a common meta-model and notation for modeling and graphically expressing a Case. A Case involves actions taken regarding a subject in a particular situation to achieve a desired outcome. Traditional examples are Cases that refer to legal and medical working environments, where a legal Case involves the application of the law to a subject in a certain fact situation, and a medical Case involves the care of a patient in the context of a medical history and current medical problems. The subject of a Case may be a person, a legal action, a business transaction, or some other focal point around which actions are taken to achieve an objective. The situation commonly includes data that inform and drive the actions taken in a Case [9].

A case contains all elements of a CMMN model. There are two phases for each case. Design-time phase, during which, business analysts prepare the case execution by modeling the case. Once a case has started to being executed, the case is in the run-time phase. In this phase, the case workers are working on achieving the case objectives [5]. A CMMN model primarily comprises the following case items:  

Task: :

Tasks describe activities that can be executed during the run-time phase. Four types of tasks are supported: human (performed by a knowledge worker), process (to embed a process, e.g. a BPMN model), decision (to embed a decision, e.g. a DMN model) and case (to embed other cases e.g. other CMMN models);

Stages: :

Stages are containers for case elements. They allow structuring a case hierarchically.

Milestones: :

Milestones represent a target and thereby allow checking the progress of a case.

Event Listener: :

An Event Listener captures events, which are things that “happen” during a case. Events may trigger, for example, the enabling, activation, and termination of stages and tasks, or the achievement of milestones.

Sentries: :

Sentries allow defining temporal-logical dependencies between stages and/or tasks, “watching out” for important situations to occur (or events), which influence the further proceedings of a case. If a stage or task has a sentry attached, it can only be started if the precondition defined by the sentry is fulfilled. Sentries also represent a combination of conditions and events that define the sequence of tasks to be implemented [11].

Case File Item: :

A Case File Item represents a piece of information of any nature, ranging from unstructured to structured, and from simple to complex, and can be defined based on any information modeling language. In knowledge-intensive work, documents are typical outputs of tasks or stages.

Connectors: :

Connector serves to visualize complex dependencies between elements; It also represents the standard events that drive the flow of the Case.

Discretionary Items: :

These identify an item, of which instances can be planned, to the “discretion” of a case manager [2, 5].

 

Case management is concerned with determination of which tasks are applicable, or which follow-up (discretionary) tasks are required, given the state of the Case. Decisions and flow may be controlled by events or new facts that continuously emerge during the course of the Case, such as the receipt of new documents, completion of certain casks, or achieving certain Milestones. Individual tasks that are planned and executed in the context of the Case might be predefined procedural processes in themselves, but the overall Case cannot be orchestrated by a predefined sequence of tasks. Finally, the meta-model and notation are used to express a case model in a common notation for a particular type of Case, and the resulting model can subsequently be instantiated for the handling of a particular instance of a Case [9].

4 Modeling EEE Exchange with CMMN

Based on the description provided in Sect. 2.1, one could easily conclude that EEE exchange could not be effectively modeled using BPMN, as the sequence of activities unpredictable and random. However, a visual model of the process would be useful during user requirement analysis stage. For that reason, we identified it as a Case that could be modeled using CMMN, which enables the modeling of such activities in a more fluid fashion.

To evaluate whether CMMN is easy to use by modelers, two modeling groups we established, consisting of a BP modeling expert, a junior modeler and a developer each, all familiar with BPMN. None of them was familiar with CMMN. Both groups were provided with a short case description (see Sect. 2.1) and a chance to interview ReWeee management team. The purpose of the study was to identified potential obstacles in CMMN adoption. The groups studied CMMN standard and relevant literature and resulted in a EEE exchange case model using CMMN. Both of them interviewed ReWeee experts and ask for additional information on the provided description. No interaction between the modeling groups was allowed. The two models produced were extensively different, a not anticipated outcome, as discussed in the following. We consider both models to be valid in terms of utilizing CMMN concepts. Though, they project two different perspectives as far as both the level of analysis and design philosophy is concerned, as shown in Figs. 1 and 2.

4.1 Analytical Perspective

The first one of the models is described in Fig. 1 below. It presents the functionality that the collaborative platform provides to its users, highlighting the interaction between the various activities included in the ReWeee Case.

Fig. 1.
figure 1

EEE exchange case from an analytical perspective.

Full size image

What can be commented for this modeling attempt, is that its design logic was based in analytically depicting what the user of the collaborative platform should be enabled to do, as narrated by ReWeee management team. As the end-users had in mind a description of the case as a sequence of available screens by a collaboration platform, the modeling team adapted their perspective. What is primarily modeled is which are the events that lead the case from one state to another (in practice from one screen to another) without having in mind which activities are mandatory or not. For that reason, the is no use of discretionary tasks [9], while the majority of actions are linked to each other. Finally, data queried during the platform life cycle are emphasized, while EEE exchange case milestones are not modeled. It is attempted to describe the case in detail so as to ensure that nothing is going to be skipped during implementation.

4.2 Abstractive Perspective

The second model for the EEE exchange Case, is shown below on Fig. 2. It also projects, like the first one, the whole functionality provided from the ReWeee platform, but in contrast with the first one it emphasizes on which actions are mandatory for the EEE exchange case to be completed successfully. More analytically, there is an extensive use of discretionary tasks, while there is a large amount of activities that are not connected with each other. Data created during the Case lifecycle are hardly under consideration in this model, but on the contrary milestones are defined to highlight anything that is considered as important for the ReWeee Case, while stages are also modeled in order to isolate the less important parts. What could be commented is that this modeling attempt comprehends CMMN nature better, but the model created it is quite likely to deviate from the actual implementation as it is not taken under consideration. Contrariwise, it is attempted to ensure that the end-user has understood the EEE exchange case components.

Fig. 2.
figure 2

EEE exchange case from an abstractive perspective.

Full size image

5 Reflections

5.1 Rising Questions

As the first model (see Fig. 1) seems to be more complex and structural that the second one (see Fig. 2), one could argue that the first modeling team fail to understand how to use CMMN, while the second one succeeded. In the following, we discuss the results of interviewing both teams and explore what drove them to adopt their perspective. At the end of our discussion, we concluded it is not as straightforward as it seemed to explicitly choose or dismiss one perspective. The questions set to two modeling groups are presented, alongside with the arguments given from them. The modeling experience of both groups was discussed, with some queries as a basis, in order to explore their willingness to adopt CMMN in modeling similar Cases. These queries referred to: the modeling objective of their attempt, what difficulties they faced in modeling the Case and what would be the difference in modeling the EEE exchange Case with BPMN. The following table (Table 1) presents a summary of the arguments provided from the modeling groups.

Table 1. Queries and Arguments for the two modeling perspectives
Full size table

In principal, the analytical model (Fig. 1) had as its primary aim to describe exchange case flow in detail, having the visitor of ReWeee platform in mind. It was an effort to precisely describe the user experience expected as exposed by ReWeee management team. Emphasis was given to the correlation of tasks representing each possible step of the overall process in great detail. Furthermore, focus is given to depict the way EEE exchange Case will be automated, without missing any of the projected functionality. That leads to a quite descriptive model which seems more relevant to a BPMN model than one modeled with CMMN. On the other hand, the abstractive model (Fig. 2), attempts to define which ones of the Case activities are mandatory so as to complete the Case by making extensive use of the Discretionary Task notation element. That way, a high level of abstraction is provided to the model, making it easily readable and to comply with CMMN philosophy. Though it lacks in information about Case Data or how Model elements are correlated.

Moreover, the ease of modeling was also discussed with the two modeling groups. For the one that modeled EEE exchange Case in an analytical way, Sentries [9] were the most facilitating feature of CMMN, enabling them to model transitions in the case’s state. Having the projection of the sequence of activities as their main goal, this feature was the one that helped them the most at their modeling attempt. The other group, that created the abstractive model, find the ease of modeling lying to the use of Discretionary Tasks for modeling less important Tasks. That way, the mandatory Tasks, that lead to Case completion, could be highlighted.

On the other hand, both of the groups referred facing difficulties during the modeling of the EEE exchange Case. For the first group, that modeled the process analytically, it was difficult to identify how to model the flow of the process. Namely, they could not identify easily how sequence is represented. For that reason they utilized extensively the notion of Sentry, using events not only to project the control of flow but also to describe how the completion of a Task could commence another Task. However, that made their model quite complex, not familiar with CMMN. On the contrary, for the other group that modeled the ReWeee process in a more abstractive fashion, it was difficult to define the exact correlation between the Case activities. That led them to model a mass of Tasks, independent to each other, which was quite unusual for the modelers and that also led to an undefined sequence of activities. As it was commented in the model description above, that could likely make the model deviate from the actual implementation.

Finally, concerning the differentiation from BPMN, the analytical model had a design philosophy very close to the one of the BPM, as it had the representation of the sequence of the Case activities as its main objective. Extensive data modeling and strict sequence definition made the modeling very close to the philosophy of BPM. The final model looked different from a corresponding BPMN model just because the differentiation in notation elements. On the contrary, the abstractive model projected the functionality provided by the projection of the Tasks available but in a quite different way from a BPM model. There was not such a thing like sequence representation, while data were completely out of frame. This fact led the model to look like more than a definition of Tasks without taking under consideration the correlation between them. It may followed the philosophy of CMMN but the Case representation was not anywhere near an implementation model.

5.2 Discussion

The two models, seem to be conflicting to each other nearly in every query that was set. Firstly, they had quite opposing perspectives. The first (Fig. 1) seemed to focus on modeling the automation of EEE exchange case, handling tasks in a unified fashion, regardless if these were mandatory or optional for the Case completion and, in general, modeling nearly everything that one would like to know for the Case before automating it. The second (Fig. 2) focus exactly on the opposite. Having the identification of the main tasks and the distinction between mandatory and optional tasks as main objective, it is unimportant for the modeler to represent sequence and correlation of tasks in great detail. The reason can be given through the fact that the second model complies totally with the philosophy of CMMN that, as was mention in its description earlier in this paper, does not focus on defining automation properties. However, one should have in mind the CMMN is claimed to provide for executable models [7].

Different goals, led to different views on the Case modeling. For the first group, the projection of case automation related details was the main reason of finding difficulties in complying with CMMN. Case Management Modeling and Notation addresses Cases from a different point of view from BPMN. While BPMN offers only limited precautions for ad-hoc adaptations, CMMN provides a way for modeling cases where the logical dependencies may be optional [5]. To attempt the substitution of BPMN with an alternative modeling language, is quite tricky since a substitution in modeling philosophy is also necessary. A misunderstanding could lead to have a complex model, not complying with the methodology provided, that has no differentiation with BPMN in the way modeling of tasks is handled. On the other hand, having a model with quite distinct tasks, not connected with each other, made it harder for the modelers to find correlations between the Case activities and highlight how tasks are instantiated. This could not help anyone who would like to automate the case, as important components are missing like data and events.

The discussion above, led as to the conflicting consequence that a descriptive CMMN model like the one of Fig. 1, which could be considered as “executable”, looks in way quite alike as a BPMN model, in terms of identification of flow. However in the CMMN model, utilizing Sentries the conditions (e.g. recorded events) to enable a task execution are identified and the events generated by its execution are also recorded. The main difference distinguishing BMPN and CMMN has to do with the way representing flow, in an analogy referring to the difference between UML activity and state diagrams, both representing behavior.

On the contrary, an abstractive model like Fig. 2, leads to a model easily identified as a Case Management model, describing a Case. However, modelers claim automation details might be missing, which are important to implement the ReWeee platform. It should be noted that CMMN adoption should not be restrictive on the selection of the platform used for the case automation.

This contradiction on the way CMMN can be employed is what the authors of this paper identify as the most important issue arising. While CMMN seems ideal for modeling Cases in an declarative manner in design-time, it provides no guidance on how to represent a running case, e.g. a way to ensure that case models could be executable, as is highlighted in [5]. Trying to define such an “executable” CMMN model was in practice the fact that caused confusion in the first modeling group.

Towards this direction, the following questions are identified for future reference.

  1. 1.

    Whether CMMN could depict executable models, in a sense similar to BPMN, that nevertheless will comply with its philosophy should be further explored. Using existing tools, it may only become executable in practice as a supplementary part of BPMN [3], as indicated in its standard.

  2. 2.

    CMMN extensions could be proposed so as to depict executable models, considering the fact that at this stage of research it seems unable to satisfy such requirement. Such an example is examined in [6]. The extension should keep the main philosophy of CMMN unchanged, retaining it declarative, while it should provide automation to promote execution capability. Ideally, such extensions should be general enough to be supported in different case management support platforms.

  3. 3.

    What are the parameters of such an executable CMMN model should be identified, along with its design requirements and its main parameters, namely the main ingredients that could make CMMN models executable. The term “executable” should also be explored in a difference sense complying with CMMN philosophy. While the existence of a CMMN engine may not always be a desired property, the support of task and case templates as well as data management utilities may be of use.

6 Conclusions and Future Work

Our experience using CMMN to model collaborative processes was discussed in this work. What can be concluding is the fact that we have a new modeling notation for flexible and variable process, identified as Cases, which could be accepted as an alternative to BPM methodology at least in modeling the design-time of a process. Considering the difficulties of learning a new non traditional BPM alternative as is mentioned in [4], the CMMN models projected earlier in this work, describe a collaborative process in an acceptable way, without any loss of the activities modeled.

However, according to our experience, it is not obvious how to employ CMMN to model processes or cases, resulting in executable models as provided by BPMN. There have been directions in literature towards this end, and considering its continuously growing reputation Case Management seems promising for providing to process modelers what BPMN lacks of, namely, flexibility in the process modeling. Towards this end, we set as future challenges to find responses to the questions set in the discussion. Additionally, a further evaluation of CMMN language could take place, considering the modeling experience of other modeling groups in similar Cases.