deliverable number: d.a2.4 architecture for enactment and … · 2011-09-15 · processes to...

Programme

Integrating and Strengthening the European Research Strategic Objective

Networked businesses and governments Integrated Project / Programme Title

Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application

Acronym

ATHENA Project No

507849 ATHENA – Project Name

Enactment of Cross Organisational Business Processes ATHENA - Project No

A2

Deliverable Number: D.A2.4

Architecture for Enactment and Integration of Cross-Orgranizational Business Processes

Work package – A2.5 Leading Partner: SAP

Security Classification: Restricted (RE)

November 2005

Version 1.0

IP- Project / Programme ATHENA Project - No 507849 ATHENA - Project Enactment of Cross Organisational Business Processes Project Number A2 Document Deliverable Number: D.A2.4 Date 01.03.06

060228_ATHENA_DA24_V10.doc CONFIDENTIAL Page ii / 51

Table of contents

1 SUMMARY........................................................................................................................................ 1

2 INTRODUCTION............................................................................................................................... 2

3 ENACTMENT OF CROSS-ORGANISATIONAL BUSINESS PROCESSES .................................. 3 3.1 A2 CBP Engine Implementation................................................................................................. 3 3.2 Nehemiah in a Web Service Environment................................................................................. 4 3.3 Simulation Capability .................................................................................................................. 5 4 FROM BUSINESS MODELS TO PROCESS EXECUTION............................................................. 6

5 MODEL TRANSFORMATION........................................................................................................10 5.1 EPC to PIM4SOA........................................................................................................................10 5.1.1 Motivation .............................................................................................................................10 5.1.2 Basic terms and notations....................................................................................................10 5.1.3 Methodical approach............................................................................................................11 5.1.4 Design Considerations .........................................................................................................12 5.1.5 Internal modelling architecture .............................................................................................13 5.1.6 Modelling guidelines.............................................................................................................15 5.2 IEM to Maestro ...........................................................................................................................19 5.2.1 Maestro general export ........................................................................................................19 5.2.2 Maestro + Executable Annotation ........................................................................................19 5.2.3 IMPORT NOTES FOR MO²GO FROM XMI:........................................................................20 5.3 MO²GO to PIM4SOA Export ......................................................................................................20 5.3.1 Introduction...........................................................................................................................20 6 TASK MANAGEMENT FOR SEMI-AUTOMATIC PROCESS COORDINATION..........................26 6.1 Integrating Support for Ad-hoc and Structured Work ...........................................................26 6.1.1 Customised and Integrated Software Support .....................................................................26 6.1.2 Emergent Interoperability .....................................................................................................27 6.1.3 Integrating Knowledge Management in Everyday Work ......................................................27 6.2 Modeling and Execution Approach .........................................................................................27 6.2.1 Active Process Models .........................................................................................................28 6.2.2 Emergent Workflow..............................................................................................................28 6.3 Modeling Architecture...............................................................................................................29 6.4 Implementation Architecture....................................................................................................30 6.5 Relationships to the Overall Execution Framework and Other ATHENA Projects.............32 6.6 Implementation ..........................................................................................................................32 7 EVENT AND DOCUMENT CORRELATION..................................................................................37 7.1 Motivation...................................................................................................................................37 7.2 Event and document correlation approach ............................................................................37 7.3 Event and document correlation architecture........................................................................38 7.4 Integration with A5 tools...........................................................................................................39 7.5 Semantic support in the correlation context ..........................................................................40 8 ENACTMENT PROTOTYPE – EADS SCENARIO ........................................................................42 8.1 Scenario Description with A2 Enactment Focus....................................................................42 8.2 Realization of Scenario .............................................................................................................45 9 IMPLEMENTATION ACTIVITY LIST .............................................................................................47

10 CONCLUSION ................................................................................................................................49

11 REFERENCES................................................................................................................................50


060228_ATHENA_DA24_V10.doc CONFIDENTIAL Page iii / 51

List of Figures

Figure 3-1 Possible Internal Landscapes................................................................................................ 3 Figure 3-2 Nehemiah in Web service environment ................................................................................. 4 Figure 3-3 Nehemiah Start Page............................................................................................................. 5 Figure 4-1 A2 Conceptual Results .......................................................................................................... 6 Figure 4-2 A2 Tools and Prototypes ....................................................................................................... 7 Figure 4-3: A2 Model Transformation ..................................................................................................... 8 Figure 4-4 The need for Taskmanagement............................................................................................. 9 Figure 5-1 Orchestration and choreography ......................................................................................... 11 Figure 5-2 Stages of mapping ............................................................................................................... 12 Figure 5-3 ARIS – EPC and process orchestration............................................................................... 13 Figure 5-4: PIM4SOA – executable and abstract process at CIM level................................................ 14 Figure 5-5 PIM4SOA – executable process at PIM level ...................................................................... 14 Figure 5-6 Vertical hierarchy and horizontal classification.................................................................... 16 Figure 5-7 Modelling vertical hierarchy ................................................................................................. 17 Figure 5-8 Modelling horizontal hierarchy ............................................................................................. 17 Figure 5-9 Modelling input and output in function allocation diagrams................................................. 18 Figure 5-10 Modelling view processes as ‘process modules’ ............................................................... 18 Figure 5-11 Modelling CBPs ................................................................................................................. 18 Figure 5-12 Model of the PIM4SOA metamodel in MO²GO. Action, Auftrag and Resource are standard

MO²GO classes that are extended by the classes from PIM4SOA metamodel. Order and Quotation are subclasses of Document............................................................................. 21

Figure 5-13 PIM4SOA information metamodel (see WD6.5.1[2], p14)................................................. 22 Figure 5-14 Example of a Collaboration and its description in MO²GO................................................ 22 Figure 5-15: PIM4SOA process flow metamodel .................................................................................. 23 Figure 5-16 PIM4SOA CBP extensions ................................................................................................ 24 Figure 5-17: How Private and View Processes map to a Collaboration between two executable

providers and an abstract process..................................................................................... 25 Figure 6-1. The interplay of articulation and activation. ........................................................................ 28 Figure 6-2. Task management metamodel (in the EKA notation from A1). .......................................... 29 Figure 6-3. Components of the Metis Enterprise Portal and Repository. ............................................. 30 Figure 6-4. Task management work breakdown structure.................................................................... 33 Figure 6-5. Task management timeline................................................................................................. 33 Figure 6-6. Task allocation overview..................................................................................................... 34 Figure 6-7. Task properties edit form. ................................................................................................... 35 Figure 6-8. Management dashboard for project monitoring and analysis............................................. 36 Figure 4-27: A2 event and document correlation.................................................................................. 37 Figure 4-28: A-EdoC overview .............................................................................................................. 38 Figure 4-29: A-EdoC architecture.......................................................................................................... 39 Figure 4-30: A-EdoC integration with A5 tools ...................................................................................... 40 Figure 4-31: A-EdoC integration with A3 tools ...................................................................................... 41 Figure 8-1: Change management process (only the CBP is shown in that figure). .............................. 44 Figure 8-2: Set up for realization of scenario ........................................................................................ 45


060228_ATHENA_DA24_V10.doc CONFIDENTIAL Page 1/51

1 Summary

It is the goal of work package A2.5 to provide an enactment engine for CBPs as well as simulation functionality. Execution of processes that span multiple organizations has to deal with specific requirements, such as the lack of a central engine instance, message exchange being the means of communication and an increased demand for privacy. Simulation is necessary to increase the understanding of the process flow for all involved stakeholders to find potential pitfalls and allow for process optimization. Here it is important to provide graphical support and the possibility to manually execute each step of the process including message exchanges.

In D.A2.3 we have identified 3 possible, most common internal landscapes for organizations participating in a CBP. From a pure ATHENA viewpoint we proposed an A2 CBP Engine that executes private processes as well as CBPs and is capable of managing the required synchronisation. Based on the architectural considerations, we implemented this A2 CBP Engine (Nehemiah) including simulation functionality. However, it cannot be assumed that each partner is capable of implementing Nehemiah, depending on how many internal changes are required. Additionally better support for more ad-hoc / collaborative situations in a cross-organisational scenario is required. Therefore this Deliverable includes the following three engines: • A2 CBP Engine (Nehemiah): implementing the pure ATHENA A2 approach • BPEL Engine: for situations where Nehemiah is not an option • Task Management Engine: supports Task Management and collaborative situations

Furthermore, as this is the last A2 Deliverable with technical content, we use this document to give an overview of all concepts and tools developed in A2 and show how they fit together. A big role in this context plays required model transformation that is necessary to follow the A2 approach from Business Models down to executable process specifications. Finally we apply the results to one of the ATHENA scenarios, in this case the EADS Aerospace scenario.



2 Introduction

From the Description of Work the following objectives are defined for work package (WP) A2.5: • Cross-Organisational Business Process Engine • Simulation of Cross-Organisational Business Processes

This objective is to be achieved in the general framework of Project A2 “Cross-Organizational Business Processes”, which has the following goal:

“Providing interoperability on the business layer by effectively extending internally used business processes to achieve execution of business processes between collaborating enterprises while considering their privacy requirements.”

Work package A2.5 contributes to this goal by presenting the following results: • An enactment engine for cross-organisational business processes:

o A2 CBP enactment engine: Based on the architecture design of WP2.4, the A2 CBP engine is developed. The engine is capable of executing processes defined in the modelling tool Maestro (developed in A2.2) and supports the A2 CBP approach. Private processes as well as views are executed and an overall monitoring of the CBP is possible. The development of the engine is summarized in section 3.1 and a handbook that describes the usage of the engine is developed (Annex1).

o Additional means of execution: Additionally a BPEL engine is part of this deliverable. This is to demonstrate different execution means within the chosen scenario. As we cannot assume that all participants will implement the A2 CBP Engine, we decided to provide an additional engine that can be used to execute the relevant processes to participate in a CBP execution (Part of the Prototype).

o Task Management Engine: While capable of automating routine procedures, the CBP Engines specified in A2.4 cannot handle ad-hoc, evolving processes. Therefore we have developed a Task Management Engine capable of handling collaborative work situations (Section 4.3).

• Simulation Functionality for CBPs: It is specified in the DoW that the development of simulation capabilities is part of the WP. At design time, it is necessary to simulate the execution of the commonly agreed on CBP to detect possible problems or find optimization potential within the CBP. This simulation is intended to be on a technical or business level (Section 3.2).

• A2 Concepts and Tools Overview: Overview of all concepts and tools developed in A2 and show how they fit together.

• Model Transformation in order to create executable models out of processes defined on business level: It is the goal of the engine developed in this deliverable to execute the business process models that are defined using the A2.2 modelling method. The processes are firstly defined by business experts and express the partner’s integration from a business point of view. In order to execute these processes in the A2 CBP engine, a transformation approach needs to be developed (Section 4.2).

• Enactment Prototype: Based on the developed engines and transformations we will show how these interact by implementing the product development and change management scenario provided by EADS (Section 5).



3 Enactment of Cross-Organisational Business Processes

3.1 A2 CBP Engine Implementation

As specified in the DoW A2.5’s main goal is the development of an enactment engine for CBPs. In A2.4 we have specified three different architectural designs that allow for process execution in a CBP context (see D.A2.3). The architectural designs were based on different internal landscapes that can occur at each partner. The most common architectures have been identified as:

Cross-Organizational Business Processes

External Views ProcessEngine

View ProcessEngine

Internal

Private Business Process Engine

Application Components

Database

Business Services

Application Components with Embedded Private

Business Processes

Database

View Process and Private Process

implemented in one engine


