Towards the Usage of Object-Aware Process Variants in Multiple Autonomous Organisations Philipp Hehnle1,* , Manfred Reichert1,* 1 Institute of Databases and Information Systems, Ulm University, Germany Abstract Managing similar software products and thereby reducing costs has been subject to research in the field of Software Product Line Engineering (SPLE). In our previous work, we applied the concepts of SPLE to activity-centric processes. Although research was conducted to manage variants of object-aware processes, there are still open challenges. In this paper, we address the challenge of managing object- aware process variants in autonomous organisations, which run their information systems separately. Keywords Business Process Management, Process Configuration, Process Variability, Software Reuse 1. Introduction As a result of the right to self-administration, various German municipalities use slightly different digitised variants of the same business processes [1]. Existing approaches for managing process variants focus on the control flow rather than on the implementation level, i.e. in a process model, fragments may be added, moved, or removed [2] and gateways may be restricted (e.g. an OR gateway may be restricted to an AND gateway) [3]. To reduce costs when developing similar software products, the discipline of Software Product Line (SPL) Engineering emerged [4]. An SPL comprises a set of common core software artefacts from which individual software products may be derived, i.e. be configured by selecting and combining the software artefacts [5][6]. In our previous work [1], we applied the concepts of SPL Engineering to activity-centric process management to benefit from the advantages (e.g. reduced costs) in that a process-aware information systems may be derived from a set of software artefacts including a process model by selecting different implementations for the activities of that process model. Thereby, it is possible to derive various process-aware information systems with varying activity implementations. Frequently, in activity-centric process management, data objects are under-specified. Besides, activity-centric process management lacks flexibility as users must not carry out activities in varying sequences. In contrast, data-centric process management [7] is a paradigm specifying unstructured or semi-structured processes in which data and processes are coupled tightly and the progress of a process is driven by data. The object-aware process management approach [8] ZEUS’24: 16th Central European Workshop on Services and their Composition, February 29 - March 1, 2024, Ulm, Germany * Corresponding author. $ philipp.hehnle@uni-ulm.de (P. Hehnle); manfred.reichert@uni-ulm.de (M. Reichert)  0009-0006-0420-7000 (P. Hehnle); 0000-0003-2536-4153 (M. Reichert) © 2022 Copyright for this paper by its authors. CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) S. Böhm and D. Lübke (Eds.): 16th ZEUS Workshop, ZEUS 2024, Ulm, Germany, 29 February–1 March 2024, published at http://ceur-ws.org CEUR ceur-ws.org Workshop ISSN 1613-0073 Proceedings Hehnle and Reichert: Towards the Usage of Object-Aware Process Variants in Multiple Autonomous Organisations implements the data-centric process management paradigm. There are object types and their corresponding object behaviours. The latter are specified in terms of lifecycle processes which comprise states and state transitions. At runtime, the object types are instantiated with their lifecycle processes. Activities with user forms are generated when a state is reached in which data is required and activities are completed (i.e. the process continues) when the required data becomes available (i.e. the user has entered the object attributes). Thus, the progress of a lifecycle process is data-driven and determined by changes of the object attributes. PHILharmonicFlows is a framework for object-aware process management. In [9], [10], and [11], an object-aware and process-aware information system (OPAIS) is presented as a proof-of-concept implementation of PHILharmonicFlows. While there have been approaches dealing with variants in activity-centric processes, only little research covers variants in OPAISs. The work in [12] deals with variants in one OPAISs. However, the same process can be operated in variants in different autonomous organisations that run their OPAIS separately. The management of process variants in separate OPAISs remains an open challenge, which is addressed in this paper. 2. Related Work This section presents an approach to deal with variants in OPAISs as well as core concepts of SPL Engineering. In [12], an approach is presented for coping with process variants in OPAISs. At design time, when evolving a process in an OPAIS (e.g. adding or removing attributes from an object or updating a lifecycle process) the changes are logged rather than propagated to the process in production. As soon as the changes need to be deployed to production, the logs created during design time can be replayed, i.e. propagating the changes to production. When developing various variants of a process, the base process containing the commonalities is copied by replaying the corresponding logs. Each copy of the base process is the starting point for a variant where the variant-specific changes are applied to. When the base process is altered, the changes can be applied to all variants by replaying the logs triggered by the changes to the base process. Certainly, this approach facilitates the development of variants and the propagation of common changes. However, the approach neglects that autonomous organisations that run process variants will most likely have physically independent hardware/OPAIS instances. Therefore, the logs need to be distributed among various OPAIS instances. Furthermore, the approach assumes that each variant is used once. However, multiple organisation might use the same variant each on their separate OPAIS instance. The logs should not be copied but referenced so that changes to a variant can be performed centrally and applied to all organisations that use the same variant. Moreover, an organisation might use a combination of variants instead of creating a new variant from scratch or use an outdated version of a variant while the variant has been updated centrally, i.e. different versions of a variant might be in production. During bug analysis, it becomes necessary to rebuild a specific version of a variant of an organisation. Feature models [13] describe software products in terms of their features by outlining which features are mandatory, optional, and which features require or exclude each other. Configuration management in SPL Engineering [14] deals with managing the versions of the common core artefacts as well as the derived software products over time. In contrast, version 10 Hehnle and Reichert: Towards the Usage of Object-Aware Process Variants in Multiple Autonomous Organisations control tools for configuration management in software engineering only manage one software product over time. In [15], a Divide & Conquer approach for configuration management is proposed that divides the challenge in sub-challenges and solves them with the use of existing version control tools from software engineering. 3. Research Direction This section presents an approach to deal with variants in OPAIS of autonomous organisations. First, a real-world example is described which serves as motivation. Then, requirements are elicited based on the example. Finally, an approach satisfying these requirements is sketched. During a cooperation with German munic- Object Lifecycle Processes ipalities, the process for checking the spe- Object Types Application Accepted cial parking permit application of craftsper- +companyName Application Filled in Decision Rejected sons was studied. This process is pictured in +commercialRegisterNo. Car Accepted a slightly adapted and simplified form com- 1..n Car +licensePlate Filled in Decision Rejected pared to our previous work [1]. In German municipalities craftspersons may apply for a special parking permit which allows them to Figure 1: Object-Aware Process park in zones of the city where citizens have to pay or where parking is not permitted. The object-aware process for checking this application is depicted in Figure 1. The applicant must provide information about her company and the company’s cars for which the parking permit shall be valid (cf. object types on the left-hand side). On the right-hand side, the lifecycle processes for the object types are shown. Different municipalities might need adaptions to the base process (cf. Figure 1) which results in variants. Some municipalities might require the applicant to submit pictures of the cars to prevent issuing parking permits for private cars. In other municipalities, information about the cars is not required at all. Then, the parking permit is valid for whatever car it is situated in. German municipalities are autonomous organisations, which run their information systems separately. Based on the example, the requirements are deduced for managing variants in OPAISs of autonomous organisations. R1: Each organisation must be able to select a combination of adaptions in conjunction with the base process and build (i.e derive) a process variant. R2: Multiple organisations may derive the same process variant. R3: Adaptions need to be managed centrally in that changes to them can be propagated easily to all process variants that are using these adaptions. R4: Not every combination of adaptions may be valid. It needs to be evident what adaptions exclude each other. R5: As the base process and the adaptions evolve, not every organisation may want to apply the updates. R6: For bug analysis, it needs to be evident which organisation uses which version and adaptions of the base process in order to rebuild and analyse the corresponding variant. Using concepts of SPL Engineering, namely feature models [13] and the Divide & Conquer approach for configuration management proposed in [15], it becomes possible to satisfy the 11 Hehnle and Reichert: Towards the Usage of Object-Aware Process Variants in Multiple Autonomous Organisations Adapt. 1 Adapt. 2 Base Config. A V1 Process legend V1 V2 Base: V2 consists of V2 L1:[+Picture] Options: L5:[+Car] Adapt.1 Adapt. 2 - Adaption 1 Adapt1: V1 optional L3:[-Car] V1 exclusive V3 V1 Figure 3: Feature Diagram Figure 2: Configuration Management requirements. The base process and every adaption are stored as logs each in a central repository under version control. Thereby, changes due to the evolution of the base process and the adaptions can be applied centrally. Every organisation has a configuration that stores the version of the base process and the selected adaptions. During derivation, the referenced logs are fetched and replayed in the organisation’s OPAIS instance. As each repository is under version control, older version of the logs can be used which allows the organisations to stay on older versions of the variants. Furthermore, for bug analysis, the configuration of each organisation is under version control as well. Consequently, to analyse a bug a specific version of a variant of an organisation can be restored and inspected. Figure 2 is an example for configuration management and shows the repositories and their version history over time. It reveals that Adaption 1 in Version V2 uses log L3 to remove the object type Car, whereas Adaption 2 in Version V1 uses log L1 to add the object type Picture. Obviously, Adaptions 1 and 2 cannot be co-selected as the picture object type needs a car object type it belongs to, which is removed in Adaption 1. Figure 3 imposes the base process with its adaptions in a feature model, which indicates that Adaptions 1 and 2 are mutually exclusive. Furthermore, Figure 2 represents the evolution of the base process model (viz. three versions) and the exemplary repository of one organisation, which stores a configuration (Config. A) to derive a process variant by specifying that the base process in version V2 and Adaptation 1 is selected. 4. Conclusion and Outlook This paper deals with managing variants in OPAISs in that multiple autonomous organisations may derive process variants from a base process by selecting and combining adaption to the base process whereas different versions of both the base process and the adaptions may be used. Consequently, there may be a variety of process variants and versions that need to be tracked. This work presents an approach that applies concepts of SPL Engineering to OPAIS variants in order to keep track of the process variants and their versions. In future work, we plan to assemble a tool chain that is able to automatically derive and keep track of process variants in OPAIS by using, extending, and integrating tools from SPL Engineering, and, where necessary, creating new tools. Furthermore, black-box-activities [9] implementing business logic as well as customised forms (i.e. opposed to generated forms) need to be considered in the future. 12 Hehnle and Reichert: Towards the Usage of Object-Aware Process Variants in Multiple Autonomous Organisations References [1] P. Hehnle, M. Reichert, Handling Process Variants in Information Systems with Software Product Line Engineering, in: 2023 IEEE 25th Conference on Business Informatics (CBI), 2023, pp. 1–10. [2] A. Hallerbach, T. Bauer, M. Reichert, Capturing variability in business process models: the Provop approach, Journal of Software Maintenance and Evolution: Research and Practice 22 (2010) 519–546. [3] W. M. P. van der Aalst, A. Dreiling, F. Gottschalk, M. Rosemann, M. H. Jansen-Vullers, Configurable Process Models as a Basis for Reference Modeling, in: Business Process Management Workshops, volume 3812 of Lecture Notes in Computer Science, Springer, 2006, pp. 512–518. [4] L. Bass, P. Clements, R. Kazman, Software architecture in practice, Always learning, 3. ed. ed., Addison-Wesley, 2013. [5] S. Deelstra, M. Sinnema, J. Bosch, Product derivation in software product families: A case study, Journal of Systems and Software 74 (2005) 173–194. [6] C. Kästner, S. Apel, Feature-Oriented Software Development, in: Generative and Transfor- mational Techniques in Software Engineering IV: International Summer School, GTTSE 2011, Springer, 2013, pp. 346–382. [7] S. Steinau, A. Marrella, K. Andrews, F. Leotta, M. Mecella, M. Reichert, DALEC: A frame- work for the systematic evaluation of data-centric approaches to process management software, Software & Systems Modeling 18 (2019) 2679–2716. [8] V. Künzle, M. Reichert, PHILharmonicFlows: towards a framework for object-aware process management, Journal of Software Maintenance and Evolution: Research and Practice 23 (2011) 205–244. [9] C. M. Chiao, V. Kuenzle, K. Andrews, M. Reichert, A Tool for Supporting Object-Aware Processes, in: 2014 IEEE 18th International Enterprise Distributed Object Computing Conference Workshops and Demonstrations, 2014, pp. 410–413. [10] K. Andrews, S. Steinau, M. Reichert, A Runtime Environment for Object-Aware Processes, in: International Conference on Business Process Management, 2015, pp. 6–10. [11] S. Steinau, K. Andrews, M. Reichert, A Modeling Tool for PHILharmonicFlows Objects and Lifecycle Processes, in: International Conference on Business Process Management, 2017. [12] K. Andrews, S. Steinau, M. Reichert, Enabling Process Variants and Versions in Distributed Object-Aware Process Management Systems, in: Information Systems in the Big Data Era, Springer, 2018, pp. 1–15. [13] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, S. Peterson, Feature-Oriented Domain Analysis (FODA) Feasability Study, Technical Report, 1990. [14] P. Clements, L. Northrop, Software product lines: Practices and patterns, SEI series in software engineering, 7. print ed., Addison-Wesley, 2009. [15] C. W. Krueger, Variation Management for Software Production Lines, in: Software Product Lines, volume 2379 of Lecture Notes in Computer Science, Springer Nature, 2002, pp. 37–48. 13