Iris Reinhartz-Berger, Wided Gu´edria, Palash Bera, S´ergio Guerreiro Michael Fellmann, Matthias Weidlich
BPMDS 2017 RADAR
in the 18th International Working Conference on
Business Process Modeling, Development and Support (BPMDS)
EMMSAD 2017 RADAR
in the 22nd International Working Conference on Evaluation and Modeling Methods for Systems Analysis and Development
(EMMSAD)
EMISA 2017
8th International Workshop on Enterprise Modeling and Information Systems Architectures (EMISA)
Essen, June 12-13 2017
BPMDS 2017 Radar, EMMSAD 2017 Radar, and EMISA 2017 Workshop Proceedings
Jens Gulden
University of Duisburg-Essen
Universit¨atsstr. 9, 45141 Essen, Germany [email protected]
Selmin Nurcan
Universit´e Paris 1 Panth´eon - Sorbonne 21, rue Broca, 75240 Paris cedex 05, France [email protected]
Iris Reinhartz-Berger University of Haifa
Carmel Mountain, Haifa 3498838, Israel [email protected]
Wided Gu´edria
Luxembourg Institute of Science and Technology
5 Avenue des Hauts Fourneaux, L-4362, Esch-sur-Alzette, Luxembourg [email protected]
Palash Bera
Saint Louis University
3674 Lindell Blvd., St. Louis, MO, 63108, USA [email protected]
S´ergio Guerreiro
Universidade de Lisboa, Av. Rovisco Pais 1, 1049-001 Lisbon, Portugal INESC-ID, Rua Alves Redol 9, 1000-029 Lisbon, Portugal
Michael Fellmann University of Rostock
Albert-Einstein-Str. 22, 18059 Rostock, Germany [email protected]
Matthias Weidlich
Humboldt-University Berlin
Unter den Linden 6, 10099 Berlin, Germany [email protected]
Copyright c 2017 for the individual papers by the authors. Copying permitted only for private and academic purposes. This volume is published and copyrighted by its editors.
Joint Keynote of BPMDS and EMMSAD
Domain Specific Conceptual Model Engineering (abstract) . . . 5 Heinrich C. Mayr
BPMDS 2017 Radar
Preface and Organization . . . 7 Jens Gulden and Selmin Nurcan
Research in progress
Using Patterns for Communicating About Flexible Processes . . . 12 Ralf Laue and Kathrin Kirchner
Using a Fractal Enterprise Model for Business Model Innovation . . . 20 Ilia Bider and Erik Perjons
Enabling Compliance Monitoring for Process Execution Engines . . . 30 Marwa Hussein, Ahmed Awad and Osman Hegazy
Defining Auto-Adaptive Modeling Interfaces Based on Stakeholder
Proximity. . . 38 Alexander Nolte and Jens Gulden
Designing Visual Decision Making Support with the Help of Eye-tracking 47 Barbara Weber, Jens Gulden, and Andrea Burattin
Unsupervised Event Abstraction using Pattern Abstraction and Local
Process Models. . . 55 Felix Mannhardt and Niek Tax
Towards Assessing the Theoretical Complexity of the Decision Model
and Notation (DMN). . . 64 Faruk Hasi´c, Johannes De Smedt and Jan Vanthienen
Lessons learned from practice
Analyzing the Trajectories of Patients with Sepsis using Process Mining . 72 Felix Mannhardt and Daan Blinde
Beyond Activities: Business Process Models from a Knowledge
Management Perspective. . . 81 Pavel Kraus and Gil Regev
Preface and Organization . . . 90 Iris Reinhartz-Berger, Wided Gu´edria, Palash Bera, S´ergio Guerriero
Architectural Intelligence: a Framework and Application to e-Learning. . . 95 Jan Martijn Van Der Werf, Casper van Schuppen, Sjaak Brinkkemper, Slinger Jansen, Peter Boon, and Gert van der Plas
Towards Modeling Monitoring Services for Large-Scale Distributed
Systems with Abstract State Machines. . . 103 Andreea Buga and Sorana Tania Neme¸s
A Proposed Method in Agile Practices to Create Requirements
Documentation and Test Cases . . . 113 Palash Bera and Abhimanyu Gupta
Combining Top-down and Bottom-up Enterprise Modelling. . . 122 John Krogstie and Snorre Fosland
EMISA 2017 Workshop
Preface and Organization . . . 130 Michael Fellmann and Matthias Weidlich
PhD Proposals
Mining Projects from Structured and Unstructured Data. . . 133 Saimir Bala
Design and evaluation of a web-based modeling platform to support the learning of conceptual modeling and of studying the corresponding
learning processes. . . 138 Benjamin Ternes
Leveraging process mining techniques for up-to-date resource profiles . . . . 143 Mathijs Creemers and Mieke Jans
Novel Directions
Towards Hyperscale Process Management. . . 148 Kevin Andrews, Sebastian Steinau, and Manfred Reichert
Misalignment Symptom Detection with XML-based Enterprise
Architecture Model Analysis . . . 153 D´ora ˝Ori
Microservices-based Business Process Model Execution . . . 158 Agnes Koschmider
Joint Keynote of BPMDS and EMMSAD
Heinrich C. Mayr
Alpen-Adria-Universit¨at Klagenfurt
Universit¨atsstr. 65–67, 9020 Klagenfurt am W¨orthersee, Austria [email protected]
Abstract. Models are the fundamental human instruments for manag- ing complexity and understanding. As such they play a key role in any scientific and engineering discipline as well as in everyday life. Many modeling paradigms evolved over time in the various disciplines which lead to a huge variety of modeling languages, methods and tools. This in particular is true for Informatics, which is a modeling discipline per se, and since long tries to systematize the realm of modeling by (1) clarifying the hierarchy of model layers like e. g. in MOF (meta object framework), (2) introducing ontological commitments into model hierarchies for a bet- ter semantical grounding, (3) harmonizing various modeling approaches to unified/universal ones, and (4) providing a framework for a system- atic domain specific modeling method (DSMM) design where universal approaches fail.
Still, there is much to be done; in particular, to make systematic modeling an everyday activity in any domain of Information Systems and Software Development. But this requires a methodological modeling framework that is both, flexible enough to be applied in diverging fields, and rigid enough to pass assessments and certification as is standard practice in engineering disciplines.
The talk will sketch candidate building blocks of such a framework. First, by means of some examples, attention will be drawn to what is still going wrong in the modeling domain. Based here on and on a taxonomy of modeling method characteristics, the practicability and the effectiveness of these building blocks will be discussed using Ambient Assistance as an example modeling domain.
Short bio: Heinrich C. Mayr has been a full professor of Informatics at Universitt Klagenfurt since 1990, leading the Application Engineering Research Group. Until then he was an assistant professor at the Univer- sity of Karlsruhe (today: KIT), visiting professor at several universities, and CEO of a German software company. His research is documented in over 200 publications and includes information system design methodolo- gies, requirements and model engineering, and knowledge management.
He has held, amongst many other functions, that of President of the Gesellschaft f¨ur Informatik (GI). For 6 years he served as Rector of the University. Currently he is editor in chief of the “Lecture Notes in In- formatics”, chairman of the ER steering committee, chairperson of the
council of the Software Internet Cluster SIC, and Member of the TC Wirtschaftsinformatik of the German Accreditation Organisation ASIIN.
BPMDS 2017 RADAR
in the 18th International Working Conference on
Business Process Modeling, Development and Support (BPMDS)
Essen, June 12-13, 2017
BPMDS 2017 Radar Proceedings
The topics addressed by the BPMDS series, in conjunction with CAiSE (Con- ference on Advanced Information Systems Engineering), are focused on business processes and their IT support. This is one of the keystones of Information Sys- tems theory beyond short-lived fashions. The continued interest in this topic on behalf of the Information Systems community is reflected by the success of the past BPMDS events and by their promotion from a workshop to a working conference. The BPMDS series produced 17 events from 1998 to 2016. From 2011, BPMDS has become a two-day working conference attached to CAiSE.
The basic principles of the BPMDS series are:
1. BPMDS serves as a meeting place for researchers and practitioners in the areas of business development and business applications (software) develop- ment.
2. The aim of the event is mainly discussions, rather than presentations.
3. Each event has a theme that is mandatory for idea papers.
4. Each event’s results are, usually, published in a special issue of an interna- tional journal.
The goals, format, and history of BPMDS can be found on the website:
http://www.bpmds.org/.
BPMDS RADAR solicits short papers related to business process modeling, development, and support. We invited interested authors to contribute short papers in the two categories “research-in-progress” and “lessons learned”, using a separate call-for-papers especially for short paper submissions.
Research-in-progress papers present preliminary results that may not have been fully validated yet. The work presented, however, is advanced enough to show its contribution and significance.
In the lessons learned from practice category we welcome all practitioners to share with BPMDS participants and followers their own experiences in the topics related to the BPMDS conference.
BPMDS 2017 received 11 short paper submissions from as many countries (Algeria, Belgium, Canada, Egypt, Germany, Malta, Sweden, Switzerland, The Netherlands, UK, and USA), out of which 9 short papers were eventually se- lected. Most of the short papers have been directly submitted to the BPMDS RADAR track. A few from the main conference (2 among the accepted 9) have been re-evaluated “from scratch” by the program committee in their shorter form. Each paper received four reviews from the members of the international program committee. The most important criteria for RADAR papers was the contribution and the significance of the research ideas (research-in-progress) and the added value of the feedback from industrial/practical experience (lessons learned from practice).
All short papers were submitted with a maximum length of 8 pages. The final versions published in these proceedings were allowed to be extended to up to 10 pages length.
8
RADAR for having shared their work with us, as well as the members of the BPMDS 2017 program committee, who made a remarkable effort in reviewing the submissions. We also thank the organizers of CAiSE 2017 for their help with the organization of the event, and IFIP WG8.1 for the support.
May 2017 Jens Gulden
Selmin Nurcan
9
Selmin Nurcan Universit´e Paris 1 Panth´eon - Sorbonne, France Jens Gulden University of Duisburg-Essen, Germany
Steering Committee
Ilia Bider Stockholm University and IbisSoft, Sweden Selmin Nurcan Universit´e Paris 1 Panth´eon - Sorbonne, France Rainer Schmidt Munich University of Applied Sciences, Germany Pnina Soffer University of Haifa, Israel
Industrial Advisory Board
Ilia Bider Stockholm University and IbisSoft, Sweden Pascal Negros Arch4IE, France
Gil Regev EPFL and Itecor, Switzerland
Industrial Track Chairs
Rainer Schmidt Munich University of Applied Sciences, Germany Jens Gulden University of Duisburg-Essen, Germany
Program Committee
Jo˜ao Paulo A. Almeida Federal University of Espirito Santo, Brazil Eric Andonoff Universit´e Toulouse 1, France
Judith Barrios Albornoz University of Los Andes, Venezuela Kahina Bessai Loria University of Lorraine, France Ilia Bider Stockholm University and IbisSoft, Sweden
Karsten Boehm FH KufsteinTirol - University of Applies Science, Austria
Lars Brehm Munich University of Applied Science, Germany Dirk Fahland Technische Universiteit Eindhoven, The Netherlands Claude Godart Loria University of Lorraine, France
Renata Guizzardi Universidade Federal do Espirito Santo, Brazil Jens Gulden University of Duisburg-Essen, Germany Amin Jalali Stockholm University, Sweden
10
Marite Kirikova Riga Technical University, Latvia
Agnes Koschmider Karlsruhe Institute of Technology, Germany Marcello La Rosa Queensland University of Technology, Australia Jan Mendling Vienna University of Economics and Business, Aus-
tria
Michael Moehring Aalen University of Applied Sciences, Germany Pascal Negros Arch4IE, France
Jens Nimis University of Applied Sciences Karlsruhe, Germany Selmin Nurcan Universit´e Paris 1 Panth´eon - Sorbonne, France Oscar Pastor Lopez Universitat Politecnica de Valencia
Elias Pimenidis University of the West of England
Gil Regev Ecole Polytechnique F´ed´erale de Lausanne, Switzer- land
Manfred Reichert University of Ulm, Germany
Hajo Reijers Vrije Universiteit Amsterdam, The Netherlands Iris Reinhartz-Berger University of Haifa, Israel
Colette Rolland Universit´e Paris 1 Panth´eon - Sorbonne, France Michael Rosemann Queensland University of Technology, Australia Shazia Sadiq The University of Queensland, Australia
Rainer Schmidt Munich University of Applied Sciences, Germany Stefan Sch¨onig University of Bayreuth, Germany
Samira Si-Said Cherfi CEDRIC - Conservatoire National des Arts et M´etiers, France
Pnina Soffer University of Haifa, Israel Roland Ukor FirstLinq Ltd, United Kingdom Barbara Weber Technical University of Denmark
Matthias Weidlich Humboldt-Universit¨at zu Berlin, Germany Jelena Zdravkovic Stockholm University, Sweden
Alfred Zimmermann Reutlingen University, Germany
Additional Reviewers
Aa, Han van der Knuplesch, David Andrews, Kevin Schunselaar, Dennis Aysolmaz, Banu Steinau, Sebastian
11
Flexible Processes
Ralf Laue1 and Kathrin Kirchner2
1 University of Applied Sciences of Zwickau, Department of Computer Science Dr.-Friedrichs-Ring 2a, 08056 Zwickau, Germany
2 Berlin School of Economics and Law, Alt-Friedrichsfelde 60, 10315 Berlin, Germany [email protected]
Abstract. We describe the experiences from a project in the medical domain where processes were modeled in modeling sessions in close co- operation with physicians. In this project, we experienced difficulties in modeling flexibilities within processes. Flexible and knowledge-intensive processes do not follow a fixed sequence of steps, but rely on knowledge and experience of the medical staff. During the process execution process, the actors can decide for additional steps, change the execution order or skip a task. In standard business process modeling languages, it is not clear how to model such flexible situations.
We observed, however, that many flexible situations can be described by recurring patterns. We argue that those patterns can be used as build- ing blocks for communication among the stakeholders. The advantage is that those building blocks are close to the vocabulary that is used when domain experts describe a process. The patterns can support the process modeler to recognize flexible situations in processes. In addition, a pattern catalog can recommend a way to model such situations in a suitable way in a standardized modeling language.
1 Introduction
In the research project Process Intelligence in Healthcare (PIGE, see www.pige- projekt.de) four different complex medical processes were modeled in several levels of detail (liver transplantation, living donor liver transplantation, hepa- tocellular carcinoma and colon rectal carcinoma). The project ran from 2010 to 2013 at the University Hospital Jena, Germany. A modeling session involved typically 2-3 physicians with experiences in the required process as well as 1-2 process modeling experts. Depending on the process and the required level of de- tail, further participants, e.g., nurses or administrative personal, were invited to the session or interviewed. From our experience with process modeling projects [2] the PIGE team (including the second author of this paper) learned that a close collaboration with process participants is useful in modeling. For this pur- pose, there is a need for a notation that describes process models in a way that is understandable also for non-modeling experts. Such a notation helps to elicit a process together with all stakeholders and to achieve a high model quality [4].
Fig. 1.Example of modeled BPMN process with annotation
In this paper, we build upon our practical experiences in modeling processes in the medical domain. We introduce patterns for the early stage of business process modeling. The aim of our patterns is to speak about variable parts of a process (model) using a vocabulary that is close to domain experts’ understand- ing.
2 Lessons Learned from Practice
A medical treatment process is a typical scenario for a flexible process. Physi- cians decide dynamically which treatment is needed depending on the health status of the patient. A certain order of steps is known advance, e.g., that some preliminary examinations have to be carried out before an operation. The se- quence of these examinations might change due to availability of medical devices and physicians at a certain moment.
In our modeling projects, we used the language BPMN for documenting medical processes. The reason for this decision was that BPMN is the current industry standard for business process modeling. If a process was (partly) flexi- ble, the PIGE team experienced the following ways to model variability:
1. Only the typical process was modeled (covering only the control flow used in ≈80% of all cases) or the process was modeled at a low level of detail.
This might be all right for domain experts who are already involved into the process. However, it is not easy for new employees to understand the process and possible options in full detail because some information is missing.
2. Text annotations were used to write down possible additional steps or alter- natives in natural language (see Fig. 1)
3. All possible different pathways were modeled as shown in Fig. 2(a). Here, task A is an optional step, while B and C can be carried out in an arbitrary order (but not in parallel). In case of a lot of alternative pathways, the number of branches becomes very high and thus, make it confusing to understand the process. Therefore, this option was used very rarely in our modeling sessions.
One problem in modeling flexible processes is the fact that there is no 1:1 correspondence between constructs of modeling languages such as BPMN and
the vocabulary that is frequently used by domain experts. For example, in our project the physicians often use phrases such as “if executed successfully” or
“if executed successfully in time”. This applies to activities which can have an outcome that is interpreted as “positive” or “negative”. An example of a positive outcome would be that some antibody is found in a blood-test. Note that this notion of “executed successfully” is different from the fact that the blood-test has been completed properly (without exception). Of course, BPMN allows to model the different outcomes of an activity by using an XOR split gateway followed by two labeled sequence flow arcs. However, using such constructs in a modeling workshop quickly leads to relatively large models for situations that can be expressed very shortly as e.g. “If needed, activity A is executed, afterward B and C are performed in arbitrary order”. A possible notation that can replace Fig. 2(a) is shown in Fig. 2(b). This model would be easily understandable by domain experts, but is not in line with syntactically correct BPMN models that are needed by workflow engines.
3 Patterns for the Early Stage of Business Process Modeling
The concept of patterns means to document known solutions to recurring prob- lems which are known to work well in a given context. Before the concept of pat- terns was introduced in the field of business process modeling, semantic patterns have already been used for for creating unambiguous textual use case specifica- tions. [5] discusses four patterns “Sequence”, “Constraint”, “Concurrency” and
“Repetition” which can be regarded as patterns occurring between activities in a process. In the area of business process modeling, the the most popular work on patterns are the workflow patterns [9]. These patterns have been widely used by practitioners, vendors and academics. They are helpful for selecting a work- flow system that corresponds to the needs of an organization and for evaluating the expressiveness of modeling languages. Workflow patterns provide an answer to the question which elements a workflow engine or modeling language should have in order to be useful in a given context. While this is a very important question, it is a rather technically-oriented point of view.
We brainstormed about typical situations in a process that are described by the stakeholders verbally as one fact. This means that the object of investiga- tion was which building blocks are frequently used when people communicate about a process. An example for such a building block is when stakeholders
(a) Process in BPMN (b) Same process
Fig. 2.Process Example in BPMN and Using Pattern Blocks
say that activities are “performed at the same time / in parallel”, etc. This is clearly different from the technically-oriented terminology of the workflow pat- terns which describe this situation as a combination of the patterns “Parallel Split” and “Synchronization”. The human-oriented perspective of our patterns also means that it is important to use pattern names that can be understood and used intuitively by domain experts.
Based on our modeling experience, we identified a set of linguistic patterns that are frequently used to express common situations (and in particular variabil- ity) in processes. Using those patterns as “process building blocks” in a workshop with practitioners avoids large graphical models that might be difficult to read for some stakeholders. On the other hand, we do not lose preciseness, because each pattern can be transformed into formal modeling languages.
In addition to the most basic patterns (such as parallel execution, see [4]), the following patterns have been identified:Optional Executionand the very similar pattern Execute only if..., Repeat Activity Until Success (with a variant where the number of repetitions is limited by some number), Activity Must Succeed in a Given Time,Perform in Any Order,Try Alternatives Until Success (with two variants “ordered” and “in any or- der”),Pass All Tests(with three variants which will be discussed below) and Additional Activity Necessary (with several variants describing the time when this additional activity should be executed). Using those patterns allows using terse models such as Fig. 2(b) in modeling workshops.
Due to space limitation, we can only give examples of three patterns here.
We selected patterns that relate to a series of tests. Such situations occur quite often in medical processes, but also in other domains (e.g., approval procedures).
Our pattern catalog is organized by pattern templates. Each template con- tains the pattern name, the visual representation, a description of the situation where it is used and an example where this pattern occurred in a real process.
For the purpose of this paper, the examples have been taken from the living liver donation process modeled in the PIGE project. Here, a healthy person who is closely related to the patient, donates a part of liver to that patient. Before the transplantation process, the donor undergoes an evaluation process to make sure that she/he is healthy enough and aware of procedures and consequences. Next, the pattern template contains a paragraph “Related Patterns” with references to sources where variants of this pattern have been discussed.
In addition to the extract published in this paper, the full pattern template also contains guidance how this pattern can be expressed in BPMN. This part can contain a discussion about modeling variants. In addition, some of the pat- terns contain a paragraph “Considerations for Optimization” which discusses challenges for process improvement in the given situation. It suggests questions and recommendations that can be worth discussing in a process workshop.
In the following subsections, we present the three variants of Pass All Tests. Please note that every time when we use the term “activity”, it can refer either to a single (atomic) task or to a sequence of several tasks. Without limiting generality, in our diagrams we restrict ourselves to two tests.
3.1 Pass All Tests (Ordered)
Problem: Some object has to undergo a series of tests. The order in which the tests should be executed is known beforehand. The process can proceed by executing the next activities only if all tests have been passed successfully. As soon as the first test fails, another path in the process flow is taken, and no further tests are necessary.
Example:A prospective liver donor needs to undergo a blood test to investigate the compatibility to the patient’s blood. In case the blood is not compatible, the donor is not suitable, and no further tests are necessary. Otherwise, an investi- gation by a psychologist is planned. Here, too, the donor can be found to be not suitable if there are any contraindications.
Related Patterns: The iterative approval of an object (such as a document) by multiple organizational roles is discussed as Iterative Approval pattern in [8]. In [7], the iterative approval of a document by multiple organizations has been discussed. However, the solution from [7] works only if all approval tasks and all roles who are responsible for the approvals can be regarded as being essential the same task/role.
3.2 Pass All Tests (Any Order)
Problem:Some object has to undergo a series of tests. The order in which the tests should be executed has to be decided at run time. The process can proceed by executing the next activities only if all tests have been passed successfully.
As soon as the first test fails, another path in the process flow is taken, and no further tests are necessary.
Example: After the blood compatibility and psychological testing, a number of further investigations and tests are necessary. Their sequence can be decided by the medical personal, depending on the free time of specialists and the availabil- ity of CT and MRI scan devices, etc. If a mayor contraindication is found, the donor is not suitable, and no further tests are necessary. A transplant operation can only be planned if the whole evaluation procedure is completed successfully.
3.3 Pass All Tests (Parallel)
Alternative names: All-or-nothing[1]
Problem: Some object has to undergo a series of tests. These tests can be done in parallel (to be executed by different actors).
Example:While the prospective liver donor is undergoing medical investigations, medical consultations (meetings among physicians from different disciplines) can take place to discuss the case and discuss possible contraindications.
4 Discussion and Outlook
Our proposed patterns can be directly used in a modeling session and support the modeling of flexible process parts. While discussing the process, domain experts explain their activities and use phrases for expressing flexibility, e.g.,
– The number of investigations on this list can usually be carried out in any order: This corresponds to our patternPass All Tests (Any Order). – The first important step is ... the next step is ... If it fails, the whole procedure
is canceled: This calls for our patternPass All Test (Ordered). – While the patient is still ... other investigations...: This leads to our pattern
Pass All Tests (Parallel).
The application of our flexible patterns as building blocks can help to trans- fer the process description of a domain expert to a valid BPMN model. We will illustrate this with an example from the living liver donor evaluation process.
In one modeling session, the evaluation process was discussed together with the physicians. During the evaluation, several investigations have to me made to decide whether the person can donate a part of her/his liver. The physicians explained the rough process of donor evaluation: After drawing blood to test whether it is compatible with the receiving patient, the person has to pass a psychological test. Here, the motives for the donation are discussed and it has to be evaluated whether the donor can face consequences and risks. Afterward, physical investigations and some other investigations are undertaken. If at any point of these investigations a contraindication occurs, the evaluation process ends, because the person cannot donate a part of her/his liver. Using our pat- terns, this high level description leads to our Pass All Tests (Ordered) pattern. This information leads to the overall picture shown in Fig. 3. The + sign at the bottom center of some tasks shows that the details are elaborated in a more specific diagram.
Next, for thePhysical examinationsubprocess, the physicians explained that a number of investigations have to be done. For some of them, a special device is needed, that might be busy at the moment. Furthermore, a medical doctor from another department might be needed. Depending on the availability of those resources, an investigation might be postponed and another one can be done earlier to avoid waiting time. Needed investigations are written on on a paper evaluation list. If one investigation is planned with a concrete time, the date (and later also the result) is written down on the list. The nurses and physicians can see at a glance which investigations are still open, and whether a contraindication occurred. The possible donor has to undergo a number of investigations in any order, thus our patternPass All Tests (Any Order) can be used. All investigation results need to be positive in a way that the patient can be considered as a donor.
In the PIGE project, it turned out to be too confusing to model the execution of six tests in arbitrary order using only BPMN constructs. Therefore, a BPMN model with text annotations has been suggested (Fig. 4(a)). While the involved physicians understood the model thanks to their domain knowledge, the disad- vantage is that such models still tend to be large and confusing. Furthermore, no transformation to a formal language would be possible. In contrast to Fig. 4(a), Fig. 4(b) is easy to understand and can additionally also be equipped with a formal syntax by transforming it to a formally defined language such as BPMN.
One of the patterns discussed in Sect. 3 (Pass All Tests (Parallel)) was discussed by Simon [6]. With respect to a model depicting this pattern he argued that graphical business process modeling languages “either ... leave room for interpretation, of if they are precise, they reach such a degree of complexity that they are difficult to read and understood by somebody who has not developed the model in his/her own”. This statement illustrates the advantage of our approach:
Instead of complex models, we use rather simple building blocks for a discussion among the stakeholders while still providing the possibility to transform the model into a formal modeling language. An approach to transform such building blocks automatically to BPMN has been presented in a previous paper [4].
The usefulness of “building blocks” that are close to the usual vocabulary of the domain experts has been confirmed in nearly 20 interviews with process experts in various domains (see [3] for an overview). It follows the basic idea
Fig. 3.Living Liver Donor Evaluation: Overall Picture
(a) BPMN (Detail from a Larger Model) (b) Pattern Block Fig. 4.Subprocess: Physical Investigations of Living Liver Donor
that the modeling language should be adapted to the language that a domain expert uses in a modeling workshop - and not the other way round.
While the patterns we have already identified can be used to describe a considerable amount of situations, we do not claim that our pattern catalog is complete. Instead, we are sure that in order to cover more flexible situations in business processes, further patterns have to be identified in future. Furthermore, the usefulness of our patterns needs to be evaluated in more modeling sessions.
References
1. Gruhn, V., Laue, R.: Good and bad excuses for unstructured business process mod- els. In: European Conference on Pattern Languages of Programs (2007)
2. Kirchner, K., Malessa, C., Scheuerlein, H., Settmacher, U.: Experience from col- laborative modeling of clinical pathways. In: Modellierung im Gesundheitswesen:
Tagungsband des Workshops im Rahmen der Modellierung 2014. pp. 13–24 (2014) 3. Kirchner, K., Neˇskovi´c, S.: Using CUTA4BPM to support participative development of expert-driven processes. In: 2nd International Conference on Information Society Technology (2012)
4. Kirchner, K., Neˇskovi´c, S., Stojimirovi´c, D.: From user-understandable to technical process model: A model-driven approach using CUTA4BPM. In: 3nd International Conference on Internet Society Technology and Management (2013)
5. Rolland, C., Achour, C.B.: Guiding the construction of textual use case specifica- tions. Data Knowl. Eng. 25(1-2), 125–160 (1998)
6. Simon, C.: Incremental development of business process models. In: Workshop En- terprise Modelling and Information Systems Architectures. pp. 222–235 (2005) 7. Thom, L.H., Lazarte, I.M., Iochpe, C., Priego-Roche, L., Verdier, C., Chiotti, O.,
Villarreal, P.D.: On the capabilities of BPMN for workflow activity patterns repre- sentation. In: BPMN Workshop. LNBIP, vol. 95, pp. 172–177. Springer (2011) 8. Thom, L.H., Reichert, M., Iochpe, C.: Activity patterns in process-aware informa-
tion systems: basic concepts and empirical evidence. Int. Journal of Business Process Integration and Management 4(2), 93–110 (2009)
9. van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.: Work- flow patterns. Distributed and Parallel Databases 14(3), 5–51 (2003)
Using a Fractal Enterprise Model for Business Model Innovation
Ilia Bider and Erik Perjons
DSV - Stockholm University, Stockholm, Sweden [ilia|perjons]@dsv.su.se
Abstract. In their previous work, the authors have developed a new kind of en- terprise model, called fractal enterprise model, that connects enterprise processes via assets used for running these processes. One of the possible usages of this model is facilitating innovation, more exactly, changing or extending a business model used in the enterprise. This research-in-progress paper presents the idea of how such facilitation could be arranged, and lists the problems that need to be solved in order to convert the idea into a practical methodology. The discussion is based on a hypothetical example.
Keywords: process architecture, enterprise model, business model, innovation, business transformation
1 Introduction
In our previous work [1], we have introduced a Fractal Enterprise Model (FEM) which has a form of a directed graph with two types of nodes Processes and Assets, where the arrows (edges) from assets to processes show which assets are utilized by which pro- cesses and arrows from processes to assets show which processes help to have specific assets in healthy and working order, see Fig. 1, 2 and 3 (in Section 2). The arrows are labeled with meta-tags that show in what way a given asset is utilized, e.g., as work- force, reputation, infrastructure, etc., or in what way a given process helps to have the given assets “in order”, i.e., acquire, maintain or retire the assets. Building a FEM is supported by a set of archetypes that show what kinds of assets are needed for particular process types and which assets they can help to acquire, maintain and retire. An arche- type can be generic – applicable to all processes, or specific for some class of processes, e.g., acquiring stakeholders. Areas of applicability of FEM include, but are not limited to:
1. Finding “invisible” processes that exist/should exist in the enterprise or are related to a particular asset or process.
2. Arranging existing process documentation for better reusability, see [2]
3. Understanding interconnectedness of various parts of the enterprise, in particular, the multipurposeness of some assets and processes, see [3].
4. Assessing a proposed organizational change by pinpointing assets and processes that will be affected during intervention and showing how these are interconnected.
5. Preventing "organizational cancer" [4] when a supporting process starts behaving as though it were a primary one, disturbing the balance of the organizational structure.
6. Planning business model transformation, e.g., moving up in the value chain, as sug- gested in [5].
The objective of this paper is to present our current efforts for goal 6 – using FEM to support business model transformation/innovation. The topic of business model inno- vation became popular with the appearing of the business model canvas [6]. However, the canvas helps only in developing/depicting an existing or new model, but does not support the process of transforming an existing model into a new one that should sub- stitute the existing model or be a complement to it. Such transformation is done in an ad-hoc manner based on intuition. With such an ad-hoc type of transformation, there is a risk that a new model has no relation to the old one and does not take into considera- tion the capabilities and assets that already exist in the organization in question. As a result, a new model could be difficult, if ever possible, to implement.
The approach to business model transformation/innovation suggested in this paper consists of two steps: (1) generating hypotheses, and (2) assessing promising hypothe- ses. The first step is based on analyzing which asset(s) should be used in a new business activity. The second step consists of comparing a FEM for a new business activity with the FEM for already existing one, and assessing the differences. The paper presents the ideas of how these steps could be completed via using an artificial example in Section 2, which is followed by a discussion of current directions of our research in Section 3.
2 An Example
Consider an example, inspired by Amazon, of an enterprise the primary business of which is selling books over the internet. The business goes quite well, and the company decides on expanding its operations, but in another area. They need to generate hypoth- eses on what strategic direction to take, analyze them, assess the size of a change to be introduced, and create an implementation plan. In essence, the task of management is to develop and implement a new business model in addition to the already existing one, using as much of the existing organizational assets (capabilities) as possible.
Generating hypotheses can be started with creating a limited part of a FEM model, e.g., its upper level, to identify assets/capabilities that could potentially be used for de- veloping a new business model. An example of such FEM is presented in Fig. 1 that shows a part of the topmost level of FEM with a book sales process as the root and four assets supporting the process. Note, however, that this is not the full set of assets needed for the primary process, if needed, others, e.g., a stock of books, could be added.
Generating and deliberating hypotheses based on Fig. 1 could be done in the follow- ing manner:
1. Focus on the asset Private customers. Question: Can we sell something else to the same customers over internet using the same software and deployment platform?
The answer depends on the size and saturation of the market for particular products.
It might be too difficult to get a market share if the competition is hard.
2. Focus on the asset Packing and delivering staff. One possibility is to provide stock management, packing and delivering services for a bigger book-seller. However, it could be difficult to combine this with the company’s own book selling business.
3. Focus on the asset Webshop software. The Webshop software could be licensed to other book sellers, but it would result in helping the competitors.
4. Focus on the asset IT platform for Webshop deployment. The platform could be pro- vided as a general IT deployment platform. The market for such services is on the rise, and there is no direct risk of helping competitors in the book-selling business.
Fig. 1. The upper part of FEM
After considering four alternatives above, one or more could be chosen for further anal- ysis. Assume, for example, that the last alternative has been chosen, then the IT platform asset is moved as a node in a hypothetical new FEM tree and is expanded upwards and downwards, as shown in Fig. 2. Expanding up consists of adding a root of a new FEM tree which is IT platform for deployment as a service, where an asset IT deployment platform becomes an infrastructure asset to the new service process. Note that this asset is not exactly the same as in Fig. 1. In Fig. 1, the deployment platform is specific for the webshop software, while in Fig. 2, this is a general platform for deploying custom- ers’ software. Normally, such platform includes a virtual server, an operating system, one or more DBMS's, one or more webserver software, etc.
Expanding down means adding more assets to the root, and continuing the expansion of the assets by adding process nodes aimed and managing these assets. In particular, a beneficiary is added as an asset to the root, and processes aimed at managing asset IT platform for customer deployment are added to this node as well. The processes’ nodes are further expanded by adding the asset Platform specialists as Workforce supporting these processes (see Fig. 2).
At the next step, we need to compare the assets and processes in the old FEM tree (Fig. 1) with the ones in the new FEM tree (Fig. 2), expanding these trees as required.
The comparison is presented in Fig. 3 where both FEM trees are presented and links between similar assets and processes are drawn. The figure helps to discuss how much
of the existing processes and assets can be (re)used in a new business activity and how much needs to be built from scratch.
Fig. 2. Building a new FEM tree
The differences between components of the existing and new FEMs are presented in Fig. 3 as green dashed “horizontal” arrows. The green dashed “horizontal” arrows have labels that explain the differences. More explanations are presented below:
─ Beneficiary (customer) asset. As we can see from Fig. 3, the customers for a new business (on the right) are not the same as the customers for the existing business (on the left). The former are enterprises/organizations that rent an IT platform to run their own applications, while the latter are private customers who like reading books.
Thus a new set of processes to manage the new sort of customers is to be built, starting with sales and marketing processes to acquire new customers. However, some help for acquiring new customers could be obtain if we assume that decision makers in an organization are often book readers, and may have used the webshop in the past. As the webshop is user friendly and fast, there is a Reputation asset that supports the Customer retention process in the existing FEM. For those decision makers who have experience of buying books via the webshop, this reputation can be of value when deciding to use the general IT platform service. Therefore, reputa- tion Excellent technical platform based on customer experience could be moved
from the left hand side of Fig. 3 to become an asset to the Sales and Marketing of the new FEM, on the right side of Fig. 3.
─ Infrastructure asset related to the deployment platform. As has already been men- tioned, the platform for delivery as a service has a more general nature than for de- ployment of webshop. Some components need to be added and some deleted. In addition, for the webshop it is enough to have one platform which has enough power.
In the new business, each customer gets its own platform, and the power can vary from platform to platform.
─ Processes that manage the asset IT platform for customer deployment (i.e. the pro- cesses acquire, maintain and retire) have different nature than the ones that manage asset IT platform for Webshop deployment. For example, there is a need to create a new platform very quickly, as well as dismantle it quickly.
─ The difference can happen on the next levels of FEM tree as well. For example, the new business activity may require more Platform specialists, thus the Hiring process may need to recruit more personal each year than the existing process.
3 Research directions
The example from the previous section shows that FEM can be used for generating hypothesis and assessing them already today. However, the process is rather cumber- some with many manual steps and ad-hoc decisions. To ensure adoption of the approach by practice, the approach should be converted to a structured methodology with tool support. This, in turn, will require extension of FEM and building a computerized tool.
3.1 Extending FEM
The hypotheses generation step could be facilitated by a set of transformational arche- types. Such an archetype shows how to use an asset(s) further down in the existing FEM tree to create a new FEM tree based on that asset. As an example, the last two hypoth- eses considered in Section 2 can be considered as belonging to the archetype "Using an infrastructural asset for building a service of providing this asset to external customers".
In this case, a "supporting" asset becomes the main one on which the new business activity rests. This transformational archetype is visualized in Fig. 4.
Other examples of transformational archetypes could be as follows:
─ From manufacturer to designer: instead of manufacturing and selling own products, the company designs products for others. The new model can substitute the old one, but can also be used as a complement.
─ From designer to manufacture: having a good design capability and an idea of a new innovative product results in starting manufacturing and selling the product. Note that this transformational archetype is a reverse to the previous one.
Fig. 3. Comparing Two FEM trees
─ From educator to consultant: an education activity in a business/technical topic can be transformed to a consultant activity in the topic. This transformation is based on the asset of the type Workforce. Instead or in addition to being teachers, the workers become consultants.
─ From consultant to educator: a reverse archetype to the previous one.
Fig. 4. An archetype for becoming an infrastructure provider (generalization of Fig. 3).
Our plans regarding transformational archetypes include creating a list of possible transformational archetypes, formalizing them and finding historical examples where each archetype has been successfully implemented.
The hypotheses assessment step could be facilitated by extending FEM with quali- tative and quantitative characteristics of its nodes, so that it would be easier to compare nodes in the existing and new FEM. Both processes and assets nodes could be quanti- fied and qualified. For example, processes nodes could be quantified with:
─ Number of process instances completed per a time unit (year, month, or day) – max, min, average.
─ The average life length of the process instance.
─ Number of process instances that run in parallel – max, min, average.
It might be more difficult to quantify assets nodes. The measures for these nodes could depend on the asset type. For example:
─ Assets of type stakeholder, e.g., beneficiary (customer), workforce, etc. can be meas- ured as the number of stakeholders
─ Assets of type stock, can be measured in stock units, e.g., a number of products of a certain type
─ Assets of type infrastructure can be measured in the number of units, the total power, production capacity, etc., dependent on the type of assets.
─ Assets of type reputation can be measured on a fixed scale, like week, medium, strong.
Besides quantitative parameters, both processes and assets could be characterized with qualitative parameters for which the comparison operators, like ">" and "<", are not applicable. For example, a process can be characterized by its level of flexibility, e.g.
according to the classification introduced in [7]: loose, guided, restricted, and stringent.
Assets of the type workforce could be characterized by its level of qualification.
3.2 Providing tool support
Manual drawing of FEM diagrams and linking them together is a tedious work that could be facilitated by developing a computerized tool support. Such support would include at least the following components:
1. Support for building a FEM based on the generic and specific archetypes suggested in [1].
2. Support for transforming an existing FEM into a new one based on the transforma- tional archetypes discussed in Section 3.1
3. Support for calculating the differences between the nodes of two FEMs based on quantitative and qualitative parameters discussed in Section 3.1
As our suggestions are aimed at facilitating hypotheses generation and analysis, it is of utmost importance for the tool to have user interface suitable for team work. A team working with a large screen should be able to instantly make changes in the model, add notes, save work for further consideration, compare two hypothesis, etc. Currently we are testing ADOxx environment [8] for building tool support. Fig. 5 shows implemen- tation of item 1 on the list above when an archetype is applied to a primary process.
Fig. 5. The result of applying an archetype to a process (ADOxx based test)
4 Areas of application
To discuss the area of application of the ideas presented in this paper, we will consider five levels of strategy work introduced in [9]:
1. Doctrine or policy, which defines who we are.
2. Infrastructure/capability, which defines what infrastructure/technology we should use in our business, and what capabilities we need to develop.
3. Grand strategy, which defines in which sector to operate and with whom to make alliances.
4. Strategy, which defines our structural coupling with the external world, e.g. compet- itors, collaborators, market. The questions to decide here are whether we are part of a heard, a heard leader, an independent, etc.
5. Tactics, which defines operational levels procedures.
The work presented in this paper, in the first hand, is aimed at supporting the strategic work on the level of doctrine/policy by providing assistance in generating and assessing the hypothesis of extending or radically changing the doctrine/policy (who we are). In the example discussed in Section 2, the policy has been extended from being a book seller over internet to a platform provider. The suggested approach can also be useful for moving from doctrine/policy changes to infrastructure/capability level, as it helps to determine which capabilities are already in place and which needs to be developed.
It is doubtful that the approach could assist to work on a grand-strategy level. However, a FEM model of an enterprise might be helpful on the strategy level as well, as the choice of strategy depends on the qualitative and quantitative characteristics of various processes and assets already in place or to be developed. Explicating the connection between FEM and strategy level patterns as defined by [9] is included in our plans for the future.
In the example discussed in Section 2, a new business model is developed as an addition to the existing one. Though such case is possible, we believe that a change in the business model, and hence our work, is more important in a situation when a com- pany's current model becomes outdated, and needs to be substituted with a new one in order for the company to survive. In this case, the Boyd's idea of destruction and crea- tion from [10] needs to be applied. This is done by decomposing the current company into interconnected set of capabilities, i.e. processes and assets (analysis), and compos- ing them in a different manner while applying some twisting to get them fit in a new scheme of things (synthesis).
5 Concluding remarks
In the previous sections, we have demonstrated how FEM could be used for business model innovation/transformation, and what needs to be developed to convert the idea into a practically feasible methodology with tool support. Due to the space limitations
we are not able to provide any additional details of our research. It is worthwhile to mention, however, that our research follows the design science approach. Therefore, besides working on the issues highlighted in Section 3, we are putting efforts to dis- seminating the ideas among management consultants working with the issues of busi- ness transformation. An example presented in Section 2 has been developed as part of the dissemination efforts, and it showed to be helpful for this end, when demonstrated as a story in InsightMaker [11], see http://bit.ly/2qakWJR. Also, the current text has been used as a means for transferring the message to the expert in the field to get the ideas validated.
Acknowledgements. The authors are grateful to Patrick Hoverstadt for valuable com- ments on the draft of this paper.
References
1. Bider, I., Perjons, E., Elias, M., Johannesson, P.: A fractal enterprise model and its application for business development. Softw Syst Model (2016)
2. Josefsson, M., Widman, K., Bider, I.: Using the Process-Assets Framework for Creating a Holistic View over Process Documentation. In: Enterprise, Business-Process and Information Systems Modeling, LNBIP V. 214, pp.169-183 (2015)
3. Elias, M., Bider, I., Johannesson, P.: Using Fractal Process-Asset Model to Design the Process Architecture of an Enterprise: Experience Report. In : BPMDS 2014 and EMMSAD 2014, LNBIP 175, Thesalonniki, Greece, pp.287-301 (2014)
4. Hoverstadt, P.: The Fractal Oragnization: Creating Sustainable Oragnization with the Viable System Model. John Wiley & Son (2008)
5. Henkel, M., Bider, I., Perjons, E.: Capability-based Business Model Transformation. In : Advanced Information Systems Engineering Workshops, LNBIP 178, Thesaloniki, Greece, pp.88-99 (2014)
6. Osterwalder, A., Pigneur, Y.: Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. Wiley, Hoboken, NJ,US (2014)
7. Bider, I., Kowalski, S.: A framework for synchronizing human behavior, processes and support systems using a socio-technical approach. In : BPMDS 2014 and EMMSAD 2014, Thesalonniki, Greece, pp.143-157 (2014)
8. ADOxx. (Accessed 2017) Available at: https://www.adoxx.org 9. Hoverstadt, P., Loh, L.: Patterns of Strategy. Taylor & Francis (2017)
10. Boyd, J. R.: Destruction and creation. Lecture presented to the U.S. Army Command and General Staff College (1976)
11. Give Team: Insightmaker. (Accessed 2014) Available at: http://insightmaker.com/
Engines
Marwa Hussein Zaki , Ahmed Awad , and Osman Hegazy
Information Systems Department, Faculty of Computers and Information, Cairo University, Giza 12613, Egypt
m.hussein, a.gaafar, [email protected]
Abstract. Most of organizations try to ensure that their business processes are compliant with regulations and laws, so runtime monitoring of process compli- ance is considered to be of crucial importance. In this regard, there are several frameworks that enable the monitoring based on variants of event processing technologies. Most of these frameworks presume a rich activity lifecycle model for the execution of tasks. However, most of process execution engines support simpler lifecycle models. Thus, these frameworks fall short in monitoring com- pliance for such engines due to missing needed input events.
The goal of this paper is to enable compliance monitoring for different process execution engines. First we propose a middleware layer that maps different exe- cution engines’ lifecycles states to a reference lifecycle model. Also, unmatched states will be derived from execution’s engine states. Additionally, we implement compliance anti patterns to prove the feasibility of our approach.
Keywords: Business Process Management; web services; compliance; runtime monitoring; lifecycle mapping
1 Introduction
Most of the organizations try to ensure the compliance of their business processes against regulations and laws to avoid non-compliance penalties [21]. As a result, differ- ent approaches were developed to check the compliance of a business processes through different phases of a business process lifecycle [13,21] e.g., at design time [21], at the process execution (runtime) [3] or at the evaluation phase [18].
Compliance monitoring at process execution time is considered of utmost impor- tance because not every possibility of violation can be checked at design time. Several approaches have been developed to enable the monitoring of running processes compli- ance, e.g. [14,3]. Most of the monitoring frameworks presume a rich activity lifecycle model, cf. [3,10] compared to the simple task lifecycle models supported by business process execution engines. So, many of the expected execution events by the moni- toring frameworks will be missing. This introduces the threat of having violations go undetected. To make use of those frameworks, the gap between what is provided by execution engines and what is expected by monitoring frameworks has to be filled.
In this paper, we propose a mapping approach that fills the gap between the activ- ity lifecycle models supported by different process execution engines and the reference
lifecycle model proposed by Russell et al. [19] and supported by the BP-MaaS moni- toring framework [3], as an example monitoring framework, and two process execution engines: Activiti [17] and jBPM [6]. For each, we have studied the supported task life- cycle models of the engines, compared them to the reference lifecycle and identified the mapping. To achieve the compliance monitoring, we implemented the compliance patterns presented in [3].
The rest of the paper is organized as follows: Section 2 presents our proposed model, Section 3 discusses related work and Section 4 concludes the paper with an outlook on future work. The needed preliminaries, some of the background techniques and a simple running example are provided in an extended version of this paper [9].
2 Enabling Monitoring
Lifecycle Mapping Logic
Reference Lifecycle
Compliance Rules
Monitoring System Event Mapping
Reference Events
Engine Raw Events Stream
Violation Events
Fig. 1: Proposed monitoring system framework
Our contribution can be seen as a middleware which consists of: a) An engine- specific mapping to the reference task lifecycle b) Implementation of the compliance monitoring anti patterns in [3]. Fig. 1 depicts the architecture of the middleware. The Lifecycle Mapping Logicis a set of rules used to perform the mapping fromEngine’s raw eventsto thereference events. Currently, these rules are manually derived and pro- grammed into an executable language. For the case of jBPM, the mapping rules are encoded as Drools rules. For Activiti, rules are encoded as extensions to the engine and written in EPL syntax, more details are given later in this section. The mapping logic is done offline and once per process execution engine. It only needs to be revisited in case either the engine lifecycle or the reference lifecycle is changed. At runtime, themoni- toring systemdetects and throwsviolation events, if any, based on the inputcompliance rulesand the events coming from the reference events stream.
2.1 Reference Task Lifecycle
The lifecycle in Fig. 2 illustrates the state transitions of tasks as follows: a work item (a task) iscreatedby the system. It is either directlystartedorallocatedto a resource. A
task can be delegated to another resource either by the system (escalate), or the respon- sible resource (delegate). After assigning a resource, the task will bestarted. However, the resource can skip it to becompleted directly. Moreover, a resource can suspend a task to besuspendedand resume it again (resume) to bestartedand finallycompleted or (redo) it after completion. If the resource fails to execute the taskfailed, it can try to (restart) it again or (reallocate) to another resource . More details about this lifecycle could be found in the extended version of this paper [9].
Fig. 2: Reference task lifecycle model adapted from [19]
2.2 Lifecycle Mapping
The lifecycle mapping part has two inputs: (1)Engine Raw Events Streamand (2)Life- cycle Mapping Logicwhich contains a list of rules used to obtain the corresponding reference event. The output of this part is theReference Event Streamwhich contains the mapped and the derived missing reference events.
There are four different possibilities for mapping an engine-specific event/state to the reference state. The first possibility is that there is adirect correspondence. Both the engine activity state and the reference state carry the same name and meaning. The sec- ond possibility is that there is anaming mismatchbut aconceptual match. For instance, the engine defines activity stateassigned which is matched with the reference state allocated. The third possibility is that the reference state can be derived via observing a pattern over one or more of the engine’s states. As an example, the reference state tran- sitionresumedcan be derived by detecting a sequence ofsuspendedandstartedevents of the same task instance and the same performer. The last possibility is that there isno mapping possible, this means that the engine does not support this state.
We investigated different execution engines’ lifecycles for different languages such as BPMN, BEPL and workflow systems (YAWL). A survey about these engines and their lifecycles could be found on the extended version of this paper [9] We report im- plementation onjBPM[6] andActiviti[17] asCamunda1andActivitialmost have the same API functions. We investigated the YAWL workflow engine’s lifecycle [20] with- out a specific implementation as this workflow system is more scientific and complex for regular user; rather than BPMN execution engines which are easier to understand and use. Table 1 summarizes the mapping between the different states of these engines’s lifecycle to the reference lifecycle.
1https://camunda.com/
Table 1: Mapping the lifecycle of different engines to the reference lifecycle Reference states Engine States
Activiti jBM Camunda YAWL
Created create created new Enabled
Allocated assignment reserved assigned Enabled2 Started Rule 1 in progress Rule 1 Fired Suspended Rule 2 suspended Rule 2 Suspended Failed no mapping failed no mapping Failed Completed complete completed completed Complete
The direct mapping and the naming mismatch are straightforward. In the latter case, when the engine generates an event with the mis-named state, our approach generates another event copying all the data of the original event except for the state where the conceptually equivalent state is substituted. In the third case, the approach can derive the reference state by observing the occurrence of one or more of the engine’s events.
This process happens by adding engine extension to throw a new event when the engine performs an operation on the task that is not supported by its lifecycle. The following rules are specific for each engine.
ForActivitiandCamundaengines:
– Rule 1:(Start on Create) action can be inferred when task tis created with per- formerriand the system directly starts this task. If the start event is not supported by the engine, we consider that the task is immediately started after creation and a newstart on createevent is thrown and mapped tostartedreference event.
– Rule 2:(Suspended) event can be inferred when the whole process instance is sus- pended as the engine doesn’t support the suspended state on the task level. When the engine reports a wait state for the process instance, we can detect that asus- pendedevent occurred and is thrown to the stream.
After the investigation of the Activiti and Camunda engines, we found that thefailed state is not supported and there is no way of mapping this state.
2.3 Compliance Monitoring Implementation
This subsection provides the implementation details of compliance monitoring within ActivitiandjBPM engines. We use complex event processing (CEP) with the help of EsperwithinActivitiwhich consists of four parts: (1)Business Process Modelwhere we define task listeners in the XML file defining the process, (2)Task Listenersthat detect any change in the task’s state through the process execution and generate a predefined event to be analyzed later, (3)Esper Enginethat is responsible for generating streams and populating them with events coming from different sources, initiating listeners to detect events from the engine, throwing new events in case of any changes after pro- cessing and communicating with our middleware (4)Stream; that contains all kinds of
2Enabled state with more information about the resource
events either raw, mapped or complex events thrown from our middleware. All the logic for mapping events or implementation of compliance anti patterns is implemented using Event Processing Language (EPL) and Drools Rule Language (DRL).
The following lists present a sample EPL query of the implementation of the map- ping cases.
Listing 1.1: EPL statements for naming mismatch for the allocated state
1insert into referenceeventsstream ( taskInstanceId , receiveTime ,
2eventType , performer ) select taskInstanceId , receiveTime ,
3'allocated', performer from engineraweventsstream where
4eventType = ? "
jBPMsupports the CEP technology through the integration with Drools [2]. The mapping approach onjBPMstarts by defining an active session to register the streams which contains the raw events generated from the process instances execution. After that Drools rules match the incoming events with the defined mapping logic and fires when a mapping match is found.
The following list introduces a sample of the Drools rule used in the naming mis- match case injBPMfor theinprogressstate.
Listing 1.2: inprogress detection drools rule
1rule " inprogress Rule "
2when
3$mevent : events ( tasktype == " InProgress ") from
4entry - point engineStream then
5$mevent . seteventType (" started " );
6update( $mevent );
The second part of our approach is the implementation of the compliance rules us- ing the anti patterns technique presented in [3]. We implemented most of the patterns, e.g.exist,absence,response,one to one response,next,sequenceandseparation of duty using the rule semantics logic of the Drools engine [2]. The framework uses the refer- ence events stream and the compliance patterns as input and matches each pattern with its corresponding anti-pattern rule to detect any possible violation as depicted in Fig. 1.
We implement this part using the Drools fusion component which contains complex event processing features. The anti patterns queries are written using the Drools rule language (DRL) and are stored in the production memory of the Drools engine. The compliance rules which present one of the inputs for the compliance monitoring part is stored in the working memory of the engine as ”facts” to be compared later with the stored Drools rules. The streams containing events in Drools engine are called entry points. Based on the compliance rules and the events from the entry points, Drools rules fire and throw a violation event whenever a violation occurs. The following list introduces sample of the rules used to implement the compliance rules anti-patterns.
Listing 1.3: Exist anti pattern rule
1
2Exist anti pattern
3when Event ( $task : task , $ts : tistamp , $type : type ,