Database

Cross-Organizational Business Processes

External Views ProcessEngine

View ProcessEngine

Internal



Database

Business ServicesInternal



Database

Business Services


Business Processes

Database


Business Processes

Database

View Process and Private Process

implemented in one engine


Database

Figure 3-1 Possible Internal Landscapes

• A2 CBP engine (right): an engine is designed that executes private processes as well as

View/CBP processes. • Internal Private Process Engine (left): It is assumed that an internal process engine is fully

implemented and it is not an option to exchange it for the A2 CBP engine. The view engine has to be developed in a way that allows for integration with the existing internal engine.

• Direct Application Integration (centre): No internal process management system is available for private process enactment and monitoring.

To conclude the A2 view approach, the A2 CBP engine (Nehemiah) has been implemented as part of the prototype due in this deliverable. The engine implementation is based on the architectural design specified in D.A2.3. The engine is contained on a CD that is part of this deliverable. A manual including installation guide is available in Annex 1.



3.2 Nehemiah in a Web Service Environment

To use Nehemiah in a Web service environment, various other ATHENA tools are necessary: in particular Gabriel, Lyndon and Johnson (see Figure 3-2 below).

A2/A5

Gabriel

TaskRepository

Gabriel

TaskModeling

TaskEnactment

ModelRepository

ServiceEnactment

RU

NTI

ME

A2

Maestro

Business ProcessRepository

Nehemiah

BusinessProcess Modeling

BusinessProcess

Enactment

DES

IGN

TIM

ER

UN

TIM

E

A5

Lyndon

Rep.

Johnson

ServiceModeling

ModelRepository

ServiceEnactment

Services

Figure 3-2 Nehemiah in Web service environment

Design

Web services are enacted in Johnson and the configuration tool Lyndon can be used to upload WSDL description files into the Service repository which will create all relevant objects like message type, endpoints and processing chains. A Gabriel service task simply provides a field to specify the service’s logical name as it is stored in the Service repository as well as a mapping between data items and the service’s formal parameters. These Gabriel service tasks are available in Maestro where they can be easily dragged into the workflow model.

Execution

At runtime the Gabriel task manager listens to task-related events occurring in the workflow engine Nehemiah. Whenever a task is created or has its status changed, the task manager reflects this event in its own repository of task objects which can be regarded as Gabriel’s local copies of Nehemiah’s task instances. Gabriel’s task model comprises Nehemiah’s but enhances it with information about the action that has to be performed for a task. Such an action can be user interaction or service invocation. In addition, it is also possible to model users and roles in Gabriel and define security constraints.

Gabriel looks up the task profile and based on its type puts the task at the top of some appropriate principal’s list or delegates it to Johnson. In case of a service task the task manager of Gabriel asks Johnson to perform the appropriate service call and forwards the call results to the workflow engine so that workflow data gets updated.



The integration of those tools is not developed using A2 resources. This will be done in A5 (see D.A5.3, relevant parts are 1.4 and 6.1) and in A4.

Figure 3-3 Nehemiah Start Page

3.3 Simulation Capability

Nehemiah offers simulation functionality for CBPs. Each CBP model in Maestro can be imported into Nehemiah and its flow can be simulated. It is possible to simulate private processes independent of CBPs as well as CBPs including all partner processes. A simulation is possible to start from the perspective of the high level CBP (by process) or from the perspective of one involved organisation (by partner role). For a detailed functional description of the simulation functionality please refer to Annex 1 (Nehemiah Handbook).

When simulating a process in Nehemiah, independent engines are started, depending on how many partners are involved. This can be done on one machine or separate machines, as desired. The engines run the simulation independent of each other; so that no central instance exists (a common JMS Server has to be installed). The state of each activity can be manually changed from one state into another and is internally updated in the repository.



4 From Business Models to Process Execution

The following figure depicts the main conceptual results developed in A2 and how they fit together:

Figure 4-1 A2 Conceptual Results



The following figure depicts the A2 Tools and their fit into the overall picture:

Figure 4-2 A2 Tools and Prototypes



Model Transformation:

In order to facilitate the modelling method developed in A2.2 and to end up with executable models, various model transformations are necessary. The following figure shows all necessary and implemented model transformations within ATHENA and the responsible partner. Depending on available resources and technical fit, the transformations algorithms have been developed in different WPs and projects. The following sections either describe the algorithms (for those that are part of A2.5) or give a quick introduction and references.

Figure 4-3: A2 Model Transformation



Need for Task Management

Distributed, knowledge based cooperation must be supported by flexible information systems (IS). Business process systems such as workflow management, enterprise resource planning, and supply chain management, apply models to facilitate work performance, control, management and coordination. In these systems, process modelling and execution are separated, performed at different times, by different people, using different tools. While capable of automating routine procedures (the left end of the process spectrum depicted below), such systems cannot handle ad-hoc, evolving processes (the right end). These processes are becoming increasingly important in the global, networked economy, so the scope of process support should be extended. A possible approach is described later in this Chapter.

Figure 4-4 The need for Taskmanagement

Routine Ad-hoc Hard-coded

applications Email Task

management

Number of processes

Value added

Groupware

A2 CO-BPMS

A2 Task management

BPMS



5 Model Transformation

5.1 EPC to PIM4SOA

Scope: To create technical models out of business models created in ARIS. PIM4SOA is used as a metamodel and enables a further transformation into technical languages (such as Maestro, UML or executable languages, such as BPEL).

5.1.1 Motivation

Today monitoring, controlling and optimizing business processes are critical factors for the success of an enterprise. Moreover new challenges to enterprises, which for example arise from the need to adapt to the processes of new customers or business partners, require fast changes of complex and already existing business processes. Therefore the target is to be fast in making executable processes available and to react to process changes as fast as possible respectively. A possible method for resolution is to use a model driven development and architecture. However in a model driven development, approaches for modelling are applied, which are not sufficiently integrated to both describe collaborative business processes (CBP) and to model information and communication technology systems. This leads to a gap between the methods used for modelling, so that the representation of CBPs by the functionality of an information and communication technology system is often insufficient.

This section provides an introduction of how cross-enterprise process oriented models at business level can be transformed to models of information and communication technology systems. It is an overview of a set of transformations from ARIS to the BPDM-based1 PIM4SOA (Platform-Independent Model for Service-Oriented Architecture) with a focus on the requirements of CBPs. Given the immense role of ARIS for industry, there is a high interest in architectural and tool support for extending the scope of the conceptual extensions to ARIS for CBP from a mere business analyst level down to the ICT level. Thus, the ultimate goal is to support the end-to-end modelling of CBPs from the business analyst level (using ARIS) down to the executable level (e.g., represented by a BPEL-based process representation). We think that a UML-based (and, in particular PIM4SOA-based) representation is a good intermediate step in this process, as it allows IT analysts and process developers to customize high-level process definitions, to fill in additional details needed for executing the processes, and finally do all this supported by a rich suite of well-developed and commercial tools. The work described in this document is a first step towards this goal.

First we introduce the basics of business process modelling forming the basis for the ARIS-PIM4SOA mapping. Second we go into the methodical approach of the mapping. As a third point we present the different diagram types we chose for modelling business processes in the section ‘Design Consideration for the Mapping’. Finally we provide an overview of the mapping itself, which is a compendium of the main parts of the mapping.

5.1.2 Basic terms and notations

Business processes model enterprises’ specific process flows in describing those activities which are conducted in pursuing enterprises’ objectives and for generating revenue. In implementing value-added chains business processes interact with partners. Those interactions can be organization internal as well as cross-enterprise interactions. In order to enable business processes to collaborate with partners and to facilitate the composition of business processes, the paradigm of service-oriented architecture is applied to business process modelling (see [FGJ04]). Business processes and activities are treated as components which provide services to and consume services from other business process components. Interacting business processes form a network of interconnected processes where conversations are conducted. The same process can appear in multiple solutions and can be connected to different partners in each case. The service-oriented approach to business process modelling is appealing mainly because it provides a natural logical view to distributed systems.

1 To be precise, the PIM4SOA business process metamodel is based on the BPDM specifications (see WD.A6.5.1. for details on PIM4SOA).



In the context of the collaboration of business process components orchestration and choreography is distinguished. [Pel03] defines orchestration and choreography for the collaboration of business process components as follows: • Orchestration: Orchestration refers to an executable process that may interact both with internal

and external services. Orchestration describes the interactions between services, including the business logic and the execution order of the interactions. Within an orchestration, the process is always controlled from the perspective of one of the business parties.

• Choreography: Choreography describes processes in a more collaborative way, where each party involved in the process describes the part it plays in the interaction. Choreography tracks the sequence of messages exchanged between multiple business parties. Often choreography is associated with the public message exchange that occurs between multiple services.

Orchestration differs from choreography in describing process flow between service components controlled by a single party (as we can see in Figure 5-1 the global process is often the controlling party). More collaborative in nature, choreography describes the sequence of public messages, where no party owns the conversation by controlling the process flow.

Figure 5-1 Orchestration and choreography

[FGJ04] distinguishes between an internal and an external view on business processes. Depending on the viewpoint, a process is described either as an executable, abstract, or collaborative process. • Executable process: The internal view models the ‘how’ of a business process to a level of detail

the modeler knows. In [Ibm03] processes, which model process flows as a set of partially ordered tasks, are called executable processes. As the flow of the processes’ interactions is described from the point of view of a single process, which coordinates participating sub-process, this kind of process composition is referred to as process orchestration.

• Abstract process: The external view models the ‘what’ of a business process. Each process specifies its roles, which it takes up in the collaboration with other processes, but doesn’t give any indication about its own realization. The interfaces of such business processes components are called abstract processes. Abstract processes additionally describe their public interactions they perform in relation to their roles in collaborations. They give no indication about whole collaborations or their own realization.

• Collaborative process: In the case of process choreography the collaboration between abstract processes is described in collaborative processes. Collaborative processes use abstract processes to model the message exchange between processes and the sequence of the message exchange from the viewpoint of an external observer. Collaborations between the involved parties are modelled as interaction patterns between their roles they take in.

5.1.3 Methodical approach

In this work we introduce a mapping between ARIS and PIM4SOA, consisting of a set of horizontal and vertical transformations. The mapping makes it possible to deduce PIM4SOA-Models at platform independent level from ARIS-Models at computation independent level. Processes at platform independent level shall be described in such a way, that they can be transformed to process execution languages like BPEL4WS at platform specific level. The mapping is described in two stages: • Transformation of ARIS models to object-oriented PIM4SOA models (see a1) in Figure 5-2),

which are as far as possible equivalent, whereas static and dynamic structures have to be considered. The focus is on the transformation of the process-oriented event-driven process chains, which are used for the representation of dynamic aspects in ARIS.



Figure 5-2 Stages of mapping

• Generation of PIM4SOA models at platform independent level out of PIM4SOA models at computation independent level (see a2) in Figure 5-2. The PIM4SOA models should be generated in such manner, that the requirements to the system (e.g. given process flows or organizational structures) are predetermined and a system designer can only adjust the system’s design and architecture. Tools which implement the MDA approach will provide implementations to perform this task automatically.

5.1.4 Design Considerations

