Stephan Roser

A categorization of collaborative business process modeling techniques

Business process modeling (BPM) is one of the key factors in defining service-oriented solutions for business collaborations. Like in traditional software engineering there is a need for adaptable methodologies to develop information and communication technology (ICT) systems supporting collaborative business processes. In this work we introduce a categorization for the classification of modeling languages and approaches used to model collaborative business processes. Considering an example, we show how the classification of modeling languages and approaches facilitates the development of methodologies for collaborative business processes.

Translation of QVT Relations into QVT Operational Mappings

Model transformations play a key role in Model-Driven Engineering solutions. To efficiently develop, specify, and manage model transformations, it is often necessary to use a combination of languages that stand for different transformation approaches. To provide a basis for such hybrid model transformation specification solutions, we developed and implemented a translation of the declarative QVT Relations into the imperative QVT Operational Mappings language.

Automatic Generation and Evolution of Model Transformations Using Ontology Engineering Space

Model-driven software development facilitates faster and more flexible integration of information and communication systems. It divides system descriptions into models of different view points and abstraction levels. To effectively realize cross-organisational collaborations, it is an important prerequisite to exchange models between different modelling languages and tools. Knowledge is captured in model transformations, which are continuously adjusted to new modelling formats and tools. However, interoperability problems in modelling can hardly be overcome by solutions that essentially operate at syntactical level. This paper presents a novel approach using the capabilities of semantic technologies in order to improve cross-organisational modelling by automatic generation and evolution of model transformations.

Model- and Architecture-Driven Development in the Context of Cross-Enterprise Business Process Engineering

Modelling and enacting cross-enterprise business processes (CBPs) is a key ability for successfully setting up and managing virtual organizations, e.g. supply chains. In this paper we present and compare approaches for modelling CBPs based on the service-oriented architecture paradigm. By embedding our overall approach into a model- and architecture-driven development perspective, we show how service-oriented systems realising CBPs can be derived from business-level modelling

Token analysis of graph-oriented process models

In Business Process Management, graph-based models are used to represent coordination protocols between collaborating partners as well as for service orchestration and composition. At runtime however, current process engines are commonly based on mainly block-structured languages, such as BPEL, that differ structurally and semantically from process graphs. Recent work has accomplished elaborate mappings between both representations. Although most mappings strongly depend on the segmentation of the graph-model into components, the necessary graph-decomposition itself is not described in these works. This paper presents a novel approach based on Token Analysis to automatically identify components. The technique also allows for optimizations by integrating further steps in the translation of process graphs to executable workflows.

A Model-Driven Approach to Designing Cross-Enterprise Business Processes

Modeling and managing business processes that span multiple organizations involves new challenges, mainly regarding the ability to cope with change, decentralization, and the required support for interoperability. In this paper, we present an approach to modeling cross-enterprise business processes based on the model-driven architecture (MDA). Starting from the ATHENA interoperability architecture, we propose a conceptual architecture for cross-enterprise business processes. Then, we present a methodical approach towards designing cross-enterprise business processes based on a model-driven architecture. The core contribution of the paper is a set of original mappings at and across different layers of the model-driven architecture, including a mapping from ARIS to UML and the Business Process Definition Metamodel (BPDM).

Adaptive Design of Cross-Organizational Business Processes Using a Model-Driven Architecture

To enable enterprises to keep up with the constant change in business relationships and cross-organizational value chains, it is crucial to develop adaptive business systems and value chains. In order to achieve this, methodologies, methods, and infrastructures to support end-to-end modeling of cross-organizational business processes are required, allowing changes to business processes being defined at the business level and providing well-defined (and possibly largely automated) model transformations and refinements down to the level of information and communication technology systems.

A Decentralized Broker Architecture for Collaborative Business Process Modelling and Enactment