Starting from the Siemens guidelines (the so-called Siemens Reference Process House (SRPH) for business process modelling using ARIS, we can make some basic restrictions on the set of ARIS diagrams that need to be considered. Still, a wealth of candidate diagram types available for modelling with UML 2.0 and PIM4SOA remains. Taking the different abstraction layers defined through the MDA into account, the users of the various model and diagram types, and the issues to model we give a short overview of the relevant diagram types that we consider for the ARIS-PIM4SOA mapping. • ARIS at computation independent level: We propose to use three diagram types for modelling at

computation independent level: value-added chain diagrams, function allocation diagrams and event-driven process chains. The ARIS-PIM4SOA mapping is limited to these diagram types on which the mapping rules are built.

• PIM4SOA at computation independent level: From a static point of view we use class diagrams for modelling with PIM4SOA at computation independent level in the ARIS-PIM4SOA mapping. Through class diagrams it is possible to map all important structures. For business process modelling from a dynamic viewpoint, activity diagrams and sequence diagrams appear suitable. On the basis of the service-oriented architecture business processes are realized as components in PIM4SOA [FGJ04]. Thus we distinguish between the description of the internal realization of a process component and the communication of business process components among each other. Executable processes are described via activity diagrams in the ARIS-PIM4SOA mapping, while the communication of partner process is described via sequence diagrams. Since for modelling abstract processes also the sequence of the messages is relevant, we use interaction overview diagrams for representing abstract processes.

• PIM4SOA at platform independent level: Like at computation independent level we use class diagrams for modelling the static aspects of the system to develop in the ARIS-PIM4SOA mapping. These class diagrams are revised and extended by additional concepts. As in all other diagrams the granularity of description is always raised from high abstraction levels to low abstraction levels. The diagrams which are used for the description of system behaviour are also transferred from computation independent to platform independent level. Beneath the refinement of all these diagram types, activity diagrams are particularly extended by data flow. Activity diagrams are the basis for the transformation of executable processes to platform languages for automated process execution like BPEL4WS.



5.1.5 Internal modelling architecture

The view on each process for modelling processes plays a decisive role. According to the point of view from which one or multiple processes are described, we can use executable, abstract or collaborative processes for modelling the diagrams. In this section we introduce how diverse process types are used in the diagram types of the ARIS-PIM4SOA mapping. At the same time we give an overview of the dynamic aspects of the ARIS-PIM4SOA mapping. At last we summarize the other remaining concepts of the mapping, which have not been introduced yet.

ARIS at computation independent level

The modelling methodology underlying the SRPH proposes that process flows are modelled with event-driven process chains (EPC), where both the internal flow of processes and the external interfaces of processes are described. In Figure 5-3 (left) we can see an EPC of a process whose process interfaces are shaded grey and are used for the description of abstract processes. An abstract process specifies the interactions of a process with partner processes and the sequence of the outgoing and incoming messages. As in ARIS these interactions are explicitly modelled as process interfaces, the interaction sequences are modelled implicit in the executable processes. The executable process, i.e., the diagram elements which are not shaded in Figure 5-3 (left), model the internal control flow of the process it describes.

It is possible to model the process flow of process choreography relationships as well as the flow of process orchestration relationships. A schematic view of how to model process orchestration is show in Figure 5-3. The process flow of a function, which is modelled in the EPC of a process as a sub-process, is described in a separate EPC. There the predecessor process and the successor process of the sub-process have to be adopted in the EPC of the sub-process. Moreover the predecessor event and the successor event have to be modelled in the EPC of the sub-process. Are these preconditions not satisfied, we can assume, that the relationship between processes is a process choreography relationship.

Figure 5-3 ARIS – EPC and process orchestration

PIM4SOA at computation independent level

We use activity diagrams for modelling the process flow at computation independent level. Sequence diagrams describe the communication between partner processes, whereas interaction overview diagrams model the connections between sequence and activity diagrams. In the ARIS-PIM4SOA mapping those executable and abstract processes are modelled, which have already been modelled in ARIS diagrams. In Figure 5-4 (left) an executable process is shown which is modelled in an activity diagram.



Figure 5-4: PIM4SOA – executable and abstract process at CIM level

Abstract processes are described in interaction overview diagrams (see Figure 5-4 (right)). Moreover it would be possible to extend CIMs with collaborative processes by combining sequence diagrams, describing the communication between the partner processes in an interaction overview diagram. Thereby the abstract processes would have to be considered. Whether a process is in process orchestration or process choreography with its partner processes, can be seen in the activity diagram which represents the executable process. Choreography relationships of a process are modelled through actions with the stereotypes «receive» and «send». The use of a process by super-processes over input- or output-parameters or the invocation of sub-processes in an activity diagram indicates a process orchestration.

PIM4SOA at platform independent level

At platform independent level the focus of the description is even more on the internal realization of the process flow as at computation independent level. For this reason activity diagrams are extended by data flow which is modelled between the activities and actions. In Figure 5-5 the data objects are modelled via a PIN-notation at the actions (e.g. Object1, Object2 and Object3). Additional data containers, so called «datastores», offer the possibility to store data. The modelling of executable, abstract and collaborative processes is the same as at computation independent level. Process orchestration and process choreography are at platform independent level also the same as at computation independent level.

Figure 5-5 PIM4SOA – executable process at PIM level



5.1.5.1 Further conceptual issues

In addition to the concepts of the ARIS-PIM4SOA mapping introduced above, there are several other concepts the mapping takes intro consideration. These span modelling process hierarchy, the description of ports, interfaces and roles of processes and modelling input and output data of processes. • Process hierarchy: Hierarchical process structures as they appear e.g. in the SCOR model

[SCOR] are modelled as embedded classes which can also be found in the PIM4SOA overview model. As in [JRH+04] p.42 described the graphical representation of embedded classes corresponds to directed associations from the enclosing to the embedded class.

• Ports and interfaces of processes: Processes offer services to other processes and use services from other processes. In class diagrams ports specify endpoints used to conduct the interactions of a process with its environment that is in the case of the ARIS-PIM4SOA mapping with other processes. One port can combine several services, which a process provides to its environment or requires from its environment. Services are modelled as interfaces that are classes with the stereotype «interface». For interfaces we distinguish between provided interfaces and required interfaces.

• Roles of processes: In UML the ARIS object type ‘person type’ is depicted as a class with the stereotype «role». A person type represents a role which can fulfill a function’s need for a resource [IAF+04]. In PIM4SOA we model these relationships as associations between processes and roles.

• Input and output data of processes: In PIM4SOA information objects are modelled as so-called business entities, which are classes with the stereotypes «entity». They have identity, behaviour and their own state and can be seen as hard concepts from business users’ perspective. Information objects can represent input parameters as well as output parameters of functions. The Siemens RPH defines how input and output parameters have to be modelled. In PIM4SOA we represent these relationships as associations between the processes and business entities.

5.1.6 Modelling guidelines

The notion of business processes supported by information and communication technology systems within and between enterprises got increasing attention during the last few years. ATHENA D.A2.2 gives a conceptual definition of cross-organisational business processes (CBP) providing a unified view on collaborative processes to achieve and optimize cooperation between companies. There concepts of how to realize CBPs in models from a business as well as an information and communication technology point of view are described. The CBP approach identifies the following main views and terms: • Private processes representing company internal processes that have to be executed in order to

produce a product or a service. • View processes combining different private processes to a more abstract level that enables

companies to hide critical information from unauthorized partners. • Abstract processes enabling cross-organisational business processes by representing tasks of a

company and showing the outside world the sequence of messages as well as required physical input and output.

• Cross-organizational business processes define the interactions between two or more business entities (by combining different abstract processes of participating organisations).

Since business processes are often too complex to be illustrated in a single model, several models have to be used for modelling business processes. There are mainly two ways to meet this requirement. Vertical Hierarchy can be necessary to capture business processes in different levels of granularity. Horizontal classification can be used to ‘cut’ long process models into several models with the same granularity.



Figure 5-6 Vertical hierarchy and horizontal classification

The transformation tool described in this Section, which realizes model transformations from ARIS business-level models to service-oriented IT-models (i.e. instantiations of the PIM4SOA metamodel) is based on and consistent to the concepts described in A2.2. Nevertheless it is necessary to present some modelling conventions as a more precise description of how to model concepts of the CBP approach in ARIS models. Models satisfying these conventions can be read by the transformation tool in order to produce PIM4SOA models.

The description is aligned with the concepts of the CBP approach. When presenting how to model processes in the various models the symbol types are identified in brackets after each model element that is allowed. The following conventions have to be considered:

Modelling Private Processes:

For modelling private processes representing the description of organisations’ internal processes ARIS Event-driven Process Chains (EPCs) are used. There an EPC can contain functions (function), events (event, start event, stop event), interfaces (process interface), decision-rules (AND-, XOR- and OR-rule) and the control flow. Both ways of modelling more complex processes, vertical hierarchy and horizontal classification, are supported by the transformation.

Vertical hierarchy is used to describe a single process step in more detail but also can illustrate process hierarchies and dependencies. A process can be described in more detail, by modelling its realization in a separate EPC (as shown in Figure 5-7). Such detailed EPC starts and ends with an event.



Process2Start event

Prozess1

Prozess2

Event1

End event

Event2

Process3

Event1

Event2

Process2.1

Event2.1a Event2.1b

Process2.2a Process2.2b

Process2Start event

Prozess1

Prozess2

Event1

End event

Event2

Process3

Event1

Event2

Process2.1

Event2.1a Event2.1b


Start event

Prozess1

Prozess2

Event1

End event

Event2

Process3

Event1

Event2

Process2.1

Event2.1a Event2.1b


Figure 5-7 Modelling vertical hierarchy

Horizontal classification instead is used to cut process models into different parts with the same level of granularity. The control flow of EPCs modelling horizontal classification starts and ends with process interfaces. As shown in Figure 5-8 the process interface of the predecessor process links to the successor process and the process interfaces of the successor process links to the predecessor process. It is further important that the last event of the predecessor process and the first event of the successor process represent compatible states (pre- / post-conditions).

Process2

Process2.2

Process1

Event2

Event3

Process1.2

Process2

Event1

Event2

Process1

Process2

Process2.2

Process1

Event2

Event3

Process1.2

Process2

Event1

Event2

Process1

Figure 5-8 Modelling horizontal hierarchy



Since the transformation tool supports EPCs for modelling private processes and not extended Event-driven Process Chains (eEPCs), Function Allocation Diagrams (FADs) have to be used to model input and output of processes (see Figure 5-9). Input and output of the process are modelled by technical terms. Furthermore it is possible to model organisational units, which are in charge of performing the process with the person type symbol.

Process

Person type

Technical term -output

Technical term -input1

Technical terminput2

Figure 5-9 Modelling input and output in function allocation diagrams

Modelling View Processes:

The process view concept providing an abstraction of private processes is also supported by the transformation. Though there is no separate diagram for modelling view processes, they can be visualized as process modules (see Figure 5-10) in diagrams showing cross-organisational business processes.

View Process

Figure 5-10 Modelling view processes as ‘process modules’

Modelling Cross-Organizational Business Processes:

In addition to that, the transformation tool supports the bilateral view for modelling cross-organizational business process as proposed in A2.2. Bilateral view diagrams consist of interfaces, organizational units and process-modules, which can represent a single function as well as complex processes or sub-processes. Organizational units have to be on the left-hand margin of the diagram as shown in Figure 5-11. All process-modules are entered to the diagram on the same level as the organizational unit that provides the process, and are linked together by the control flow. The input and output of a function is represented by an interface that always has to be placed directly before and on the same level as its following process-module.

Organizational elements A... .Role1

Role2

Role3

Organizational unit1



View Process1

Interface2 View process2

View Process3

View Process4Interface4

Interface3

Interface5 View Process5

Figure 5-11 Modelling CBPs



5.2 IEM to Maestro

Scope: This is a direct export from IEM to Maestro that was developed prior to the completion of the common metamodel (PIM4SOA) to allow a first transformation from a business level to a technical level and finally an execution within Nehemiah. The XMI Export prototype is developed as a Java client application that can read the currently open MO²GO model and export it into a XMI file. Before the export begins the user can choose some configuration options. Besides the usual UML export format there are the following export types: 1) Maestro: This is a general Maestro export that considers all the minimal requirements of the Maestro tool for importing a MO²GO enterprise models. The Maestro tool can import a single layer. Thus the most important requirement is that the XMI file has a single ActivityGraph element containing all the model elements. Therefore, if the model has several layers then some transformations are required. 2) Maestro + Annotation: The second Maestro export type is based on the general export and considers also the annotation in the MO²GO model. Only actions annotated as EX (executable) or UEX (user-executable) are exported and those actions that are annotated as NEX (non-executable) are not exported. All actions that have no annotation are assumed to be executable.

After choosing the Maestro or the Maestro + Executable Annotation export type the user has to choose which part of the IEM model should be exported. Possible options are the names of all layers and of all instances of the Resource class. Choosing a layer leads to an export of all the elements in it and in the sub-layers. Choosing a resource the user can export only the actions (and the elements connected to these actions) that are supported by this resource.

5.2.1 Maestro general export

For the Maestro export a similar mechanism is used as in the IEM – BPDM export. The output file format is XMI 1.2 and uses UML 1.4. The resulting files can be imported in UML tools for further use. The XMI file format is also used to transfer a MO²GO model to Maestro. However, there are some differences that need to be considered when exporting for Maestro. A UML tool can import the XMI file resulting from the IEM – BPDM export including all the information about the MO²GO model, such as: class and process hierarchy, class and instance attributes, stereotypes and tagged values. UML tools are supposed to read and show such details whereas other tools may be designed to represent information differently and read only specific parts of the XMI file. Therefore, in order to export more complex models from MO²GO to Maestro some adaptations are necessary during the usual IEM – BPDM export. In the BPDM export a detailed action is exported as an ActionState element with stereotype <<sub-process>> and the detailing layer is exported as a separate ActivityGraph element. For the Maestro export this is changed and when a detailed action need to be exported instead of it all the elements that are inside the detailing layer are exported as if they were in the current layer. In this way the XMI.content element contains just three child elements:

1) <UML:Model> which contains all the information about the model classes and their states, definitions of all attributes, stereotypes.

2) <UML:ActivityGraph> has a context property that refers to the process class which is described by this activity graph. Also contains a list of the elements that make up the process and the transitions between them.

3) <UML:Diagram> is the container for the graphic information belonging to the activity graph. The positions and sizes of all model elements and transitions from the referenced activity graph are described inside this element. \

5.2.2 Maestro + Executable Annotation

The Actions in a MO²GO model may be categorised according to their type of execution. For this purpose there is an enumeration attribute defined for the Action class with three possible values: EX, NEX and UEX. Only actions annotated as EX (executable) or UEX (executable with user interface) are exported and those actions that are annotated as NEX (non-executable) are not exported. <?xml version="1.0" encoding="iso-8859-1"?> <XMI xmi.version="1.2" xmlns:UML="org.omg.xmi.namespace.UML" timestamp="Fri Aug 05 16:32:17 CEST 2005"> <XMI.header> <XMI.documentation>



<XMI.exporter>Moogo XMI Writer</XMI.exporter> <XMI.exporterVersion>0</XMI.exporterVersion> </XMI.documentation> </XMI.header> <XMI.content> <UML:Model xmi.id="Im4ad62798m1043d874ec6mm6e91" name="Moogo:A2Model" isSpecification="false" isRoot="false" isLeaf="false" isAbstract="false"> ...</UML:Model> <UML:ActivityGraph... >... </UML:ActivityGraph> ... <UML:ActivityGraph... >... </UML:ActivityGraph> <UML:Diagram .... > … </UML:Diagram> … <UML:Diagram .... > … </UML:Diagram> </XMI.content> </XMI >

5.2.3 IMPORT NOTES FOR MO²GO FROM XMI:

• Import relies on XMI 1.2 and UML 1.4 • Only Elements with defined names can be imported. Be sure to define names for the logic

elements as well. • For Poseidon the default ActionState name is contained in the CallAction expression body. If the

ActionState itself has no name the expression is imported as the name for the Mo²go action • A detailed Action in UML is defined by a Package with the same name as the ActionState and a

UML Class inside this package (the first class in the package is taken). An ActivityGraph with context referring to this class describes the details of the ActionState from the upper package

• There is no support for text and graphic elements. To be implemented later.

Attributes:

• SimpleData and Program: OK • Simple type in XMI is defined as DataType with the same name as the IEM simple data type, i.e.

Integer, program, string, etc. (right now only works if the Model was exported from MO²GO) • Other attributes also need to be implemented

5.3 MO²GO to PIM4SOA Export

Scope: Equivalent to the ARIS to PIM4SOA transformation, business processes are transformed into a technical representation. The metamodel is chosen to allow for reuse.

5.3.1 Introduction

The MO²GO – PIM4SOA export is an extension of the IEM – BPDM general export developed in A2.2. In order to support all the PIM4SOA elements the standard MO²GO metamodel was extended by integrating the PIM4SOA metamodel into IEM/MO²GO. This metamodel consists of classes and attributes corresponding to the classes defined in the PIM4SOA specification (see Figure 5-12). Figure 5-12 shows an example of an Order and Quotation classes that extend the PIM4SOA Document class. During the export of the business process model from IEM/MO²GO all classes which have a PIM4SOA parent class get the appropriate stereotype. For example any subclass of the ServiceProvider class in MO²GO will be exported as a class with stereotype <<ServiceProvider>>. These structures are exported as class diagrams.

Besides the class structure in MO²GO also the process view is used to model the workflow of business processes. In the context of PIM4SOA it can be used to model any collaborative process as well as the private and public views of processes. The process views are exported by use of activity diagrams.



Ak tio nPro c e s sStr u c tu r e d Ta s kTime rC o lla b o r a tio n

Au ftr agD o c ume n t

O rd e rQ u o ta io n

R e s s o u rc eC o lla b o ra tio n U s eTime rSp e c ific a tio nSe rv ic e U s e rSe rv ic e Pro v id e r

Pr iv a te Pro c e s sVie w Pro c e s sC o lla b o ra tio n Pro c e s s

Se rv ic eVie w Ta s k

Figure 5-12 Model of the PIM4SOA metamodel in MO²GO. Action, Auftrag and Resource are standard MO²GO classes that are extended by the classes from PIM4SOA metamodel. Order and Quotation are

subclasses of Document.

Information

As described above, a MO²GO class can be exported to PIM4SOA in form of an UML-class element and the appropriate stereotype is applied. PIM4SOA elements can be subclasses of the IEM main classes Product, Order and the Resource. Therefore a special attribute is used. Exemplary subclasses are the PIM4SOA classes “Document” or “Entity”. The “Document” class is exported for any MO²GO class with the attribute “isDocument”. Analogically for elements of the class “Entity” – the “isEntity” attribute is used.

“Documents” and “Entity” classes are used to model the structure of the Information in PIM4SOA (Figure 5-13). The precise use of PIM4SOA in relation to UML and MO²GO has to be researched more in detail in future on practical examples. The reason is based on the fact that in the current MO²GO export PIM4SOA prototype the instances of “Document” and “Entity” classes have to be linked using MO²GO reference attributes. This relationship between these elements is mapped in PIM4SOA as a <<Document>> class associated with an <<Entity>> class. Entities, just like all other classes, can have attributes.

The instances of the MO²GO classes are mapped to “Item” elements and the IEM parent class of the instance is mapped to “ItemType”. The table below gives an exemplary overview about the relation and linking of PIM4SOA and IEM/MO²GO elements.

The ROOT class in MO²GO is exported as UML-Package stereotyped as a “BusinessTypeLibrary”.

IEM UML- Class Diagram PIM4SOA Root Class Package BusinessTypeLibrary Class Class ItemType Input-Output Objects Class Item Class with Attribute “isDocument” Package Document Class with attribute “isEntity” Class Entity Attributes Attribute Attribute



Figure 5-13 PIM4SOA information metamodel (see WD6.5.1[2], p14)

Services

“Services” and “Collaborations” are modelled in MO²GO by creating a process from type “Collaboration” and by modelling its details (Figure 5-11).

The detailed information for a MO²GO “Collaboration” process has to include the “Role” Elements connected to a “CollaborationUse” Action:

Figure 5-14 Example of a Collaboration and its description in MO²GO

In MO²GO “RegistryItems” is a list attribute defined in the “Registry” class. Each entry in this list is from type reference and has to point to an “Endpoint” element.



IEM UML PIM4SOA Stereotype Collaboration Action Collaboration Collaboration CollaborationUse Action CollaborationUse /

CollaborationOccurance CollaborationUse

Role – CollaborationUse Connection

Dependency RoleBinding

Role Ressource Part Role Registry Resource Package Registry RegistryItems Attribute Class, Part RegistryItem

Modelling of Processes

The PIM4SOA process flow metamodel (Figure 5-15) has just minor differences from the metamodel of BPDM. Each process view from MO²GO is exported as an UML Activity Diagram. See the respective tables for a list of the mapping from MO²GO to PIM4SOA elements.

Figure 5-15: PIM4SOA process flow metamodel

The Steps in the Process are the elements in the scope of an activity graph. IEM Element (Class type)

UML Activity Diagram

PIM4SOA Stereotype

Action Action Task Detailed Action (StructuredTask) Action,

ActivityGraph StructuredTask

Detailed Action (Process) Activity Graph in the context of a <<Process>> Class

Process

Resource (CollaborationUse)

CollaborationUse / CollaborationOccurance

CollaborationUse

Decision Decision Decision Join Join Join Join (Merge)

Merge Merge

Split Fork Fork Action (Timer)

Action Timer

Resource (TimerSpecification) Object TimerSpecification Resource (PrivateProcess)

Class PrivateProcess

Resource (ViewProcess)

Class ViewProcess

Resource (CollaborationProcess)

Class CollaborationProcess



Maestro to and from PIM4SOA

Scope: To exchange models via a common metamodel. This includes an import from a business level (e.g. of ARIS models), an exchange on a technical level or a transformation to BPEL (via PIM4SOA).

The PIM4SOA import and export into Maestro is developed in A4 and partly also in A6 (WD.A4.3, D.A4.4).

PIM4SOA to BPEL

Scope: To transform technical models into executable models. The models in PIM4SOA are either coming from a business level (through the ARIS transformation) or from a technical level (e.g. form Maestro).

The PIM4SOA export into BPEL is developed alongside work in A6, see WD6.5.1 Chapters 2.3 and 4.1.1. This section will document only additional considerations for cross business collaboration.

Support for CBP in the PIM4SOA metamodel

WD.A2.2 outlines extensions to the PIM which support Cross Business Processes. These extensions (with some minor modifications) are shown in the following class diagram. Note that each type of ServiceProvider may (will) contain an associated Process, so for convenience we can think of these service providers themselves as the ‘processes’ (ViewProcess, PrivateProcess) talked about elsewhere.

Figure 5-16 PIM4SOA CBP extensions

These extensions support engines such as Nehemiah that can implement private processes running with their 'public' view processes. The view process enacts the participation of the private process in a collaboration. Its process model abstracts/hides internal details of the private process using view tasks.