process (organisational intern) enterprise boarder broker boarder abstract process (organisational extern) centralized broker Fig. 1. Centralized vs. decentralized broker (PP=private process, VP=view process) From a runtime view point there are two alternatives depending on whether the broker is hosted by a third party or not. In case the logical enterprise boundary in the architecture is also a physical boundary in the runtime architecture, a view process is realised and executed by the participating enterprise owing also the private processes. Thus, the decentralized broker architecture satisfies the requirement of flexibility and modularity at the conceptual level. The view processes are preserved in any A Decentralized Broker Architecture for Collaborative Business Process Modelling and Enactment 5 runtime architecture derived from this conceptual architecture. The privacy of internal data depends on the realization of decentralized broker at runtime. This requirement can be met, if view processes are not hosted by a third party, but rather implemented and executed by the respective enterprises participating in the CBP. 4 A Model-Driven Design of Collaborative Business Processes Business level models on a computational independent level of abstraction are not affected by the adoption of a decentralized broker in the conceptual architecture. In contrast to this ICT models at platform independent level of abstraction differ very well in describing centralized and decentralized brokers. Thus the transformation presented in [ 3] had to be adjusted to a decentralized broker architecture. This chapter shows how from an ARIS business level description on a very high level of abstraction we derive ICT models for realizing collaborating components of a decentralized broker architecture. We are able to generate view processes, being an abstraction from more detailed private processes, and their links to the private process implementation by the means of the service-oriented PIM4SOA metamodel at platform independent level. 4.1 Starting Point: CBPs with ARIS ARIS provides means to model private processes focusing on the isolated consideration of an organisation’s (internal) processes [ 12]. EPC description of private processes can be used to model process orchestration and process choreography. For process orchestration, the concept of vertical hierarchy [ 8] can be applied to describe process steps and decomposition in detail. ARIS process modules represent view processes encapsulating internal process steps. ARIS process module chains [ 8] can be used for modelling cross-organisational business processes describing the interactions between collaborating parties. Process module chains are EPCs extended with a swim lane concept. View processes which belong to the same role of the cross-organisational collaboration are allocated in the same swim lane. Organisational units responsible for the realization of roles in the CBP are depicted in the first column of the respective swim lane. A control flow from a process module enacted by one role, to a process module enacted by another role, represents an interaction that takes place between these roles and their realizing organizational units respectively. 4.2 Refining CBPs for PIM4SoA In this section, the metamodel for specifying services and collaborations presented in Section 2.2 is extended by concepts for describing private processes which participate in various collaborations through their view processes. Private processes, view processes and collaboration processes are service providers. A private process is an executable service provider who references view processes that enact its participation in external collaborations. Its behaviour is modelled by an executable process. A view process is an executable service provider whose behaviour is a process flow model that may include view tasks. A 6 B. Bauer, J. P. Muller and S. Roser view task is an activity that abstracts a set of activities of the realizing private processes into a single task. A view process realizes roles in a single collaboration and view tasks are visible in the collaboration. A collaboration process is an abstract service provider whose behaviour is a process flow model. The collaboration process may specify the view processes that together enact the collaboration. We regard a view process as an executable process that realizes several abstract processes one for the collaborations it participates in and the others to participate in the implicit collaborations with the private processes it supports. A view process connects the abstract process an organization provides to a CBP with realizing private processes of the organization. Nevertheless a view process is an executable process. 4.3 Generation of decentralized PIM4SOA broker description from ARIS Now we present transformations from an ARIS CBP-description to a metamodel / domain specific model for service-oriented (business) process modelling at a platform independent level, namely PIM4SOA. 4.3.1 Example CBP The CBP example comprises the solicitation of quotations and the choice of component suppliers by an automotive manufacturer. Three roles are involved in the cross-organizational business process: Fig. 2. Case study – process overview OEM (Original Equipment Manufacturer): An OEM is the automotive manufacturer planning to produce a new automobile type. PO (Purchasing Organization): Independent company or department of the OEM conduction the solicitation of quotations and the final selection of the suppliers. SU (Supplier): The SU is a component supplier for the automotive industry aiming to place contracts with the OEM and PO. 4.3.2 Transforming the CBP The ARIS to PIM4SOA transformation of CBPs is described by rules consisting of source and target patterns. Each rule is illustrated by the means of a sample transformation dealing with the CBP example presented in Section 4.3. Transformation of CBP, derivation of View Processes and Collaborations [Rule 1.1] A Decentralized Broker Architecture for Collaborative Business Process Modelling and Enactment 7 Src: A CBP is modelled in an EPC with row display containing a swimlane concept. Trg: A collaboration process, which is an abstract service provider, is instantiated. [Rule 1.2] Src: The EPC describing the CBP is structure by swimlanes separating the process modules of the different participants. Trg: For each swimlane a VP is instantiated and connected to the collaboration process it participates in. The name of the VP, i.e. of the service provider, is the name of the department participating in the CBP and realizing roles of the collaboration. [Rule 1.3] Src: In the case the source and target process module of a control flow edge lie in different swimlanes, there is a collaboration between the two roles represented by swimlanes. Trg: a) For each pair of roles that collaborate according to the source pattern, one collaboration and the two collaborating roles are instantiated. The two roles are assigned to the collaboration. For each collaboration pair of role one and only one collaboration is instantiated. b) Two VPs, which were derived from the swimlanes (Rule1.2), belong to the two roles participating in the collaboration. For each of the two VPs a collaboration use is instantiated referencing the collaboration. c) Bindings are instantiated specifying for the collaboration uses, which roles of VPs (boundRole) realize are which roles of the collaboration (role).

Improving Interoperability in Collaborative Modelling

The application of model-driven development facilitates faster and more flexible integration by separating system descriptions to different levels of abstraction. In cross-organisational development new challenges arise to enable enterprise models sharing knowledge independent of language and tools. However, interoperability problems in modelling can be hardly overcome by solutions operating essentially at syntactical level. This paper presents an approach using the capabilities of semantic technologies in model-driven development and discusses its improvements for collaborative modelling.

Architecture for the Design and Agent-Based Implementation of Cross-Organizational Business Processes

New forms of cooperation like collaborative business scenarios require a deep but flexible integration of enterprises. In order to manage inter-organizational business processes, existing concepts for business process management need to be adapted and extended. In this paper an approach is presented, that shows how cross-organizational processes can be planned and implemented. The approach in this article describes the conceptual preparation of CBPs independently from specific techniques used for execution. However, the authors consider the potentials of their execution offered by agents in comparison to other state of art techniques like WS-BPEL engines.