Cross Business Processes are not in themselves considered at the base PIM4SOA level, because it is more directly involved with ‘Orchestration’ than ‘Choreography’ (see 4.2.1.2). These extensions are intended to provide a useful exchange format between the cross business processes which can be modelled in Maestro etc. and executed in Nehemiah, and tools with model omitting these concepts. This is achieved by providing a transformation to flatten some elements of Cross Business Processes into the PIM4SOA, described below.



Transforming CBP elements to core PIM4SOA

Of particular interest is the transformation from the PIM4SOA (with CBP) to BPEL, as discussed in the overview of this document. This will be by way of mapping those aspects which can be useful in BPEL down to basic PIM4SOA components. View Processes and Private Processes map to ServiceProviders / Processes from the standard PIM4SOA metamodel as follows:

Private Processes map directly to standard Service Providers, and therefore to a BPEL process. An executable process can then be created, which will interact with a ‘View Process’ (see below) to expose the functionality.

View Processes map to both an abstract ServiceProvider (BPEL process), exposing the externally visible behaviour, and an executable process implementing the coordination with Private processes.

The abstract process includes Collaboration Uses (which will become partner links, see WDA6.5.1, ch. 4.1.1) corresponding to the role in the collaboration in which this view process participates. The process flow does include interaction activities with the other roles in the collaboration but not those with the private process.

The Executable Process includes those internal collaborations (which will become PartnerLinks) with the private process.

The figure below (4-18) shows the parts of a CBP which can be usefully transformed to BPEL by way of the PIM4SOA. Private processes which are modelled may be transformed into PIM4SOA ServiceProviders (processes). More importantly, View Processes are also transformed to executable processes. It is this which would be transformed using the PIM->BPEL transform to give a process, executable in a BPEL engine, providing the independent ViewProcess engine as in figure 3-1.

Figure 5-17: How Private and View Processes map to a Collaboration between two executable

providers and an abstract process

A ViewTask places some additional Steps in both of the above created ServiceProviders.

Additional activities in the private process to include communication with view process through partner link type.

Additional activities in the executable view process to include communication with private process through partner link type.

The BPEL processes which will be created by following through these transformation steps will require tailoring to a specific execution environment before deployment – in particular, bindings to actual service providers implementing any service consumed will be necessary. Further investigation could be done to automate more of this process by way of annotations to the model.



6 Task Management for Semi-Automatic Process Coordination

The objectives of the Troux Task Management solutions include: • To be able to directly execute process models from the enterprise layer (A1), • To support knowledge-intensive ad-hoc, emergent and dynamic cross-organisational processes,

not just automated routine procedures, • To provide a simple and easily configurable cross-organisational process management system

for SMEs and other companies not willing or able to invest in large scale process automation systems,

• To enable prototyping and piloting of cross-organisational business processes, letting businesses interact and establish mutual trust in the early phases of a collaboration, without a large up-front investment,

• To facilitate cross-organisational training, experimentation and testing during business process development,

• To enable exceptions of automated processes to be captured and managed inside the A2 system, for traceability, accountability, and coordination,

• To facilitate change management of cross-organisational business processes, • To dynamically and interactively bind internal process data to web services and other external

process steps, even if the models are not completely specified in advance, • To monitor and manage ongoing automated and ad-hoc process instances in an integrated

manner, and • To maintain complete records of all cross-organisational processes for accountability.

6.1 Integrating Support for Ad-hoc and Structured Work

Designing computerised systems for planning, coordination, management, collaboration and learning, is a difficult socio-technical problem. In knowledge intensive inter-organisational collaboration, success depends on the participants' creativity and joint problem solving abilities. Each problem is unique, complex and incompletely understood. A framing of the problem is developed alongside the solution. Participants with different backgrounds may not fully grasp each other's terminology, and must develop a common understanding. Organisations, information systems, models and languages must thus be open to change, in order to capture a continuously unfolding shared understanding among process stakeholders.

Plans do not predetermine the course of work, actions are situated and people must interpret plans creatively in the contexts that arise (Suchman, 1987). Even in seemingly routine and unskilled work, exceptions and uncertainties permeate the environment. Workers reflect upon and manage these problems in a sophisticated manner (Wenger, 1998). To some extent, most work can thus be regarded as knowledge intensive. Most processes also have routine parts, which can be predefined. Many software development companies, for instance, have prescribed quality management procedures for administration, testing, audit and approval. Systems must thus integrate support for ad-hoc and structured work, and allow structure to emerge as plans are elaborated throughout the process (Haake&Wang, 1997; Jørgensen&Carlsen, 1999; Shipman&McCall, 1999). Users must be supported in selecting a suitable degree of plan specificity for the current state of their project, balancing plan complexity with the need for guidance and control.

6.1.1 Customised and Integrated Software Support

Simple and useful tools motivate use. Software that offers a wide range of functionality often becomes overwhelmingly complex and incomprehensible. Consequently, only a small portion of the available services is utilised. This condition is known as featuritis. We thus need role and task specific user interfaces, emphasising what is needed in the current context. Interfaces and semantics should also adapt to the local needs of each project. Process models, describing who performs which tasks, when, and why, are powerful resources for such customisation.

Systems and processes should also adapt to the skills and preferences of each individual. Users filling different roles have different needs for IS support, and varying degrees of computer literacy. Personalisation fosters a sense of ownership, further motivating active participation. Studies have shown that personal templates and configurations spread informally through the organisation, improving processes and disseminating knowledge in an emergent manner (Trigg&Bødker, 1994).



6.1.2 Emergent Interoperability

Inter-organisational and multi-disciplinary cooperation requires not only information exchange, but also knowledge sharing. Effective teams must form across local cultures. Common frames of reference are established throughout the project, so support systems must allow the meaning of terms, models and artefacts to evolve. In communities of practice, this learning process is called negotiation of meaning (Wenger, 1998). Ambiguous models are required because the meaning of formal, well-defined terminology cannot be negotiated. IS must also support the process of negotiating and reconciling diverging views, model and language interpretations.

The unique nature of each project, and the changing set of partners, seldom makes it economically viable to integrate information systems through conventional development methods. Standardisation requires that the domain is static and well understood, and is thus seldom appropriate for knowledge work. Consequently, we need a flexible infrastructure that allows shared understanding and semantic interoperability to emerge from the project, rather than being a prerequisite for cooperation.

6.1.3 Integrating Knowledge Management in Everyday Work

Lack of integration into everyday work is a reported shortcoming of knowledge management (KM), enterprise modelling and process improvement (Davenport&Prusak, 1993; Ohren et al. 2002). KM too often becomes the domain of outside experts that lack a full understanding of the complexities of work and the local language of the work community (Wenger, 1998). Work performers become sources of information to KM activities, not active participants. Standardisation and codification, rather than local innovation, skill development, organisational and social learning, become the focal points of KM (Carlsen et al. 2002). Failure rates above 50% are commonly reported (Lawton, 2001).

The gap between what people say and what they do, makes it difficult to use process models and other official accounts of work as input to KM (Argyris&Schön, 1978). It must thus be straightforward to modify process models locally. Still some knowledge cannot be modelled and will remain tacit (Nonaka&Takeuchi, 1995). Most descriptions are thus incomplete while they are used, subject to an ongoing elaboration and interpretation. Change and learning demand that the system be open. Models are completed only when they are no longer in use. When the work is completed, models document (some perspectives on) the history of the project.

In software engineering, researchers have defined process classification schemes, e.g. to select appropriate methodologies. Reflecting the wide diversity of processes, even within a single industry, up to 15 classification dimensions with 37400 process types have been proposed (Cockburn, 2003). This number suggests that predefined process models cannot be constructed for all variants. Instead, process templates must be adapted and combined in the particular circumstances of each project2.

6.2 Modeling and Execution Approach

Our approach relies on the assumption that end users must be actively involved in creating, updating and interpreting models of their own work, as part of the work. Local participants are the only ones with sufficient knowledge of the process. Modelling by end users has met scepticism from the workflow research community (Bernstein&Jablonski, 2000). On the other hand, studies of user participation in IS development, tailoring, knowledge management and process improvement indicate that our approach is viable (Argyris&Schön, 1978, Suchman, 1987; Wenger, 1998). In workflow management, users also deal creatively with change and exceptions, often by taking the process out of the system and handling it manually (Bowers et al., 1995). Systems not designed for user involvement thus present a barrier both to local innovation and to the capture of these contributions for further assessment. End user participation remains primarily an organisational problem, involving trust, power and community building, but simple, user-oriented, and adaptable modelling languages will also remove barriers.

2 Although each project is unique, models can be reused, providing starting points for detailed planning. By harvesting experience from past projects into templates, knowledge management is anchored in practice, emergent, bottom-up and middle-up-down rather than centralised, top-down.



Models are defined as explicit representations of some portions of reality as perceived by some actor (Wegner, 1997). A model is active if it directly influences the reality it reflects. Model activation involves actors interpreting the model and adjusting their behaviour accordingly. This process can be (Jørgensen&Carlsen, 1999; Jørgensen, 2004) • Automated, where a software component interprets the model, • Manual, where the model guides the actions of human actors, or • Interactive, where prescribed aspects of the model are automatically interpreted and ambiguous

parts are left to the users to resolve.

We define a model to be interactive if it is interactively activated (Jørgensen, 2004).. By updating such a model, users can adapt the system to fit their local plans, preferences and terminology. This concurrent activation and articulation (modelling) is depicted in Figure 6-1.

Articulation

Activation

Domain Interactive model

Figure 6-1. The interplay of articulation and activation.

6.2.1 Active Process Models

Process models defined as part of corporate procedures and quality management, rely on manual activation. The loose coupling between the domain and the model often result in models that are not adhered to. Workflow management systems, on the other hand, automatically activate predefined process models. The enactment engine controls the progress of work. Adaptive workflow research focuses on algorithms for dynamic change and exception handling (Bernstein&Jablonski, 2000; Jørgensen, 2001; Klein et al. 2000). Dynamic change adapts running instances to changes in the class schema, increasing the efficiency of top down control. Exception handling algorithms involve users in resolving unforeseen problems, but only as a last resort, when all else fails. The objective is to automatically restore the system to a consistent state. Automation demands well-understood domains, repetitive processes, clear organisational roles, an established terminology, and predefined plans. Knowledge intensive processes do not obey these constraints.

6.2.2 Emergent Workflow

Interactive process models generate emergent workflow systems (Jørgensen&Carlsen, 1999) where the process structure emerges from the work, rather than being prescribed by outside experts. As the process unfolds, users articulate their plans and actions into the model, and help the system to interpret and activate the model in the situations that arise. Emergent workflow seeks to augments users' capabilities to cooperate, innovate and manage their own work. Its enactment engine is an open interaction machine (Wenger, 1997), collaborating with users to solve problems, and not a closed Turing machine executing a completely predefined "process program"3.

Some research has likewise integrated modelling and enactment, proposing evolving (Herrmann, 2000), human-centred (Faustmann, 2000), free (Dourish et al., 1996) and mixed-initiative (Bernstein, 2000) workflow concepts (Jørgensen, 2001). But this research has resulted in few operational tools. We know of no commercial system that has opened up the system for human participation, and uses openness as a lever for simplifying the modelling language and activation semantics.

3 By delaying modelling from the development to the operation phase, interactive models becomes a general approach to tailorable and evolving IS (Jørgensen, 2004). Visual models are used to control behavioural reflection. Users immediately see the effects their articulation work has on the system.



6.3 Modeling Architecture

The processes will be modelled in a semi-structured way using process languages in Metis compatible with the ATHENA A1 POP* core, cf. deliverable document DA1.4. Both concrete individual processes and process templates will be modelled at the instance level. New tasks can also be created from templates through the web browser user interface, by invoking these operations: New task, New subtask, New next task, Redo etc. etc. The metamodel for task modeling, is pictured below.

Figure 6-2. Task management metamodel (in the EKA notation from A1).



6.4 Implementation Architecture

Task management will be constructed as a MUPS solution (Model-configured User-Composeable Platforms and Services) in the Metis Enterprise Portal Environment. This active model execution framework (depicted below), established partially in A6.6, will be extended with new capabilities through this work.

Figure 6-3. Components of the Metis Enterprise Portal and Repository.

The user interface has two main components • Web portal (HTML), containing

o Task lists, with configurable o Tasks shown, selected e.g. all tasks for one person, in one process, in one collaboration, with

a certain status (new, ongoing, completed) etc. o Properties shown for each task o Navigation structure (list or hierarchy)

o Task execution and administration forms, providing access to everything related to a task, in a model-configurable way, e.g. its properties such as descriptions and deadlines, status, input and output data, documents, underlying services and tools, people participating, subtasks etc.

o Put together in a user-composeable navigation structure and layout. • Visual modeling (Metis), with model views for e.g.

o Task definition and process modeling o Task assignment and resource allocation o Monitoring of ongoing tasks and processes o Tasks and processes for each object in an enterprise architecture model, e.g. all tasks related to

one trading partner, all tasks related to the selling on one particular product, all tasks implemented by a specific automated process or web service etc.

On the server side, all data about tasks and processes (templates as well as concrete tasks) are stored in the Metis Enterprise repository. The two primary execution components adapted for dynamic task management are: • The Configuration Manager, which provides dynamic binding of parameters to model objects,

such as tasks, utilising multi-dimensional inheritance and aspect-oriented configurations, • The Portal server, which provides basic building blocks for HTML portals, including user interface

components and containers, made accessible as portal services.

In this work, the portal is extended with model-configured, user-composeable MUPS services,

Portal

Reporting

Visual Modeling

Collaboration

Collection

Policy Management

Workflow

Metis Client Tools

Metis Collection

Metis Team MPCE

Metis Enterprise Repository

Repository



which utilise existing portal services and user interfaces. The main components of this framework, is depicted below. Configurable services will consist of • Dynamic lists and forms as described above, including • Configurable components, containers and visual presentation styles, • Providing access to services that can be plugged in at run-time, e.g.

o Parameterised URLs, o Web services, o Automated business processes in other A2 engines, BPEL engine and the Troux Process

Manager (Oakgrove), and o Metis modeling operations.

The configuration manager will be applied at runtime for extracting information from these context and binding them to service and task parameters • Collaboration context, e.g. a partnership between two or more companies, such as a supplier and

a customer, • Task context, the task in question, its parent tasks and subtasks, and all other model elements

they are connected to, • User context, the user performing the work, and any information related to him/her, such as the

employer company, role in the task, responsibilities in the collaboration etc.

Because the system is designed to be interactive, the parameter values extracted from these multi-dimensional contexts will be presented to the user for confirmation and elaboration, before being submitted to a task or service.

In addition to operational data, solution configuration parameters will also be extracted in the same way, e.g. for • Which user interface elements to use for interacting with tasks and related information objects,

how to lay them out and structure them, etc. • Which services that are made available to a given user in a given context, • Which information the user is given access to, • Which software tool, service or execution environment that will support the performance and

management of a given task, • Etc.



6.5 Relationships to the Overall Execution Framework and Other ATHENA Projects

As illustrated below, the task management solution will utilise services from other, underlying platforms. These services may also have been developed based on an enterprise model, but unlike the MPCE, the other platforms do not execute the enterprise model directly. Instead, the enterprise model has been converted to business process execution models, platform independent and platform specific software models (for e.g. UML virtual machines, or rule engines), or most commonly to software application code. For all these other platforms, models are used at design-time to define the solution. In task management (and the A1 MPCE), the border between design time and runtime is eradicated, because modelling and execution takes place concurrently.

In the future, the task management component should be able to utilise enterprise models developed during the design of software, service or BPMS solutions to achieve meaningful runtime plug-in of the components that resulted from the development efforts.

The task management application is built upon he active modelling platform developed by Troux in A6. Together, they provide execution services to the modelling platform for collaborative enterprises (MPCE) developed in A1. Other technologies from A2, A5 and A6 will be integrated through the runtime web service plugin that is developed in A6.

6.6 Implementation

This section describes in greater detail the solutions developed for task management. We will focus on the complementary modelling views applied for visual task management. The first sample is a task tree view for a project, showing all planned and ongoing tasks in a project as a work breakdown structure, with the status marked with colours (grey = completed, green = ongoing, red = delayed etc.). Tasks may be opened and closed to hide/shown its subtasks.

Design timemodelling

Runtime execution

Abstraction

Programming platform

Service oriented architecture platform

Business process platform

Enterprise model

Business process model (PIM)

Platform spec. model

Code

Model-generated workplaces and

visual scenes

Business process management system

Web services

Apps.

Task Management



Figure 6-4. Task management work breakdown structure.

An important part of task planning is the deadlines and starting times (planned, estimated, actual) of each task. This can be visualised in a Gannt-diagram, or a timeline view like the one below, again using colours to separate completed, ongoing, delayed and future tasks. The visual task management template in the Metis client is also capable of importing project plans from Microsoft Project.

Figure 6-5. Task management timeline.

Swim-lane views are not just relevant for separating different roles and companies in cross-organisational business processes. It is also useful, e.g. for getting an overview of the current load on key personnel, as shown below. Here the tasks are sized according to the amount of work remaining, and critical path relationships between tasks are highlighted. Again, colours are used to highlight e.g. who has the most delayed tasks.



Figure 6-6. Task allocation overview.

Below you find the form used for entering information about a task while you are modelling. The set of properties and specialised task types can easily be extended through metamodeling.



Figure 6-7. Task properties edit form.

In addition to these views, we do of course also provide conventional process modeling views for more structured procedures. Another important capability is to see tasks in their enterprise context, i.e. to use the enterprise model as a search and navigation structure for tasks. For instance when you are working on a product model of a subsystem, you will be able to retrieve all past, present and future planned tasks related to this subsystem. In this way, task management utilises the product structures as a coordination artefact. We believe that other enterprise dimensions are just as useful perspectives towards understanding and coordinating work as processes, perhaps even more useful, because they deal with the practical realities of the content of work. More details about this integration of product and process based interoperability will be available from project A4.

Finally, we provide management dashboards, such as the one depicted below, where the results of typical analysis (funding, performance, risk, ROI etc.) can be organised and visualised in an immediately understandable manner. Here you see indicators for each project (or main task), and the projects are also grouped according to whether they are in compliance, requiring investigation or at risk with respect to the chosen analysis. The analyses are partially based on calculations on the work



breakdown structure, so that e.g. an overrun on a task is immediately propagated to higher levels, and its effects are visible in the management dashboard. Reports about the analyses can be exported e.g. to HTML, Word or Excel for further processing by people who do not have the modelling tool installed.

Figure 6-8. Management dashboard for project monitoring and analysis.



7 Event and Document Correlation

7.1 Motivation

During the execution of Cross-organisational Business Processes, private documents and events are continually related to process instances running on all the different process engines of the whole architecture. In this context, the ATHENA Event and Document Correlator (A-EDoC) would provide a set of basic services for matching documents to process instances. The Cross-organisational Business Process execution is based on the collaborative exchange of messages composed starting from the private resources of each partner. Those cooperative messages include all the shared structures involved in the CBPs while the Private Views use internal documents and messages for the interaction with own private systems. Those private resources should be associated, during the execution of the processes, to the related process instances in order to maintain the relationships between them.

7.2 Event and document correlation approach

Message correlation may be realised starting from the identification of messages and resources, using ID codes, in order to enable the classification of each single message and document involved in each particular execution of a process. In this context it is possible to understand easily that if we want to solve correlation issues we need also to define, at design time, the correlation sets that define the basic elements of the structure of each resource exchanged on the private side of the CBPs, in order to identify univocally those resources. The A-EdoC module implements only the run-time execution of the correlation, so it has to get all the design-time correlation information from the business process models or using some kind of automatic policy for capturing, directly during the run-time execution, the basic correlation sets needed to classify univocally the different message payloads.

Deliverable D.A2.2 explains possible ways for implementing at design time the definition of the correlation sets using, for instance, the comments of the BPMN notation or specific elements of the BPEL syntax. In other words it is possible to say that each process and resource involved in the execution of CBPs has to be exclusively identified and that identification will be used to link together CBPs, process instances and message payloads.

Figure 4-27: A2 event and document correlation

Process View A

Private Process A

Process View B

Private Process B

CBP

ID PP ID PP

ID VP ID VP



The figure above clarifies better the usage of the document and message identificators for sharing a sort of public state during all the CBP execution, among the partners involved in the process and between private and collaborative levels.

7.3 Event and document correlation architecture

Event and document correlation could be implemented intercepting the documents attached to the messages exchanged during the process execution and linking that information to the related process instances in order to maintain a global state between them.

The ATHENA context includes the enactment of Cross-organisational Business Processes that describes collaborative processes shared among partners and so it is necessary to maintain relationships also at cooperative level. The private processes are exposed as process views that mediate the execution inside each private context. The state maintained on the private side is not enough and should be propagated also on the collaborative layer. Each document involved in a CBP has to be putted in relation to the private state of the associated process instance and also to the related CBP instance in order to guarantee a global state in the cooperative context.

In the ATHENA framework the execution of the CBPs are managed using the tools provided by A2 for the process environment and Johnson, provided by A5, for the real exchange of the messages. The figure below describes in detail the relationships between those different components, putting the focus on the A-EdoC element. The CBPs are modelled at design-time using Maestro and they are executed at run-time using Nehemiah, which talk to Johnson using Gabriel. In this context it is possible to use Johnson for intercepting and filtering the messages exchanged during the process, Maestro for acquiring the information related to each correlation set and finally Nehemiah to get the process instance identificators.

Figure 4-28: A-EdoC overview

In this context the architecture of the A-EdoC component is based on three basic integration points that will be used to get all the information needed for storing the event and document correlations at run-time. Those correlations could be used by external components and also by process engines in order to rebuild, at run-time, relationships between processes and resources in the cooperative context. Once a correlation instance is stored, it is possible to use process IDs in order to receive the link to a particular document while if it is passed to the component the identification of a resource then it is returned the information regarding the process instance which involves that document. So the A-EdoC could be used in a double way, to obtain information on particular document starting from process IDs or getting information about particular process instances starting from correlation sets.

BPEL Engine( IBM ) Nehemiah

( SAP ) Gabriel ( SAP)

JohnsonSAP

A-EDoC(FORMULA)

MAESTRO ( SAP )

Get correlation set schemas from BPMN models

MAESTRO(SAP)

Get information about process instance IDs


Get correlation set schemas from BPMN models

JohnsonSAP



Figure 4-29: A-EdoC architecture

The previous figure explains in detail the architecture of the A-EdoC component. The core is the Event and Document Correlator which uses a repository connector for storing information about correlations and provides web-based user interfaces for managing the main settings and visualizing information on the real state of execution. The Event and Document Correlator provides also a set of services that can be used to retrieve information about the correlations and to set a new correlation. This last service could be called by Johnson, or also by other service mediators, providing the payload of a new message exchanged in a CBP context. You need also to send other message identification information that will be used by the correlator engine to retrieve from Maestro and Nehemiah data regarding the identification of the process related to that particular message.

We explain the whole execution with an example: 1) Enterprise A starts a new Cross-organisational Business Process executed by Nehemiah. 2) Enterprise A sends a message to Enterprise B using Johnson as message gateway. 3) Johnson intercepts the message and uses A-EdoC in order to store information about correlation between the message and the related process instances, both private process and CBP. 4) Johnson sends to A-EdoC the payload containing the document and other information regarding the message. 5) A-EdoC uses the data provided by Johnson in order to retrieve the information regarding the correlation set of that particular message from Maestro (or other modelling). 6) A-EdoC uses the data provided by Johnson in order to retrieve, from Nehemiah or other process engines, the information related to the processes in which the message is exchanged. 7) A-EdoC stores all the correlation information in its repository. 8) Johnson sends the message to Enterprise B. 9) When the Enterprise B will come back with the response to the Enterprise A, the CBP execution will include also all the references to the related process instances, so the Enterprise A can use A-EdoC to get information on its private document involved in that particular instance of the process.

This example could be explained better by the figure in the next paragraph in which the usage of Johnson and its flexible architecture is shown in details.

7.4 Integration with A5 tools

As we have seen before the process execution is built on top of the message exchange, so it is necessary to integrate the A2 solutions with the message layer execution support provided by A5. It is quite clear that also the correlation issue is fully related to that message layer because its main goal is to associate documents, exchanged using messages, with process instances. In this context it is



obvious that, also for A2, it is better to solve the correlation directly at message level integrating the A-EdoC component into Johnson. This result is not only the best solution for a fast and complete implementation of the event and document correlation component but it is also another great opportunity of integration between the two projects.

Figure 4-30: A-EdoC integration with A5 tools

The figure above describes a simple example, following the process modelled for the scenario shown in the next chapter, in which is included the usage of the A-EdoC component in the context of the message exchange. When a message is exchanged, the Johnson tool intercepts and elaborates it using a particular processing chain composed by different processing modules, including also the one which implements the call to A-EdoC correlation service. This is possible because Johnson is based on a flexible and extensible architecture which provides a simple way for adding features, simply using external services that work directly on the header or the payload of the messages. Using this feature, it is possible to parse the content of each message involved in the process execution in order to capture the instance of the correlation set related to that particular document schema. In this manner each correlation set instance could be linked to the related process instance using the WS-Addressing as base for deriving the identificator which specifies the right process directly related to the parsed payload. The same methodology is used in A3 to implement the semantic mediation engine (ARES). In this manner it is possible to compose a Johnson processing chain which includes the WS-Addressing feature, the A-EdoC service and the semantic reconciliation, in order to process the messages in a completely mediate and cooperative context, through different partners and standards.

7.5 Semantic support in the correlation context

As we have seen before, A3 provides a set of semantic services that can be used by other tools in order to solve, directly at run-time, different issues in a more automatic way. In this context it is possible to think about an enhanced version of the A-EdoC services capable of resolving the correlation set design just understanding during the parsing of a message which information is necessary to identify univocally that particular payload. Following this approach it will be not required to identify at design time the correlation set of each resource but the problem will be solved using the knowledge semantically stored into the domain ontologies. Those ontologies should include the concepts of “unique identificator” or “correlation set” in order to associate, during the semantic annotation process, those notions to the elements of the documents that can be used to identify univocally the resource. To clarify this we use a simple example. If you know that to identify a

4 . Create formal change request

5 . Describe problem and ideas for solution

6. Propose solution 7 . Evaluate proposed

solution 7 . Propose new

solution 7 . Accept solution

Change request process needs to be refined

8 . Decide solution

9 a ) change in product model

Notification of supplier Change production

line 9 b ) Trigger change

manufacturing baseline

Nehemiah

BPEL Engine

Supplier

Johnson

AEDC

ARES

Johnson



particular document exchanged in a message, such as an invoice, you just need the invoice number, so you have to semantically annotate that field referring also to the ontology concept of “unique identificator”. In this manner will be possible for the A-EdoC component to derive at run-time, not from Maestro but directly from the A* annotation tool [ATHDA32], all the necessary information for storing the right correlation set data.

Figure 4-31: A-EdoC integration with A3 tools

BPEL Engine( IBM ) Nehemiah

( SAP ) Gabriel ( SAP)

JohnsonSAP

A-EDoC(FORMULA)

A* (LEKS)



Get correlation set information from semantic annotation

JohnsonSAP

Get correlation set information from semantic annotation

(LEKS)A*



8 Enactment Prototype – EADS Scenario

The enactment prototype shows how the different engines developed in A2 interact to realize a change �ehemiah�t scenario in the Virtual SpaceCraft Program. The scenario description has been provided by EADS in project B4. In the following we first describe the scenario and then point out how it can be implemented using the engines provided by this work package.

8.1 Scenario Description with A2 Enactment Focus

During the construction of an airplane in the Virtual SpaceCraft program a part provided by a Landing Gear Supplier, has to be replaced with another variant of the part in the engineering phase, in order to �ehemi a specific quality requirement, e.g. “needs to for the wheel in contact with the braking system to support a pressure below N bars”. One engineer in the EADS design office (engineer E) discovered that what was initially planned to have sufficient braking is insufficient, according to the fact that the weight of the space craft and the loading is higher than initially planned.

The following actors are involved in the scenario: • Integrator (EADS): Design Office in particular Engineer E • Landing Gear Provider: Design Office in particular Engineer F

To address this change request first internal steps are necessary at the Integrator to identify the concerned part and find a solution. Then a change management process is triggered that also involves the Landing Gear Provider. The overall change process is depicted in

Figure 8-1. 1) Background: A new requirement is issued by one client of EADS for a specific spacecraft. The company has initiated processes to check their existing designs for compliance, in particular for braking when landing. 2) Working in a product model, engineer E discovers that the braking system including wheels, is insufficient and must be improved in order to meet this requirement. 3) E describes the issue and creates an internal change issue within the EADS PDM system. 4) As the issue is of particular importance it is decided during Change Issues review to investigate the problem. A first investigation, through an internal change request, is launched.

o Engineer E explores the issue with colleagues, using task management for coordination and traceability, utilizing the product structure as a coordination �ehemiah, with tasks attached within the EADS PDM system.

o As a result, it appears that braking system is to be changed, but there is some impact on the wheels, provided by the Landing system supplier

5) During next Change Issues review, the solution is exposed. o The solution raises the issue with some suppliers (Landing System provider – cooperation

needed with engineers in this company, with whom E might have cooperated earlier or not) in order to investigate impact of the proposed solution. An external change request is to be created (escalation process) within the Network Cooperation Space.

6) E creates a formal change request, launching an instance of the External Change Management Process.

7) E collects the documents describing the problem, the proposed solutions and investigation to be launched by the Landing System provider. These documents are associated as inputs to the external change request. These documents are uploaded on the shared PLM repository. When the investigation task associated to the External change request is available on the worklist of Landing Gear provider, also links to the documents and models available on the shared repository are available through Nehemiah. 8) Engineer F at the Landing Gear supplier is in charge to study the problem and proposes a solution. He uploads a description of the solution in the shared repository, and indicates that the task is achieved. 9) The change proposal is reviewed by the engineers in the two companies. The proposed solution is acceptable from a technical point of view. Then the following steps follow:

o Proposal offers (redesign or existing component) o Counteroffers o Acceptance

10) The proposed solution is refined and then a change order at program level is decided.



11) The tasks to be performed to realize the change are defined and associated to the work order at the actors. The tasks are then launched. The parts and versions to be produced are defined in advanced, according to identification rules of the program and of each organization as well as their place in the product structure. They are the outputs of the change process. The tasks to realize an associated internal change order on systems of the partners are transferred to the local workflow engines. 12) Implementation of the solution:

o Different documents and models are produced. o They are then uploaded on the PDM systems (local, then shared PDM repository), with

adequate status, and according the decided part/document number and version.

Please note that handling of complex product data is not part of this work package but will be dealt with in the context of A1 as well as A4.



Figure 8-1: Change management process (only the CBP is shown in that figure).



8.2 Realization of Scenario

To implement the change management scenario the engines provided by A2.5 are connected in the following way: • The first part of the process that is running internally at EADS and identifies the affected parts is

executed by the Task Execution Engine. • The change request process is then executed between Nehemiah running at the EADS site and

the BPEL engine running at the Supplier site.

The different engines are linked through Web services that provide the interfaces to call the tasks at the partner site. The complete setup is shown in Figure 15.

Figure 8-2: Set up for realization of scenario

The example below shows the Web service that can be used to trigger the start of the external change management process executed in Nehemiah from the Task Execution Engine.

<?xml version=”1.0” encoding=”UTF-8” ?> - <wsdl:definitions targetNamespace=”�ehemiah”

xmlns=”http://schemas.xmlsoap.org/wsdl/” xmlns:apachesoap=”http://xml.apache.org/xml-soap” xmlns:impl=”�ehemiah” xmlns:intf=”�ehemiah” xmlns:soapenc=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/” xmlns:wsdlsoap=”http://schemas.xmlsoap.org/wsdl/soap/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

- <wsdl:message name=”startPrivateProcessRequest”> <wsdl:part name=”workflowModelExternalId” type=”xsd:string” /> </wsdl:message>

- <wsdl:message name=”startCBPResponse”> <wsdl:part name=”startCBPReturn” type=”xsd:string” /> </wsdl:message>

- <wsdl:message name=”startPrivateProcessResponse”> <wsdl:part name=”startPrivateProcessReturn” type=”xsd:string” />



</wsdl:message> - <wsdl:message name=”startCBPRequest”> <wsdl:part name=”externalPartnerId” type=”xsd:string” /> <wsdl:part name=”coaltionWorkflowModelExternalId” type=”xsd:string” /> </wsdl:message>

- <wsdl:portType name=”StartProcessService”> - <wsdl:operation name=”startCBP” parameterOrder=”externalPartnerId

coaltionWorkflowModelExternalId”> <wsdl:input message=”impl:startCBPRequest” name=”startCBPRequest” /> <wsdl:output message=”impl:startCBPResponse” name=”startCBPResponse” /> </wsdl:operation>

- <wsdl:operation name=”startPrivateProcess” parameterOrder=”workflowModelExternalId”>

<wsdl:input message=”impl:startPrivateProcessRequest” name=”startPrivateProcessRequest” />

<wsdl:output message=”impl:startPrivateProcessResponse” name=”startPrivateProcessResponse” />

</wsdl:operation> </wsdl:portType>

- <wsdl:binding name=”StartProcessServiceSoapBinding” type=”impl:StartProcessService”>

<wsdlsoap:binding style=”rpc” transport=”http://schemas.xmlsoap.org/soap/http” /> - <wsdl:operation name=”startCBP”> <wsdlsoap:operation soapAction=”” /> - <wsdl:input name=”startCBPRequest”> <wsdlsoap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”

namespace=”�ehemiah” use=”encoded” /> </wsdl:input>

- <wsdl:output name=”startCBPResponse”> <wsdlsoap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”

namespace=”�ehemiah” use=”encoded” /> </wsdl:output> </wsdl:operation>

- <wsdl:operation name=”startPrivateProcess”> <wsdlsoap:operation soapAction=”” /> - <wsdl:input name=”startPrivateProcessRequest”> <wsdlsoap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”

namespace=”�ehemiah” use=”encoded” /> </wsdl:input>

- <wsdl:output name=”startPrivateProcessResponse”> <wsdlsoap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”

namespace=”�ehemiah” use=”encoded” /> </wsdl:output> </wsdl:operation> </wsdl:binding>

- <wsdl:service name=”StartProcessServiceService”> - <wsdl:port binding=”impl:StartProcessServiceSoapBinding”

name=”StartProcessService”> <wsdlsoap:address

location=”http://localhost:1080/nehemiah/services/StartProcessService” /> </wsdl:port> </wsdl:service> </wsdl:definitions>



9 Implementation Activity List

Activity Description Partner

Implemented the A2 View process engine Nehemiah as specified in Deliverable D.A2.3. The engine allows to execute private processes and view processes together in one engine.

SAP

Implemented simulation functionality in Nehemiah. This allows for simulating CBPs prior to operational use. SAP

Designed and partially implemented a mechanism to trigger process execution via a Web service. SAP

DELIVERY: Nehemiah (on CD)

Implementing a MO²GO NG client to read the currently loaded model and to generate the XMI according to the concept that was developed. Developing of a user interface for the export of different XMI options (UML, Maestro, Annotation). The export of different process granularities are implemented (CBP, VP, PP).

IPK

Testing the generated XMI files with Poseidon and Enterprise Architect and checking for correctness with the PIM4SOA documentation and the IEM-BPDM mapping concept. IPK

Formulating the requirements and annotations for the Maestro export. Developing a concept for the required extensions of the existing IEM – PIM4SOA export. IPK

Implementing the Maestro export and the annotation for executable processes. In the same time the test scenario was prepared. Modelling the test scenario model in MO²GO NG.

IPK

Final tests with the scenario model and integration of the developed client with the MO²GO NG setup. IPK

Delivery: Extension to MO²GO NG (on CD)

Implemented mapping (horizontal transformation) of business process modelling concepts, which are common to various business process description languages, from ARIS to PIM4SOA.

Siemens

Developed algorithms for and implemented a vertical transformation deriving more detailed PIM4SOA models from information based on the ARIS to PIM4SOA mapping. Siemens

Designed and implemented an extension to the ARIS to PIM4SOA transformation taking into account ATHENA A2 cross-organisational business process modelling concepts (as described in deliverable D.A2.2).

Siemens

Implemented a client for the ARIS to PIM4SOA transformation, reading ARIS XMI export as input and providing output as models conforming to a PIM4SOA metamodel implementation in the Eclipse Modeling Framework (EMF) which based on Essential MOF (EMOF). Described modelling guidelines for ARIS models so that the transformation tool can be used.

Siemens



Delivery: on CD

Implementing Web service interfaces for storing and managing correlation instances Formula

Integration of the Document and Event correlation component into Maestro using a service to retrieve the correlation sets related to each process and CBP, described at design-time

Formula

Integration of the Document and Event correlation component into Nehemiah, using a service to obtain information related to the single process and CBP instances at run-time Formula

Integration of the Document and Event correlation component into Johnson as new Processing Chain Module in order to implement the effective use of the correlation directly at the message level, tracing the message and document exchanged between the partners involved in the CBPs

Formula

Enhancing the correlation set design adding semantic support using A3 semantic services Formula

Delivery: Provided as Web Service, Documentation of WSDL

Design and implement emergent task management engine, building on MPCE. Develop and support scenario. Troux

Adapt to Troux company platform (as changed after Computas-split troux-merger) Troux

Consider wsdl interfacing with Nehemiah or other, dependent on scenario Troux

Consider utilization, adaptation and extension of annotation formalism and transformation engine to the degree that a fit emerge with the above Troux

Delivery: Installation on Troux Server

Define CBP extensions to PIM4SOA and implement a transformation from CBP to pure PIM4SOA IBM

Provide a BPEL runtime engine IBM

Delivery Eclipse / RSA plugin for Transformation



10 Conclusion

This Deliverable completes the set of technical Deliverables of ATHENA project A2 on “Cross-Organisational Business Processes”. Its focus is on providing a prototype for a CBP enactment engine. As one enactment engine may not be suitable for different company internal application landscapes we provide the following implementations: • An implementation of one of the CBP enactment architectures developed in D.A2.3. This

implementation includes simulation capabilities that allow process designers to simulate the modelled process and to determine pitfalls and problems before actually running the process in a production environment.

• A task enactment engine that is more suitable for collaborative situations that may also occur in cross-organisational scenarios (e.g. in product development).

• A BPEL engine that can be used if the other two engines are not suitable. • An event and document correlation service that can be used with the different engines.

From a conceptual point of view we provide a complete big picture of the solutions for modelling and enactment of cross-organisational business processes developed in A2 and how they are linked. We introduce a set of transformations that is necessary to support the complete A2 approach considering process models on the business level, the technical level and the execution level. In particular we have developed the following transformations: • transformation from EPC to PIM4SOA (business level to technical level). The PIM4SOA models

can then be imported into the A2 technical level modelling tool Maestro (this part is developed in A4).

• transformation from IEM to Maestro (business level to technical level) • transformation from IEM to PIM4SOA (business level to technical level) to provide a more general

approach that can be used with different technical level modelling tools in the future. • transformation from PIM4SOA to BPEL (technical level to execution level) to support the

distributed execution of a CBP on a BPEL engine (partly developed in A6).

Finally we have evaluated the different enactment architecture and the enactment engines with the help of the ATHENA Aerospace scenario provided by EADS. This scenario comprises collaborative product development parts as well as purely process-driven change management processes. Thus, it can be fully supported by the enactment engines provided in this Deliverable.

Further more general evaluations of the methods and tools developed in project A2 will be provided by work package A2.6.



11 References

1) FGJ04 FRANK, Joachim, Tracy GARDNER und Simon JOHNSTON: Business Process Definition Metamodel – Concepts and Overview, IBM, 2004.

2) IAF+04 Iyengar, Amsden, Frank, Gardner, Johnston, White, Rivett, Cobb, Goland, Frank, Miller, Fischer, Casanave, Cummins, Malhorta und Koethe: Business Process Definition Metamodel v1.0.2, IBM, Adaptive, BEA, Borland, BPMI, DAT, EDS, Unisys, 88 Solutions, 2004.

3) Ibm03 IBM: Business Process Execution Language for Web Services Version 1.1, http://www.ibm.com/developerworks/library/ws-bpel/, 2003.

4) JRH+04 JECKLE, Mario, Chris RUPP, Jürgen HAHN, Barbara ZENGLER und Stefan QUEINS: UML 2 glasklar, Hanser, 2004.

5) Pel03 PELTZ, Chris: Web Service Orchestration and Choreography, Web Services Journal Volume3 Issue 7, 2003.

6) SCOR SUPPLY CHAIN OPERATION REFERENCE MODEL, The Supply Chain Council, www.supply-chain.org.

7) Argyris&Schön, 1978 Argyris, C. and Schön, D. Organizational Learning: A Theory of Action Perspective. Addison Wesley, Reading, MA, USA, 1978.

8) Berstein, 2000 Bernstein, A. How Can Cooperative Work Tools Support Dynamic Group Processes? Bridging the Specificity Frontier, ACM CSCW Conference, Philadelphia, USA, 2000.

9) Bernstein&Jablonski , 2000 Bernstein, A. and Jablonski, S. Workshop: Beyond Workflow Management: Supporting Dynamic Organisational Processes, ACM CSCW Conference, Philadelphia, USA, 2000.

10) Bowers et al., 1995 Bowers, Button and Sharrock Workflows from within and without, ECSCW Conference, Stockholm, Sweden, 1995

11) Carlsen et al., 2002 Carlsen, S., Jørgensen, H. D., Krogstie, J. and Sølvberg, A. Process Models as a Knowledge Creation Arena, EURAM Conference, Stockholm, Sweden, 2002.

12) Cockburn, 2003 Cockburn, A. People and Methodologies in Software Development, PhD-thesis, University of Oslo, 2003.

13) Davenport&Prusak, 1993 Davenport, T. H. and Prusak, L. Working Knowledge. Harvard Business School Press, Boston, Massachusetts, 1993.

14) Dourish et al., 1996 Dourish, P., Holmes, J., MacLean, A., Marqvardsen, P. and Zbyslaw, A. Freeflow: Mediating Between Representation and Action in Workflow Systems, ACM CSCW Conference, Boston, USA, 1996.

15) Faustmann, 2000 Faustmann, G. Configuration for Adaptation - A Human-Centered Approach to Flexible Workflow Enactment, Computer Supported Cooperative Work, vol. 9, no. 3-4, 2000.

16) Herrmann, 2000 Herrmann, T. Evolving Workflows by User-driven Coordination, DCSCW Conference, München, Germany, 2000.

17) Haake&Wang, 1997 Haake, J. M. and Wang, W. Flexible Support for Business Processes: Extending Cooperative Hypermedia with Process Support, ACM GROUP Conference, Phoenix, Arizona USA, 1997.

18) Jørgensen. 2001 Jørgensen, H. D. Interaction as a Framework for Flexible Workflow Modelling, ACM GROUP Conference, Boulder, USA, 2001.

19) Jørgensen&Carlsen. 1999 Jørgensen, H. D. and Carlsen, S. Emergent Workflow: Integrated Planning and Performance of Process Instances, Workflow Management Conference, Münster, Germany, 1999.

20) Jørgensen. 2004 Jørgensen, H. D. 2004. Interactive Process Models. PhD thesis, Norwegian University of Science and Technology, Trondheim, Norway, HTTP://WWW.DIVA-PORTAL.ORG/NTNU/THESES/ABSTRACT.XSQL?DBID=4 .

21) Klein et al.. 2000 Klein, M., Dellarocas, C. and Bernstein, A. Special Issue on Adaptive Workflow Systems, Computer Supported Cooperative Work, vol. 9, no. 3-4, 2000.

22) Lawton, 2001 Lawton, G. Knowledge Management: Ready for Prime Time?, IEEE Computer, vol. 34, no. 2, 2001.

23) Lillehagen, 2003 Lillehagen, F. The Foundations of AKM Technology, Concurrent Engineering (CE) Conference, Madeira, Portugal, 2003.



24) Nonaka&Takeuchi, 1995 Nonaka, I. and Takeuchi, H. The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press, New York, 1995.

25) Ohren et al. 2002 Ohren, O. P., Jørgensen, H. D., Johnsen, S. G. and Krogstie, J. Process Models as a Framework for Knowledge Sharing and Reuse in Extended Enterprises, IKNOW Conference, Graz, Austria, 2002.

26) Shipman&McCall, 1999 Shipman, F. M. and McCall, R. J. Incremental formalization with the hyper-object substrate, ACM Transactions on Information Systems, vol. 17, no. 2, 1999.

27) Suchman, 1987 Suchman, L. Plans and Situated Actions. Cambridge University Press, New York, 1987.

28) Trigg&Bødker, 1994 Trigg, R. H. and Bødker, S. From Implementation to Design: Tailoring and the Emergence of Systematization in CSCW, ACM CSCW Conference, Chapel Hill, North Carolina, USA, 1994.

29) Wegner, 1997 Wegner, P. Why interaction is more powerful than algorithms, Communications of the ACM, vol. 40, no. 5, 1997.

30) Wegner&Goldin, 1999 Wegner, P. and Goldin, D. Interaction as a Framework for Modeling, in Conceptual Modeling, P. P. Chen, J. Akoka, H. Kangassalo, and B. Thalheim, Eds. Springer LNCS 1565, Berlin, Germany, 1999.

31) Wenger, 1998 Wenger, E. Communities of Practice. Learning Meaning and Identity. Cambridge University Press, Cambridge, UK, 1998.

32) WfMC, 2001 WfMC Workflow Handbook 2001. Workflow Management Coalition, Future Strategies Inc., Lighthouse Point, Florida, USA, 2000