Deliverable Number: D.A2.1

Transcription

1 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 ATHENA Project Name Cross-Organisational Business Processes ATHENA - Project No A2 Deliverable Number: D.A2.1 Cross-Organisational Business Process requirements and the State of the Art in Research, Technology and Standards Work package A2.1 Requirements Analysis & State of the Art Leading Partner: SAP Security Classification: Restricted (RE) 24 November 2005 Version 1.0

2

3 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Annexes No File name Title 1 WD.A2.1_Annex1.doc Cross-organizational modelling of information exchange 2 WD.A2.1_Annex2.doc SoA Business Process Execution Language for Web Services (BPEL4WS) 3 WD.A2.1_Annex3.doc Petri Nets 4 WD.A2.1_Annex4.doc Event Driven Process Chain, EPC 5 WD.A2.1_Annex5.doc Unified Modeling Language (UML) 6 WD.A2.1_Annex6.doc Agent and peer-to-peer technologies in the context of crossenterprise business processes 7 WD.A2.1_Annex7.doc State of the Art - Topics 8 WD.A2.1_Annex8.doc XPDL XML Process Definition Language 9 WD.A2.1_Annex9.doc HLA Approach for Federated Supply Chain Simulation 10 WD.A2.1_Annex10.doc Business Process Definition (BPD) Metamodel and UML2 11 WD.A2.1_Annex11.doc DAML-S (OWL-S) 12 WD.A2.1_Annex12.doc WfMC reference model 13 WD.A2.1_Annex13.doc UEML Results 14 WD.A2.1_Annex14.doc SoA - BPMN _Athena_DA21_V10.doc CONFIDENTIAL Page ii/104

4

5 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Table of Contents ANNEXES... II TABLE OF CONTENTS... III LIST OF FIGURES...V 1 EXECUTIVE SUMMARY INTRODUCTION Terms and Conventions used in the document Objectives of the document Results and Method of Work STATE OF THE ART IN RESEARCH, STANDARD AND TECHNOLOGY Objectives and working strategy Framework description Categorization of Key research challenges concerning CBPs Relevant works in the field of Cross-organizational Business Process Relevant works list Structure of the work analysis Categorization of relevant work USER SCENARIOS AND MARKET MODELS Cross-organization Business Processes Methodology What is a CBP? CBPs classification schema Classified CBPs: CPFR Classified CBPs: Cross-organizational modelling of information exchange Classified CBPs: Sales Order Processing Classified CBPs: Pharmaceuticals: Contracts & Chargebacks (Collaborative) Classified CBPs: Oil and Gas Buy and Sell Process on the Marketplace Classified CBPs: Furniture Supply Chain Management Scenario Classified CBPs: Forecast Integration Classified CBPs: Collaborative Product Development (CPD) Classified CBPs: MIN/MAX replenishment scenario Classified CBPs: eprocurement Scenario for Furniture Industry CBPs classification summary General Requirements Criteria for requirements identification Requirements list REPRESENTING CROSS-ORGANISATIONAL BUSINESS PROCESSES Swimlanes in CBP Models Concept Examples View-based modeling of CBPs Motivation Concept Example _Athena_DA21_V10.doc CONFIDENTIAL Page iii/104

6 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Views on CBP Models Partner roles Structural and Behavioural Characteristics Views for Behavioural Characteristics TYPICAL PATTERNS IN COLLABORATIVE BUSINESS PROCESSES Introducing a pattern classification framework Assumptions List of patterns METRICS Purposes and approach Quality elements Performance indicators Metrics definitions CONCLUSIONS REFERENCES _Athena_DA21_V10.doc CONFIDENTIAL Page iv/104

7 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 List of Figures Figure 2-1Results and Dependencies in WP A Figure 3-1 Relevant work classification... 7 Figure 3-2 Key challenges classification... 8 Figure 3-3 State-of-the-art thoroughness chart Figure 4-2 Gartner Group s Collaboration definition...28 Figure 4-3 Example of process asymmetry Figure 4-4 Process Model for CPFR Figure 4-5 CPFR CBPs classification chart Figure 4-6 Order Exchange CBP classification chart Figure 4-7 Process Model for Sales Order Processing Figure 4-8 Sales Order Processing CBP classification chart Figure 4-9 Process Model for Pharmaceuticals: Contracts & Chargebacks (Collaborative) Figure 4-10 Pharmaceutical Contracts & Chargebacks CBP classification chart Figure 4-11 Process Model for Oil and Gas Buy and Sell Process on the Marketplace Figure 4-12 Oil and Gas Marketplace CBP classification chart Figure 4-13 Furniture Supply Chain Management CBPs classification chart Figure 4-14 Distributed supply network example...54 Figure 4-15 The SCOR Model Figure 4-16 Forecast Integration CBPs classification chart Figure 4-17 Collaborative phases in Product Development (FIAT Auto) Figure 4-18 CPD scenario classification chart Figure 4-19 Process Model for Inventory replenishment Car manufacturer and supplier replenishment process Figure 4-20 IV&I Min/Max replenishment CBP classification chart Figure 4-21 Process Model for eprocurement scenario in furniture industry Figure 4-22 eprocurement for Furniture Industry classification chart Figure 5-1 Example Structure for swimlanes Figure 5-2 Swimlanes in SAP Collaborative Business Maps Figure 5-3 Benefits of swimlanes Figure 5-4 View-based modelling of CBPs Figure 5-5 Example processes modelled using process views Figure 5-6 Collaborations of the On Demand Manufacturing process from [14] Figure 5-7 Collaborative process of the Order Fulfillment collaboration [14] Figure 5-8 Abstract process for the manufacturer role of the Order Fulfillment collaboration [14] Figure 6-1 Pattern Framework Figure 7-1 Measurement approach Figure 7-2 A2 Results and measurable elements produced by each WP _Athena_DA21_V10.doc CONFIDENTIAL Page v/104

8

9 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable Number: D.A2.1 Date 16/02/ Executive Summary The present document is the main result of Athena Workpackage A2.1, which aims to analyze state of the art, business cases and requirements in the field of Cross-organizational Business Processes (CBPs). The Introduction describes the overall approach, which builds on input from several sources: ATHENA projects, other related EU projects, research and industry sources, standardization initiatives and practitioners in the field. An analysis and classification framework is proposed to integrate existing results on the subjects, examples of CBPs from the business communities, requirements and best practices. The final objective is to consolidate all these information to drive and assess the technical developments of A2. The State-Of-the-Art Section introduces a framework to categorize works related to CBPs modelling and execution. The framework is based on a list of aspects, grouped in three main categories: Cross-organizational business process Model, Architecture and platform, Ontology Issues. A list of 29 relevant works has been identified so far. The most important works are further documented by Annexes to the present document. The works are categorized for their relevance to each category and sub-category of aspects. The User Scenarios and Market Models Section provides a definition for CBPs, from a business perspective, and a taxonomy to classify CBPs according to business-related aspects. Relevant CBPs are described at a proper level of detail and classified. The present version of the document contains 9 classified CBPs. A classification summary table allows to highlight common or missing aspects across all the analyzed CBPs. The CBPs analysis leads to User Requirements. Few requirements have been identified so far; in the future we expect to have more requirements from the introduction of further CBPs. In the same Section, General Requirements are defined. The Requirements purpose is to ensure that CBPs can be modeled and executed properly by the platform representing Project s A2 main target. The perspective is the Users. This means that execution and monitoring of CBPs are the main focus. Modelling features are considered if relevant to the users, e.g., the ability to model certain kinds of processes or interactions. That is why these are labeled as General requirements, distinguishing them from Technical requirements related to a specific component of the CBP modelling and execution platform (e.g., modelling tool or execution engine). Section 6 Representing Cross-Organizational Business Processes deals with the modelling techniques to be adopted for CBPs. Two approaches will be combined to this purpose. At a high level, the Swimlane concept will be used to introduce the overall process and its main actors. At a lower level, BPDM seems a promising approach to provide a more detailed representation, based on the concepts of Collaborative and Abstract Processes. The final Section 7 introduces the Metrics, defined with the objective to measure the results of the A2 Project as they are made available by A2 the Project Workpackages. The metrics will be applied at each ATHENA Milestone on A2 results due for that Milestone. First of all, we identify a set of quality elements that give us the perception of the quality of A2 results, and these quality elements are represented by performances indicators. Performances indicators are functionally dependent on detailed metrics, defined for each Workpackage as quantitative measures applicable to the Workpackage specific results (e.g., Requirements, Technical Specifications, Software Tools) _Athena_DA21_V10.doc CONFIDENTIAL Page 1/109

10 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Introduction 2.1 Terms and Conventions used in the document Acronyms: CBP = Cross-organizational Business Process BPDM = Business Process Definition Metamodel 2.2 Objectives of the document The present document is a working version released at Project Month 4 of Deliverable D.A2.1, due at Month 21. The document collects and presents early results from Work Package A2.1 Requirements Analysis and State of the Art, having the following general objectives: Identify typical aspects of business process interoperability, Build a metric to assess work on modeling, transforming, process engine, and architecture, State of the art analysis on related research, standards, and technology. These objectives are to be achieved in the general framework of Project A2 Cross-Organisational 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. Workpackage A2.1 contributes to this goal by pursuing the following activities: 1. Evaluation of user scenarios and market models. Collaboration business cases and requirements are gathered from the field, referring to users and practitioners from different countries and industrial sectors. Established practices, conventions and standards already in use are taken into account, as well as desired features and long-term scenarios from market leaders and analysts. This activity is carried out in close contact with end-users organizations engaged in Activities B3 and B4. 2. Develop typical patterns that need to be supported. Cases and requirements from the above analysis are distilled into patterns, i.e., generic processes described in detail using the selected methodology for modeling CBPs. The typical patterns are the starting point to derive technical requirements for a solution that enables modeling and execution of CBPs. 3. Analyze the State of the Art. State of the art in the field of CBPs modeling and support is studied taking into account research, standards and solutions on the market. The analysis leverages results from previous projects like IDEAS and UEML and new projects like INTEROP NoE. 4. Define a metric to assess further work on modeling, transformation, execution and architectures for CBPs _Athena_DA21_V10.doc CONFIDENTIAL Page 2/104

11 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Results and Method of Work We consider Results any original content, produced or edited by the WP participants, meant to be reused by other WPs or Projects, namely: User scenarios and market models, where we classify and describe relevant occurrences of CBPs in terms of: o o Cross-organization Business Cases categorized by industry, functional scope, market relevance, current status of accomplishment, future evolution, technical complexity, organizational and business impact. User Requirements, representing outstanding features of a solution to enable Cross- Organizational Business Processes, from the end user perspective. State of the art analysis, consisting of: o Collected and classified works from research, standards, and technology in the field of CBP o Technical requirements mapping on the collected works to analyze gaps in current technical state of the art. o Selection of the most appropriate tools to be evaluated for designing the environment for execution of CBP. Typical Patterns, obtained from the generalization and formal representation of the previously identified Collaboration Scenarios. Technical Requirements, derived from the analysis of typical patterns and from translation of User Requirements into expected technical features of modeling tools, workflow management and architecture. We consider Tools any method or technique, already available or developed ad hoc, introduced for the sole purpose to accomplish the WP Results. Tools for WP A2.1 include: The methodology for CBP modeling, selected with the main purpose to allow proper modeling of the Typical Patterns and identification of Technical Requirements. The Metric, defined by the most appropriate set of indicators to measure the Project accomplishments in all areas, from requirements coverage to enactment of CBPs. We consider the following Sources for both information and Tools to be used in our WP: Projects B3 and B4, as main input to the User Scenarios and Market Models. Project A1 as primary reference for the Methodology for CBP modelling. Other EU Projects, in particular IDEAS, UEML and INTEROP, as main sources for State of the Art analysis. Opinion leaders (e.g., market analysts and acknowledged experts), Other Consortia involved in CBP initiatives (e.g., VICS, RosettaNet) and user companies with practical collaboration experiences. Figure 2-1Results and Dependencies in WP A2.1Figure 2-1 shows dependencies between Results, Tools and external Sources as well as between different types of Results. Given these dependencies, the method of work is necessarily iterative, with results revised as new Sources become available for each new version of the Document planned at Month 9, 15 and _Athena_DA21_V10.doc CONFIDENTIAL Page 3/104

12 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Sources Athena B4 B3 A1 Other Projects IDEAS UEML INTEROP General State of the art State of the art M4 State of the art M9 State of the art M15 M21 WP A2.1 Results User Scenarios & Market Models M4 State of the artm9 State of the art Typical Patterns M4 State of the artm9 State of the art Technical Requirements State of the artm9 State of the art M15 M21 M15 M21 M15 M21 Opinion leaders Other Consortia Users Methodology for CBP State Modelling of the art M4 State of the art State of the M9 art M15 M21 Tools Metric State of the artm9 State of the art M15 M21 Figure 2-1Results and Dependencies in WP A _Athena_DA21_V10.doc CONFIDENTIAL Page 4/104

13 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ State of the art in Research, Standard and Technology 3.1 Objectives and working strategy The goal is to learn from past experiences regarding research, standards, and technology in the field of CBP, and to build upon them what is necessary to enable execution of Cross-organizational business process. The final scope of this analysis is enabling to identify the right tools, standard and technology to be used to satisfy the technical requirements. This work capitalizes the main results obtained in projects IDEAS and UEML: UEML project is an IST Thematic Network funded by the European Commission in the Sixth Framework Program) and it was set up in an attempt to contribute to the solving of the problems of multiple Enterprise Modelling Languages. The long term objective of UEML is the definition of a Unified Enterprise Modelling Language, which would serve as an interlingua between EM tools.[1] IDEAS project (Interoperability Development for Enterprise Application and Software) elaborate a strategic road maps in the domain of enterprise application and software interoperability for the next ten years and propose to the European Commission a structure and an organisation to support the implementation of these road maps in the Sixth Framework Programme[2]. Starting from these projects, we derive a first list of relevant works in the area of CBP and the approach used to derive the SoA analysis. The approach followed to describe the State of the Art in research, standard and technology is the following: Defining the framework that we will use to classify and analyse the State of the Art in Research, Standard and technology. Collection of relevant works according to the defined framework. The starting point of this activity will be the results obtained in IDEAS and UEML. Mapping technical requirements on State of Art results, identify the gap between each of them and the technical requirements. In this way we characterize the most appropriate standard, methodologies and tools to match the requirements, and eventually what are the research areas to investigate and possibly cover to better satisfy the requirements itself. Identifying the most appropriate tools to be considered when designing the A2 environment for modelling and execution of CBP. 3.2 Framework description The framework identifies the set of dimension upon which the standards, tools and technologies can be positioned, and the measures that we want to analyse to understand the level of compliance with the requirements. More in depth, a dimension answers the question: how is the tool, or standard positioned upon a particular direction of analysis? Whilst, a measure answers the question: how well the standard or tool satisfies the requirements. Each standard or tool can be viewed or evaluated against more than one dimension. Our starting point to define the framework is the IDEAS Interoperability framework: we will map it upon the aspects regarding the cross-organizational business process. In this way, we subdivide our state of the art analysis in four main domains: Cross-organizational business process model: identify the topics concerning modelling and management of CBP. This domain can be further divided in two other categories: o Notational Aspects: that is aspects concerning the visual representation and expressiveness o Execution Significance: that is aspects concerning the computability by a machine. Methodology: identify the topics concerning a structured collection of tools, techniques and process steps for creating and maintaining an enterprise system during its lifecycle. Methodologies typically _Athena_DA21_V10.doc CONFIDENTIAL Page 5/104

14 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 specify aspects related to models and modelling methods, architecture, enactment and ontological issues. Architecture and platform for enactment and integration of Cross-Organizational business Process: identify the topics concerning architecture and platform key building blocks defined at level of architecture metamodel for enactment and integration of Cross-Organizational business Process. This domain can be divided in the following categories 1 : o o Execution platform: that is aspects related to business process execution, monitoring and repository building blocks, as process flow execution, transaction integrity, schedule service, event management, monitoring and repository services, configuration management services, long running transaction support, exception handling. Integration technologies: that is aspects related to application and external interaction building blocks, as: message parsing and validating, message mapping, message enrichment and formatting, routing services and application integration services. Ontologies Issues: identify the topics concerning semantic needs to describe and execute CBPs. This classification will be further divided into two categories: o Language for ontology specification: a specification used to encode an ontology. o Ontology content: a specification to describe a working model of entities and interactions in some particular domain of knowledge. Requirements can be broadly subdivided into Functional Requirements, expressing specific CBP support needs, and Technical Requirements that are CBP-independent. In the ATHENA A2 project the two categories of Requirements are handled separately: General Requirements, defined in Chapter 4 of the present document, provide the users and industry view on the tools and methodologies needed to support cross-organizational business processes. These requirements are directly related to specific CBPs typologies, also described in Chapter 4. Technical Requirements express the functional and technical features expected from the tools designed and developed in A2. These requirements are tool-specific, and as such are separately managed by each development Workpackage in A2 (for example A2.2 for CBP modelling and A2.4 for enactment architecture). This document refers to these Technical Requirements in Chapter 7, relating them to the General Requirements for metrics calculation. The above introduced classification dimensions apply to both categories of requirements. An additional classification that we intend to apply to Technical Requirements only is based on Quality Attributes, identifying general non-functional aspects regarding the quality of a solution. A list of quality attributes is inherited from IDEAS framework 2 and is the following: QA-1Security: Describes the ability of a solution to protect enterprise resources and control the access to them. This includes authentication, authorization, and data encryption. QA-2Scalability: Is the ability of a solution to adjust to an increased number of business tasks QA-3Evolution: the ability of the system to react to changing requirements. QA-4Performance - the ability of a solution to quickly execute a business task and to retrieve and return information in a timely fashion. QA-5Availability - the availability of a solution to be accessible, e.g 5x8, or 7x24. QA-6Portability - the ability of a solution to be used on different hardware platforms, operating systems, and runtime environments with little changes of the solution. QA-7Genericity: Measure the applicability to different situations in terms of processes and market model. The described framework will be applied in the way shown in the following Figures. Relevant work will be categorized as shown in Figure 3-1: 1 This categorization is derived from the Athena A5 project. 2 See [2] _Athena_DA21_V10.doc CONFIDENTIAL Page 6/104

15 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 CBP Model - Notational aspects CBP Model - Execution Significance Cross-organizational business process Model Relevant Work Classified into Methodologies Architectures and Platform - Execution Platform Architectures and Platform - Integrating technology Methodologies Architecture and platform for enactment and integration of Cross-Organizational business Process Ontology - Language for ontology specification Ontology - ontology content Ontologies Issues Figure 3-1 Relevant work classification Chapter 3.4 provides the list and discussion of relevant works considered in our analysis. Details about specific relevant works are given in the Annexes. A summary table of relevant work classification results is given in Section A further dimension considered in our framework is constituted by Key Research Challenges. They are defined as general relevant issues that should be addressed by our research in the CBP modelling and execution field. Key Research Challenges have been identified by the Athena A2 partners according to two main criteria: Relevance to CBP modelling and execution support. Challenges represent general goals that need to be achieved for full adoption of the CBP concept and technologies by industrial users. Innovation content. Challenges represent new elements that are not significantly present in stateof-the-art, considering both industry and research. As a further element in our framework, Key Research Challenges can be classified according to the previously introduced analysis dimensions, as shown in Figure 3-2. This will allow correlation between research challenges, relevant works in state-of-the-art and the general CBP Requirements, all classified according to the same basic set of dimensions. This correlation, completed by further analysis parameters for CBPs (see Chapter 4) and for requirements, will allow the calculation of metrics to measure requirements satisfaction, level of innovation and other aspects of A2 work (see Chapter 7). A list of the Key Research Challenges identified so far, classified according to the above described framework, is given in Section _Athena_DA21_V10.doc CONFIDENTIAL Page 7/104

16 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 CBP Model - Notational aspects CBP Model Execution Significance Cross-organizational business process Model Methodologies Architectures and Platform - Execution Platform Architectures and Platform - Integrating technology Ontology - Language for ontology specification Ontology - ontology content Methodologies Architecture and platform for enactment and integration of Cross-Organizational business Process Ontologies Issues Classified into Key Research challenges Figure 3-2 Key challenges classification Classified Relevant Works and Key Research Challenges will be represented as rows in a matrix with the classification aspects as columns, using a three scale checkmark with the following meaning: not relevant, that is the work, or challenge, does not address the related aspect; potential, that is the work considers the related aspect applied but applicability is not yet demonstrated; for Key Research Challenges, it means that a certain challenge has marginal implications on the related aspect; relevant, that is the work is applied on the related aspect; for challenges, it means that the challenge refers mostly to the related aspect. As a first example of this classification schema, consider the analysis of Key Research Challenges, summarized in the following Section _Athena_DA21_V10.doc CONFIDENTIAL Page 8/104

17 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Categorization of Key research challenges concerning CBPs CBP Model Archit. & Platform Ontology Methodology Legend: or empty = not related; = related; = might be related Notational Aspects Execution significance Execution platform Integrating technologies Language for ontology specification Ontology content Methodology RC1 Ability to model details that are needed on execution level, showing invoked services, exchanged messages, etc RC2 Ability to model CBPs which are incomplete ie. Without details for execution RC3 Ability to provide different levels of refinement adding computational or (execution) platform-specific details RC4 RC5 Ability to model the global view from the perspective of an external observer and to model the collaboration from the view of one particular participant Ability to model the collaborative business process based on external observable structure and behaviour of participants without imposing a specific implementation RC6 Ability to monitor the execution of CBP RC7 Ability to link private processes with publicly shown process views _Athena_DA21_V10.doc CONFIDENTIAL Page 9/104

18 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 RC8 RC9 RC10 RC11 RC12 RC13 RC14 RC15 RC16 Ability to link (and reuse) internal components (not necessarily processes) with process views eg. As part of a Service Oriented Architecture Ability to replace implementation of process view (with variety of quality aspects) Ability to add semantic information to model Ability to access semantic information at runtime eg. Through semantic annotation available as meta data at runtime Combining / using both peer to peer and / or central approachs for CBPs modeling and execution Separating CBPs process modeling from deployment architectures (peer to peer and / or central) Modeling and execution paradigms for CBPs which one to choose or combine User-influenced modeling and execution of CBPs Impact of the size of enterprises on CBPs able to scale up and down RC17 Change and configuration control management (process evolution / versioning, dynamic changes of instances) RC18 Deployment requirements / methodology for exploiting the results and outcomes _Athena_DA21_V10.doc CONFIDENTIAL Page 10/104

19 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 RC19 RC20 RC21 RC22 RC23 Big picture architecture (including security, change management, ) that are relevant for A2 Mapping different interpretations of intra-organizational processes at the cross-organizational business processes level using semantic annotation of CBPs Impact of the change / evolution of intra-application business process management and architectures on CBPs Exception handling / undo and redo of CBPs Negotiation / contract management of setting up / deploying / executing CBPs solutions (including differences in cultural / legal interpretations) RC24 RC25 RC26 RC27 RC28 Dry runs / simulation / animation (some mechanism and methodology) of CBPs to validate business processes before deployment Support trust building among CBP partners by e.g. evolutionary approach of process visibility, not building new barriers, etc. Integrating legacy systems and infrastructure with CBPs solution. Privacy, IPR, value / reward sharing issues of CBPs participants Policies / rules that are not visible in the process model and their potential _Athena_DA21_V10.doc CONFIDENTIAL Page 11/104

20 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 impact on CBP RC29 Diversity of meta models at local (intraorganizational) business processes RC30 Insufficient level of precision at local business process models RC31 Ability to execute incomplete CBPs RC32 Process improvement / reengineering (adding value metric) at CBPs level RC33 RC34 RC35 RC36 Dynamic execution / behavior of a sub process depending on the context Reusability of process model components Modeling and execution of complex interactions among CBP participants Visualization and knowledge sharing among human participants of CBPs _Athena_DA21_V10.doc CONFIDENTIAL Page 12/104

21 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable Number: D.A2.1 Date 16/02/ Relevant works in the field of Cross-organizational Business Process Relevant works list Relevant pieces of works analysed in the project are listed and shortly described in the following Table. Where appropriate additional information is included, either as Annexes or in other Sections of the document. Work Swimlane concept to model CBPs HLA Approach for Federated Supply Chain Simulation BPMN SHORT DESCRIPTION The main idea in swimlanes is to clearly structure complex process models. The process flow is structured in different lanes. Each swimlane contains activities performed by one participant of the process or additional information about the process. This way the process model does not become overloaded and a clear and well structured model can be created. This concept is only about structuring the layout of models and does not offer a methodology to model processes. In addition it is methodology independent. It can be used in conjunction with different methods and applied in different tools The Federated Supply Chain Simulation approach uses a configuration mechanism on top of the high level architecture (HLA) [IEEE1516] to realise a flexible plug and play mechanism for the simulation of different supply chains. This is supported by a modelling approach based on templates for the design of the simulation scenarios. The templates can represent whole enterprises which may be combined within a supply chain. This content addresses a architecture for distributed and federated simulation and not the supply chain process itself. BPMN was developed by BPMI.org, and version 1.0 was ready in may The modelling notation is targeted at business people, using a small set of core modelling elements. The scope of BPMN is to provide a Process View, using relations to other notations to model other views such as data and organizational view. BPMN does not have a specified metamodel, but work is currently being undertaken mapping BPMN to the BPD metamodel from OMG. The notation contains 4 main notational element categories, flow object, artefacts, swim lanes and connecting objects. These can be used to model both internal processes as well as B2B collaborations. With respect to work patterns, BPMN models have the same level of expressiveness as UML 2.0 activity diagrams. There are several tools available for creating Business Process Diagrams (BPD) with BPMN. FURTHER INFORMATION See 5.1 Swimlanes in CBP Models. WD.A2.1_Annex9 WD.A2.1_Annex _Athena_DA21_V10.doc CONFIDENTIAL Page 13/109

22 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Work Petri nets EPC Business Scenario Maps WfMC reference model SHORT DESCRIPTION The modelling concept of Petri Nets is applied for the modelling of the temporal behaviour of systems which are in different discrete states at different times. By receiving events a transition can be caused between these states. This modelling concept is mainly suitable for sequential and object obtained processes, however, this modelling concept can also be used for time-continuous processes, if there are processes with single stationary states and if the transitions between these states can be neglected. For these reasons, this modelling concept can be used in all ranges of the system development and represents an essential modelling manner. Especially, it is interesting for system developers or software engineers in the area of industrial automation. Petri Nets have been developed since the beginning of the 60'ies, where Carl Adam Petri defined the language. It was the first time a general theory for discrete parallel systems was formulated. The language is a generalisation of automata theory such that the concept of concurrently occurring events can be expressed. The EPC-Methodology depicts complex processes by describing the logic activity flow through a sequence of function, event and logic operators. The Event-Driven Process Chain (EPC) was developed in 1992 at the Institute for Information Systems (IWi) at the University of Saarland together with SAP employees in an R&D project financed by SAP AG. The method of the EPC has become a standard in the field of Business Process Management (BPM), so it is the key component of SAP R/3 s modelling concepts for business engineering and customizing. SAP Business Scenario Maps provide a detailed graphical representation of key end-to-end processes for a particular industry or cross-industry. SAP Business Scenario Maps define collaborative processes, simplify implementation, and assess the potential business benefits and return on investment for collaborative solutions. More specifically, they provide detailed activities, roles, system interfaces, and even business documents required for e- business processes. The Workflow Management Coalition is a non-profit, international organization of workflow vendors, users, analysts and university/research groups. The Coalition s mission is to promote and develop the use of workflow through the establishment of standards for software terminology, interoperability and connectivity between workflow products. It provides a common "Reference Model" for workflow management systems, identifying their characteristics, terminology and components, enabling the individual specifications to be developed within the context of an overall model for workflow systems. FURTHER INFORMATION WD.A2.1_Annex3 WD.A2.1_Annex4 WD.A2.1_Annex7 WD.A2.1_Annex _Athena_DA21_V10.doc CONFIDENTIAL Page 14/104

23 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Work XPDL SHORT DESCRIPTION XPDL means XML Process Definition Language and it is the language proposed by Workflow Management Coalition for interchange process definition between workflow system, process definition repositories and business processing modelling tools FURTHER INFORMATION WD.A2.1_Annex8 Wf-XML XML Based protocol proposed by Workflow Management Coalition for run-time Integration of Workflow Process Engine. WD.A2.1_Annex12 UML UEML BPD metamodel BPEL4WS The Unified Modelling Language (UML) is mostly used to specify, visualize and document models of software systems, including their structure and design. Due to its general approach, it is however also possible to use UML for modelling non-software systems and especially interesting for us for modelling business processes. Especially the new UML 2.0 standard introduces some new interesting features for modelling business processes. The objectives of the UEML project are: To develop a first version of a Unified Enterprise Modelling Language to facilitate interoperability between Modelling Languages, in the frame of ongoing standardization efforts in this domain, To build an UEML demonstrator to promote, test and collect comments, validate and improve the proposed UEML, To create a European consensus among the e- business community by setting up a working group composed of experts representing all the competences of the community (researchers, industrials, standardization bodies ). BPDM defines an abstract metamodel for business process definition. As such this metamodel provides a common abstraction for multiple business process or workflow definition languages. Consequently, this metamodel can be used to define platform independent models of business processes and such models may then be transformed to platform specific meta models of particular languages and implementations. Business process behaviour based on web services i.e. can be seen as a (business) extension to the web services paradigm. Besides representing an implementation language (execution requires implementation) BPEL4WS can also be used to model interfaces of business processes through the notion of abstract processes as detailed in the specification. BPEL4WS is a merger of IBM WSFL and Microsoft XLANG. WD.A2.1_Annex5 WD.A2.1_Annex13 See 5.3 Views on CBP Models. WD.A2.1_Annex _Athena_DA21_V10.doc CONFIDENTIAL Page 15/104

24 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Work BPML WSCI ebxml SHORT DESCRIPTION XML-based meta-language developed by the Business Process Management Initiative (BPMI) as a means of modelling business processes, with the ability to model enterprise data. BPML includes specifications for transactions and compensating transactions, dataflow, messages and scheduled events, business rules, security roles, and exceptions. BPMI has identified three crucial aspects of BPML capability: because it will be used for mission critical applications, it must support both synchronous and asynchronous distributed transactions; because it will model business processes deployed over the Internet, it must offer reliable security mechanisms; and because it will be used throughout integrated development environments, it must encompass project management capabilities. An XML-based language used to describe the flow of messages exchanged by a Web service in the context of a process. It allows the description of the observable behavior of a Web service in a message exchange. WSCI (Web Service Choreography Interface) also describes the collective message exchange among interacting Web services, providing a global, messageoriented view of a process involving multiple Web services. Project to standardize the secure exchange of business data using XML. Among other purposes, ebxml (Electronic Business Extensible Markup Language) would encompass and perhaps replace a familiar standard called Electronic Data Interchange (EDI). ebxml is designed to enable a global electronic marketplace in which enterprises could safely and securely conduct business through the exchange of XML-based messages. The United Nations body for Trade Facilitation and Electronic Business Information Standards (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) launched the project as a joint initiative; main concepts: (1) provide an infrastructure that ensures data communication interoperability; (2) provide a semantics framework that ensures commercial interoperability; and (3) provide a mechanism that allows enterprises to find each other. FURTHER INFORMATION WD.A2.1_Annex7 WD.A2.1_Annex _Athena_DA21_V10.doc CONFIDENTIAL Page 16/104

25 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Work SCOR SHORT DESCRIPTION SCOR (Supply Chain Operations Reference Model) is a Process Reference Model to describe supply chain processes, developed and promoted by the Supply Chain Council ( a no-profit international organization constituted by more than 800 members, including major manufacturers, retailers, technology vendors, consultants and public institutions. SCOR proposes process definitions and metrics to describe and measure the supply chain, using a three-level top-down approach. At Level 1, the supply chain main Process Types are identified (Plan, Source, Make, Deliver and Return), as well as 13 general metrics applying to the supply chain as a whole. At level 2, the supply chain is configured in terms of Process Categories, each defined by a process type and the type of production (MTS, MTO, ETO, Retail). At level 3, detailed process descriptions are given within each category, and performances measures are defined using more than 200 metrics. SCOR is widely applied for business process re-engineering and enterprise performances monitoring. Presently, it provides a representation of supply chains in terms of an enterprise internal processes. The individual enterprises can be linked, but not the processes between them. No definition is given for collaborative cross-enterprise processes. A Collaboration Committee is active within the Council but its activity seems in its early stages, still focusing on generic collaboration aspects [3]. FURTHER INFORMATION CPFR Collaborative Planning, Forecasting and Replenishment ( is a concept that allows collaborative processes across the supply chain, using a set of process and technology models that entities in a supply chain can use for collaboration on a number of buyer/seller functions, towards overall efficiency in the supply chain. Collaborative Planning Forecasting and Replenishment (CPFR) represents a paradigm-breaking business model that extents Vendor Managed Inventory principles by taking a holistic approach to supply chain management among a network of trading partners [5]. CPFR has the potential to deliver increased sales, organizational streamlining and alignment, administrative and operational efficiency, improved cash flow, and improved return-on-assets (ROA) performance. The CPFR process model has been developed by the VICS Association in cooperation with leading retailers, consumer packaged goods manufacturers as well as consulting and software providers. See Classified CBPs: CPFR _Athena_DA21_V10.doc CONFIDENTIAL Page 17/104

26 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Work ROSETTANET Agent and peerto-peer technologies in the context of cross-enterprise business processes View Concept SHORT DESCRIPTION RosettaNet is a consortium of major Information Technology, Electronic Components, Semiconductor Manufacturing, Telecommunications and Logistics companies working to create and implement industry-wide, open e-business process standards. RosettaNet has developed a structured four-part approach for creating what it calls Partner Interface Processes (PIPs): Business Process Modelling examines common business procedures and defines the components of the processes. Business Process Analysis analyzes the processes and defines a target list of desireable changes to the processes. PIP Development establishes guidelines and documentation for the changes. Dictionaries consist of two data dictionary: a technical properties dictionary and a business properties dictionary. Along with the RosettaNet Implementation Framework (which defines an exchange protocol for PIP implementation), the dictionaries form the basis for PIP development. Agent and Peer-to-Peer technology can be applied to collaborative business processes. Both technologies are suitable for distributed computing in various application domains and are, hence, promising candidates for modelling, executing, and monitoring business processes connecting collaborating companies. In cross-organisational business processes white-box knowledge about involved systems and their processes cannot be expected. Workflow views are an important concept in this context. They allow for a controlled visibility of private workflows by external parties whilst providing flexibility through workflow views. Relevant work in this area deals with supporting architecture as well as formal models to obtain workflow views from private workflows (generalisation) and vice versa (specialisation). FURTHER INFORMATION WD.A2.1_Annex7 WD.A2.1_Annex6 See Section _Athena_DA21_V10.doc CONFIDENTIAL Page 18/104

27 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Work Research Projects SHORT DESCRIPTION The Vega Project (Virtual Enterprises using Groupware tools and shared Architectures) developed a platform to support the interaction of users and IT systems from different organisations that form a virtual enterprise. K. Schulz: Implementation of the distributed workflow service, d303. Technical report, ESPRIT Vega EP R. Steinmann: Demonstration of virtual enterprise - vega 5th review demonstration. Technical report, ESPRIT Vega EP 20408, R. Steinmann. Public final report. Technical Report PFR-01, ESPRIT Vega EP The Crossflow project formulates an approach to architect cross-organisational business process interactions. The Crossflow architecture builds upon proxy gateways that protect or encapsulate the provider/consumer core services of the organisations. The architecture is workflow management system independent. Crossflow introduces business contracts to describe the business operation between partners. J. Klingemann; J. Waesch; K. Aberer: Adaptive outsourcing in cross-organizational workflows. In: Proceedings of the 11th International Conference, CAiSE 1999, Heidelberg, Germany, pages Springer Verlag, J. Klingemann; J.Waesch; K. Aberer: Deriving service models in cross-organizational workflows. In: Proceedings of the 9th International Workshop on Research Issues in Data Engineering - IT for Virtual Enterprises, RIDE-VE 99, pages IEEE Computer Society, IBM Research: Crossflow architecture description. Technical report, ESPRIT Crossflow EP 28653, The WISE project describes an integration effort where several known technologies were brought together in order to provide a coherent technological solution for interorganisational workflows. A. Lazcano et al: The wise approach to electronic commerce. In: International Journal of Computer Systems Science & Engineering, special issue on Flexible Workflow Technology Driving the Networked Economy, Vol. 15, No. 5, September G. Alonso et al: WISE: Business to Business E- Commerce. In: Proceedings of the 9th International Workshop on Research Issues in Data Engineering - IT for Virtual Enterprises, RIDE-VE'99, IEEE Computer Society, P , FURTHER INFORMATION WD.A2.1_Annex _Athena_DA21_V10.doc CONFIDENTIAL Page 19/104

28 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Work SAP Products UN/CEFAT BEA Weblogic Integration SHORT DESCRIPTION SAP Business Workflow (aka WebFlow ): SAP s workflow product based on R/3. Workflow is a robust production workflow system, (upgrade continuity with the rest of the SAP system, versioning, scalability, no gluing...) offering standard workflow templates delivered by SAP that can be used out-of-the-box or tweaked to deliver the optimum business process for your company. Workflows can be up and running including training in under a day (thanks to the knowledgeware delivered as part of the template packet). It seamlessly integrates into the SAP environment, be it R/3, Business to Business Procurement, CRM, APO 3d11d e829fbbd/content.htm SAP Exchange Infrastructure (XI): employs XML for process integration and is particularly targeted at interenterprise collaboration: Provides a technical infrastructure for XML-based message exchange in order to connect SAP components with each other, as well as with non-sap components Delivers business-process and integration knowledge to the customer, in the form of SAP s predefined business scenarios Provides an integrated toolset for building new business scenarios by defining and maintaining all integration-relevant information ("shared collaboration knowledge") cture/index.asp United Nations Centre for Trade Facilitation and Electronic Business: covers topics such as UN/CEFACT s Modeling Methodology (UMM) and Core Component Technical Specification (CCTS) and also initiated together with OASIS the ebxml initiative in 1999 to develop an open XML based framework for enabling the global use of electronic business documents. A broad scope infrastructure approach to enterpriseclass integration. It provides a single, intuitive interface for integrating applications and business processes, and deploying custom e-business applications across the enterprise or to suppliers, distributors, and other business partners. Integration features transactions across application boundaries and hence offers some collaborative capability. It also supports ebxml and BPEL4WS which are two of the main standards relevant to A2. FURTHER INFORMATION WD.A2.1_Annex7 WD.A2.1_Annex7 WD.A2.1_Annex _Athena_DA21_V10.doc CONFIDENTIAL Page 20/104

29 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Work DAML-S (OWL-S) Crossorganizational modelling of information exchange Research addressing modelling aspects of CBPs Commercial Products jpass Subject oriented Process Specification and Execution SHORT DESCRIPTION The Web Ontology language for Web Service (OWL-S) is a semantic language that provides a framework which helps building software agents that work with Web Services. It could simplify automatic Web Service discovery, with or without common registries, automatic services composition and interoperation, automatic WS invocation and automatic execution monitoring. OWL-S is based on the W3C recommended OWL ontology language. This language, also named DAML (DARPA Agent Markup Language), was born from the DAML+OIL project that had joined the two single projects DARPA DAML and OIL. OWL uses the Resource Description Framework (RDF) syntax to describe ontologies for the web resources. OWL would be the main framework to build a great common ontology that can add semantic to the web resources. This approach is being developed under EU FP6 Project SPIDER-WIN. The main target is to reach transparency of the external contacts to customers and suppliers and their influence to the internal processes especially to the control processes of planning and production (management) and services e.g. (engineering, construction, prediction service for exceptions, logistic). So the main focus is the communication between companies and it s support by IT systems. Review of literature specifically addressing the modelling of CBPs. Review of popular software products from leading vendors: - Microsoft Biztalk - IBM WebSphere - Oracle BPEL Process Manager. The subject-oriented approach is implemented in a BPM tool called jpass! In a process description from a subject-oriented point of view the focus lies on all involved resources. They are the people or systems performing the process steps (subjects of a process). In the subjectoriented point of view each subject defines its own control flow, which it coordinates and synchronizes with the control flows of other subjects via messages. A subject encloses the interactions and activities executed by a certain involved organizational unit/person within a considered process. FURTHER INFORMATION WD.A2.1_Annex11 WD.A2.1_Annex1 WD.A2.1_Annex7 WD.A2.1_Annex7 WD.A2.1_Annex _Athena_DA21_V10.doc CONFIDENTIAL Page 21/104

30 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Structure of the work analysis The analysis of relevant work has been documented through Annexes having the following structure: Abstract Abstract of the work proposed. Foundations Work description. This section summarises the main features of the work proposed, especially ones related to the aspects of CBP modelling, enactment architecture and platform and ontologies. A high level description of the proposed work is given, where possible with some simple examples, without entering into details of the work itself (e.g., a standard specification document). Extensibility Available options for customizing and extending the approach or tools. Evolutions Possible new areas of research of evolution of the work proposed. Methodologies, Technologies and tools related List (and little description) of the Methodologies, technologies and tools related to the work proposed. References _Athena_DA21_V10.doc CONFIDENTIAL Page 22/104

31 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Categorization of relevant work The following Table shows the analyzed works relevance to the aspects categories listed in Section 3.2, using the three checkmarks for categorization: = not relevant, the work does not address the aspects related; = potential: the work could be applied in this area. = relevant: the work is applied in this area. Relevant work Swimlane concept to model CBPs HLA Approach for Federated Supply Chain Simulation Notational Aspects CBP Model Archit. & Platform Ontology Methodology Execution significance Execution platform Integrating technologies Language for ontology specification Ontology content Methodology BPMN Petri nets UML EPC SAP Business Scenario Maps WfMC reference model XPDL Wf-XML UEML BPD metamodel _Athena_DA21_V10.doc CONFIDENTIAL Page 23/104

32 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 = not relevant, the work does not address the aspects related; = potential: the work could be applied in this area. = relevant: the work is applied in this area. CBP Model Archit. & Platform Ontology Methodology BPEL4WS UN/CEFACT BPML WSCI EbXML SCOR CPFR ROSETTANET Agent and peer-to-peer technologies Vega Project Crossflow project WISE project SAP Business Workflow SAP Exchange Infrastructure (XI) BEA Weblogic Integration DAML-S (OWL-S) _Athena_DA21_V10.doc CONFIDENTIAL Page 24/104

33 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 = not relevant, the work does not address the aspects related; = potential: the work could be applied in this area. = relevant: the work is applied in this area. Cross-organizational modelling of information exchange Research on CBP modelling CBP Model Archit. & Platform Ontology Methodology Microsoft BizTalk IBM WebSphere Oracle BPEL Process Manager jpass! _Athena_DA21_V10.doc CONFIDENTIAL Page 25/104

34 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 To verify the thoroughness of our state of the art analysis we consider the number of relevant, potential, not relevant or not classified works against each of the aspects in our framework. According to the 34 works analyzed so far, we obtain the distribution shown in the following table: CBP Model Architecture and Platform Ontology Methodology Level of compliance Notational Aspects Execution significance Execution platform Integrating technologies Language for Ontology Specification Ontology content Methodology Relevant works Potential works Not relevant The following chart displays gives a graphical indication on the thoroughness of our state-of-the-art analysis. Thoroughness of State-of-the-art Analysis Language for ontology specification Integrating technology Notational Aspects Execution Significance Methodology Potential Relevant Execution Platform Figure 3-3 State-of-the-art thoroughness chart _Athena_DA21_V10.doc CONFIDENTIAL Page 26/104

35 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ User scenarios and market models 4.1 Cross-organization Business Processes Methodology The purpose of this section is to identify, describe and classify relevant cases of multi-enterprise collaboration in business activities, originating Cross-organizational Business Processes. These will constitute the basis for the User Requirements collection. Our approach is based on the following considerations: User-driven requirements can be comprehensive for a certain scenario but they are not necessarily collaboration-oriented. Users, in their own right, may not see or care about differences between cross-organizational processes and internal business processes. Furthermore, modelling and architecture features that make CBPs unique (e.g., harmonizing data and meta-data across partners systems) are absolutely transparent to the final users. On the other hand an aseptic approach, starting from hypothetical generic collaboration patterns, would lead to toy collaboration processes (e.g., the classic send-the-order / confirm-the-order mantra). These will likely fail the attempt to match real user requirements, and will not allow us to weight technical features against their business relevance. In other words, we risk to pursue a solution for its technical appeal just to discover lately that it will bring insignificant business benefits. We think this approach would not fit the scope and objectives of a project like ATHENA. Hence we propose to work as follows: 1. Collect relevant business cases from practitioners, vendors, consultants and opinion leaders from different industry sectors and geographical regions. The main input to this activity is provided by B4 results, but the A2 Partners expertise and State-of-the-Art analysis will serve as well. 2. Analyze business cases to extract real Cross-organizational Business processes. For us, this means focusing on inter-enterprise collaboration activities, either current, planned or hypothetical, matching the CBP definition below. Where possible, common processes are synthesized from two or more business scenarios, even from different industry sectors. 3. Describe the CBPs and classify each of them against a number of dimensions, intended to give an idea of the relevance to A2 objectives and the relevance to the users business if properly supported. 4. Compare and evaluate all the classified CBPs to find similarities, evolutionary trends, most relevant requirements. This activity is preliminary to the identification and modelling of typical patterns What is a CBP? Business-to-Business Collaboration is one of the hottest topics in today s technology industry, addressed by many standardization consortia, research projects, publications and solutions. For the purposes of our work, we intend to adopt a definition of inter-enterprise Collaboration allowing us to identify and classify Cross-Organizationalal Business Processes. This definition must not be too generic, since we intend to focus only on those types of value-creating interactions that justify adoption of advanced interoperability platforms. On the other hand, the definition must not impose any restriction on the scope and technical means for collaboration, since our analysis must address the users in most sectors without imposing constraints on what they do and how they collaborate. An interesting definition of Collaboration in business is the one provided by Gartner Group some years ago [10], presented in Figure _Athena_DA21_V10.doc CONFIDENTIAL Page 27/104

36 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Figure 4-1 Gartner Group s Collaboration definition The above definition highlights two interesting points: collaboration means common endeavors (processes) involving some form of intellectual capital sharing, collaboration means coming to terms with (former) enemies for mutual benefits. Another related definition comes from AMR [11]: Extended supply chains need a platform like ISCC (Inter-enterprise Supply Chain Coordination) that allows specific business processes to happen based on the data from multiple parties with different characteristics. A further characteristic of CBPs which is not evident from the above definitions is Symmetry. Even if they are able to link each others applications, companies working in a multienterprise environment will need shared processes to operate. Process symmetry means that the partners follow consistent paths, that that mirror each-other in whole or in part when they interoperate. This is a very complex requirement, peculiar of multienterprise processes, that cannot be solved by simply exporting or extending an individual company s internal processes. The symmetry requirement is highlighted in technical papers [14] and analysts publications addressing multi-enterprise processes [13]. Process symmetry is also the main target of many standardization attempts currently under way like, e.g., CPFR [5] or RosettaNet [12]. An example of a collaboration attempt missing the symmetry requirement is given in Figure 4-2, where SCOR definitions are confronted for two facing processes, respectively on the customer and on the supplier side. On the one side, the customer exposes its materials requirements planning process, aiming at better synchronization with the supplier production planning. Notification of exceptions or forecast changes would require synchronized actions on the supplier side. On the other side, the supplier exposes its sales order management cycle, asking the customer to enter inquiries and get orders confirmation with prices. This is a quite common form of asymmetry, preventing any real coordination between demand and supply management _Athena_DA21_V10.doc CONFIDENTIAL Page 28/104

37 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 P2.1 Identify, Prioritize, and Aggregate Product Requirements Planning Decision Policies P2.3 P2.4 Customer (Planning) Balance Product Resources with P2.2 Product Requirements Identify, Assess, and Aggregate Product Resources (Supplier) Product Availability Inventory Availability Schedule confirmations/change Establish Sourcing Plans Supply Schedules Schedule changes (Supplier) Asymmetric Collaboration Space Inventory Availability/ Delivery Date Order quote (customer) Customer) Inquiry Supplier (Sales Order Management) D2.4..D2.12 Load, Ship, Payment D2.3 Reserve Resources & Determine Delivery Date D2.2 Receive, Configure, Enter & Validate Order D2.1 Process Inquiry & Quote Figure 4-2 Example of process asymmetry Based on these considerations we could state that CBPs: 1. Take place between multiple independent parties (enterprises or other forms of organization). 2. Involve users from these different parties in high-level interactions, aimed at common intellectual endeavors. 3. Are based on multiple data-sets, owned and maintained by the different involved parties. 4. Imply some form of governance between the involved parties, solving the problem of pre-existing competing interests (we could call this trust-building and trust-insurance). 5. Expose some degree of symmetry in the roles played by the different parties. 6. Start, evolve and end over time. We shall further analyze and discuss the Collaboration definition and CBP identification criteria, as they are a primary requirement for our analysis. Indeed this is not simply a theoretical exercise, but it will allow us to sift out real CBPs from generic user scenarios CBPs classification schema Each CBP is referred to a Business Case, which for us represents a higher level collection of processes grouped from a business perspective. Business Case definitions are out of the scope of our work, and come from external sources: ATHENA scenarios. For example, a Business Case will be generated by each Business Scenario addressed in Action B4. These are the only scenarios that will be actually piloted within the ATHENA IP _Athena_DA21_V10.doc CONFIDENTIAL Page 29/104

38 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Industry consortia. For example, CPFR processes from the VICS consortium represent one business case. Other sources. For example, definition of collaborative processes coming from technical partners expertise (e.g., SAP). We are not defining new Business Cases in this document, or describing them in detail. We are only referencing known Business Cases as the source for CBPs definitions. Each business case is described by the following attributes: Industry sector The sector(s) the scenario applies to. Sources Certified information sources for the Collaboration Scenario description. Scenario description A short but precise description of the scenario from a business perspective. Within each Business Case, we propose to describe CBPs according to the following schema: Description of CBP A description of the Cross-organizational Business Processes in terms of interactions between the participating organizations. Of course diagrams and table can be added if it helps to clarify the Scenario. Anyway the purpose here is not to specify the nuts and bolts of a process, but to identify its main features. Detailed modelling will be done in the Typical Patterns section, using the selected modelling methodology. To our purposes, it is important that CBPs can be classified and selected according to at least 6 dimensions: Interaction Complexity How complex are cross-organizational interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration One-to-many data publication. Point-to-point data interchange. Users of different organizations working together on shared and consolidated data. 4) Cognitive Collaboration Seamless exchange and joint production of knowledge. Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Process is managed transparently to the existing organizations, i.e., without changes on internal processes. Each relation is established and managed separately by the participating parties. An Enterprise (Channel Master) is in charge of governance for its partners relations. Processes take place in a community regulated by an independent third-party organization. Maturity How mature is the users understanding and implementation of the process? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards _Athena_DA21_V10.doc CONFIDENTIAL Page 30/104

39 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Process is just being discovered by opinion leaders. Only some innovative companies are just now working at it. Widely accepted data formats for this specific process. Process is formalized and supported by Application-to- Application interfaces. Velocity Which is the time frame for cross-organizational interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Partners interact at monthly intervals. Partners interact at weekly intervals. Partners interact at daily intervals. Partners interact online. Variability To what degree can the process vary? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization The process happens always in the same way between the same parties. The process can happen in a predetermined number of ways, according to specified conditions. The process can evolve dynamically to match unexpected conditions. Process, partners and governance rules can evolve dynamically (e.g., one-of-a-kind virtual enterprise). Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business The process improves performance in an existing business. (e.g., reducing costs). The process increases revenue in an existing business. (e.g., improve service levels). The process creates new business opportunities. (e.g., new product availability) Classified CBPs: CPFR Industry sectors Consumer Packaged Goods (CPG), Hi-Tech Retail, Pharmaceutical, Apparel, Food/Service. Sources Voluntary Interindustry Commerce Standards (VICS) Association [4]. Description CPFR is a standard approved by EAN.UCC and promoted by the VICS Association to create collaborative relationships between buyers and sellers through co-managed processes and shared information. The CPFR standard provides definitions and specifications for a set of collaborative processes between buyers and sellers in a consumer-oriented supply chain. The benefits expected from CPFR processes implementation are improved efficiency, increased sales and reduced inventory for the individual companies, and better satisfaction for the final consumer. The CPFR process model _Athena_DA21_V10.doc CONFIDENTIAL Page 31/104

40 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 represents voluntary guidelines aimed at structuring and guiding supply chain partners in setting up their relationship and processes. Figure 4-3 Process Model for CPFR Cross-Organizational Business Processes All CPFR processes are inspired by the following guiding principles: Value-chain orientation: the processes are focused on satisfying the final consumer. Single forecast, shared and agreed upon by all the value chain participants. Removal of supply process constraints, allowed by the commitment of each trading partner to the joint forecast and plans. Thus a risk-sharing principle is established on removal of supply chain constraints like, e.g., high levels of safety stocks. CPFR proposes a unified process model organized along two dimensions: The three Collaboration stages, namely Planning, Forecasting and Replenishment. In each stage, collaboration occurs on a different subject, respectively: Sales Forecast, Order Forecast and Order Generation. The Scenario, determining which collaborating entity (Buyer or Seller) has the lead role in the collaboration process. This does not mean that the leading entity is driving decisions that, in the CPFR model, are the result of all the parties contribution. Rather, the lead role stands for data ownership, as CPFR requires that there is one entity taking ultimate ownership of the shared data for normal activities like, e.g., releasing the orders. The owner entities change in each Scenario, as shown in the following Table 4-1, indicating which entity takes ownership of the main subject data in each stage of CPFR _Athena_DA21_V10.doc CONFIDENTIAL Page 32/104

41 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 For example, according to Table 4-1 in Scenario C the Buyer owns the Sales and Order Forecast data, while the Seller takes charge of issuing the order. Scenario Planning (Sales Forecast ownership) Forecasting (Order Forecast ownership) Replenishment (Order ownership) Scenario A Buyer Buyer Buyer Scenario B Buyer Seller Seller Scenario C Buyer Buyer Seller Scenario D Seller Seller Seller Table 4-1 CPFR Scenarios with leading entities CPFR processes are defined independently of the Scenario. Only one definition is given for a process, where certain activities can be assigned to either the buyer or seller depending on the Scenario the process is implemented in. When analyzing interoperability requirements related to CPFR, it is important to take into account that Scenarios do not correspond to different implementations of CPFR, e.g., for different supply chains. Indeed, within the same implementation different Scenarios may coexist, where the same type of data is owned by different actors according to criteria like, e.g., distribution channel or product category. The CPFR process model consists of the definitions for nine primary activities, called Steps, that take place in the different stages of the overall process: Planning o Step 1. Develop Collaboration Agreement. o Step 2. Create Joint Business Plan. Forecasting o Step 3. Create Sales Forecast. o Step 4. Identify Exceptions for Sales Forecast. o Step 5. Resolve/Collaborate on Exception Items. o Step 6. Create Order Forecast. o Step 7. Identify Exceptions for Order Forecast. o Step 8. Resolve/Collaborate on Exception Items. Replenishment: o Step 9. Order Generation. A detailed description of each Step is available in [4], CPFR Process Overview, Tab 2, Nine-Step Process Model. The public documentation on CPFR includes high-level process definitions, Data Flow diagrams and UML models of CPFR entities. A corresponding set of XML schemas has been also developed, which is now part of the EAN.UCC System XML Messaging Standard [6]. For what attains the present document, we are not going to deal with the details of CPFR processes and their implementation. Rather, we have to classify them as relevant cross-organization collaboration cases, with the aim of finding out general patterns and main interoperability requirements. To this purpose, the CPFR nine Steps are mapped onto five CBPs, that we think are better suited _Athena_DA21_V10.doc CONFIDENTIAL Page 33/104

42 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 to give a high-level representation of cross-organization interactions taking place between companies adopting the CPFR standard. In CPFR documentation Steps are described as part of a single process, which should be implemented as a whole to achieve all the expected benefits. Subdivision into Steps is not meant to identify autonomous sub-processes, but to isolate details of a complex process. The basic difference in our point of view is that we intend to find out cross-enterprise processes that companies might implement, as part of a more complex CPFR program, or even as isolated initiatives. Hence, for example, it makes no sense to consider Steps 3, 4 and 5 as separate processes, since it is unlikely that some company will identify or resolve Forecast Exceptions without sharing the Forecast itself. CBP-1 Develop Collaboration Arrangement (CPFR Step 1) Buyer and Seller define the terms of the collaborative relationship to be developed for mutual benefits. The two parties co-develop a document addressing the following issues: Goals and objectives of the collaborative relationship, Involved competencies, Resources and Systems, Collaboration points and Responsible Business Functions, Information sharing needs, Service and ordering commitments, Resolution of disagreements, Review cycle. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration 3 Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one 3) Extended enterprise 4) Community 4 agreements Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 5 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency 3 CPFR explicitly identifies co-authoring of a complex document as the main activity in this process. This clearly appears a cognitive collaboration case. 4 To evaluate governance requirements in this case we have two options: 1) We consider the CPFR Step 1 specifications as simply recommendations for a manual procedure, required as the first methodological step but not the subject of B2B interoperability as the following steps. If this is the case, only one-to-one agreements are needed, based on the common business practice of the involved people, who work autonomously on unstructured data (text files, spreadsheets). 2) Instead, as we believe, Step 1 is expected to reach a similar level of standardisation as the other steps, allowing businesses and systems interoperability even in this stage of the CPFR process. If this is the case, the process of finding partners and establishing agreements can only be supported by a third party, e.g., a community aggregating potential CPFR partners. 5 The lack of specification on structured data and processes suggests that standardisation in this part of CPFR goes no further than generic methodological recommendations _Athena_DA21_V10.doc CONFIDENTIAL Page 34/104

43 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization 6 Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 7 3) Transform the business CBP-2 Create Joint Business Plan (CPFR Step 2) Buyer and Seller develop a joint business plan setting targets for the collaborative relationship, by exchanging information about their individual companies business plans. The joint plan deals with issues such as: Individual and joint business goals, Category management roles and responsibilities, Joint category and promotional plans, including pricing strategies, Develop common item management profiles, Establishing a common business plan. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration 8 Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one 3) Extended enterprise 4) Community 9 agreements Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards Velocity Which is the time frame for cross-organization interactions in this process? 4) Process standards 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 6 The process subject is potentially very wide, the involved functions are many and much dependent on each company s internal organization. This makes it almost impossible to achieve some level of standardisation in the process definition. 7 The CPFR stated objectives are to improve efficiency and increase revenues in an existing and well defined business scenario (consumer products distribution). 8 Even though the category and item management profiles data can be standardised to a certain extent, achieving agreed-upon values for such parameters require a common strategy, which is surely the outcome of cognitive collaboration. 9 Although the interaction is bilateral and the partners are already engaged in a collaborative relationship, the complexity of joint business plan development, and the risks involved, suggest that some kind of third-party organization should oversee the whole process _Athena_DA21_V10.doc CONFIDENTIAL Page 35/104

44 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business CBP-3 Collaborate on Sales Forecast (CPFR Steps 3, 4 and 5) The purpose of this process is to create, update and maintain a joint Sales Forecast between the Buyer and the Seller. The forecast represents a list of consumed quantities in time, per item and stockkeeping unit (SKU). SKUs are the consumption points (e.g., warehouses) visible to both the Buyer and the Seller. The forecast is the central subject of an iterative planning process, consisting of the following sequence of activities: 1. Gather shared information: o Joint Business plan, o Historical demand data, o Causal information (e.g., expected rises in price or other events affecting demand). 2. Create and update a shared event calendar, based on: o Buyer point-of-sale data, o Buyer events (opening, closings, holidays, promotions,..), o Seller events. 3. Gather changes from exceptions resolution (point 7). 4. Generate the Sales Forecast. 5. Apply constraints on Sales Forecast: o Exception criteria set in CBP-1, o Buyer changes on the Business Plan, o Seller changes on the Business Plan, o Constraints from the Seller Order Forecast. 6. Identify Forecast Items as Exception Items. 7. Resolve/Collaborate on Exceptions o o o o o Buyer/Seller retrieves Exception Items and decision support data (e.g., historical data, performance measures). Buyer/Seller Selects Exceptions based on desired criteria. Buyer/Seller compare exceptions with research information. Interaction on unresolved exceptions. Commit forecast changes to solve exceptions. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community _Athena_DA21_V10.doc CONFIDENTIAL Page 36/104

45 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 10 3) Data interchange standards Velocity Which is the time frame for cross-organization interactions in this process? 4) Process standards 1) Month 2) Week 3) Day 4) Zero latency 11 Variability To what degree can external or internal conditions modify the process? 1) Static 12 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business CBP-4 Collaborate on Order Forecast (CPFR Steps 6, 7 and 8) The purpose of this process is to create, update and maintain a joint Order Forecast between the Buyer and the Seller. The order forecast represents actual quantities per item to be shipped by the Seller to replenish the buyer stock-keeping units (SKU). The order forecast is the central subject of an iterative planning process, consisting of the following sequence of activities: 1. Gather Sales Forecast. 2. Buyer provides input data: o Point-of-sale data, o Events impacting on order forecast (e.g., new products, stores opening/closings), o Inventory strategy data, o Current inventory position (on hand, in transit, on order). 3. Seller provides input data: o Historical demand data, o Capacity data, o Additional item management data (e.g., lead time), o Order execution data (e.g., actual shipments). 4. Gather changes from exceptions resolution (point 7). 5. Generate the Order Forecast. 6. Apply constraints on Order Forecast: o Exception criteria set in CBP-1, o Buyer changes on the Business Plan, o Seller changes on the Business Plan, 10 Several CPFR pilots are mentioned in literature, most of them focusing on this process as the most important target. 11 Most state-of-the-art CPFR implementations are based on batch data transfers (e.g. via EDI) allowing at best daily interaction. Nevertheless collaborative forecasting would require closer interactions, where each party is immediately informed on updates from the other party. 12 The process flow is not significantly affected by external conditions of any kind _Athena_DA21_V10.doc CONFIDENTIAL Page 37/104

46 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 o Constraints from the Seller Supply/Capacity. 7. Identify Forecast Items as Exception Items. 8. Resolve/Collaborate on Exceptions o Buyer/Seller retrieves Exception Items and decision support data (e.g., historical data, performance measures). o Buyer/Seller Selects Exceptions based on desired criteria. o Buyer/Seller compare exceptions with research information. o Interaction on unresolved exceptions. o Commit forecast changes to solve exceptions. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business CBP-5 Generate Order (CPFR Step 9) The purpose of this process is to transform an Order Forecast into a committed order. The process consists of the following sequence of activities: 1. Extract Frozen Forecast. The owner entity (buyer or seller based on the scenario) extracts forecast data within the agreed-upon frozen period. 2. Deploy Frozen Forecast to Order generation. The forecast data are committed to an order building system to generate the order. 3. Create the order, in the shared CPFR environment. 4. Acknowledge the order; the acknowledgment is due from the non-owner entity (buyer or seller depending on the scenario). Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative 4) Cognitive _Athena_DA21_V10.doc CONFIDENTIAL Page 38/104

47 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 collaboration Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business The following Table and chart summarize CBPs classification results for CPFR. CBP CBP-1 Develop Collaboration Arrangement CBP-2 Create Joint Business Plan CBP-3 Collaborate on Sales Forecast CBP-4 Collaborate on Order Forecast CBP-5 Generate Order Interaction Governan ce Maturity Velocity Variability Relevance , , ,5 1 2, ,5 1 2, ,5 1 2,66 13 Normalized value on a 0..4 scale _Athena_DA21_V10.doc CONFIDENTIAL Page 39/104

48 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Interaction 4 3 Relevance Governance CBP-1 Develop Collaboration Arrangement CBP-2 Create Joint Business Plan CBP-3 Collaborate on Sales Forecast Variability Maturity CBP-4 Collaborate on Order Forecast CBP-5 Generate Order Velocity Figure 4-4 CPFR CBPs classification chart Classified CBPs: Cross-organizational modelling of information exchange Industry sectors o Automotive industry o Aeronautic industry But the scenario is not really districted to these sectors. Sources EU FP6 Project Spider-Win (See Annex 1 to this document). Description The project SPIDER-WIN (IST ) includes a sub task to collect enterprise models (mainly order processing) from different partners and to synchronise them along the supply chain and across different regions. The partners are Fraunhofer IPK, Fibertecnic, PM, Joinet, IMIK, CIAP, Ducati, PZL, SISTEPLANT and Bentivogli. The goal of the project is to achieve efficient, simple and context-aware SME co-operation with low-level local software requirements and adapted to the typical availability and quality of resource data in very small enterprises, focused on the exchange of order status changes. Cross-Organizational Business Processes The following evaluation of the order exchange process is related only to the actual facts identified during the interviews within the different enterprises of this scenario. The main problem is the heterogeneous structure of different small, medium and big enterprises as well as their different organizations. In other supply chains and especially for bigger enterprises the situation may be more progressive. CBP-6 Order exchange process (SPIDER-WIN) The target is to reach transparency of the external contacts to customers and suppliers and their influence to the internal processes especially to the control processes of planning and production (management) and services e.g. (engineering, construction). The process models is based on SCOR and takes into account, within each enterprise, the internal process structures for planning, control and production: _Athena_DA21_V10.doc CONFIDENTIAL Page 40/104

49 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Kind of all incoming and outgoing orders and their processing take into account plan and control negotiation, sourcing, making, delivery, returns; Kind of all incoming and outgoing products and their internal processing (sourcing, making, delivery, returns); Long, mid and short term planning (e.g. experience, methods, forecasting policy, frame contracts, documentation); Problems during planning/controlling and their handling (delays, quantity splits, request of changes) potentials (improvements); Other communication with business partners (e.g. common planning, information exchange, request of design..). Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 14 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 15 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 16 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency 17 Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 18 4) Dynamic 14 The scenario addresses mainly data exchange but also some collaboration in order of resource allocation and order management. However the data base of the later software system will be accessible for all partners depending of their roles within the supply chain. 15 The complexity depends on the kind of supplier. E.g. a medium aeronautical company (A) distinguishes three different types of providers: 1. B1 - This supplier is given a production or purchase order for the manufacturing of parts. Therefore the company (A) focuses only on the reception of the finished parts (and don t take into account to all the productive process and material procurement of B1 enterprise) 2. B2 - This provider because of his dimension, cannot access the main providers of aeronautical materials. The market of aeronautical materials is quite closed, and they are not willing to sell materials in small amounts or punctually. Therefore, the company (A) will make the material procurement for this provider in order to improve delivery terms and prices. 3. B3 - This provider is sourced the materials and the production order from company (A). The company (A) indicates what to do at any stage of the manufacturing process. (A) will only invoice the working hours which are required to finish the work. During the sourcing of materials, the materials are property of (A), but they are sent directly to the provider and are never stocked at (A). 16 Especially for SMEs internet services are quite difficult and not generally used. 17 Companies working on a contract frame with calls/orders in a time frame of a month, week or day depending of the company. 18 The process may differ depending on the order and depending on exceptions _Athena_DA21_V10.doc CONFIDENTIAL Page 41/104

50 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 19 3) Transform the business Interaction 4 3 Relevance 2 Governance 1 Variability 0 Maturity CBP- 6 Order exchange process (SPIDER-WIN) Velocity Figure 4-5 Order Exchange CBP classification chart Classified CBPs: Sales Order Processing Industry sectors Any Make-To-Stock or Make-To-Order industry (e.g., Furniture Industry). Sources SAP Business Maps [4]. Description A customer sends an inquiry to a vendor. The vendor uses the enquiry to create a quotation. Prices have to be set based on predefined price lists, while delivery dates are determined based on availability check and scheduling. When the customer places an order, prices can be taken from the quotation or determined again, based on what the customer and vendor have negotiated. The order can be entered by a telesales agent, by a sales representative in mobile sales using a laptop or handheld device, or by the customer in the Internet via business-to-business or business-to-consumer internet sales. In all cases, the customer can access real-time information about order status. A credit check instructs the system to process the sales order or block it until credit is cleared. An availability check confirms products at the requested date or a later date. The system automatically determines how long it will take to pack and transport goods. It also triggers subsequent functions such as delivery and billing, and updates order status accordingly. The sales representative can track the order status to see, for example, if the sales order has been delivered or an invoice sent. The sales manager can view sales data that has been automatically extracted and use it for reporting and analysis. 19 The cross-organizational order management support reduces cost and decrease the reaction time of an order. It makes the supply chain more transparent and eases the forwarding of unexpected events along the SC (e.g. production fails, delivery delay) and the specific reaction to this event _Athena_DA21_V10.doc CONFIDENTIAL Page 42/104

51 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Figure 4-6 Process Model for Sales Order Processing CBP-7 Sales Order Processing See above description and schema. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? _Athena_DA21_V10.doc CONFIDENTIAL Page 43/104

52 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance 20 What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business Interaction 4 Relevance 3 2 Governance 1 Variability 0 Maturity CBP-7 Sales Order Processing Velocity Figure 4-7 Sales Order Processing CBP classification chart Classified CBPs: Pharmaceuticals: Contracts & Chargebacks (Collaborative) Industry sectors Pharmaceutical Industry Sources SAP Business Maps [4]. Description This Business Scenario Map is designed for the pharmaceutical industry. It shows how different companies - a manufacturer, a wholesaler, a group purchasing organization (GPO)/buyer - negotiate the best contract prices and settle the resulting chargebacks. The figure illustrates the different activities that are carried out in the scenario. The use of the swimlane concepts enables a clear definition of responsibilities. 20 Normalized value on a 0..4 scale _Athena_DA21_V10.doc CONFIDENTIAL Page 44/104

53 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Figure 4-8 Process Model for Pharmaceuticals: Contracts & Chargebacks (Collaborative) CBP-8 Pharmaceuticals: Contracts & Chargebacks (Collaborative) The buyer, such as a hospital or a drugstore, may join a group purchasing organization (GPO) to negotiate a better price for purchasing large volumes of drug products. The GPO negotiates with manufacturers to obtain the best contract prices for its members. A typical drug manufacturer may have to negotiate thousands of contracts per year with hundreds of different GPOs. These GPOs may contain over 100,000 individual members. To simplify the distribution of their drug products, manufacturers also negotiate selling drug products in large quantities to wholesalers at specified catalog prices. The wholesalers then stock their multiple distribution centers with the drug products. Buyers purchase the drug products from wholesalers at the agreed GPO contract prices. The chargebacks occur when the wholesaler sells the drug product at a _Athena_DA21_V10.doc CONFIDENTIAL Page 45/104

54 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 contract price lower than what he/she paid. The chargeback is the difference between the manufacturer's price to the wholesaler and the contract price to the customer. The wholesaler will submit a chargeback request to the manufacturer on a regular basis (daily or weekly). Each chargeback request may contain thousands of line items for review. A typical drug manufacturer will process millions of chargeback requests per year and transfer hundreds of millions of dollars per year in chargeback payments. There are frequent discrepancies in the requested chargeback amount. One of the main reasons for the discrepancies is buying group membership. In the pharmaceutical industry, a customer may belong to one or more buying groups that have contracts with the manufacturer. The buying group to be in effect for purchasing from the manufacturer is chosen annually by each customer, and then notification is sent by EDI or via the Web as a bid award to wholesalers. When a customer orders from a wholesaler, it is charged the contracted price and the wholesaler submits a chargeback for any price difference to manufacturer by EDI or through the Web. The manufacturer replies by EDI or through the Web with the amount of credit and any reason for discrepancy. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business _Athena_DA21_V10.doc CONFIDENTIAL Page 46/104

55 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Interaction 4 Relevance 3 2 Governance 1 Variability 0 Maturity CBP-8 Pharmaceuticals: Contracts & Chargebacks (Collaborative) Velocity Figure 4-9 Pharmaceutical Contracts & Chargebacks CBP classification chart Classified CBPs: Oil and Gas Buy and Sell Process on the Marketplace Industry sectors Oil and Gas Sources SAP Business Maps [4]. Description This scenario describes a typical process in the Marketplace for Oil&Gas which links oil companies and their suppliers (See Figure 4-10) _Athena_DA21_V10.doc CONFIDENTIAL Page 47/104

56 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Figure 4-10 Process Model for Oil and Gas Buy and Sell Process on the Marketplace CBP-9 Oil and Gas Buy and Sell Process on the Marketplace In the first step of the buy&sell process, the buyer queries the Marketplace for Oil&Gas to search and find the product they need. The buyer can use a stocks database hosted on the Marketplace that provides stock levels for the requested item of all participating oil companies. Alternatively, or if the product is not available in the database, the buyer can look for the product in the Marketplace catalogue. The catalogue enables the buyer to search across a broad base of suppliers. After selecting a product and supplier, the product information is transferred from the Marketplace to the buyer s procurement application. There, the requisition can be processed and approved according to company procedures. The corresponding purchase order is transferred to the Marketplace where the purchase order is either _Athena_DA21_V10.doc CONFIDENTIAL Page 48/104

57 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 stored in the seller s mailbox for later retrieval by the seller, or the purchase order is sent from the Marketplace directly to the seller s system. In the seller s system, a sales order is created and processed. The buyer can view the order and shipment status information. The up-to-date location of the shipment can be tracked in cooperation with the logistics provider. After product receipt and invoice verification, payment can be initiated. A financial service provider on the Marketplace can be employed to handle the payment process. Order, delivery, and payment processes are streamlined and automated on the Marketplace, shortening the order-to-cash cycle (OTC). Inventory levels can be reduced as a result of shorter procurement times. Automation of the buying process combined with company-specific rules allow greater control over maverick buying. To extend this scenario, there are cases in the Oil&Gas domain, where the exchange partners do not to reveal their identity to each other such that it is impossible for any competitor to conclude a potential shortage of their supply. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business _Athena_DA21_V10.doc CONFIDENTIAL Page 49/104

58 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Interaction 4 Relevance 3 2 Governance 1 Variability 0 Maturity CBP-9 Oil and Gas Buy and Sell Process on the Marketplace Velocity Figure 4-11 Oil and Gas Marketplace CBP classification chart Classified CBPs: Furniture Supply Chain Management Scenario Industry sectors Furniture Industry Sources Groupo Permasa, Castellon (Spain) AIDIMA, Valencia (Spain) Description Suppliers are involved to an extent in the design and production planning processes. This allows the manufacturer to keep up-to-date on component and material revisions, availability and lead times. Suppliers can therefore gauge demand for components and materials from the outset. There is an added advantage that suppliers are aware of which stage of production phase is currently in execution and can ensure the delivery of goods when required (JIT). This reduces the requirement for storage at the manufacturer site. It is not uncommon for manufacturers to sub-contract parts of the manufacturing process out to third parties. This interaction with the third party manufacturer requires a detailed level of cooperation from collaborative product design, process planning, lead times and payment & invoicing. There is also a level of CBP when it comes to logistics and distribution (although this depends on the particular company. It is not applicable in the case where logistics and distribution is carried out by the company itself as this would be an internal process.) As many furniture manufacturers are SMEs, they employ the services of logistics companies to distribute their products. The logistics company need to be aware from an early stage, what products are destined for where and when. Such information is vital to allow the manufacturer and logistics company to work together to ensure that orders are delivered on time with the maximum efficiency and minimum cost to both parties. Cross-Organizational Business Processes CBP-10 Inter-enterprise involvement with Supplier in Production Planning. Manufacturer must make the supplier aware of decisions made during production planning. This is a two way information flow where the suppliers lead times and availability to meet the requirements are fed back to the manufacturer. Interaction Complexity _Athena_DA21_V10.doc CONFIDENTIAL Page 50/104

59 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business CBP-11 Sub contracting sections of the manufacturing process - Design Collaboration at the design phase requires mutual agreement between the two partners. regarding the design specification, costs, time-to-deliver, etc. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? _Athena_DA21_V10.doc CONFIDENTIAL Page 51/104

60 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 1) Run the business 2) Grow the business 3) Transform the business CBP-12 Logistics & Distribution Planning Inventory levels, service levels as well as replenishment performances must be measured using shared metrics, visible to the interested parties for SLA assessment. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business CBP CBP-10 Interenterprise involvement with Supplier in Production Planning. CBP-11 Sub contracting sections of the manufacturing process - Design CBP-12 Logistics & Distribution Planning Interaction Governan ce Maturity Velocity Variability Relevance _Athena_DA21_V10.doc CONFIDENTIAL Page 52/104

61 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Interaction 4 3 Relevance Variability Governance Maturity CBP-10 Inter-enterprise involvement with Supplier in Production Planning. CBP-11 Sub contracting sections of the manufacturing process - Design CBP-12 Logistics & Distribution Planning Velocity Figure 4-12 Furniture Supply Chain Management CBPs classification chart Classified CBPs: Forecast Integration Industry sectors General Sources SIEMENS Description CBP-13 Decentralized Forecast integration The scenario describes a collaborative management activity in a decentralized supply network. The nodes in this network are the supply chain partners (suppliers, OEMs, inventory managers, retailers, customers). The partners are partially business units of a single company, partially separate enterprises with separate business goals, enterprise models, and IT infrastructure. Figure 1 shows an example scenario of such a distributed supply network. The partners in the network collaborate (and at times compete) in cross-enterprise business processes. This particular example deals with the fulfilment of a make-to-order customer order, which involves (1) the production unit in which the product required by the customer is manufactured; (2) the logistics dispatching unit which is responsible for scheduling the delivery of the manufactured good; (3) the logistics monitoring unit which will track the delivery of the order until it has been successfully delivered to and accepted by the customer; (4) one or more transport service providers which are responsible for transporting the ordered goods to the customer; (5) the customer which will receive, examine the delivery and either accept or return the delivered order. In many respects, this scenario extends and generalizes on the scenario Collaborate on Sales Forecast _Athena_DA21_V10.doc CONFIDENTIAL Page 53/104

62 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Manufacturers Customer Logistics Dispatching Transportation Service Provider Logistics monitoring Figure 4-13 Distributed supply network example. An important activity of the supply network partners is to make predictions (forecasts) about important future developments in the supply network, e.g.: Predictions of future market demand for a certain type of product or service Predictions of future market supply available for a certain type of product or service. Predictions of the development of the values of various key performance indicators referring to the partners internal processes or its ability to deliver (e.g., lead time, delivery reliability, delivery capability, delivery quality) Predictions of performance or events related to a specific business transaction (e.g., forecast of critical (e.g., likely to be delayed) orders) These forecasts serve as the basis to make strategic and operative decisions in all phases of the supply chain process as viewed from an individual partner. We shall analyze this by using a wellknown industrial standard model for supply chain management, the Supply Chain Operations Reference Model (SCOR) [1]. Figure 2 illustrates the overall view of the supply chain according to the SCOR model. PLAN SOURCE MAKE DELIVER RETURN Figure 4-14 The SCOR Model Forecast results are used in the planning phase to plan targets for all subsequent phases. In the sourcing process, supply side forecasts are used to determine operative actions e.g., in case of a predicted supply shortage. The MAKE phase (production) will need to adapt to supply and demand predictions to produce adequate levels of output. Finally, the delivery phase will need to manage inventories to meet up with the requirements of forecast situations. The RETURN phase is the phase which currently is least affected by forecasting results. However, with information and communication technology becoming more and more pervasive, we see a trend to intelligent preventive maintenance and diagnosis applications that will largely benefit from possibilities to predict upcoming problems e.g., in a machine. Forecast Integration: Requirements and benefits The scenario described in this paper is forecast integration, i.e., how to put the local forecasts of the supply network partners together into an integrated forecast. It becomes obvious from the above that forecast integration in a distributed supply network is itself a highly collaborative process that requires soliciting different, potentially incoherent or even conflicting local views and intentions. The goal is for this integrated forecast to satisfy the following requirements: _Athena_DA21_V10.doc CONFIDENTIAL Page 54/104

63 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 The quality of the integrated forecast is expected to be better (more accurate) than the quality of the local forecasts. The timeliness of availability of forecasts is expected to increase by means of goal-directed communication. In particular, the supply network is expected to be able to react more quickly to changing situations. The integrated forecast is largely based on information held by the individual partners. The partners need to be in a position to determine which information they wish to share in which form with other partners, and in particular how and whether they intend to collaborate with a specific partner. In particular, information exchanged can be of qualitative nature (e.g., containing results of forecasts from partners) or at object-level (e.g., process information related to a specific business transaction such as the time when a certain milestone has been reached). A useful metaphor to enable this flexible collaboration is that of supply network partners offering services to each other, using some sort of service infrastructure that enforces a collaboration model determining which partners can access which services from which other partners, at which service level and (possibly) at which cost. Partners use different processes, methods, tools, or algorithms to come up with local forecasts which they then may decide to share with each other. There is a clear requirement for interoperability between the partners, mainly at the knowledge and ICT levels but also at the business level, to enable partners to obtain relevant forecast data from other partners and to correctly interpret this data to improve their local forecasts. From the perspective of each supply network partner, the benefit of forecast integration is to improve its performance on selected key performance indicators by improving its basis for forecasting and local decision-making. Hence it is in the interest of each partner in the supply network to increase its (inherently incomplete) information base by gathering good-quality knowledge from its partners. It is not necessarily in the interest of a supply chain partner to improve other partners information state and hence their competitiveness. The consequence of this observation is that forecast integration as most forms of cross-enterprise collaboration do will work best in win-win constellations that are not (or at least not strictly) competitive. Still, even in a competitive scenario it may be in the best interest of a partner to reveal certain well selected information to other players in the supply network. Again, the role of a well-designed secure infrastructure for service provisioning and policy-based access management is obvious for this scenario. To summarize, the key promises of cross-enterprise collaboration in order to integrate forecasts of different supply network partners are to increase local visibility, quality and reliability of forecasts, and hence to provide a more accurate basis for strategic and operative planning decisions for the individual organizations involved in the supply network. In addition, the availability of additional high-quality information will enable existing decision-support systems to produce better results, and will enable a new generation of integrated cross-enterprise decision-support and collaboration tools. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity _Athena_DA21_V10.doc CONFIDENTIAL Page 55/104

64 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business Interaction 4 3 Relevance Variability Governance Maturity CBP-13 Decentralized Forecast integration Velocity Figure 4-15 Forecast Integration CBPs classification chart Classified CBPs: Collaborative Product Development (CPD) Industry sectors Automotive. Sources Centro Ricerche FIAT. Description Collaborative Product Development (CPD) is the name given by FIAT to the phases of its product development process that involve collaboration with suppliers. In Figure 4-16, where the full product development is represented, CPD sub-processes are highlighted in the area surrounded by a red line. Although there are other collaborative activities along the FIAT Auto product development, indicated in the picture by arrows where blue fades into yellow, CPD includes the most collaboration-intensive and strategic activities. It starts with the Target Setting and the nearly contemporary suppliers choice process of Sourcing. A third phase, once defined the suppliers panel, consists in the real Product Design. All the three processes involve external suppliers with a different participation degree. The relevance of collaboration with suppliers has rapidly increased in the automotive industry since the introduction of the lean production concept, that stressed the importance on vehicle development planning and assembling rather than component manufacturing. Similar approaches to supplier collaboration are adopted by all the major car manufacturers, although the CPD process here described refers to practices which are peculiar of the FIAT Auto group _Athena_DA21_V10.doc CONFIDENTIAL Page 56/104

65 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Figure 4-16 Collaborative phases in Product Development (FIAT Auto) CBP-14 Target Setting This process consists of the identification of the customer requirements and their translation in technical objectives (engineering parameters). Departments involved are Marketing, Advanced Development and Engineering. The process starts from the functional objectives of a new vehicle to be designed. This is the result of an activity performed by Marketing and Advanced Development (AD), directed to the definition of the mission of the new car. The document that contains these envisaged information is called PRP (Product Range Plan). From the PRP, a collaborative process allows to define the detailed tree of product features for the new car, the CCP, that is stored and managed by an ad-hoc application, the PSI. From this information, the Engineering unit derives the vehicle technical specifications for the new car (VTS), still stored in the PSI. The next steps are to derive the Performance Drivers (PD) for the car and its relevant sub-systems, and then to give detailed technical specifications for each sub-system (SSTS). These information are both stored in the PSI and are passed on to the purchasing unit to start the supplier involvement process. During the sourcing process SSTS document is examined by the suppliers that suggest alternative ways to realize the sub-system whom SSTS refers to. Suppliers feedback on this document return in OEM and are processed in the terminal phase of the Target Setting. Typical feedbacks concern the choice of materials, the technologies to adopt during the component production and engineering design. In this way the suppliers contribute to better define the technical specifications and the way to achieve them. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? _Athena_DA21_V10.doc CONFIDENTIAL Page 57/104

66 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business CBP-15 Sourcing Sourcing is the process that enables company procurement managers to select the most-effective suppliers. The process consists of a complex sequence of interactions between three main parties: The OEM, i.e., the purchasing organization within the FIAT Auto group. The Purchasing Unit (PU), a centralized purchasing function provided by an outsourcing company on behalf of the entire FIAT group. This company acts as a services supplier for the OEM to handle the relationships with the sub-systems suppliers. The Suppliers, i.e., the companies entitled to submit offers for parts and components to be included as sub-systems into a new FIAT car. The sourcing process is split into four phases: The first phase starts from the elaboration of a State of Requirements (SOR) document and ends with the evaluation of the feedback on the SSTS issued by the involved Suppliers. The SOR (containing the SSTS) is provided by the OEM, initially in a lean version, to the PU. This triggers the generation of a SOR-related document the Action Plan on the PU information system. Based on the Action Plan, the PU involves selected Suppliers to provide feedback on the initial SOR, by taking part in a collaborative activity with the OEM and PU. The second phase starts with the approval and issuing of the 1 st SOR version. Next a first RFQ is issued by the OEM and published to the Suppliers via the PU. The Suppliers issue their Offers that are first evaluated in a joint technical review, involving the OEM, the PU and the Suppliers themselves. The same offers are then technically evaluated by the OEM (Eng Dept) and then by the PU from the economical point of view. The third phase follows the same steps as the second one, starting from a 2 nd SOR revision and involving a restricted pool of suppliers. Through a 2 nd RFQ release, a new set of more detailed Offers is produced and evaluated. After the technical and economical evaluations, start the fourth phase that is a formal negotiation with the selected supplier(s.), with the aim of defining the terms of agreement for future collaboration. Once this activity is completed, the formal decision of selecting the supplier is taken between the PU and the OEM. The official communication to the Supplier closes the process. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards _Athena_DA21_V10.doc CONFIDENTIAL Page 58/104

67 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business CBP-16 To be analyzed. Collaborative design Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business CBP Interaction Governance Maturity Velocity Variability Relevance CBP-14 Target Setting CBP-15 Sourcing CBP-16 Collaborative design _Athena_DA21_V10.doc CONFIDENTIAL Page 59/104

68 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Interaction 4 3 Relevance 2 Governance 1 Variability 0 Maturity CBP14 - Target Setting CBP15 - Sourcing CBP16 - Collaborative design Velocity Figure 4-17 CPD scenario classification chart Classified CBPs: MIN/MAX replenishment scenario Industry sectors Inventory for Automotive Supply Chain Management. Sources International team supported by AIAG, OESA, and Odette. [ IVI_Min- Max_Future_State_of_Execution2nd_draft_v5.pdf] Description This scenario describes a typical process in the Min/Max replenishment for car manufacturing which links car manufactory companies, their suppliers and carriers (See Figure 4-18) _Athena_DA21_V10.doc CONFIDENTIAL Page 60/104

69 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 cd Overview Activity model Customer:CustomerService Replenishment System/Service:CollaborationService Supplier:SupplierService Carrier:CarrierService ActivityInitial [Fulfilment] StoreQuery Handle QOH parameter name: QOH Event2 [Customer Planner] Update Customer Data Receive QOH QOH Request Request QOH ActivityInitial Set Min Max Levels Min/Max Levels Set Inv entory Lev els Inventory Levels QOH QOH Request QOH Rev iew QOH «Process» {MinLevel > QOH or MaxLevel < QOH} [MinLevel < QOH and MaxLevel > QOH] [Customer DB] Send QOH Data QOH Min Max Levels Inventory Levels QOH Receive Min/Max Lev els Receive Inv entory Lev els NotifyShipping Shipment Details FlowFinal [Shipper] ShipmentDetails Verify Handle Shipment Response QueryResponse StoreQuery FlowFinal Send ShipentDetails ShipmentDetails Receive ShipmentDetails Create PaperWork ASN Send ASN Data Send ASN Data to Supplier System [Supplier DB] ASN StoreQuery Check Store QueryResponse ASN Send ASN Data Handle ASN ASN Receive ASN Receive Goods ASN REquest Send ASN Data [Customer Receiver] ASN Receive Goods Goods Move Goods Request ASN Data ASN Request Audit Goods ASN Handle Receipt Update Database Receipt Receive Receipt [Customer DB] Send Receipt Receipt Send Receipt Receipt Receive Receipt ActivityFinal Figure 4-18 Process Model for Inventory replenishment Car manufacturer and supplier replenishment process CBP-17 IV&I Min/Max replenishment Car manufacturer and supplier order process The initial business process to be defined will be min-max, in which suppliers are allowed to view _Athena_DA21_V10.doc CONFIDENTIAL Page 61/104

70 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 customer s inventory data and make decisions to cover customer build and support internal operations. By keeping the scope narrow, it is intended to solve the interoperability issue among software providers. The overall view of this process is to allow the supplier to see (by item number) the customer s inventory level, the minimum and maximum inventory specifications, and other pertinent data to make a decision to ship or not ship. The business process team identified 3 messages they see as necessary to transmit data for this process. The first is an inventory message containing the supplier number, item number, quantity on-hand, minimum inventory level, maximum inventory level, and several other fields to allow the ship/not ship decision to be made. The second message is an ASN (Advanced Shipping Notice) to allow the systems involved to see the in-transit quantities and to use the data to feed receiving systems. The third message (considered optional) is a receiving advice to allow the customer to inform the supplier of the receipt of inventory and any discrepancies during that process (wrong item number, wrong quantity, no ASN, etc.) To extend this scenario, there are cases in the inventory replenishment domain, where exchange partners might be a one-to-many pattern. For instance it can be several car part suppliers and several car part suppliers for each part, such as competing tire companies. This allows for bidding service, quality of service checks, contract issues etc. Adding a payment actor will typically require a high level of security, as well as electronic signing etc. There can be several car sellers for each car brand. These represent the stores that the end-user is interacting with. Trust issues can be integrated here. The reputation of car sellers may vary with respect to prices, reliability, quality etc. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the user s environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business _Athena_DA21_V10.doc CONFIDENTIAL Page 62/104

71 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Interaction 4 3 Relevance 2 Governance 1 Variability 0 Maturity CBP-17 IV&I Min/Max replenishment Car manufacturer and supplier order process Velocity Figure 4-19 IV&I Min/Max replenishment CBP classification chart Classified CBPs: eprocurement Scenario for Furniture Industry Industry sectors Furniture Sources ATHENA scenario description [AIDIMA: e-procurement CAT]. Description This scenario describes a typical eprocurement scenario in the furniture industry which links retailers, manufacturers and providers (see Figure 4-20) _Athena_DA21_V10.doc CONFIDENTIAL Page 63/104

72 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 M1. Request for Q t ti M2. Quotation M3. Order R1. Request for Q t ti R2. R3. Order M4. Order Confirmation MANUFACTURER R4. Order Confirmation Retailer-Manufacturer 1. RFQ 2. Quote 3. Order Manufacturer-Supplier 1. RFQ 2. Quote 3. Order 4. Order Confirmation Retailer-Manufacturer 4. Order Confirmation Interior Decoration Project RETAILER PROVIDER Figure 4-20 Process Model for eprocurement scenario in furniture industry CBP-18 eprocurement scenario for Furniture Industry The Customer sub-scenario covers the product selling by the Manufacturer. The process starts when a customer of the manufacturer prepares an RfQ (Request for Quotation) by attaching a decoration project performed by the end-user assisted by a commercial employee at Retailer s facilities, usually a shop with PC-based decoration project. This RfQ is sent through the Internet to the Manufacturer s Sales Department. Sales takes care on the processing of the RfQ and contacts other departments, such as Product Design or Administration, for completing the Quotation to be sent back to the Retailer. The kind of information that Sales requires Product Design to provide is a high quality description of the decoration project that the Retailer has sent. Product Design verifies the project received by checking the product information such as product codes, finishing and measurements, in order to correct the requested products if necessary. Sales sends back to the Retailer the Quotation with remarks, if applicable, and with the pricing information, i.e. the total price of the quotation, a suggested delivery date, etc. This sending is performed through the Internet avoiding the paper usage as in the AS-IS scenario explained. The Retailer, as keeps in touch with the end-user, accepts the Quotation and sends back an Order with the requested products as the Manufacturer has sent. This process is also performed through the Internet. When the Order arrives to Manufacturer s Sales department, the IT-system processes the Order by checking the integrity of the ordered products according to the product definition that already exists in the Manufacturer s data base. After the checking has been performed, the IT-system automatically decomposes the ordered products in a Bill of Material ready for manufacturing. At the same time, the IT-system launches through the Internet the Order Response to the Retailer confirming the delivery date and the payment information of the products. Once the products have been manufactured, they are shipped and sent to the Retailer facilities in order to be served directly to the end-user. By the way, a Delivery Note is also sent accompanying the goods and through the Internet. By acknowledging the reception of goods and after checking that the goods are in-line with the description provided in the Delivery Note, the person in charge of receiving _Athena_DA21_V10.doc CONFIDENTIAL Page 64/104

73 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 the goods has to sign the Delivery Note and give a copy to the carrier who must give it to the Manufacturer. Once the Manufacturer has the Delivery Note proceeds to invoicing the Retailer for the goods served. The content of the Invoice will include both business data of Manufacturer and Retailer as well as the payment information and a description of the goods. The Supplier sub-scenario covers the material procurement by the Manufacturer. The process starts when the Manufacturer realizes that to the manufacturing of a piece of furniture, he has to order some material as he currently has a lack of material in his warehouse. In this sense, the process performed by the Manufacturer is nearly the same to the previous one. The Manufacturer s Production Department asks to Procurement Department to provide them with some material as they either have run out of material during the last manufacturing processes either they forecast to run out of material before the next procuring process due to the current manufacturing schedule. Procurement Department prepares and sends an RfQ based on the information provided by Production to the appropriate supplier. Before performing this task, the appropriate supplier is selected between the Supplier Portfolio that the Manufacturer deals with. Once received the RfQ by the Supplier, he calculates the production plans of material and responds to the Manufacturer with a formal Quotation including the expected amount of the potential Order and forecasted delivery date. Proceeding as before, the Manufacturer analyses the Quotation and formally responds to the Supplier with an Order including the desired products and a requested delivery date. Although this process can be performed in an automated way, by using an IT-system, should be carefully checked by the personnel of Procurement as an error in this part could cause serious risks, not only financial but also productive, to the Manufacturer. The Order arrives to the Supplier who before performing the manufacturing or the preparation of the material sends back to the Manufacturer a formal answer, the Order Response with the real amount and delivery date. As mentioned, the Supplier prepares or manufactures the material to be sent together with the Delivery Note. The Delivery Note as in the previous case, must be signed by the Warehouse Responsible after checking the correspondence of material (physical) and lines in the document. Afterwards, the Supplier sends to the Manufacturer the Invoice with the ordered products with the payment information as main information. Interaction Complexity How complex are cross-organization interactions required for the process? 1) Publishing 2) Data exchange 3) Cooperative collaboration 4) Cognitive Collaboration Governance Complexity How complex is the multi-enterprise organization required to sustain the process? 1) None 2) One-to-one agreements 3) Extended enterprise 4) Community Maturity How mature is the users environment towards CBP understanding and implementation? 1) Stone age 2) Early adoption 3) Data interchange standards 4) Process standards Velocity Which is the time frame for cross-organization interactions in this process? 1) Month 2) Week 3) Day 4) Zero latency Variability To what degree can external or internal conditions modify the process? 1) Static 2) Conditional process 3) Dynamic process 4) Dynamic organization Business Relevance What impact is expected on the users business by proper support of the CBP? 1) Run the business 2) Grow the business 3) Transform the business _Athena_DA21_V10.doc CONFIDENTIAL Page 65/104

74 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Interaction 4 3 Relevance Variability Governance Maturity CBP-18 eprocurement scenario for Furniture Industr Velocity Figure 4-21 eprocurement for Furniture Industry classification chart _Athena_DA21_V10.doc CONFIDENTIAL Page 66/104

75 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ CBPs classification summary CBP ID Sector Complexity Governance Maturity Velocity Variability Relevance CPG\Retail Pharmaceutical Apparel Food\Serrvice. Automotive Aerospace Oiil & Gas Furniture industry Publishing Data exchange Cooperative coll. Cognitive Collab. None One-to-one Extended enterpr. Community Stone age Early adoption Data interch. std Process t d d Month Week Day Zero Latency Static Conditional proc. Dynamic process Dynamic organiz. Run the business Grow the b i Transform the b CBP1 CBP2 CBP3 CBP4 CBP5 CBP6 CBP7 CBP8 CBP9 CBP10 CBP11 CBP12 CBP13 CBP14 CBP15 CBP16 CBP17 CBP _Athena_DA21_V10.doc CONFIDENTIAL Page 67/104

76 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ General Requirements Criteria for requirements identification The Requirements listed in the following are derived from the CBPs analysis and classification, applying the following criteria: 1. The Requirements aim is to ensure that CBPs can be modeled and executed properly by the platform representing Project s A2 main target. Functional requirements, related to the applications supporting an individual party in a CBP, are out of scope. 2. The perspective is the Users. This means that execution and monitoring of CBPs are the main focus. Modelling features are considered if relevant to the users, e.g., the ability to model certain kinds of processes or interactions. That is why these are labeled as General requirements, distinguishing them from Technical requirements related to a specific component of the CBP modelling and execution platform (e.g., modelling tool or execution engine). 3. Requirements must refer to classified CBPs, inheriting the CBP classification attributes. To prioritize the requirements, we use the following levels: critical, important and optional/desirable In the requirements description, the following words are assigned to the each level. Critical (C): "MUST", "MUST NOT, "REQUIRED", "SHALL", "SHALL NOT". Important (I): "SHOULD", "SHOULD NOT", IMPORTANT and "RECOMMENDED" Optional/desirable (D): "MAY", MAY NOT and "OPTIONAL". Obsolete (OB) The interpretation conforms to specifications from the Internet Engineering Task Force See RFC 2119 ( _Athena_DA21_V10.doc CONFIDENTIAL Page 68/104

77 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Requirements list Req. ID Title Description GR1 Common The users need a common environment where collaboration to interact and share context and state environment. information related to symmetric cooperative and collaborative processes. GR2 GR3 Multiple interaction means Datainterchange standards compatibility Users must have multiple ways to perform their required actions in a CBP. Where possible and requested, the same action can be performed via data transfer from the user own system or via on-line transactions. Independently of the interaction means, the effect on the CBP platform must be the same, for what attains process execution and tracking. Where existing standards are already in use by the collaborating parties, the system should allow their incorporation in CBPs in a transparent way. GR4 Alert system The user should be allowed to react to events in real time, thanks to a push system signaling CBPs relevant events to the appropriate actors. GR5 GR6 GR7 GR8 GR9 GR10 GR11 Privacy Requirement Scalable exposition of private information Adapt to different partners Model based information hiding Real-time on screen information Suitable modeling language for CBP Reflect internal organizational The user must be able to provide internal information on private data and processes on different levels of abstraction. The user should be allowed to selectively hide or expose internal information to an existing interaction with a business partner, depending on trust building and contractual agreements. The user should be able to flexibly participate in interactions with different partners without having to change the internal process. The selection of which internal data is shown to the outside world is clearly business-driven and made by managers and process owners. This requires modelling techniques that support modelling of partner interaction from a business viewpoint and that allow for model based information hiding and exposing, without involving coding. The user has to be able to receive real-time information of publicly available data of the partners process (e.g. the shipping status of its order). Business users should be able to capture the requirements of CBP applications through highlevel, graphical languages which are focussed on the business level and which best facilitate problem analysis CBP specifications should capture not only externally exposed business processes and data Related CBPs CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-18 CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-18 CBP-7, CBP- 8 CBP-3, CBP- 4, CBP-5, CBP-6 (CBP-6), CBP-18 (CBP-6) (CBP-6), CBP-18 (CBP-6) CBP-18 (CBP-6) (CBP-6), CBP-18 Prio-rity C C OB (Subst. by Fehler! Verweisquelle konnte nicht gefunden werden.) I I I C I C C I _Athena_DA21_V10.doc CONFIDENTIAL Page 69/104

78 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR12 GR13 GR14 GR15 constraints externally Globally observable status tracking Automatic transformation of business documents Exception handling Modelling of contracts of organisations but also their externally exposed organisational structures (roles). The user should be able to observe and track the overall status of the process, not only the status of its private tasks. The execution environment should allow for an automatic transformation of business documents from one format used in one organization to another format used in another organization. (syntactical and semantical transformation) CBP specifications should support business exception handling covering not only systemlevel failures but also business errors. The modeling tool should not only allow for the design of business processes combining tasks or services, but also for modeling of underlying terms and conditions of the business contract. Related CBPs (CBP-6) CBP-14, CBP-15, CBP-16 CBP-14, CBP-15, CBP-16, CBP-17, CBP-18 CBP-14, CBP-15, CBP-16, CBP-17, CBP-18 GR16 Capture trust The capturing of trust has to be enabled. I GR17 GR18 GR19 GR20 GR21 GR22 Feedback on service, ranking Possibility to simulate CBPs Support for existing templates and patterns Representation of operational context of interaction Process controlling / monitoring for CBPs Collaborative modeling of CBP Desirable would be a mechanism that allows for specifying / modeling of feedback on used services or even enables a ranking of services. This information could then be used (internally in one organization or from different organizations in one marketplace) for further decisions about service invocation. Business users should be able to validate CBP specifications through models which have sufficient expressive power and which are executable (for CBP simulation). CBP business templates and patterns among other productivity tools should be supported. This relates to the requirement of capturing additional contextual information about an interaction between business partners. Imagine two organizations in two different time zones. Constraints like a response has to be sent within two hours of the request could be problematic if the local time of one business partner is outside of business hours. Mechanisms have to be developed that capture this operational context and enable process modelers to make use of it when specifying the CBPs. The business user should be able to control and monitor not only the internal processes, but also the CBP Since CBP is a multi-party application area, the tools should support collaborative development of CBP specifications. CBP-14, CBP-15, CBP-16 CBP-14, CBP-15, CBP-16 CBP-14, CBP-15, CBP-16 CBP-14, CBP-15, CBP-16, CBP-18 CBP-6, CBP- 14, CBP-15, CBP-16 Prio-rity I C I I D D OB (Subst by Fehler! Verweisquelle konnte nicht gefunden werden.) D C OB (Subst. by GR25) _Athena_DA21_V10.doc CONFIDENTIAL Page 70/104

79 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR23 GR24 GR25 R.C.01 GR26 specifications Low impact on organization Allow document format specification Collaborative and integrated CBP modeling framework supporting different aspects of CBP modelling (1) Collaborative and integrated CBP modeling framework supporting different aspects of CBP modelling (2) The proposed solution should have a low impact for each organization involved in term of cost to activate the integration, management, internal process management, resources skill, etc.. The system should allow to represent and manage different documents formats to be exchanged and transformed at execution time Given the distinct natures of business and technical aspects of modeling, a framework incorporating the best-of-breed techniques for the different layers of modeling from business to technical is REQUIRED. The CBP framework MUST facilitate collaborative development of CBP specifications by business users in the different stakeholder partners. The emphasis of collaboration here is on the development aspect of CBP specifications (not on CSCW functionality of a CBP). Thus, functions such as the seamless, multi-developer partitioning of a model, support of incomplete models, model versioning, tracking of open issues requiring resolution for model completion - typify collaborative model development. The full extent these collaborative support functions is not identified in this requirement. Related CBPs CBP-6, CBP- 14, CBP-15, CBP-16, CBP-18 CBP-7, CBP- 8, CBP-14, CBP-15, CBP-16, CBP-18 CBP-1, CBP- 6, CBP-10, CBP-11 CBP-1, CBP- 6, CBP-10, CBP-11 Prio-rity C C I C GR27 GR28 GR29 Collaborative and integrated CBP modeling framework supporting different aspects of CBP modelling (3) Collaborative and integrated CBP modeling framework supporting different aspects of CBP modelling (4) Collaborative and integrated CBP modeling framework supporting different The support of collaborative development through a distributed environment is considered an OPTIONAL requirement. Such a requirement would imply that collaborative development support is indifferent to whether users are collaborating in the same location or in their local settings in partner organizations. A common environment is REQUIRED to facilitate where to interact and share context and state information related to symmetric cooperative and collaborative processes. The related aspects of models MUST be integrated across the different techniques supported in the framework. In other words, an integrated CBP modeling framework is REQUIRED. CBP-1, CBP- 6, CBP-10, CBP-11 CBP-1, CBP- 6, CBP-10, CBP-11 CBP-1, CBP- 6, CBP-10, CBP-11 I C I _Athena_DA21_V10.doc CONFIDENTIAL Page 71/104

80 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR30 GR31 GR32 GR33 aspects of CBP modelling (5) Collaborative and integrated CBP modeling framework supporting different aspects of CBP modelling (6) Collaborative and integrated CBP modeling framework supporting different aspects of CBP modelling (7) Collaborative and integrated CBP modeling framework supporting different aspects of CBP modelling (8) CBP business context level (1) The approach to modelling of a CPB, as well as the particular modelling aspects - from business to technical levels - MUST be described through a modelling methodology (a cookbook ). The specifications of CBPs MUST be captured, as far as possible, through graphical/visualization means. Related to this, the modelling techniques adopted for CBP modelling MUST be utilized, as far as possible, through a highly effective graphical/visualization user interface. Where inappropriate or not possible for a part of CBP specifications to be captured through graphical means, the non-graphical (i.e. textual) part MUST be well-integrated with the graphical part. At the very least, if the graphical or nongraphical parts are modified, then the other related parts MUST be highlighted for cascaded modification where appropriate. For example, if a business object type is used as part of an interaction flow in a CBP, and that interaction is deleted, then the delete of the business object should also be highlighted to the user for delete. It might be needed for delete if no other interaction uses the business object. It would not be deleted if another interaction uses it. The modeling of the business context out of which a CBP model has been designed, SHOULD be supported. Related CBPs CBP-1, CBP- 6, CBP-10, CBP-11 CBP-1, CBP- 6, CBP-10, CBP-11 CBP-1, CBP- 6, CBP-10, CBP-11 CBP-1, CBP- 6, CBP-10, CBP-11 Prio-rity I I I I GR34 CBP business context level (2) This distinction recognizes that CBP design is a response to an operational business situation, including its goals, objectives, expectations and problems. The designed CBP model SHOULD not be confused with this business context. For instance, not all aspects of models at the business context level will be executable (e.g. meetings, problem escalation up the organizational hierarchy, physical transport of materials). CBP-1, CBP- 6, CBP-10, CBP-11 I GR35 CBP business context level (3) The relationship between the CBP business context and CBP design model is one of loose (not strict) refinement. This is because business users determine what aspects of the context should be automated (scoping) and how the problem-focussed business context relates the solution-focussed design model (informal mapping). Thus, it is IMPORTANT to support CBP-1, CBP- 6, CBP-10, CBP-11 I _Athena_DA21_V10.doc CONFIDENTIAL Page 72/104

81 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description this informal, loose refinement step. Related CBPs Prio-rity GR36 GR37 CBP business context level (4) CBP design level (1) It MAY be useful to develop rules for the loose refinement step, as part of a CBP design. For example, rules might be developed to associate physical transportation of materials at the CBP design model (like the standard interactions at either end of the related parties). A CBP design model level MUST be supported, being distinguished from the business context level out of which it was designed, and the platform execution level. CBP-1, CBP- 6, CBP-10, CBP-11 CBP-1, CBP- 6, CBP-10, CBP-11 D I GR38 CBP design level (2) The CBP design level MUST be conceptual, independent of operational business contexts and platform-specific implementation levels. (In information systems theoretic terms, it must reflect the Conceptualisation Principle, while in systems engineering terms, it reflects the Platform Independent Model aspect of OMG s Model-Driven Architecture). CBP-1, CBP- 6, CBP-10, CBP-11 I GR39 CBP design level (3) The CBP design level MUST support conceptual specifications for the business level. Therefore, they MUST be highly suitable for business users, have a sufficient expressive power, and a clear (formal) semantics to avoid modelling ambiguities and errors. CBP-1, CBP- 6, CBP-10, CBP-11 I GR40 CBP design level (4) Business users MUST be able to validate CBP design models through model execution (i.e. model simulation). CBP-1, CBP- 6, CBP-10, CBP-11 I GR41 CBP design level (5) The modelling technique MUST be amenable to automatic verification to detect syntactic and semantic errors in the modelling. CBP-1, CBP- 6, CBP-10, CBP-11 I GR42 GR43 CBP execution level (1) CBP execution level (2) A CBP execution model level MUST be supported, being distinguished from the CBP design level out of which it was transformed. The purpose of this level is to demonstrate the credibility of the design model with respect to the implementation platform. (In systems engineering terms, it reflects the Platform Specific Model aspect of OMG s Model-Driven Architecture). This level MUST allow application and platform specific aspects of the specification to be factored in (e.g. invocation of the application components, the implementation choice for message channels). CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 8, CBP-9, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 8, CBP-9, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. I I _Athena_DA21_V10.doc CONFIDENTIAL Page 73/104

82 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR44 GR45 CBP execution level (3) CPB process assembly (1) The target platform chosen MUST be general enough so that the demonstration of implementation can be used to indicate how other platforms might be used. Support of all possible target platform MUST NOT be the goal. A mechanism MUST be available for the assembly of CBPs through process components from private and public processes. Related CBPs CBP-17, CBP-18 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 8, CBP-9, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 Prio-rity I I GR46 CPB process assembly (2) The private process components made globally visible MUST support a view of private processes which does not allow the internal details of private process to be exposed. (This is analogous to abstract processes in the WS- BPEL and other service composition languages). GR47 Best practice Best practice by way of CBP business templates and patterns among other productivity tools SHOULD be supported. GR48 Global information sharing (1) Global business information schema SHOULD be supported which allows for a common reference of shared business message interchange. CBP-1, CBP- 8, CBP-9 D CBP-1, CBP- 8, CBP-9, CBP-10, CBP-17 I I GR49 Global information sharing (2) Common message interchange data and formats MUST be available through the schema for all CBP applications. All business documents are REQUIRED to abide by this structure in order to be supported for message interchange in CBP applications. CBP-1, CBP- 8, CBP-9, CBP-10, CBP-17 I GR50 Global information sharing (3) The schema SHOULD also store global business object types, relationships and constraints for CBP applications. This will allow parties in a CBP application to structure business messages at the conceptual (i.e. implementation independent level). It will also provide an independent basis for mapping to party-specific data definitions. CBP-1, CBP- 8, CBP-9, CBP-10, CBP-17, CBP-18 I GR51 Global information sharing (4) It is IMPORTANT that the schema also provide party-specific business object structures, where parties may wish to expose these. The global to local mapping of business object types and business message structures would be visible for all CBP applications or within the application that the party is involved with. The party SHOULD nominate the level of visibility for its exposed data definitions. CBP-1, CBP- 8, CBP-9, CBP-10, CBP-17 GR52 Business The transformation of business messages for CBP-2, CBP- I I _Athena_DA21_V10.doc CONFIDENTIAL Page 74/104

83 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR53 GR54 GR55 GR56 message transformation (1) Business message transformation (2) Business message transformation (3) Business message transformation (4) Multiple ways of CBP operation one party collaborating with another through a CBP application SHOULD be automatic. Transformations SHOULD take into account syntactic transformation. Transformations MAY also take into account semantic data transformation. Existing data standards (e.g. ebxml) used within collaborating parties for data-interchange SHOULD be supported through CBPs in a transparent way. It is IMPORTANT that implementation standards, as such, be mapped from schema definition level. This allows data state within CBP processes and messaging to be independent of lower-level implementation standards A CPB MUST be executed in different ways, both passive and active. Passive execution is where the execution of the CBP occurs through the underlying executions of applications of the collaborating partners. The CBP thus reflects the underlying application executions. Active execution is where CBP actions are the basis of direct execution. The different forms of execution reflect the needs of different business situations. The passive mode reflects a top- Related CBPs 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17,, CBP-18 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17,, CBP-18 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-11, CBP-12, CBP-13, Prio-rity D I I I _Athena_DA21_V10.doc CONFIDENTIAL Page 75/104

84 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR57 GR58 GR59 Status tracking of CBP (1) Status tracking of CBP (2) Status tracking of CBP (3) down coordination of execution while active reflects a bottom-up, event based application domain. Note, the issue of notifying users of actions through work-lists is orthogonal to the above point. Work-lists and the like would continue to used, regardless of active or passive forms of executing a CBP. The progress of a CBP MUST be globally visible to allow monitoring and tracking of its execution as a whole. Private processes, being encapsulated in CPBs, MUST NOT have their activities tracked. It is DESIRABLE to support the notion of milestone for a CBP application. A milestone is independent of status tracking. It represents one or more points marked in a CBP, where dependence with processing might be modeled. E.g. the point at which a sale has been secured is point in a CBP which could mark a milestone. Related CBPs CBP-14, CBP-15, CBP-16. CBP-17, CBP-18 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17, CBP-18 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 CBP-14, CBP-15, CBP-16 Prio-rity I I D GR60 GR61 Status tracking of CBP (4) Monitoring and audit of CBP (1) Milestones MAY be monitored so that the performance of CBP parties can adjust accordingly. The processing components of a CBP MUST be globally visible to allow monitoring and tracking in their specific aspect. This includes monitoring what processes have been executed, what business messages have been exchanged, what is currently active, what the bottlenecks of the CBP are, the exception rate etc. In other words, the monitoring should allow all parties to determine how effectively the CBP is progressing. CBP-14, CBP-15, CBP-16 CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. I I _Athena_DA21_V10.doc CONFIDENTIAL Page 76/104

85 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR62 Monitoring and audit of CBP (2) Particular events related to CBP management SHOULD be made visible to the different levels - CBP application as a whole or to specific parties so that various management roles can respond in a timely and appropriate way to the events. Related CBPs CBP-17, CBP-18 CBP-2, CBP- 3, CBP-4, CBP-14, CBP-15, CBP-16. CBP-17 Prio-rity I GR63 GR64 GR65 GR66 GR67 Monitoring and audit of CBP (3) Multi-cast interactions Exception handling (1) Exception handling (2) Different scopes of CBP An audit facility MUST be available to undertake analyses of specific CBPs that have executed, and CBP performance analysis as a whole. The details of what reports should be available through the audit facility have been left open. While most current CBP languages and technologies cater for binary interactions between collaborating, real-scale CBP applications REQUIRE multi-cast interactions. Therefore multi-cast interactions SHOULD be supported in CBP models (see CBP patterns for more details). CBP models MUST handle business exception handling covering not only system-level failures but also business errors. Compensation and alternative/contingencies for processes, available through some workflow and BPM languages, MUST be utilized for exception handling. It is IMPORTANT to make the system scopes of a CBP explicit to reflect the different sensitivities CBP-2, CBP- 3, CBP-4, CBP-5, CBP- 6, CBP-7, CBP-8, CBP- 9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 5, CBP-6, CBP-7, CBP- 8, CBP-9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17, CBP-18 CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 5, CBP-6, CBP-7, CBP- 8, CBP-9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17, CBP-18 CBP-1, CBP- 2, CBP-3, I I I I I _Athena_DA21_V10.doc CONFIDENTIAL Page 77/104

86 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR68 visibility (1) Different scopes of CBP visibility (2) of information and event flow in those scopes. One scope might be the different parties in a CBP which essentially are part of the same organization and a known coalition with an established degree of trust (like government agencies). The formalization of a system scope SHOULD be based on the parties that are collaborating. Other forms of establishing a system scope could be possible, but have deferred in the present requirements. Related CBPs CBP-4, CBP- 5, CBP-6, CBP-7, CBP- 8, CBP-9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17, CBP-18 Prio-rity I GR69 GR70 GR71 Different scopes of CBP visibility (3) Different scopes of CBP visibility (4) Reflect internal organizational constraints externally (1) Business messages SHOULD contain the relevant data for parties within a system scope. Thus, two different scopes entail different degrees of business message detail for the parties in the scopes. Similarly different degrees of event visibility SHOULD be available in different scopes. (Note: Typical system scopes that have been used in classical system analysis techniques like SSADM are the business domain and business environment). CBP specifications MUST contain organizational role requirements for undertaking CBP activities. This allows CBP parties to understand at an external level the role context involved in the undertaking a CBP activity (much like the process context is understood for a business message that occurred between parties). CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 5, CBP-6, CBP-7, CBP- 8, CBP-9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 5, CBP-6, CBP-7, CBP- 8, CBP-9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 5, CBP-6, CBP-7, CBP- 8, CBP-9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, I I I _Athena_DA21_V10.doc CONFIDENTIAL Page 78/104

87 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description GR72 Reflect internal organizational constraints externally (2) Such a constraint MIGHT be a reflection of an internal organizational constraint (much like data and processes being exposed to the CBP level as external artefacts). Related CBPs CBP-15, CBP-16. CBP-17, CBP-18 Prio-rity D GR73 GR74 Reflect internal organizational constraints externally (3) Quality of service aspects of business interactions and contracts (1) The role requirement specified against a CBP activity MIGHT be used to discover either at design or runtime, a concrete binding of the activity. Such a feature is useful in environments where competing service providers could fulfil requests. The quality of service required for messaging interactions between parties MUST be captured for modeled interactions. Examples of quality of service requirements are: message reliability (mandated acknowledgments and message persistence), transactional dependence of messaging, and message security. CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 5, CBP-6, CBP-7, CBP- 8, CBP-9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17 D I GR75 GR76 GR77 GR78 Quality of service aspects of business interactions and contracts (2) Quality of service aspects of business interactions and contracts (3) Quality of service aspects of business interactions and contracts (4) Operational constraints on interactions (1) Such requirements MUST not cloud modelled interactions but be qualified as specific configurations of the interactions. It is OPTIONAL that the contractual aspects of collaborations between parties in a CBP application be explicitly captured. A contract typically captures the timeliness expected in responses, conditions of use of information and other legal obligations. It is OPTIONAL that quality of service aspects of business interactions be integrated with contracts. The physical operational constraints of business interactions SHOULD be captured. Examples of these constraints are the reliability of communication (given the connection CBP-1 CBP-1 I D D I _Athena_DA21_V10.doc CONFIDENTIAL Page 79/104

88 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Req. ID Title Description constraints of different parties) and geographical timezones. Related CBPs Prio-rity GR79 Operational constraints on interactions (2) The execution of CBP SHOULD factor the different constraints. For example, the required response times for requests should factor in the different timezones that parties operate in. Constraints like a response has to be sent within two hours of the request could be problematic if the local time of one business partner is outside of business hours. I GR80 Operational constraints on interactions (3) Mechanisms SHOULD to be developed that capture this operational context and enable process modelers to make use of it when specifying the CBPs. (Another example is low or unreliable connectivity, which might result in re-polling of requests if responses have not been seen. Use of message persistence may also be a useful function under this sort of constraint). The exact set of operational constraints has been left open, and as has their degree of support required. D GR81 Feedback on service ranking It is OPTIONAL to support a mechanism for specifying / modeling of feedback on used services, e.g. a ranking of services. This information is typically useful in e-marketplaces where a choice of service providers is available and where decisions during service discovery as to which one to select. D GR82 Automated support for determining impact on collaboration (1) Automated support for determining impact on collaboration (2) It MAY be possible to determine through automated support how effectively a particular party given its exposed artifacts - process definitions, data, roles can participate in a given CBP application. I GR83 Taken as a whole, the CBP design environment SHOULD facilitate as low impact an integration in a CBP application as for each organization involved in term of cost to activate the integration, management, internal process management, resources skill, etc.. CBP-1, CBP- 2, CBP-3, CBP-4, CBP- 5, CBP-6, CBP-7, CBP- 8, CBP-9, CBP-10, CBP-11, CBP-12, CBP-13, CBP-14, CBP-15, CBP-16. CBP-17, CBP-18 I _Athena_DA21_V10.doc CONFIDENTIAL Page 80/104

89 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Representing Cross-Organisational Business Processes For a successful support of cross-organisational business processes, interoperability has to be captured beyond current protocol based approaches developed in the Web Services stack. All collaboration between organisations is performed following a higher level business goal. For the understanding of interoperability it is important that managers and process owners are able to capture this goal by modelling interaction from a high level business point of view. CBPs have to be modelled capturing the overall business context of a collaboration and have to be linked up with private processes and resources without exposing private information. The methodology described in this section aims at providing a suitable solution in this context. At this current stage the methodology consists of three aspects. Chapter 5.1 focuses on structuring cross-organisational business processes by applying swimlanes. Chapter 5.2 introduces views as a layer of abstraction above private processes called views. The approach allows for high level modelling of CBPs, enabling a scalable exposition of internal processes. Furthermore it provides a mechanism to flexibly link up internal processes with varying partner processes. Chapter 5.3 Introduces BPDM as a modelling methodology based on UML supporting the view concept. The next step will be to bring the concepts together to develop a consistent methodology. 5.1 Swimlanes in CBP Models Concept The goal in modelling these cross-organisational business processes is to describe an end-to-end process and the role every partner plays in the overall business process. According to Becker et al. primary principles to ensure the quality of business process models are clarity and a systematic layout [7]. In the context of cross-organisational process models, the activities of each partner have to be clearly distinguished and single responsibilities as well as interfaces have to be defined. This requires a suitable graphical representation for CBPs that allows for modeling the process as one coherent endto-end process, but still clearly shows which partner performs which action. The main idea in swimlanes is to clearly structure complex process models. The process flow is structured in different lanes. Each swimlane contains activities performed by one participant of the process or additional information about the process. This way the process model does not become overloaded and a clear and well structured model can be created. Figure 5-1 Example Structure for swimlanes This concept is only about structuring the layout of models and does not offer a methodology to model processes. In addition it is methodology independent. It can be used in conjunction with different methods and applied in different tools. In ATHENA we are able to combine swimlanes with the methodology we choose to model cross-organisational business processes Examples In UML activity diagrams swimlanes are used to divide the activities performed by a particular object [8]. In EPC s swimlanes can be used to separate additional information (as data or responsible _Athena_DA21_V10.doc CONFIDENTIAL Page 81/104

90 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 persons) from the actual process flow. Another example for the use of swimlanes are SAP Business Scenario Maps [9] [4]. The aim is to show how the different enterprises and participants collaborate and to document the resulting value potential using an easily understandable zippered graphic. Thus they provide a detailed graphical representation of key end-to-end processes for a particular industry or cross-industry. SAP Business Scenario Maps define collaborative processes and simplify implementation project. More specifically, they provide detailed activities, roles, system interfaces, and even business documents required for e-business processes. They can be described completely with three different views for documenting the same business process: the Business View, the Interaction View and the Component View. These different views are adapted to the information requirements of the different addressees (management, technical department, IT specialists) and describe a consistent transition from the business relationships up to system implementation in an IT application landscape. The following example shows the interaction view of an example coming from the automotive industry. The Interaction View is concerned with the dependencies between the individual activities within the entire process and the exchange of information between the businesses partners. The business documents exchanged between the business partners are defined and specified. Each partner is arranged in a separate swimlane and specific responsibilities as well as interfaces and communication points are clearly characterized. Figure 5-2 Swimlanes in SAP Collaborative Business Maps The following example (Figure 5-3) shows the benefit of using swimlanes in comparison to a model, where process steps of different partners are modelled in one lane. The first model shows the business process without swimlanes. A clear separation of the responsibilities and the flow of messages between different partners cannot be distinguished. The second model uses the concept of swimlanes. Different colours are used for different partners. The individual participation of each partner in the business processes is clearly readable _Athena_DA21_V10.doc CONFIDENTIAL Page 82/104

91 Create RFQ Invoicing Billing FIN SCE SRM CRM Customer Begin Begin Begin Begin Begin Begin Begin Sender Send RFQ Create RFQ Receiver Receive RFQ Receiver Receive RFQ Sender Send RFQ Create Sender Quotation Send AC Request Create Quotation Receiver Receive AC Request Receiver Receive AC Request Sender Send AC Request Check Availability Check Availability Sender Send AC Response Receiver Receive AC Response Sender Send AC Response Receiver Receive AC Response Quotation Processing Quotation Processing Choice Choice Release Quotation Sender Send Quotation Receiver Receive Quotation Sender Create Sales Order / Send Availability Check Quotation Receiver Receive Quotation Create Sales Order / Availability Check Create PO Create PO Receiver Receive AC Request Sender Send AC Request Sender Send AC Request Receiver Receive AC Request Check Availability Sender Send AC Response Check Availability Receiver Receive AC Response Sender Send AC Response Receiver Receive AC Response Submit Credit Check Sender Send Credit Check Request Submit Credit Check Receiver Receive Credit Check Request Check Credit Receiver Receive Credit Check Request Sender Send Credit Check Request Sender Send PO Sender Receiver Send Credit Receive Credit Check Check Response Response Check Credit Sender Send Credit Check Response Receiver Receive Credit Check Response Receiver Receive PO Release Sales Order Release Sales Order Create and Release PO Receiver Receive SO Receiver Receive SO Receiver Receive SO Sender Send Sales Order Receiver Receive SO Sender Send Sales Order Create Billing Due List Sender Send PO Create Billing Due List Create Cross-Docking Delivery Create Cross-Docking Delivery Receiver Receive PO Confirmation (from Supplier) Receiver Receive PO Sender Send PO Receiver Receive PO Receiver Receive PO Update Status PO Create and Release PO Create Invoice Due Document Create Invoice Due Document Sender Send PO Update Receiver Receive PO Sender Send PO Receiver Update Receive Cross-Docking PO Pending Receiver Receive PO Confirmation (from Supplier) Update Cross-Docking Pending Update Status PO Receiver Receive PO Update Receiver Receive PO Update Receiver Receive PO Update Sender Send PO Update Update Status of Inbound Update Invoice Due Document Confirm Inbound Delivery Update Invoice Due Document Receiver Receive PO Update Update Status of Inbound Receiver Receive Invoice (from Supplier) Sender Send Inbound Delivery Confirmation Receiver Receive Invoice (from Supplier) Confirm Inbound Delivery Invoice Processing Invoice Processing Receiver Receive Inbound Delivery Confirmation Receiver Receive Inbound Delivery Confirmation Sender Send Inbound Delivery Confirmation Execute Cross-Docking Delivery Sender Send Accounting Documents Receiver Receive Accounting Document Sender Send Accounting Documents Receiver Receive Accounting Document Sender Send ASN Execute Cross-Docking Delivery Create Invoices Create Invoices Payment Run Payment Run Sender Send ASN Receiver Receive ASN Receiver Receive ASN Sender Send Invoice Sender Send Invoice Receiver Receive Invoice Receiver Receive Invoice Pay Invoice Sender Send SO Update Sender Send SO Update Receiver Receive SO Update Receiver Receive SO Update Pay Invoice Update Order Status Update Order Status Merge End End End End End End Merge End End End IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Figure 5-3 Benefits of swimlanes 5.2 View-based modeling of CBPs Motivation For a successful integration, business partners have to model their interaction from a high level business point of view, independent of an underlying implementation. On the other hand they have to link their existing internal processes and resources to the agreed interaction model and offer processoriented interfaces to the outside world. An important requirement in this context is to enable organisations to conceal its private processes to preserve autonomy and privacy. White-box exposition of internal knowledge, such as internal process steps, data, and resources can not be expected. However, successful implementation of cross-organisational business processes requires information sharing and exposing parts of the internal processes. The level of exposure can vary, and contracts with partners as well as trust building may lead to revealing more internal information as the business relationship develops. A particular interaction may require involved partners to adapt for the purpose of the communication. This adaptation can not necessarily be reflected in the partners' private (internal) business processes without inflicting their ability to interact with other partners in a different context. Imagine an automotive supplier that is providing parts to two different car manufacturers that prescribe a particular sequence of interaction. The supplier s goal will be to run the same internal process and still to collaborate with both manufacturers. To enable this, process-oriented abstraction needs to be modelled and tightly bound to the corresponding private business process. The decision about how much knowledge will be shared and which insight into the internal process is given, is clearly business-driven and made by process owners or managers. Managers and process owners decide about the context of the interaction with their business partner and define the first high level view of the CBP. This requires modelling techniques that support modelling of partner interaction from a business viewpoint and that allow for model-based information hiding and exposing, without involving coding. It is the intent that a process modeller can leave a private process unchanged and relate it to a process-based interface which can be adapted to interact in a specific collaboration _Athena_DA21_V10.doc CONFIDENTIAL Page 83/104

92 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Concept The main idea of view-based modelling of CBPs is to introduce process views as an additional layer above the private processes of an organisation [17]. Process views provide a process-oriented interface between business partners (cp. 0). Private processes are only known to their owning organisation and not exposed to the outside world. Process views are an abstraction of the private processes, containing information that needs to be published for the purpose of a specific interaction. From a structural perspective, private processes consist of (private) tasks and (private) dependencies, whilst process views consist of view tasks (synonym: virtual tasks) and view dependencies (synonym: virtual dependencies). Several tasks of a private process can be combined to one view task. [15][16] This modelling concept is depicted in Organisation 1 in Figure 5-4. Based on one private process, different views can be generated (cp. Organisation 3) and thus reflect the specific requirements of multiple interactions. CBPs are then constructed by interweaving process views of different organisations [18](cp. CBP 3 in Figure 5-4). Using different views of the same internal processes, organisations are able to interact in a different context without changing the internal process (cp. Organisation 3 in Figure 5-4). By means of distribution and outsourcing, a CBP indirectly connects private business processes in a cross-enterprise business scenario. The inter-enterprise coordination thus builds on a distributed business process model where partners manage their own part of the overall business process. A CBP specifies tasks that each of the parties is required to perform as agreed in their contract. Figure 5-4 View-based modelling of CBPs This is considered a promising concept to selectively hide details of private processes, whilst providing a process-oriented interface to facilitate the state-oriented communication between trading partners. Furthermore views allow for offering different perspectives on the same internal process when interacting in a different context _Athena_DA21_V10.doc CONFIDENTIAL Page 84/104

93 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Example The following process example is modelled using the view-approach. It involves two companies, a Mining Company (JJJ Mining) and a contractor (ABC Engineering). Scope of the process is the entire end-to-end process from the request for tender to the final payment of the contractor. The following figure depicts the process flow which is further explained below. Figure 5-5 Example processes modelled using process views The middle process shows the cross-organisational process as agreed by JJJ Mining and ABC Engineering. It interweaves the publicly available process views of each company. The process starts with the Mining Company making public a request for tender (RFT) that contractors can submit a response to. To keep this process simple in the context of this paper, we only model the interaction between the Mining Company and the contractor that is finally chosen to deliver the work. Other contractors responding to the RFT are not considered. Internally the publishing of the RFT would involve the identification of the scope of work and a preparation of the tender document. The contractors are only interested in the published RFT, consequently these steps are not exposed in the process view. Once the RFT is published, ABC Engineering starts working on a response. Among other things the contractor would estimate a cost-price and a premium. Noticeably these are confidential information that should not be revealed to the Mining Company and are therefore hidden in the private process. Once the contractors have submitted the response, JJJ Mining has to choose which tender to accept and to award the contract. Awarding a contract involves several internal steps which again are hidden behind the view task. Activities include defining relevant criteria to choose the tender, compare the incoming tender according to these criteria, choose the most suitable tender and offer a contract to the contractor. The criteria that are used to choose the contract can be a lowest price, experience of the contractor in similar projects, etc. and observably this is sensitive information which should be concealed. After signing the contract, ABC Engineering fulfils the work that has been agreed on. While ABC Engineering performs the work, it is managed and monitored by the Mining Company, hence these two process steps run in parallel. Once the work is completed, the payment has to be arranged. ABC Engineering measures the work that they performed and submits a payment claim. On the Mining company side, the reaction on the payment claim is as follows: A surveyor measures the quality and quantity of the performed work and decides to accept or reject the payment claim depending on the results. If the payment claim is accepted, the payment is performed and the process ends. If the _Athena_DA21_V10.doc CONFIDENTIAL Page 85/104

94 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 performance feedback of the surveyor doesn t correspond to the payment claim, an escalation process is started in which the contractor only receives payment according to the performed work and this process finishes. On the contractors side either the total amount of the payment claim or a part of it will be received. Assuming that any steps that result from a not full payment of the amount will trigger an exception process, this process ends after payment (total amount or less) has been received by the ABC Engineering. It is important that we define clearly the meaning and usage of virtual dependencies in Process Views. To say that a dependency arrow indicates sequentiality between two virtual tasks may raise questions. For example (see Figure below), Receive is not dependent exclusively on Monitor and on Send order, because it actually cannot start before the supplier has shipped the ordered goods. The solid arrow might suggest otherwise. In other words, if I looked at the Process View only from the Customer point of view, I would expect to be able to start Monitor and Receive as soon as Send order is closed. Everybody knows that in the real world this is not going to happen because some supplier input would be required to start the second activity, but anyway we should try to be more explicit about that. For example, use a dashed arrow for dependencies that are constrained by external events (e.g., supplier delivery). If we take this kind of approach, a solid-line virtual dependency would mean sequentiality with no external input. For example, in the Supplier Process View, Delivery depends only on Confirm order and this depends on Receive order. These activities could be grouped into a single one, but are kept separated because in the Process View we decide to give visibility on the process advance at a higher detail level. This does not mean that we are already modelling the CBP, we still see things from the Customer point of view. This situation is quite common. Users see processes from a single-party point-of-view (e.g., in ERP systems) but external-facing processes are often like subterranean rivers: disappearing underground somewhere and reappearing somewhere else, a lot of non-documented activities in between. We think our representation approach should take into account this. Another related, if more general, issue is on methodology. When modelling a CBP, the most _Athena_DA21_V10.doc CONFIDENTIAL Page 86/104

95 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 natural approach would seem a top-down one: we look at the whole picture then we describe the process views depending on the contribution of each partner in the CBP. When we start trying this in the real world, we will find a lot of private processes, with no clear description of external dependencies (the above underground rivers). In this case, maybe a bottom-up approach would be better suited, or at least complementary to the full picture design. In practical terms, it is likely that nobody knows the full picture when we start with the final users. This is to say that methodology is important when thinking about representation tools. If A1 or some other project is in charge of methodological aspects, maybe it is time to start discussion about these aspects. 5.3 Views on CBP Models The following concepts are used in the current development of the Business Process Definition Metamodel. Some information, the example and figures are taken from the paper Business Process Definition Metamodel Concepts and Overview [14]. The example describes an Order Fulfillment collaboration and an On-Demand Manufacturing process that participates in it and two further collaborations Partner roles A collaboration describes a common interaction pattern between partner roles. The same collaboration can be used in many scenarios that require the same interaction pattern and is specified independently of any implementation of the partner roles. A process can implement multiple roles in a collaboration or in multiple collaborations. For example, a Sales collaboration may specify the sale interaction between two partner roles Seller and Buyer. A Broker process might participate in two instances of this collaboration - once as a Seller and once as a Buyer. In another example a Purchasing process might participate in a collaboration with suppliers and further collaboration with Manufacturing processes Structural and Behavioural Characteristics A collaboration between partners bears structural and behavioural characteristics. Structural characteristics are for example the role of partners and the communication channels between them. Behavioural characteristics specify the interaction protocol that means the possible interactions between the partners through the communication channels. The following view shows structural characteristics of three collaborations Parts Provisioning, Order Fulfillment, and Open Auction. customer Parts Provisioning supplier customer Confirmation Shipment Rejection Order Fulfillment Order manufacturer auctioneer Open Auction bidder roles played by partners of the On-Demand Manufacturing process roles played by the On-Demand Manufacturing process roles played by partners of the On-Demand Manufacturing process Figure 5-6 Collaborations of the On Demand Manufacturing process from [14] _Athena_DA21_V10.doc CONFIDENTIAL Page 87/104

96 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 The figure shows the communicating roles together with an overview of the items they exchange. Note that the term "item" is used in a very general sense here, and may represent messages, documents, or business artifacts of any kind. Further view(s) detail out the sequencing of the interactions between the partners. This approach corresponds to UML which defines different diagrams for the static structure and the dynamic behaviour of a system Views for Behavioural Characteristics The characteristics can be either described from the viewpoint of an external observer or one of the participants. The first is defined by a collaborative process, the latter by an abstract process. The collaborative process provides details of the interaction protocol specifying the sequence of exchanged items. The process flow is defined by an activity graph but uses symmetrical concepts that describe the directed interaction between two roles. Order Fulfillment customer Confirmation Shipment Rejection Order manufacturer customer manufacturer Confirmation Shipment customer Order manufacturer manufacturer: can fulfill order? [yes] [no] customer manufacturer Rejection Figure 5-7 Collaborative process of the Order Fulfillment collaboration [14] The figure details out the interactions between the partner roles. It involves a decision can fulfill order? that is made by the participating manufacturer at some point in time. The decision influences the further sequence in the interaction protocol. Note that the Order Fulfillment collaboration only involves two partner roles. We anticipate more complex collaborations with multiple partners and communication channels. An abstract process describes what a partner is expected to do in order to participate in a collaboration. It does not define how this is accomplished but rather constrains the internal behaviour. An abstract process is defined by an activity graph and can be associated to a partner role in a collaboration. Receive and send constructs specify the communication with other partner roles _Athena_DA21_V10.doc CONFIDENTIAL Page 88/104

97 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 <<signal>> Shipment assemblies: Assembly [] invoice: Invoice customer : Ordering Confirmation Shipment Rejection Order Fulfillment Order manufacturer : Fulfillment receive order from customer send confirmation to customer send assemblies & invoice to customer can fulfill order? [yes] [no] send rejection to customer Figure 5-8 Abstract process for the manufacturer role of the Order Fulfillment collaboration [14] The figure shows the abstract process that the On-Demand Manufacturing process must implement to participate in the collaboration as manufacturer. The figure also shows the items exchanged in the collaboration: order, confirmation, assemblies & invoice, and rejection. Note that the sequencing of sending and receiving tasks in an abstract process only represents an ordering constraint and does not exhibit the complete sequence of internal tasks. For example, the can fulfill order? decision can be quite complex and involve many internal tasks. However this is irrelevant for the collaboration and not specified in the abstract process. The corresponding partner role involved in an interaction is depicted within the construct. In the example, all interactions are with the customer partner role. This corresponds to modeling with UML activity diagrams. UML supports swimlanes as an alternative notation where constructs are placed within the swimlane _Athena_DA21_V10.doc CONFIDENTIAL Page 89/104

98 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Typical patterns in collaborative business processes The patterns described in this section - and which are relevant in an A2 context - are generic structures that capture CBP interactions. The patterns are formalized on a very generic level, independent of any modeling method or specific business scenario. The goal should not be to define many patterns that only apply in a specific context, but to come up with a very high level description of patterns describing generic characteristics in the communication of business partners in a crossorganisational interaction. 6.1 Introducing a pattern classification framework To derive patterns and to structure the different dimensions that apply to an interaction between different business partners and organizations, we propose the following framework: Figure 6-1 Pattern Framework The first criterion is the number of senders and receivers that participate in an interaction. A sender sends a message by writing the message into a channel and the receiver or consumer is intended to read the message. Generally the number of senders and receivers can be 1 to many and every combination is possible. We also assume that different tiers of senders and receivers may occur. A receiver of a message can also turn into a sending end by passing on a message. The next characteristic in a CBP interaction is the granularity of a message. One interrelated message can be sent in only one physical message or in many pieces that need to be combined at the receivers site. The third dimension refers to the nature of interaction between different parties and is the most complex. This specifies the number of interactions between an initiating request and a final response, rules or conditions that apply to the interaction (time constraints, etc.) and the logical sequence in the flow of messages _Athena_DA21_V10.doc CONFIDENTIAL Page 90/104

99 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Assumptions For the formalization of the relevant patterns we need to make assumptions of which some are just valid for this first version of patterns. Those will be removed later when we further detail the patterns and focus on more sophisticated ones. The other assumptions will stay valid for the final version of the patterns. Request and response are used in a general sense of the terms: The terms request and response do not imply that these are initiating or final message, but they are used for every message arising from sending or receiving ends. Implied message acknowledgment: For every message exchange acknowledgement messages are created that tell you whether the message was successfully delivered. We do not model or describe these messages; however we assume that they are generated and received. Implied fault handling: At this early stage of the patterns we imply that if an exception or error occurs somewhere in the interaction, the fault is handled implicitly and does not affect the communication. This assumption will be removed when patterns become detailed and we will consider fault handling explicitly. Asynchronous message receipt at receiving or sending end: For the internal processes we assume asynchronous message handling. The internal process does not suspend while waiting for a response, but response independent steps can be executed. Appropriate level of private process expressive power: We assume that the private processes possess sufficient mechanism for association of multiple messages. This includes in particular ability to support the multiple instances for message senders and receivers, synchronization or partial synchronization, and merges on message receives. Shared state of collaboration: We assume that the overall state of the interaction is known to all participating senders and receivers at any time. The reason is to guard against race situations. Required responses imply timeliness: Timelines on responses as well as timeouts are not elaborated on at this stage. Underlying messaging technology for o Messaging reliability: For the patterns we assume a reliable message exchange through underlying technology, where every message receives the specified destination in an adequate period of time. o Messaging mapping to persistence store: All message exchange is automatically stored in a repository. We do not consider the technical details for the persistence store at this stage. o Messaging correlation/mediation/routing to endpoint target: We assume that a technical solution is in place that is responsible for sending the message to the right receiver. o Messaging security: We imply that any security problems are sufficiently handled by the underlying technology and all message exchange is safe. In A2 the handling of these aspects is part of WP A2.4 and A2.5. They have to be considered in the Architecture and Enactment Engine and an appropriate technological support has to be developed. However, they can be assumed to work for the pattern definition, as this focus on possible interactions between partners _Athena_DA21_V10.doc CONFIDENTIAL Page 91/104

100 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ List of patterns In order to describe relevant patterns, we propose to use the following structure: Name: Is an identifier for the pattern that indicates what the pattern does. Description: Short explanation of pattern describing the interaction that takes place between business partners. May contain a graphical representation. Synonyms: List of existing synonyms in related sources and literature references. Example: Description of a real-life business example where this pattern is commonly used. References to classified CBPs should figure here. Problem: Specification of the problem space arising from the pattern and that can t be solved using existing interoperability solutions. List of patterns This is a first version. Especially the examples as in relation to the CBPs need some more work, as some of the more advanced patterns require a more detailed description of the CBPs in order to find suitable examples. Request, single response Description: A party sends a request to one or more parties. Only one response is required from the parties that respond, i.e. of received responses, the first is accepted while the others are ignored Synonyms: Canvass first bid Example: Problem: Request, optional response Description: A party sends a request to one or more parties. Responses are not required, i.e. some or no party responds. Synonyms: Lazy multi-cast request Example: CBP-2 Create Joint Business Plan Information about the individual companies business goals is sent from one party to another. Problem: Atomic request Description: A party sends a request to one or more parties. All parties are required to receive the request. The requirement for response can follow other request patterns. Synonyms: Transacted multi-cast request Example: CBP-8 Pharmaceuticals: Contracts and Chargebacks After the GPO negotiates the best price for its member, all members need to be informed about the price. It is important that all members receive this information so that they can start the ordering process. Problem: Request outsourcing Description: Party A sends a request to party B, who in turn issues related requests to one or more parties. Party B coordinates interactions with these parties and formulates a response with Part A. Synonyms: CBP-15 Sourcing In this case party A is the OEM and party B the Purchasing Unit, which serves as a service supplier handling the relationships with the sub-system suppliers. Example: Problem: _Athena_DA21_V10.doc CONFIDENTIAL Page 92/104

101 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Request relaying Description: Party A sends a request to party B, who in turn issues related requests to one or more parties. Party B does not play a coordinating role, as the request has effectively been relayed. However, Party B may wish to monitor the interactions, or some state thereof, between party A and the other party(s). Synonyms: Example: CBP-8 Pharmaceuticals: Contracts and Chargebacks This pattern applies in this example if e.g. the members start the ordering process independent of the GPO (after the price negotiation), but the GPO wants to stay informed (e.g. to use the information for further negotiations). Problem: Multi-cast canvassing/auctioning Description: Party A sends a multi-cast request to several (bounded or unbounded) parties. The parties may or may not provide responses to the request. Based on responses returned, party A then formulates a new version of the request. Again, responses are canvassed. At the same time, party A might receive responses from the previous request. What is more, parties may issue more than one response to a request, even of a particular version. The latest response that they provide overrides the latest status of the data they have provided, although previous states are also maintained. Synonyms: Example: An example for this patterns are all the CBPs where a joint product development, forecasting etc takes place and multiple versions of documents or information are sent between parties. Concrete examples are CBP-2 Create Joint Business Plan, CBP-3 Collaborate on Sales Forecast. Problem: Single-cast canvassing/auctioning Description: As above but only one of the parties gets the request, i.e. the first that consumes it. Synonyms: Example: Problem: Problem escalation Description: Several parties receive a request. The processing of the request requires peer-topeer interactions between the parties for notifications and status updates. An exception arises at one party s end, while the other parties continue processing on the assumption that no exceptions have arisen. The occurrence could create deadlocks at different parties activities. Therefore, the occurrence of the exception needs to be escalated so that any such deadlocks are avoided e.g. by issuing work slowdowns. Synonyms: Example: Problem: Single-consume request Description: A party sends a request to several parties. Only one party may consume the request, i.e. the first one. Synonyms: Example: Problem: _Athena_DA21_V10.doc CONFIDENTIAL Page 93/104

102 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Delegating request Description: A party sends a request to one or more parties. Responses are required, but to a different party(s). That party(s) is known either at design time or runtime. Synonyms: Example: Problem: Routing request Description: A party sends a request to several parties. Although the request is multi-cast, parties are required to receive the request in a certain order. The order is stored as a condition in the message header of the request, and is updated as each party receives the request, i.e. the next party(s) to be sent the request depends on the ordering condition and who so far has seen the request. The condition can incorporate dynamic conditions, such as the nomination of the current party seeing the message, determining who next can see it. This pattern is useful when the order of a multi-request requires such flexibility. The original sender does not need to send out multi-requests, but one request, which is routed to receivers. Synonyms: Routing slip Example: Problem: Multi-sourced request Description: Several parties send messages which are parts of a request to party (B). The messages arise from autonomous events at the different parties, and their arrival at B needs to be timely enough for their correlation as a single, logical request. Synonyms: Example: Problem: Multi-message request Description: A party sends a request to another party and prior to receiving a response from the other party, may continuing further requests, i.e. further messages. Data states related to the different messages need to be preserved, even through the latest message affects the latest data state. Synonyms: Example: Problem: Multiple-version request Description: A party (A) sends a request to several parties. The parties may or may not provide responses to the request. Based on responses returned, A formulates a new version of the request. Again, responses are canvassed. At the same time, A might receive responses from the previous version of the request. Data states related to the different messages need to be preserved, even through the latest message affects the latest data state. Synonyms: Auctioning Example: _Athena_DA21_V10.doc CONFIDENTIAL Page 94/104

103 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Multi-message, multiple-version request Description: A party (A) sends a request to several parties. The parties may or may not provide responses to the request. Based on responses returned, A then formulates a new version of the request. Again, responses are canvassed. At the same time, A might receive responses from the previous version of the request. Parties may also issue more than one response to a request, even in a particular version (like the multi-message request pattern). Data states related to the different messages need to be preserved, even through the latest message affects the latest data state. Synonyms: Auctioning Example: Problem: Two-parties change negotiation Description: Party A sends a request for change on a shared business object. Party B confirms the change, or rejects it, or makes a counterproposal. The interaction may be iterated several times until a final decision is taken. If a change is accepted, the business object is modified accordingly, otherwise the request is neglected. Synonyms: -- Example: CBP-3 Collaborate on Sales Forecast (CPFR Steps 3, 4 and 5), CBP-4 Collaborate on Order Forecast (CPFR Steps 6, 7 and 8). Problem: _Athena_DA21_V10.doc CONFIDENTIAL Page 95/104

104 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Metrics 7.1 Purposes and approach The objective of the metrics here defined is to measure the results of the A2 Project as they are made available by the Project Workpackages. The metrics will be applied at each ATHENA Milestone on A2 results due for that Milestone. The Following Table lists the results that, according to the DOW, A2 is going to produce for the first two Milestones of the ATHENA project: Milestone Result Contributing WPs M.12 Requirements / State of the Art A2.1 Modelling method for crossorganisational business Method for semantic annotations to CBPs A2.2, A2.1 A2.3 M.24 CBP modelling tool A2.2 Semantic annotations for business processes Architecture and execution platform for CBPs Table 7-1 A2 contribution to ATHENA Results A2.3 Requirements / State of the Art A2.1 A2.4, A2.5 The approach used to evaluate the quality of our results is the following (Figure 7-1): first of all, we identify a set of elements that give us the perception of the quality of A2 results then, for each element, we identify a set of related performance indicators. These correspond to specific questions or assertions that can be measured by referring to a proper set of measurable elements produced by each WP. Quantitative metrics are defined to measure the output produced by each WP, as described in the following. Results Evaluated by Quality Elements Represented by Performance indicators Measured by Metrics Figure 7-1 Measurement approach _Athena_DA21_V10.doc CONFIDENTIAL Page 96/104

105 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Quality elements To evaluate the quality of our results we have identified the following set of elements: Innovation (on state of the art, research challenges), Usefulness (how much we address requirements of the various stakeholders), Business impact, Completeness of analysis, Reuse of existing standard and technologies Performance indicators The evaluation of each quality element is done by analyzing a set of related indicators. Performance indicators are conceived as questions that can be answered by a quantitative measure (for example: 20% ). The following table shows the relationship between project results, quality aspects and performance indicators: Result Quality element Performance Indicator Requirements Usefulness How well Industry specific CBPs are covered by our solution? Usefulness Business impact How well the CBPs identified are matched by our solution? How well industry sector requirements have been considered by our research? State of the Art Completeness How much our requirements address the research challenges? Innovation How much our work innovates on state-of-the-art? Modelling method for cross-organizational business Method for semantic annotations to CBPs Usefulness Reuse of existing standards Completeness Usefulness Requirements compliance. How much the resulting solution addresses the General Requirements. How much the result is built upon existing approaches? How much the result addresses the research challenges. Requirements compliance. How much the resulting solution addresses the General Requirements. Reuse of existing standards Completeness How much the result is built upon existing approaches? How much the result addresses the research challenges. CBP modelling tool Usefulness Requirements compliance. How much the resulting solution addresses the General Requirements. Semantic annotations for business processes Reuse of existing standards Completeness Usefulness How much the result is built upon existing approaches? How much the result addresses the research challenges. Requirements compliance. How much the resulting solution addresses the General Requirements _Athena_DA21_V10.doc CONFIDENTIAL Page 97/104

106 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Result Quality element Performance Indicator Architecture and execution platform for CBPs Reuse of existing standards Completeness Usefulness Reuse of existing standards Completeness Table 7-2 Performance Indicators How much the result is built upon existing approaches? How much the result addresses the research challenges. Requirements compliance. How much the resulting solution addresses the General Requirements. How much the result is built upon existing approaches? How much the result addresses the research challenges. To calculate performance indicators we use a set of metrics, defined to evaluate the A2 Workpackages results as shown in the next Section. The difference between performance indicators and metrics is that the former are intended to measure the overall quality of A2 achievements, while the latter are more detailed measures of specific elements produced in A2 Workpackages. Performance indicators will be defined as functions of the defined metrics (e.g., weighted sum of a specific set of metrics). The final calculation of performance indicators will be performed after completion of all the A2 Workpackages, when it will be possible to give final values to every metric. 7.2 Metrics definitions The work produced by each WP to achieve the expected result must be related to Measurable Elements. These correspond to specific products of the WP that can be measured through quantitative indicators. M1 M6 M7 M9 M12 M15 M18 M21 M24 Measurable Elements A2.1 Requirements Analysis & State of the Art A2.2 Modelling CBPs State of the Art Research Challenges Classified CBPs General Requirements Patterns Technical requirements Tool Specifications CBP modelling tool A2.3 Semantic Issues in CBPs Technical requirements Semantic annotations for business processes A2.4 Architecture for Enactment and Integration of CBPs Technical requirements Architecture Specifications A2.5 Enactment of CBPs Architecture and execution platform for CBPs A2.6 Validation of Results The following Requirements / State of the Art Intermediate Results Modelling Tool for CBPs Enactment architecture Specifications Validated results CBP modelling tool Semantic annotations for business processes Execution platform for CBPs Requirements / State of the Art Figure 7-2 shows the Measurable Elements produced within each A2 Workpackage (in pink boxes) and the ATHENA A2 Results due at M12, M21and M24 respectively (green boxes at the bottom of the Figure) _Athena_DA21_V10.doc CONFIDENTIAL Page 98/104

107 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 M1 M6 M7 M9 M12 M15 M18 M21 M24 Measurable Elements A2.1 Requirements Analysis & State of the Art A2.2 Modelling CBPs State of the Art Research Challenges Classified CBPs General Requirements Patterns Technical requirements Tool Specifications CBP modelling tool A2.3 Semantic Issues in CBPs Technical requirements Semantic annotations for business processes A2.4 Architecture for Enactment and Integration of CBPs Technical requirements Architecture Specifications A2.5 Enactment of CBPs Architecture and execution platform for CBPs A2.6 Validation of Results Requirements / State of the Art Intermediate Results Modelling Tool for CBPs Enactment architecture Specifications Validated results CBP modelling tool Semantic annotations for business processes Execution platform for CBPs Requirements / State of the Art Figure 7-2 A2 Results and measurable elements produced by each WP As a first step to measure A2 results we propose to focus on Measurable Elements. For each Element, one or more metrics are defined to allow its measurement in quantitative terms. Metrics can be simple quantitative measures of a Measurable Element, or they can be dependent on other Metrics. Dependencies can help to relate Elements with each other, even across different Workpackages. For example, the Metric Requirements CBPs coverage measures the Requirements from the point of view of the CBPs they should address. The following Table lists the Metrics for each A2 Workpackage and their definitions. Workpackage Measureable Elements Metric Definition A2.1 State of the Art Works Number of Relevant Works identified Research Challenges Classified CBPs General Requirements Number of research challenges Number of CBPs Number of CBP Sectors CBPs complexity CBPs relevance Number of Requirements Requirements CBPs coverage Works per classification aspect (Model, Methodology, Ontologies, Architecture) Challenges per classification aspect. Average on all CBPs of Governance + Interaction + Velocity + Variability. Average on all CBPs of Business Relevance + Maturity. Number of Requirements mapped on CBPs / Number of CBPs _Athena_DA21_V10.doc CONFIDENTIAL Page 99/104

108 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Workpackage Measureable Elements Metric Definition Requirements CBPs coverage A2.2 Technical Requirements Number of Requirements Modelling Tool Modelling Tool Requirements Coverage Requirements Fulfilled Reuse of existing standards A2.3 Technical Requirements Number of Requirements Semantic annotation Tool Semantic annotation Tool Requirements Coverage Requirements Fulfilled Reuse of existing standards A2.4 Technical Requirements Number of Requirements Requirements Coverage A2.5 Modelling Tool Requirements Fulfilled Modelling Tool Table 7-3 A2 Metrics definitions Reuse of existing standards Number of Requirements mapped on CBPs / Number of CBPs Number of User Requirements related to Technical Requirements / Number of General Requirements Number of fulfilled requirements (after validation) % Built on existing standards Number of General Requirements related to Technical Requirements / Number of General Requirements Number of fulfilled requirements (after validation) % Built on existing standards Number of General Requirements related to Technical Requirements / Number of General Requirements Number of fulfilled requirements (after validation) % Built on existing standards The following Table shows the current set of metrics defined in the A2 project. The values of each metric have been calculated based on the current status of work produced in A2, as of Project Month _Athena_DA21_V10.doc CONFIDENTIAL Page 100/104

109 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Metric ID Name Description Formula Range Value M0 CBPs complexity How complex CBPs are to handle, from a business perspective. M1 CBPs relevance How relevant CBPs are from a business perspective. M2 Requirements CBPs orientation How much the requirements address the CBPs. M3 CBPs coverage How much complete is CBPs support according to the Requirements. M4 M5 M6 M7 M8 M9 Number of Relevant Works - CBP Model Number of Relevant Works - Architecture Number of Relevant Works - Ontologies Number of Relevant Works - Methodology Number of Key Research Challenges - CBP Model Number of Key Research Challenges - Architecture Average on all CBPs of Governance + Interaction + Velocity + Variability. Average on all CBPs of Business Relevance + Maturity. % of CBPs mapped on a Requirement. Average on all General Requirements. % of Requirements relevant to a CBP. Average on all CBPs % 41.67% % 54.00% % 30.02% % 35.44% State-of-the-art work relevant to Modelling. % of relevant works on total state-of-the-art % 59.29% State-of-the-art work relevant to Architecture & Platform % of relevant works on total state-of-the-art % 57.14% State-of-the-art work relevant to Ontologies % of relevant works on total state-of-the-art % 14.29% State-of-the-art work relevant to Methodologies Key Research Challenges relevant to Modelling. Key Research Challenges relevant to Architecture & Platform % of relevant works on total state-of-the-art % 30.00% % of relevant Key Research Challenges % 39.58% % of relevant Key Research Challenges % 25.00% _Athena_DA21_V10.doc CONFIDENTIAL Page 101/104

110 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/2006 Metric ID M10 M11 M12 M13 Name Description Formula Range Value Number of Key Research Challenges - Ontologies Number of Key Research Challenges - Methodology Requirements Coverage - Modelling tool Requirements Coverage - Enactment architecture Table 7-4 Metrics calculated at Project Month 21 Key Research Challenges relevant to Ontologies Key Research Challenges relevant to Methodologies Technical Requirments relevant to General Requirements. (Ref. Deliverable D2.2) Technical Requirments relevant to General Requirements. (Ref. Deliverable D2.3) % of relevant Key Research Challenges % 8.33% % of relevant Key Research Challenges % 38.89% % of technical requirements mapped on general requirements. % of technical requirements mapped on general requirements % 70.83% % % _Athena_DA21_V10.doc CONFIDENTIAL Page 102/104

111 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ Conclusions In the present document we have discussed the general theme of Cross-organizational Business Processes (CBP) from a three-fold perspective: State-of-the-art. In the first part of the document we have built an analysis framework to collect and classify relevant work related to CBP management and execution, referring to both industry and academic sources. A considerable amount of effort has been devoted to CBP-related topics in the past, especially in the fields of modelling and enactment architectures. Yet no comprehensive CBP management approach has been delivered so far, that covers all the aspects related to modelling, enactment, ontology content and methodologies for a full life-cycle perspective on CBPs. High quality works and technologies are available in state-of-the-art, yet most of them focus on single selected aspects. As testified by the metrics evaluation, most works address Modelling and Architecture aspects. Less effort is devoted to Methodological aspects, and less still to Ontologies. In most cases, the analyzed works lack a true CBP perspective, they propose generic solutions that may be adapted to CBPs but actually stem from traditional intra-enterprise workflow approaches. Industry practices. We have tried to analyze how much of the CBP concept can be found in real industrial practices. A schema to classify CBPs according to business-relevant features has been proposed and 18 CBP typologies from qualified industry sources have been analyzed. The collected information has driven the definition of General Requirements, that reflect the industrial users position related to management of CBPs. The analysis of CBPs and General Requirements still confirms the lack of a uniform approach to handle all aspects of CBPs. While basic technologies to solve CBP management problems seem to be available, no CBP can count on a streamlined approach to solve all the technical and non-technical issues it raises. This is testified by the CBP Coverage metric, averaging around 35% per CBP, indicating that more than half of the needs for a specific CBP are out of our requirements scope, as we necessarily focus on requirements that can be solved by technical solutions. As expected, the largest share of the user needs resides in deployment and governance aspects (like e.g., handling trust issues). Methodologies. In answer to these needs, we have tried to approach the CBP problem from a methodological innovation perspective. We propose two approaches that would allow users to tackle the problem from a full-cbp view, instead of focusing on separate intra-company workflows as in state-of-the-art. The swimlane concept allows to define a CBP at the highest possible level, taking into account the different partners interactions and individual contributions to the full CBP. At a lower design level, the view concept, as supported by the BPDM approach, allows decomposition of CBPs into public views of individual partners processes masking internal process details. As a further methodological support, we have looked into workflow patterns specifically conceived for CBPs, to create common ground and speed-up the definition of CBPs across multiple partners. The above contents have been developed and shared across the A2 Workpackages since Project Month 4 (April 2004), and have been progressively updated and aligned with the other Workpackages results. The work here presented has the main purpose to set the scenario, in terms of existing work, industry needs and methodological approach, for the research and development activities that are being carried out in the technical Workpackages (A2.2 to A2.5). The currently available technical results show convergence on the overall scenario here described and the final evaluation at month 24, based on the metric here proposed, will gauge our progress towards full CBP support _Athena_DA21_V10.doc CONFIDENTIAL Page 103/104

112 IP- Project A T H E N A IP- Project - No ATHENA - Project: Cross-Organisational Business Processes ATHENA - Project Number A2 Document Deliverable D.A2.1 Date 16/02/ References [1] UEML, Unified Enterprise Modelling Language is a Themantic Network Project (IST ) financed by European Union (EU). The project started on March 1st 2002 and ends May 30th [2] IDEAS, Interoperability Development for Enterprise Application and Software RoadMaps (IST ). [3] Supply Chain Council s Collaboration Committee, The SCOR Model Collaboration Framework, White Paper, June [4] SAP. Sap business maps. Technical report, SAP AG, [5] Collaborative Planning, Forecasting & Replenishment (CPFR ), version 2.0, June 2003, Voluntary Interindustry Commerce Standards (VICS) Association ( [6] The EAN.UCC CPFR XML Schemas, EAN.UCC Global Standards Management Process (GSMP), March, [7] Becker, J.; Rosemann, M.; Schütte, R.: Grundsätze ordnungsmäßiger Modellierung (in german). Wirtschaftsinformatik, 37 (1995) 5, S [8] UML. [9] Hack, S. (2000). Collaborative Business Scenarios- Creating Value. In: The Internet Economy. Contribution to Symposium on E-Business, SAP AG, Walldorf. [10] Maria Jimenez, SCM Scenario: Enabling Collaborative Commerce in the Supply Chain, Gartner Group, November [11] Asgekar, Vinay, Inter-enterprise Supply Chain Coordination: Why it makes sense now, Report AMR Research, Ottobre [12] Kak, Rajeev, Sotero, Dave, Implementing RosettaNet E-Business Standards for Greater Supply Chain Collaboration and Efficiency, White Paper, RosettaNet, [13] A. White, K. Peterson, B. Lheureux, New P2P Solutions Will Redefine the B2B Supply Chain Gartner Group, 1 st February [14] Business Process Definition Metamodel Concepts and Overview. J. Frank, T. Gardner, S. Johnston. et al. Object Management Group. [15] Schulz, K.; Orlowska, M.E.: Architectural Issues for Cross-Organisational B2B Interactions. Proceedings International Conference on of Distributed Computing Systems Workshop, 2001, P [16] K.Schulz: Modelling and Architecting of Cross-Organisational Workflows. The School of Information Technology and Electrical Engineering, The University Of Queensland, Australia. [17] Liu, D.-R.; Shen, M.: Modeling workflows with a process-view approach. Proceedings of Seventh International Conference on Database Systems for Advanced Applications, Hong Kong, 2001, pp [18] Chiu, D. K. W.; Karlapalem, K.; Li, Q.; Kafeza, E.: Workflow view based e-contracts in a cross-organizational E-services environment. Distributed and Parallel Databases, Volume 12, Issue 2-3, Dordrecht, 2002, pp _Athena_DA21_V10.doc CONFIDENTIAL Page 104/104

113 Integrating and Strengthening the European Research Networked business and government Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application ATHENA Cross-Organisational Business Processes A2 WORKING DOCUMENT WD.A2.1 Annex 1 Cross-organizational modelling of information exchange Frank-Walter Jaekel, Fraunhofer IPK-Berlin Leading Partner: SAP Security Classification: Restricted (RE) May, 2004 Version 1.0

114 !" #$%& ' ( ) * * +," ))" " - Table of Contents TABLE OF CONTENTS... II TABLE OF CONTENTS... II LIST OF FIGURES... III 1 ABSTRACT CROSS-ORGANISATIONAL MODELLING APPROACH Source Project Description Scenario Description MODELLING AND ANALYSING Targets of the Scenario Steps of brief Modelling Process Model based on SCOR (brief description of a real case study) CLASSIFICATION AND JUSTIFICATION Classification Schema Justification... 8 " -" )" &. / * ) ' 2 * 3 $

115 !" #$%& ' ( ) * * +," ))" " - List of Figures Figure 1: The Modelling Process of the Process Chains within the Project... 5 Figure 2: Process Model for one Enterprise within the Supply Chain... 5 Figure 3: Modelling according to SCOR... 6 Figure 4: Resource and Product Classes (draft structure)... 6 Figure 5: Order (Control) Classes (draft structure)... 6 Figure 6: Section of the external View (Supply Chain Model)... 7 Figure 7: Relation between the Enterprise Model and SCOR... 7 " -" )" &. / * ) ' 2 * 3 $

116 !" #$%& ' ( ) * * +," ))" " - 1 Abstract This document provides a input to the WD.A2.1 from IPK according Cross-organizational modelling of information exchange. The first part is related to actual approaches concerning Cross- Organisational Business Process. This includes also the evaluation schema. " -" )" &. / * ) ' 2 * 3 +$

117 !" #$%& ' ( ) * * +," ))" " - 2 Cross-Organisational Modelling approach 2.1 Source This approach is being developed under EU FP6 Project SPIDER-WIN. The study includes mainly SMEs from Italian automotive suppliers and producer (motorcycles) Spanish aeronautic suppliers Polish aeronautic suppliers and producer (helicopters). 2.2 Project Description The main target is to reach transparency of the external contacts to customers and suppliers and their influence to the internal processes especially to the control processes of planning and production (management) and services e.g. (engineering, construction, prediction service for exceptions, logistic). So the main focus of the project is the communication between companies and it s support by IT systems. Therefore the modelling of the order transfer between the enterprises is modelled more detailed then the product transfer. The internal structure of the companies is modelled and analysed to identify the capabilities of the companies to support the external information flow. Therefore SCOR (Supply Chain Operational Reference Model) is used as base for the identification of the covered processes within the companies and to centre the focus of the modelling to the external communication. In order to have similar meanings of modelling elements and terms a modelling template was defined. During the definition of the modelling template the process types defined in SCOR have been specialised and enhanced by change management processes and the management of non compliant products (such processes defined in SCOR generic as RETURN). The approach includes also a clear description (modelling) of the interfaces between the companies. The modelling template, the common terminology and the interface descriptions based on input and output states of objects ensures that each enterprise within the supply chain is modelled in a similar structure and to realise a view of the whole supply chain. This will increase the comparability of the different models and also allows a simpler merge of the models into a general overall model. The integrated enterprise modelling (IEM) method (see the tutorial: ORIAL_Text.zip) is used for the modelling purpose. It is proven in several industrial projects for SMEs as well as for big companies. 2.3 Scenario Description In many European regions, SMEs are part of intense customer-supplier networks. These companies survive, only, because of the excellent skills of their employees and the extreme flexibility of their processes. Co-ordination mechanisms are poor, and the extremely lean organisations do not allow for any substantial IT overhead. SCM tools are too complex, expensive and personnel-intensive for these enterprises. Mechanisms like virtual market places do not help, because they assume some standardisation of products and it aims to select partners based on price and delivery time. This is not suitable for a co-operation based on skills and expertise. The project SPIDER-WIN (IST ) includes a sub task to collect enterprise models (mainly order processing) from different partners and to synchronise them along the supply chain and across different regions. The partners are Fraunhofer IPK, Fibertecnic, PM, Joinet, IMIK, CIAP, Ducati, PZL, SISTEPLANT and Bentivogli. " -" )" &. / * ) ' 2 * 3 )$

118 !" #$%& ' ( ) * * +," ))" " - The goal of the project is to achieve efficient, simple and context-aware SME co-operation with low-level local software requirements and adapted to the typical availability and quality of resource data in very small enterprises, focussed on the exchange of order status changes. The approach includes field studies in three different European regions, providing the potentially available data as well as the related quantified effort and economical benefits. Existing enterprise modelling tools and methodologies will be adapted to efficiently grasp the information from companies which are very small, informally organised, and maintain extremely fuzzy data, only. Mechanisms and algorithms will be worked out, which (a) identify profit potentials within the networked partners, (b) improve production planning reliability by efficiently connecting and evaluating the fuzzy data available from suppliers and setting up suitable alarm mechanisms and (c) give draft estimates of possible delivery horizons immediately. The first section (planed for January to August 2004) of the project conducts a field study among the end-users within the project and further suppliers of these companies. Within those smaller companies, especially when interviewing personnel from all relevant levels, knowledge of the English language cannot be expected. Therefore, the responsibility of the field studies is local. However, it is absolutely important to have one single approach for this study, in order to achieve comparable data and to derive one solution. Therefore, section one is split into two activities: Within the Field Study Preparation, Fraunhofer IPK provides the Integrated Enterprise Modelling Method (IEM), as well as a tool (MO²GO) for its efficient use. This method is very flexible, and the tool supports the application specific definition of resource sets, evaluation schemes etc.. A common model sketch has been developed, in order to guarantee that all information and requirements detected can be systematically documented within one single, consistent model. This general model has been designed in English language, for exchange and dissemination reasons. It is possible to develop the model in the native local language and afterwards it is possible to have a switch between the local native language and the English language. Guidelines for open interviews were set up, and related to typical roles in the users enterprises. A short sample process study are performed in each region. This ensure that (1) a general model and guidelines are operational for this application case and (2) that the regional coaches have really internalised the IEM and the required open interview technique. Based on these (distributed) experiences, the definition of the field study and the process model is improved and finally decided. This general model is then applied in the Full Field Study. However, the major work has been done within three tasks for each region, where the local coach is fully responsible. IPK supports the other partners, and regularly screen the models developing, in order to ensure one unique model world and to avoid that any section of the field studies runs into a dead end road. " -" )" &. / * ) ' 2 * 3,$

119 !" #$%& ' ( ) * * +," ))" " - 3 Modelling and Analysing 3.1 Targets of the Scenario One target is to reach transparency of the external contacts to customers and suppliers and their influence to the internal processes especially to the control processes of planning and production (management) and services e.g. (engineering, construction). The following issues are under account for modelling and analysis: Within the enterprise the internal process structures for planning, control and production includes: Kind of all incoming and outgoing orders and their processing take into account plan and control negotiation, sourcing, making, delivery, returns Kind of all incoming and outgoing products and their internal processing (sourcing, making, delivery, returns) Long, mid and short term planning (e.g. experience, methods, forecasting policy, frame contracts, documentation) Problems during planning/controlling and their handling (delays, quantity splits, request of changes) potentials (improvements) Other communication with business partners (e.g. common planning, information exchange, request of design...) The supply chain across enterprises includes: Check if the outcome of predecessor enterprises (e.g. supplier) is identically with the income of the related successor enterprises - and reverse Clarification of the acceptance and problems of the order processing across the borders of the enterprise (Do the suppliers accept my order processing or not? Where are the problems and how are problems solved?) This applies also to Tier 0 (End-user) down to Tier 4 (part deliverer). All needed resources, especially organization (responsible persons) and IT systems will be identified. This includes: the IT systems in use the gaps between different functions and systems of IT support according to the order processing Concerning the analysis the availability of indicators (metrics) will be clarified. According to the sensibility of enterprises especially SMEs to publish their data and process structures, levels of external transparency are defined. The analysis includes the identification of potentials of savings (man months efforts, financial resources, other resources). " -" )" &. / * ) ' 2 * 3 %$

120 !" #$%& ' ( ) * * +," ))" " Steps of brief Modelling Process Step 1 Which object is being considered (order, resource, product)?? Step 2 What are the boundaries of your chains? Step 3 Which functions do modify the state of the object (action)? Step 4 How is the object described before and after an action? Start End Step 7 Step 5 How is this function being controlled? Step 6 Which resources are necessary to carrying out this function? Figure 1: The Modelling Process of the Process Chains within the Project 3.3 Model based on SCOR (brief description of a real case study) The main focus of the project is the communication between companies and it s support by IT systems. Therefore the modelling of the order transfer between the enterprises is modelled more detailed then the product transfer (Figure 2). Figure 2: Process Model for one Enterprise within the Supply Chain The structure of the process model is based on the highest level of SCOR (Supply Chain Operational Reference Model) terminology (Figure 3). So each enterprise within the supply chain is modelled in a similar structure. This will increase the comparability of the different models and also allows a simpler merge of the models into a general overall model. " -" )" &. / * ) ' 2 * 3!$

121 !" #$%& ' ( ) * * +," ))" " - Figure 3: Modelling according to SCOR The merge and comparability of the models is also supported by predefined class structures. This class structures should clarify common wording for objects and allow evaluation procedures of the model. Examples of the class structures are illustrated in Figure 4 and Figure 5. Figure 4: Resource and Product Classes (draft structure) Figure 5: Order (Control) Classes (draft structure) Afterwards, the different process models for single enterprises will be combined to an overall supply chain model. Figure 6 and Figure 7 illustrate a section of the whole supply chain. The real whole model will not be a single sequence. Moreover it will be a network of different customer supply relations. " -" )" &. / * ) ' 2 * 3 -$

122 !" #$%& ' ( ) * * +," ))" " - Figure 6: Section of the external View (Supply Chain Model) Figure 7: Relation between the Enterprise Model and SCOR " -" )" &. / * ) ' 2 * 3 #$

123 !" #$%& ' ( ) * * +," ))" " - 4 Classification and Justification 4.1 Classification Schema Relevant work Notational Aspects Execution significance Execution platform Integrating technologies Language for Ontology Ontology content Methodology Cross-organizational modelling of information exchange 4.2 Justification SPIDER-WIN aims to design an exchange platform for order management across supply chains. The order management requires information of the enterprises participating within the supply chain. Therefore, interfaces has to be defined to connect systems available within the enterprises or if no suitable system is available then manual action using the internet browser has to be introduced. The modelling approach within the SPIDER-WIN project is supported by a modelling methodology and its notation to represent the whole supply chain network as well as the single enterprises. Modelling templates has been introduced based on SCOR to increase the comparability of the models because the models were designed from different persons in different countries. The templates define some kind of ontology (terms, semantic of the terms and structure information). " -" )" &. / * ) ' 2 * 3 $$

124 Integrating and Strengthening the European Research Networked business and government Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application ATHENA Cross-Organisational Business Processes A2 WORKING DOCUMENT WD.A2.1 Annex 2 SoA Business Process Execution Language for Web Services (BPEL4WS) Michael Friess, IBM UK Dominic Yow-Sin-Cheung & Sonia Lippe, SAP Research Leading Partner: SAP Security Classification: Restricted (RE) May 2004 Version 1.0

125 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 Table of Contents TABLE OF CONTENTS... II 1 ABSTRACT FOUNDATIONS Meta Model Partner Interactions Message properties and correlation Data handling Process Behaviour Life cycle Error Handling Event Handling Executable and Abstract Processes Language process partnerlink Sample Workflow Pattern-based evaluation of BPEL4WS EXTENSIBILITY EVOLUTIONS METHODOLOGIES, TECHNOLOGIES AND TOOLS RELATED BPEL Server and BPEL Designer by Collaxa Inc Business Process Execution Language for Web Services Java Run Time (BPWS4J) by IBM Corporation WebSphere Platform by IBM Corporation Exchange Infrastructure (XI) by SAP AG CLASSIFICATION FRAMEWORK REFERENCES SUMMARY AND CONCLUSION " 2"," &3 ) -,03 *,/ ( 0!

126 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 1 Abstract Business Process Execution Language for Web Services (BPEL4WS) provides a language to specify business processes that are composed of Web services as well as exposed as Web services; the specification states in [2] that the language specifies business process behaviour based on web services i.e. can be seen as a (business) extension to the web services paradigm. It can be used for composing solutions from processes and other components in the realm of a Service Oriented Architecture. The language supports specification of business protocols by defining partner relationships and their external visible behaviour through abstract business processes. In April 2003 the specification was submitted by BEA Systems, Inc., IBM Corporation, Microsoft Corporation, SAP AG, Siebel Systems to the Organization for the Advancement of Structured Information Standards (OASIS) consortium for standardization. Product support including process engines or tools is available or announced from several companies such as Microsoft, IBM and SAP. Business processes in BPEL4WS represent stateful, long-running interactions. Process instances are created implicitly through initial activities receiving messages. Correlation of incoming messages to process instances is supported based on business tokens significant data carried with the message, such as surname together with birthplace and date. Process behaviour is described using a single model with both hierarchical structure of specialized control constructs and graph structure. Handlers specify further behaviour for compensating activities, acting on unsolicited events, and error recovery and alternatives. " 2"," &3 ) -,03 *,/ ( 00!

127 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 2 Foundations Business Process Execution Language for Web Services (BPEL4WS) provides a language to formally specify business processes as well as business protocols. Executable business processes describe the actual behaviour of a process as it participates in a business interaction with other parties. Abstract processes define the external visible behaviour of a party involved in a business protocol. A first version of the BPEL4WS specification [1] was published in August 2002 by BEA Systems Inc., IBM Corporation and Microsoft Corporation. It provided a convergence of ideas found in the XLANG and WSFL specifications and superseded these. A second draft [2] was submitted in April 2003 by BEA, IBM, Microsoft, SAP AG, Siebel Systems to the Organization for the Advancement of Structured Information Standards (OASIS) consortium for standardization. Among other changes this version clearly separated core concepts and extensions for executable processes and business protocols. The OASIS Web Services Business Process Execution Language Technical Committee (WSBPEL TC) continues the work on BPEL [3]. The WSBPEL TC scope is to support process mechanisms in the following areas: a. Sequencing of process activities, especially Web service interactions b. Correlation of messages and process instances c. Recovery behaviour in case of failures and exceptional conditions d. Bilateral Web service based relationships between process roles The original authors of the BPEL4WS specification have summarized a number of goals that formed the basis for their specification work and are also reflected in the WSBPEL TC charter [4]. Overall Goal 1: BPEL4WS should define business processes that interact with external entities through Web service operations... [4] As the name already indicates BPEL4WS is based on Web Services, in particular on Web Services Description Language (WSDL), 1.1. All required and provided functionality of a process are expressed through Web Services more precisely, WSDL port types. Port types represent the abstract definition of endpoints as a collection of operations. [5] Overall Goal 2: BPEL4WS defines business processes using an XML based language... [4] BPEL4WS is defined as an XML schema which is in line with other standards and proposals in the Web Services space. The specification is not concerned about the graphical representation and any design methodology for business processes. Overall Goal 3: BPEL4WS should define a set of Web service orchestration concepts that are meant to be used in common by both the external (abstract) and internal (executable) views of a business process... [4] The authors recognize value of standardization for both uses. Enhancing Web Service descriptions with behavioural aspects (external process views) increases interoperability between Web Services. Unifying the concepts of process models allow the definition of platform independent, portable process definition and facilitates enterprises and vertical standards to offer or exchange such definitions. To provide precise behavioural description for cross-enterprise business protocols covering aspects such as data dependent behaviour, error recovery requires a language with many features also found in a language for executable processes. A common set of core concepts and language constructs for external and internal views eases anticipated tasks such as conformance verification of executable processes participating in a business protocol. As BPEL4WS is strongly based on Web Services (goal 1) and provides a language with common core concepts for both external and internal behaviour (goal 3), it can be used for composing solutions from processes and other components in the realm of a Service Oriented Architecture. Overall Goal 10: BPEL4WS should build on compatible Web services standards and standards " 2"," &3 ) -,03 *,/ (,0!

128 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 proposals as much as possible in a composable and modular manner. [4] It is important to see BPEL4WS in context of other Web Services standards. The basic Web Services specifications consist of XML to describe message data, SOAP and HTTP to provide communication and message interoperability and WSDL to describe services. Further specifications are introduced to provide higher-level capabilities such as security, reliability, and transactions. The general approach is based on the design principle of composability in the definition of Web service specifications [6]. In this sense BPEL4WS is focused on process modeling and relies on appropriate Web Services standards for features not in its scope. When such features are not available in other Web Services standards, they are introduced in a modular and composable fashion, for example definitions for properties and property aliases. 2.1 Meta Model Business Process Execution Language for Web Services (BPEL4WS) provides a language to formally specify business processes as well as business protocols. It includes concepts to describe the process behaviour composed of activities, partner interactions, life cycle management, data handling, correlation of messages to process instances, long-running transactions, and event handling Partner Interactions Processes interact with partners through Web Services. BPEL4WS introduces concepts to express the peer-to-peer conversational relationships between services. A partner link type models this relationship between two services with their role w.r.t. the relationship and their port type. A partner link type may be degenerated and only have only one role specified. It represents a service that is capable of linking with any service without imposing requirements onto it. The following figure captures the concept of a partner link type having a name and being associated to two WSDL port types, each representing the role of one of the partners. Role 1 Role 2 Name PortType PortType The concept is introduced as a WSDL extension element and can be used independently of the process definition. A partner link type definition can be specified in its own target namespace and in a separate WSDL document or colocated with a service definition. In BPEL4WS partner links specify the services that a business process interacts with. A partner link is named and characterized by a partner link type and defines which role the process and the partner play w.r.t. the relationship. A process might have several partner links with the same partner link type. For example a broker process might have one partner link with a Buyer another with a Seller, both based on the same partner link type. There can be three different types of partner relationships. The following figure depicts these for the process example provided in the BPEL4WS specification. The partner link for Invoice and Shipping are biliteral. The process is capable of linking to any service through the Customer partner link. The process uses the Scheduling partner unidirectionally. " 2"," &3 ) -,03 *,/ ( 10!

129 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 My Process My Process Customer myrole Invoice Partner Invoice myrole Shipping Partner Shipping Process Partner myrole Shipping myrole Scheduling Partner Partner links describe the static shape of the relationship but not the actual service endpoints which need to be resolved before a service can be invoked. Service binding is outside the scope of BPEL4WS and might be specified as part of the deployment. However, the language allows dynamic binding of partner services. This is achieved by assigning endpoint references to partner links. For example, a partner might provide the endpoint reference to a callback service as part of its message data. The optional partner construct is used to specify a partner relationship that consists of several partner links. The invoke activity defines the invocation of a Web Service operation provided by a partner. This can be an asynchronous one-way operation or a synchronous request/response operation. Required attributes partnerlink, porttype and operation specify the Web Service operation. The inputvariable attribute specifies the variable used as input message, outputvariable specifies the variable to store the result in case of a synchronous operation. The receive and corresponding reply activity define the provision of a Web Service operation. These language elements contain the required attributes partnerlink, porttype and operation to specify from which partner and via which Web Service operation the invocation is expected. The variable attribute specifies the variable used for the message received or returned respectively. An optional faultname attribute on the reply activity indicates a fault Message properties and correlation Message properties are used to name and refer data elements in a message that have a specific significance. A property has a globally unique name and a type. The property might occur in different message types. In business protocols properties are typically part of the business data. A property alias maps a property to a data element in a message part. These are defined as WSDL extensibility elements. Messages sent to the WSDL port of a businesses process need to be routed to the correct process instance. BPEL4WS supports correlation of messages to process instances based on business token(s) specific data field(s) carried with the message and identifying the process instance. A correlation set defines a set of such correlation tokens. A correlation set is declared as a list of properties and identified by a name. A correlation is used within a group of activities that interact with a given service instance. Several correlation sets can be associated with such activities and complex correlation patterns are supported Data handling Overall Goal 5: BPEL4WS provides limited data manipulation functions that are sufficient for the simple manipulation of data that is needed to define process relevant data and control flow. [4] Variables are containers that hold the state of a business process. A variable is named and typed by WSDL message type or XML Schema element or simple type. " 2"," &3 ) -,03 *,/ ( %0!

130 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 Variable data can be constructed or copied using the assign activity which consists of one or more copy constructs. Different forms of its from and to parts provide means to use messages, message parts, message properties, endpoints associated with partner links as source or destination. In addition literals and simple expressions can be used as source Process Behaviour The root activity element with in the process element specifies the process behaviour. Structured activities define the order in which activities take place. Activities can be nested within structured activities. Basic activities to signal faults, wait, do nothing, and terminate an executable process are included in addition to those for partner interaction and data handling. BPEL4WS provides a single model for expressing process behaviour that merges the two approaches of a hierarchical structure of specialized control constructs and a graph structure with control constructs based on transition and join conditions. The authors envision that this should reduce the fragmentation of the process modelling space [4]. Sequence, switch, and while activities provide sequential control structures similar to those found in many programming languages. The pick activity provides a choice based on external events which can be an incoming message or a timer event. The flow activity provides parallel execution of the contained activities. Further ordering constraints are expressed through links between a source and target activity nested in the flow. The language imposes restrictions on how links can cross boundaries of nested constructs such as while activity and various handlers. Furthermore links are only allowed to produce acyclic directed graphs. A transition condition can be specified on a link and a join condition on the target activity. By default the process engine will raise a fault, if the join condition fails. This behaviour can be deactivated for nested activities or the process as a whole. This will cause the process to skip unreachable activities silently which is also called dead-path-elimination. Context can be added to a set of activities through a scope. It can include fault handlers, compensation handlers, event handlers, data variables, correlation sets and indicate serialized access to variables Life cycle A process definition can be seen as a template for business process instances. Instances are created implicitly through initial activities receiving messages only. Multiple start activities must be specified with the same correlation set(s). This implies that later incoming messages are routed to the existing process instance. Process instances terminate normally when the process behaviour completes or abnormally, when a fault reaches the process scope or when terminated by an explicit terminate activity Error Handling The language supports error handling of business processes through compensation. Compensation and fault handlers define the behaviour to compensate completed activities and handle business exceptions. This feature referred as Long-Running Transactions is considered to be used in a local environment, in a single process instance and platform-specific implementation. The authors expect the utilization of WS-Transaction for distributed or platform-spanning scenarios and provided a detailed model of BPEL4WS Long-Running Transactions based on WS-Transaction concepts Event Handling Event handlers define behaviour invoked concurrently when an event occurs. Event handlers can be specified on a scope or for the whole process and are available as long as their scope is active. If the event is a user-defined time, the corresponding behaviour will be executed only once. If the event is an incoming message corresponding to a Web Services request/response or one-way operation, the " 2"," &3 ) -,03 *,/ (!0!

131 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 associated behaviour is performed for each incoming message Executable and Abstract Processes The specification provides extensions for executable and abstract processes. The extensions for executable processes precise the behaviour of a compliant process engine, add the terminate activity and provides a function and from form to access data elements in a message. The extensions for abstract processes relieve the constraints that variables need to be fully initialized. A from opaque form of the copy construct is used to specify non-deterministic effect of a private, hidden computations. 2.2 Language BPEL4WS is a XML based notation to describe business process behaviour. The following provides an overview of the main language elements and attributes. It is not intended to be complete and the language specification should be consulted process The root element of a BPEL4WS document defines an abstract or executable process. abstractprocess attribute indicates the process being abstract. querylanguage and expressionlanguage attributes specify the languages used for various data handling and for expressions. The default for both is XPath 1.0. suppressjoinfailure and enableinstancecompensation attributes determine overall process behaviour. partnerlinks and partners elements contain the specifications for partner links and partners. variables element contain the variable definitions. correlationsets element lists the correlation sets. faulthanlders, compensationhandlers, and eventhandlers contain the various handlers to define compensation and fault handling of long-running transactions and alternate behaviour. activity element describes the process behaviour and is typically a structured activity with further nesting partnerlink The partnerlink element specifies a partner link detailing the role of the process and the partner. name attribute specifies its name and is used in activities that interact with partners. partnerlinktype attribute is the qualified name of the partner link type. myrole and partnerrole specify the respective oles of the process and the partner. The following sample provides more details how these constructs are used. 2.3 Sample Workflow The specification uses the classical purchase order business process as an example to explain the concepts and syntax of BPEL4WS. This purchase order is shown in Figure 1: Sample process (purchase order); the figure shows sequential tasks using a dotted arrow while a solid arrow represents control flows (e.g. synchronisation). Free grouping denotes concurrent/parallel sequences. " 2"," &3 ) -,03 *,/ ( 20!

132 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 Figure 1: Sample process (purchase order) An excerpt of the equivalent BPEL4WS syntax for the service definition can be seen below. <message name="pomessage"> <part name="customerinfo" type="sns:customerinfo"/> <part name="purchaseorder" type="sns:purchaseorder"/> </message> Above text shows the syntax for a BPEL4WS message definition including two parts (customerinfo and purchaseorder) and their types; this message is then to be used by the calling operation as defined in the (WSDL) porttype which is the actual port to call. <porttype name="purchaseorderpt"> <operation name="sendpurchaseorder"> <input message="pos:pomessage"/> <output message="pos:invmessage"/> <fault name="cannotcompleteorder" </operation> </porttype> message="pos:orderfaulttype"/> This operation named sendpurchaseorder uses previously defined POMessage as input and another (here undefined) message as output/return value. Error handling is implemented through the fault tag specifying the fault name ( cannotcompleteorder ) and the message to issue in this case ( pos:orderfaulttype ). " 2"," &3 ) -,03 *,/ ( #0!

133 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 Finally a partnerlinktype needs to be defined representing the partner (service) dependencies: <plnk:partnerlinktype name="purchasinglt"> <plnk:role name="purchaseservice"> <plnk:porttype name="pos:purchaseorderpt"/> </plnk:role> </plnk:partnerlinktype> As stated before this is merely the service definition not the actual call; performing an operation (i.e. issuing the actual call) is described next. <partnerlinks> <partnerlink name="purchasing" partnerlinktype="lns:purchasinglt" myrole="purchaseservice"/> </partnerlinks> partnerlinks defines the parties that actually interact during the business process (as opposed to the general possible partner dependencies above). This shows the link name, type and the role of this link. 2.4 Pattern-based evaluation of BPEL4WS As to be expected from the merger of WSFL and XLANG, BPEL4WS represents a superset of functionality of both sub-standards. van der Aalst shows this using typical workflow patterns 1 and also analyses other business process related standards such as XPDL and BPML [7]. Aalst also states that it appears that XPDL is less expressive than BPEL4WS probably making BPEL4WS more interesting for A2 and ATHENA respectively. 1 Such as Parallel Split, Synchronisation, XORs etc. " 2"," &3 ) -,03 *,/ ( $0!

134 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 3 Extensibility BPEL4WS is designed as a set of core concepts and extensions for business processes and business protocols. The language supports extensibility through attributes with qualified names on all elements and elements from other namespaces appear within BPEL4WS elements. This is formalized in the XML Schema of the specification. BPEL4WS is meant to be composable and used in concert with other Web Service specification [6]. Extensibility of these specifications is applicable for extensions outside the scope of BPEL4WS but in the area of the respective specification. " 2"," &3 ) -,03 *,/ ( &0!

135 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 4 Evolutions The WS-BPEL TC drives the standardization of BPEL4WS focusing on common concepts as well as the usage for process interface descriptions and executable process models. The committee maintains a list of issues and the progress on them. Several issues are raised for specifying abstract processes. Products leverage the extensibility of the language to provide additional capabilities. Kloppmann et al. describe how enhancements to the language are implemented in the context of J2EE and WebSphere [8]. These include Support for human workflow including human-based activities, staff assignment and a process portal. Different QoS characteristics for business processes including non-interruptable business processes also known as microflows or micro script streams [9] and alternative unit-of-work scopes. Map BPEL4WS to J2EE artefacts and implement a deployment model for J2EE application server. The BPEL4WS specification is platform independant and does not intend to cover mapping and deployment to a specific runtime platform. Combine BPEL4WS with Java features including the use of Java interfaces and methods for partner interactions, Java as alternative for expression, Java variables and snippets. In a joint white paper BEA and IBM propose a combination of BPEL4WS with Java named BPELJ [10]. The proposal introduces further features such as callback objects, annotate Java classes with BPELJ, and support for ACID transactions. The Model Driven Architecture (MDA) initiative of the Object Management Group (OMG) aims to raise the abstraction level and separate business logic from the underlying platform technology. The MDA approach is applied to BPEL4WS and a UML profile for BPEL4WS together with a mapping tool developed [11]. Based on this profile a BPEL4WS business process can be graphically modeled with an UML tool, such as IBM s Rational XDE or Rose. The mapping tool is able to take these process models and convert them to the correct BPEL and WSDL files necessary to implement that process. The current submission for a Business Process Definition (BPD) Metamodel includes a nonnormative mapping from UML to BPEL4WS and the BPD metamodel under development will include a mapping to BPEL4WS. " 2"," &3 ) -,03 *,/ ( 0" 0!

136 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 5 Methodologies, Technologies and tools related 5.1 BPEL Server and BPEL Designer by Collaxa Inc. 5.2 Business Process Execution Language for Web Services Java Run Time (BPWS4J) by IBM Corporation BPWS4J is an alphaworks technology. It features an engine to execute processes described in BPEL4WS. It also includes executable samples and a XML validation tool for BPEL4WS documents. BPWS4J is a J2EE web application. It relies on a J2EE servlet engine and Apache AXIS. It works with Apache Tomcat and WebSphere Application Server WebSphere Platform by IBM Corporation WebSphere Business Integration Server Foundation V5.1, used in conjunction with WebSphere Studio Application Developer Integration Edition V5.1 for development, delivers a next generation integration platform optimized for building and deploying composite applications that extend and integrate your existing IT assets. The two WebSphere products provide a process engine and tool supporting BPEL4WS business processes integrated with the WebSphere platform and tooling environment. The WebSphere development environment is based on the open-source Eclipse tool platform and leverages the Eclipse Modeling Framework (EMF). EMF is an implementation of the OMG Meta-Object Facility (MOF) and facilitates the MDA development. The development environment includes an EMF implementation of the BPEL4WS metamodel Exchange Infrastructure (XI) by SAP AG One of the products on the market offering support for BPEL4WS V1.1 is SAP s Exchange Infrastructure (XI) version 3.0. An overview of XI can be found at the website below; since XI is part of Netweaver04 it will be November 2004 as a full product. XI s collaboration approach is process centric and caters both for inter- as well as intra-enterprise processes. Technically it uses Java & J2EE combined with web services as means of communication. Two main features are particularly interesting in the scope of CBPs: Cross-Component Business Process Management Cross-component business processes can be modeled and stored in the Integration Repository. Business processes are executed by a Business Process Engine running tightly integrated with the rest of the SAP XI runtime environment. B2B Integration Collaboration partner profile data can be maintained in the Integration Directory, and communication with those business partners is based on this data. A Partner Connectivity Kit allows the integration of business partners not using SAP XI or other integration solution. " 2"," &3 ) -,03 *,/ ( 000!

137 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 " 2"," &3 ) -,03 *,/ ( 0,0!

138 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 6 Classification Framework Relevant work CBP Model Notational Aspects Execution significance Architect ure and Platform Execution platform Integrating technologies Ontology Language for Ontology Ontology content Method ology Methodology BPEL4WS Justification: From a language point of view BEPL4WS does not offer any notational aspects. It is a pure execution language; any notation has to be provided by other languages, e.g. BPMN. BPEL4WS also is not relevant in the area of ontology s or execution platform. Although different platforms allow for the execution of processes described in BPEL4WS (cp. Chapter 5), this is not part of the standard. Integrating technologies: BPEL4WS offers some capability in messaging techniques, so this is relevant. BPEL4WS also builds on the notion of private and public processes where just parts of a process are exposed to the outside world. This is in sync with our methodology proposed in A2. " 2"," &3 ) -,03 *,/ ( 010!

139 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 7 References [1] Business Process Execution Language for Web Services, Version 1.0. BEA Systems, International Business Machines Corporation, Microsoft Corporation. August Business Process Execution Language for Web Services, Version 1.1. BEA Systems, International Business Machines Corporation, Microsoft Corporation, SAP AG, Siebel Systems. 5 th May OASIS TC Call For Participation: WSBPEL. OASIS. April "Goals of the BPEL4WS Specification." By Frank Leymann, Dieter Roller, and Satish Thatte. Working document submitted to the OASIS Web Services Business Process Execution Language TC.OASIS Web Services Business Process Execution Language TC. August [5] Web Services Description Language (WSDL) 1.1. World Wide Web Consortium. W3C Note 15 March [6] Secure, Reliable, Transacted Web Services, Architecture and Composition. D. Ferguson, T. Storey, B. Lovering, J. Shewchuk. 28 th October [7] W.M.P. van der Aalst, Don t Go With The Flow: Web Services Composition Standards Exposed, Jan/Feb 2003 issue of IEEE Intelligent Systems; partially online at [8] Business process choreography in WebSphere: Combining the power of BPEL and J2EE, Kloppmann et al. IBM Corporation. IBM Systems Journal, Vol 43, No 2, [9] F. Leymann and D. Roller, Production Workflow, Prentice Hall, Inc., Upper Saddle River, NJ (2000). [10] BPELJ: BPEL for Java. A Joint White Paper by BEA and IBM. March [11] From UML to BPEL. Model Driven Architecture in a Web services world. Keith Mantell. IBM Corporation. 9 th September " 2"," &3 ) -,03 *,/ ( 0%0!

140 !" #$%& ' ( %) ' * ( +), - ). - ) - /,/0 *, - 01",," " 2 8 Summary and conclusion BPEL4WS provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web Services interaction model and enables it to support business transactions. BPEL4WS defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the businessto-business spaces. Related poducts including process engines or tools are available or announced from several companies such as Microsoft, IBM and SAP. " 2"," &3 ) -,03 *,/ ( 0!0!

141 Integrating and Strengthening the European Research Networked business and government Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application ATHENA Cross-Organisational Business Processes A2 WORKING DOCUMENT WD.A2.1 Annex 3 Petri Nets Ralf Klein, Kristof Schneider, DFKI Leading Partner: SAP Security Classification: Restricted (RE) May 2004 Version 1.0

142 ...! " # $ % # $ # & '&( ) * # Table of Contents 1 ABSTRACT FOUNDATIONS EXTENSIBILITY EVOLUTIONS METHODOLOGIES, TECHNOLOGIES AND TOOLS RELATED SUMMARY AND CONCLUSION REFERENCES ,+ '+ -. $ # '(. ) *&! / # 0 1

143 ...! " # $ % # $ # & '&( ) * # 1 Abstract The modelling concept of Petri Nets is applied for the modelling of the temporal behaviour of systems which are in different discrete states at different times. By receiving events a transition can be caused between these states. This modelling concept is mainly suitable for sequential and object obtained processes, however, this modelling concept can also be used for time-continuous processes, if there are processes with single stationary states and if the transitions between these states can be neglected. For these reasons, this modelling concept can be used in all ranges of the system development and represents an essential modelling manner. Especially, it is interesting for system developer or software engineers in the area of industrial automation. Petri Nets have been developed since the beginning of the 60'ies, where Carl Adam Petri defined the language. It was the first time a general theory for discrete parallel systems was formulated. The language is a generalisation of automata theory such that the concept of concurrently occurring events can be expressed. +,+ '+ -. $ # '(. ) *&! / # 0 (1

144 ...! " # $ % # $ # & '&( ) * # 2 Foundations Definition A formal, graphical, executable technique for the specification and analysis of concurrent, discrete-event dynamic systems; a technique undergoing standardisation. Fundamentals A Petri Net consists of places, transitions, and arcs that connect them. Input arcs connect places with transitions, while output arcs start at a transition and end at a place. There are other types of arcs, e.g. inhibitor arcs. Places can contain tokens; the current state of the modelled system (the marking) is given by the number (and type if the tokens are distinguishable) of tokens in each place. Transitions are active components. They model activities which can occur (the transition fires), thus changing the state of the system (the marking of the Petri Net). Transitions are only allowed to fire if they are enabled, which means that all the preconditions for the activity must be fulfilled (there are enough tokens available in the input places). When the transition fires, it removes tokens from its input places and adds some at all of its output places. The number of tokens removed/added depends on the cardinality of each arc. The interactive firing of transitions in subsequent markings is called token game. Figure 2-1 Example of a Petri Net Classification of Petri Nets Level 1: Petri Nets characterised by places which can represent boolean values, i.e., a place is marked by at most one unstructured token. Examples: Condition/Event (C/E) Nets are Petri Nets which require the net structure to be pure and simple. The semantics are defined by the full marking class (forward and backward reachability) and require 1-liveness. Elementary Nets (EN) have been defined by G. Rozenberg and P. S. Thiagarajan as a more simpler model with only forward reachability. 1-safe Nets belong to nets of level 1, since their places are marked by at most one unstructured token. Nevertheless they are usually defined as a subclass of ordinary Petri Nets with unary arc weights, infinite place capacities and boolean markings. Level 2: Petri Nets characterised by places which can represent integer values, i.e., a place is marked by a number of unstructured tokens. Examples: +,+ '+ -. $ # '(. ) *&! / # 0 '1

145 ...! " # $ % # $ # & '&( ) * # Place/Transition (P/T) Nets are Petri Nets characterized by counter tokens, arc weights and place capacities. (Ordinary) Petri Nets (PN) are defined as a subclass of P/T Nets with infinite place capacities and unary arc weights. Level 3: Petri Nets characterised by places which can represent high-level values, i.e., a place is marked by a multi-set of structured tokens. High-Level Petri Nets with Abstract Data Types (HL+ADT) are high-level algebraic Petri Nets, where the tokens and firing rule are specified over an algebraic specification. Environment Relationship (ER) Nets are high-level Petri Nets, where the tokens are environments. Product (Prod) Nets are a high-level Petri Net formalism defined for the Product Net Machine tool. Well-Formed Nets (WN) are high-level Petri Nets similar to Coloured Petri Nets where the colour functions are defined in a different way. Regular Nets (RN) adopt the same notation as WNs allowing each basic object class to appear only once in each cartesian product of colour domains. Traditional High-Level Petri Nets were defined as Predicate/Transition nets by H. J. Genrich and K. Lautenbach and as Coloured Petri Nets by K. Jensen. +,+ '+ -. $ # '(. ) *&! / # 0 *1

146 ...! " # $ % # $ # & '&( ) * # 3 Extensibility Petri Nets Standardisation The standard is being developed by the Joint Technical Committee on Information Technology (JTC1), of the International Organisation for Standardisation (ISO) and the International Electrotechnical Commission (IEC). The technical work is undertaken by a working group of a subcommittee of JTC1 concerned with processes and techniques for software and systems engineering, called SC7, Software and Systems Engineering. The working group that is developing the standard is called WG19 Open Distributed Processing and Modelling Languages. WG19 handles many projects. The Project for Petri Net standardisation is Petri Net Techniques, and has Jonathan Billington as the overall editor. Project intends to produce a multi-part standard comprising 3 parts. Part 1 ISO/IEC Software and Systems Engineering - High-level Petri Nets - Concepts, Definitions and Graphical Notation, defines an abstract syntax (using many sorted algebraic specification techniques) for the graphical form of high-level nets, and provides it with a Coloured Petri Net semantics. This work is currently under ballot within ISO/IEC JTC1/SC7 as a Final Committee Draft. Those interested in commenting on the standard will need to do so via their National Standards Body before the due date. Part 2 is proposed to cover a Transfer Format for Petri Nets, probably based on XML. The purpose of this part is to allow Petri Net tools to exchange Petri Net models and their analysis results. Current work, co-ordinated by Ekkart Kindler, is the development of a Petri Net Markup Language (PNML) using XML. Part 3 concerns extensions to Part 1, including modularity constructs, such as hierarchies in Coloured Petri Nets, and time extensions (e.g. Time and Stochastic Petri Nets). +,+ '+ -. $ # '(. ) *&! / # 0 21

147 ...! " # $ % # $ # & '&( ) * # 4 Evolutions Coloured Petri Nets is a graphical oriented language for design, specification, simulation, and verification of systems. It is in particular well-suited for systems that consists of a number of processes which communicate and synchronise. Typical examples of application areas are communication protocols, distributed systems, automated production systems, work flow analysis, and VLSI chips. Timed Petri Nets are Petri Nets that attach delays to transitions to give them the ability to model time. Petri Net formalisms defined for/within specific Petri Net tools, e.g. AADL Nets, a high-level Petri Net formalism based on the VHDL implementation language for the COMDES tool AMI Nets, a high-level net model with temporal extensions for CPN/AMI Artifex Petri Nets, a Coloured Petri Net model with objects for the Artifex tool CAB Nets, the typed version of timed ER Nets for CABERNET Communicating Petri Nets, an object-oriented net model based on C/E Nets for NETOBJ Communicating Time Petri Nets, a timed message passing net model for ORIS COOPN/2, an object-oriented Petri Net specification language based upon Algebraic Petri Nets for SANDS Macronets, an object-oriented formalism for business modelling in Macrotec M-Nets, a high-level compositional Petri Net model for DIOGENES and PEP Object Petri Nets for LOOPN Product Nets, a high-level Petri Net formalism for the Product Net Machine Queueing Petri Nets, coloured stochastic Petri Nets with queues for the QPN Tool Simulation Nets, a stochastic coloured Petri Net formalism for XSIMNET SPECS Nets, a Petri Net specification language for SystemSPECS Stochastic Activity Networks, an extended GSPN model for UltraSAN Stochastic Reward Nets, a GSPN-like formalism for SPNP Stochastic Well-Formed Colored Nets, a stochastic high-level net model for GreatSPN THORNs, a timed object related net formalism for DNS +,+ '+ -. $ # '(. ) *&! / # 0 31

148 ...! " # $ % # $ # & '&( ) * # 5 Methodologies, technologies and tools related There are tools for Petri Nets for each need and platform (Windows, Unix, Linux, Mac, Java, DOS). With the search for the correct tool one is supported in the internet by special search machines and data bases, e.g. where more than 50 tools are specified with detailed descriptions. There also can be found detailed investigations over the most important tools with exact systems of evaluation for the individual functions and characteristics. +,+ '+ -. $ # '(. ) *&! / # 0,1

149 ...! " # $ % # $ # & '&( ) * # 6 Summary and conclusion Petri Nets are a methodology for describing and studying systems that are characterized as being concurrent, asynchronous, distributed, parallel, nondeterministic, and/or stochastic. As a graphical language, Petri Nets can be used as a visual-communication aid similar to flow charts, block diagrams, and networks. In addition, tokens are used in these nets to simulate the dynamic and concurrent activities of systems. As a mathematical tool, it is possible to set up state equations, algebraic equations, and other mathematical models governing the behavior of systems. +,+ '+ -. $ # '(. ) *&! / # 0 41

150 ...! " # $ % # $ # & '&( ) * # 7 References Homepage of the International Petri Net Community, Computer Science Department, University of Aarhus, Denmark, Peterson, J.L., Petri Net Theory and the Modeling of Systems, Prentice-Hall Inc., 1981 Girault, C./Valk, R., Petri Nets for Systems Engineering: A Guide to Modeling, Verification, and Applications, Springer-Verlag, 2002 Jensen, K., Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Volume 1, Basic Concepts, Monographs in Theoretical Computer Science, Springer-Verlag, 2nd corrected printing, 1997 van der Aalst, W./van Hee, K., Workflow Management: Models, Methods, and Systems, MIT Press, 2002, +,+ '+ -. $ # '(. ) *&! / # 0 11

151 Integrating and Strengthening the European Research Networked business and government Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application ATHENA Cross-Organisational Business Processes A2 WORKING DOCUMENT WD.A2.1 Annex 4 Event Driven Process Chain, EPC Ralf Klein, Kristof Schneider and DFKI Leading Partner: SAP Security Classification: Restricted (RE) May 2004 Version 1.0

152 ! " # $ % # $ # & '&( ) * # Table of Contents TABLE OF CONTENTS... II LIST OF FIGURES... III 1 ABSTRACT FOUNDATIONS EXTENSIBILITY EVOLUTIONS METHODOLOGIES, TECHNOLOGIES AND TOOLS RELATED SUMMARY AND CONCLUSION REFERENCES ,+ '(+ - $ # '(- ) *&!. # / 0

153 ! " # $ % # $ # & '&( ) * # List of Figures Figure 1: Components of the EPC... 2 Figure 2: Vertical decomposition in EPC ,+ '(+ - $ # '(- ) *&!. # / 0

154 ! " # $ % # $ # & '&( ) * # 1 Abstract The EPC-Methodology depicts complex processes by describing the logic activity flow through a sequence of function, event and logic operators. The Event-Driven Process Chain (EPC) which was developed in 1992 at the Institute for Information Systems (IWi) at the University of Saarland together with SAP employees in an R&D project financed by SAP AG. [1][2] The method of the EPC has become a standard in the field of Business Process Management (BPM), so it is the key component of SAP R/3 s modeling concepts for business engineering and customizing. [3][4] +,+ '(+ - $ # '(- ) *&!. # / (0

155 ! " # $ % # $ # & '&( ) * # 2 Foundations Figure 1 illustrates a process example of the EPC. This example doesn t include all possible constructs of an EPC. It only shows the logical structure of the EPC $ % High Quality # 1 2! 3 1 2! $ %! 1!! 6 Legend: Organization Flow / Resource Flow Control Flow Information Flow. Message # PPC = Information Services Flow Material Output Flow Production Planning and Control Goal 1! 3 7 Logical Operator AND Figure 1: Components of the EPC [5][6] Each EPC must follow some simple design rules to avoid undesirable behavior like dead-locks right from the beginning. Thereby no rigorous and complex system of rules and design patterns is proposed as avoiding all possible conflicts would limit the user too much. The three core nodes of an EPC are activities, events and connectors. The name of an event should reflect its characteristic as a point in time (e.g. Item completed ). It is represented by a hexagon. The name of a function should consider the time-consuming perspective of the accomplished task (e.g. Manufacture item ). A function is represented by a rectangle with rounded edges. Connectors are represented by a circle. Within the circle the type of connector is defined through the corresponding symbol. The connector can be split into an upper and lower part reflecting differences between incoming and outgoing connection rules. To clearly define when a business process is intended to begin and what is the final result, each EPC starts and ends with an event. An EPC contains at least one activity. An EPC can be composed of several EPCs. Edges are directed and always connect two elements corresponding to the sequence of activation. An event cannot be the predecessor or the successor of another event. An activity cannot be the predecessor or the successor of another activity. Each event and each activity only have one incoming and/or one outgoing edge. +,+ '(+ - $ # '(- ) *&!. # / '0

156 ! " # $ % # $ # & '&( ) * # 3 Extensibility The extensibility can be regarded, e.g. from two perspectives. First, by using the Swim Lane representation, it is possible to allocate the different functions to the responsible internal or external units. Second, it is possible to extend the methodology to constructs to represent new and relevant objects. Furthermore it is possible to align models to every construct for particularizing these construct. Figure 2: Vertical decomposition in EPC +,+ '(+ - $ # '(- ) *&!. # / 90

157 ! " # $ % # $ # & '&( ) * # 4 Evolutions Today research activities on the EPC are focusing two major issues. One is the integration of the fuzzy set theory into the EPC in order to be able to represent the fact, that in practice business processes often depend on implicit knowledge and require decisions based on unclear objectives.[7] The other is reference modelling with the EPC. +,+ '(+ - $ # '(- ) *&!. # / *0

158 ! " # $ % # $ # & '&( ) * # 5 Methodologies, technologies and tools related The EPC is one of the basic methodologies of the ARIS Design Platform of the IDS Scheer AG. Besides that, it is also possible e.g. to model an EPC with MS Visio. +,+ '(+ - $ # '(- ) *&!. # / :0

159 ! " # $ % # $ # & '&( ) * # 6 Summary and conclusion With the EPC-Methodology it is possible to depict complex processes by describing the logic activity flow through a sequence of function, event and logic operators. In order to reduce the model complexity, it is possible to align to every function another EPC. By using these alignments, very complex procedures can be handled. This is called decomposition. If you want to separate one process model into several on the same level, it is called concatenation.[8] Besides that, it is achievable to extend the methodology to constructs to represent new and relevant objects. Concerning the issue of cross organizational processes it is doable to allocate the different functions to the responsible internal or external units by using the swim lane representation. +,+ '(+ - $ # '(- ) *&!. # /,0

160 ! " # $ % # $ # & '&( ) * # 7 References [1] Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der Grundlage Ereignisgesteuerter Prozeßketten (EPK), in: Scheer, A.-W (ed.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, no. 89, Saarbrücken [2] Hoffmann, W.; Kirsch, J.; Scheer, A.-W.: Modellierung mit Ereignisgesteuerter Prozeßketten : Methodenhandbuch; Stand: Dezember 1992, in: Scheer, A.-W. (ed.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, no. 101, Saarbrücken [3] Keller, G.; Teufel, T.: SAP R/3 prozeßorientiert anwenden: Iteratives Prozeß-Prototyping zur Bildung von Wertschöpfungsketten, 2 nd ed. Bonn, [4] Keller, G.; Lietschulte, A.; Curran, T. A.: Business Engineering mit den R/3-Referenzmodellen, in: Scheer, A.-W.; Nüttgens, M. (ed.): Electronic Business Engineering. Heidelberg, 1999, pp [5] Scheer, A.-W.: ARIS Business Process Modeling, 2 nd ed., Berlin, [6]Scheer, A.-W.: ARIS Business Process Frameworks, 2 nd ed., Berlin, [7] Adam, O.; Thomas, O.; Martin, G. (2003): Fuzzy Workflows - Extending Workflow Management with Vagueness. In: Proceedings der EURO / INFORMS Istanbul 2003, Istanbul/Turkey. [8] Rump, F. J.: Geschäftsprozeßmanagement auf der Basis ereignisgesteuerter Prozeßketten, Stuttgart ,+ '(+ - $ # '(- ) *&!. # / 00

161 Integrating and Strengthening the European Research Networked business and government Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application ATHENA Cross-Organisational Business Processes A2 WORKING DOCUMENT WD.A2.1 Annex 5 Unified Modeling Language (UML) Ralf Klein, Kristof Schneider; DFKI Markus Jäger, Jörg Müller, Siemens AG Leading Partner: SAP Security Classification: Restricted (RE) October 2004 Version 1.0

162 !" #$%& ' ( ) * ' +,-",. / ",-" 3 Table of Contents TABLE OF CONTENTS... II LIST OF FIGURES... III 1 ABSTRACT FOUNDATIONS Requirements of the ATHENA Project UML diagram overview Data View Organizational View Functional View Process View Modularity Monitoring of the Process Execution Automatic Generation of the Process View Tool support Summary and Conclusion REFERENCES... 9 " 3",1" 4 5.,14 6! &

163 !" #$%& ' ( ) * ' +,-",. / ",-" 3 List of Figures Figure 2-1 Figure 1UML 1.5 diagrams... 3 Figure 2-2 Figure 2Diagrams in UML Figure 2-3 Data view of two data elements (Customer and Order), the parts of the data elements, and the relation between the data elements Figure 2-4 Organizational view of a Consortium Figure 2-5Functional view of an Enterprise... 5 Figure 2-6 Process view of a business process... 6 " 3",1" 4 5.,14 6! &

164 !" #$%& ' ( ) * ' +,-",. / ",-" 3 1 Abstract The Unified Modelling Language (UML) represents a collection of object oriented modelling methodologies for specifying, constructing, visualizing, and documenting the artefacts of a softwareintensive system [1]. Due to its general approach, however, it is also possible to use UML for modelling non-software systems and especially interesting for ATHENA for modelling business processes [2,3,4,5]. Especially the new UML 2.0 standard introduces some new interesting features for modelling business processes [1,7,8]. The focus of this paper is to review UML from an ATHENA perspective. To the ATHENA project, it is most crucial to be able to model the different views and to have sufficient support for modularity. With UML the data, organizational and functional views can all be modelled with class diagrams. For modelling the process view, activity diagrams are most suitable, especially with all their new features introduced by UML 2.0. Since class diagrams as well as activity diagrams also support modularity, it can be said that UML 2.0 completely fulfils these basic requirements of ATHENA. UML 2.0 also allows ATHENA to monitor the process execution, since its process view contains a lot of information and since it allows a detailed description of the services of the organizational entities. The last requirement of ATHENA, the automatic generation of the process view, however, is not supported by UML 2.0. As a conclusion it can be said, that UML 2.0 is suitable to describe business processes in the context of ATHENA. " 3",1" 4 5.,14 6! &

165 !" #$%& ' ( ) * ' +,-",. / ",-" 3 2 Foundations The Unified Modelling Language (UML) is mostly used to specify, visualize and document models of software systems, including their structure and design [1]. Due to its general approach, it is however also possible to use UML for modelling non-software systems and especially interesting for us for modelling business processes [2,3,4,5]. Especially the new UML 2.0 standard introduces some new interesting features for modelling business processes [1,7,8]. Although UML 2.0 can be used to model business processes in general, it still needs to be clarified, whether UML 2.0 is suitable in the context of ATHENA, since ATHENA has some very special requirements. The remainder of this section first specifies the special requirements of ATHENA. For each requirement it is then investigated if UML 2.0 is suitable to achieve the requirements. The section ends with a short summary and a conclusion regarding strengths and weaknesses of UML in the ATHENA context. 2.1 Requirements of the ATHENA Project To model a business process within the ATHENA project it is necessary to describe the data used (data view, section 2.3), i.e. what data elements exist and how are they related to each other, the organizational entities involved (organizational view, section 2.4), i.e. the organization within an enterprise and the cooperation of multiple enterprises in the business-to-business case, the services provided (functional view, section 2.5), i.e. the different tasks that can be performed within an enterprise and the different services the enterprises offer to each other in the businessto-business case, and the processes executed (process view, section 2.6), i.e. how are the data, organizational, and functional views interweaved. Another point is that each view needs different levels of abstraction, i.e. the view within an enterprise and the view spanning multiple enterprises. It is therefore necessary to support some kind of modularity within each view, i.e. each enterprise models its own data, organizational, functional, and process view and afterwards the respective views of different enterprises are combined to a common view (section 2.7). One goal of ATHENA is to automatically monitor the execution of the business process. The idea to achieve this is to describe the business process in a certain language in our case this would be UML 2.0, to transform the description model in an execution model (for example BPEL [10]), and to use an engine to execute and monitor the business process. The key question now is, weather the UML 2.0 description of the business process provides enough information for the automatic monitoring (section 2.8). Another aspect of ATHENA is the automatic generation of the process view based on the data, organizational, and functional views. Here again, the key question is, weather the UML 2.0 description of the data, organizational, and functional views provides enough information for the automatic generation of the process view (section 2.9). 2.2 UML diagram overview Because UML is known as a standard in the field of specifying, constructing, visualizing, and documenting the artefacts of a software-intensive system, we only give a short description of the UML basics. UML started out with Version 1 and has now reached version two. In the last release of UML 1 (UML 1.5), UML supports ten diagram types, five of which are called Behavioural Diagrams and five are Structure Diagrams [11]. " 3",1" 4 5.,14 6! ,&

166 !" #$%& ' ( ) * ' +,-",. / ",-" 3 Figure 2-1 Figure 1UML 1.5 diagrams Structure Diagrams: A class diagram shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships. A component diagram depicts the organizations and dependencies among components. A deployment diagram illustrates the execution architecture of systems. It represents system artefacts as nodes, which are connected through communication paths to create network systems of arbitrary complexity. Nodes are typically defined in a nested manner, and represent either hardware devices or software execution environments. A package diagram displays how model elements are organized into packages and the dependencies among them, including package imports and package extensions. An object diagram compasses objects and their relationships at a point in time. An object diagram may be considered a special case of a class diagram or a communication diagram. Behavioural Diagrams An activity diagram depicts behaviour using a control and data-flow model. A state machine diagram shows discrete behaviour modelled through finite state-transition systems. In particular, it specifies the sequences of states that an object or an interaction goes through during its life in response to events, together with its responses and actions. A use case diagram displays the relationships among actors and the subject (system), and use cases. A sequence diagram depicts an interaction by focusing on the sequence of messages that are exchanged, along with their corresponding event occurrences on the lifelines. Unlike a communication diagram, a sequence diagram includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence diagrams and communication diagrams express similar information, but show it in different ways. A communication diagram focuses on the interaction between lifelines where the architecture of the internal structure and how this corresponds with the message passing is central. The sequencing of messages is given through a sequence numbering scheme. Sequence diagrams and communication diagrams express similar information, but show it indifferent ways. " 3",1" 4 5.,14 6! &

167 !" #$%& ' ( ) * ' +,-",. / ",-" 3 From an ATHENA perspective in particular the Behavioural Diagrams are interesting because they take into account the interaction between systems. So, it is possible to depict the dynamic perspective on a system. The Structure Diagrams represent the static perspective on a system that has to be regarded to represent e.g., existing system architectures. Compared to the version UML1.5, UML 2.0 supports three more diagram types: the timing diagram, the interaction overview diagram and the composite structure diagram. [12] The timing diagram describes the change in state or condition of a lifeline (representing a Classifier Instance or Classifier Role) over linear time. The most common usage is to show the change in state of an object over time in response to accepted events or stimuli. The interaction overview diagram depicts interactions through a variant of activity diagrams in a way that promotes overview of the control flow. It focuses on the overview of the flow of control where each node can be an interaction diagram. The composition structure diagram shows the internal structure of a classifier, including the interaction points of the classifier to other parts of the system. It illustrates the configuration of parts that jointly perform the behaviour of the containing classifier. Figure 2-2 Figure 2Diagrams in UML 2.0! " Besides that, compared to the last version, especially the differentiation between soft- and hardware execution has been improved. In the following, we relate the UML diagram types to the different views that are considered to be relevant. 2.3 Data View The task of the data view is to describe all relevant data elements of a business process an their relations to each other. The most suitable UML diagram for that purpose is the class diagram. It is commonly used to describe each class in an object oriented system with its content, i.e. member variables and methods, and its relations to other classes, for example if one class contains or generalizes another. To model the data view with an UML class diagram each data element is modeled as a class, " 3",1" 4 5.,14 6! %&

168 !" #$%& ' ( ) * ' +,-",. / ",-" 3 each part of a data element is represented by a member variable of the respective class, and the relations between different data elements are modeled as relations between classes. Customer +Orders +belongs to 1 +has 0..* Order +OrderID +Article Figure 2-3 Data view of two data elements (Customer and Order), the parts of the data elements, and the relation between the data elements. Figure 2-3 shows a sample data view with two data elements, Customer and Order. The parts of a Customer are Orders and the parts of an Order are OrderID and Article. The relation between the two data elements is that a Customer has up to n Orders and that an Order belongs to 1 Customer. 2.4 Organizational View The organizational view describes the organizational entities involved in the business process. To model the organizational view with UML it is also advisable to use the class diagram, where each organizational entity is described as a class and where the relation contains is used, whenever one organizational entity contains another. Consortium Enterprise 1 Enterprise 2 Department 1 Department 2 Figure 2-4 Organizational view of a Consortium. Function 1 Function 2 Figure 2-4 shows the organizational view of a Consortium. The Consortium consisting of Enterprise 1 and Enterprise 2, where Enterprise 1 has the departments Department 1 and Department 2, etc. 2.5 Functional View All organizational entities can perform certain functions, i.e. provide certain services to other organizational entities. If the organizational entity providing the service is an enterprise, the service is offered to other enterprises in order to form a business process spanning multiple enterprises. If the organizational entity providing the service is for example a department, the service can be used within the enterprise for certain internal business processes. If UML is used, each service/function provided by a certain organizational entity is simply represented by a method of the class representing the organizational entity (see section 2.4). The name of the method gives a description of the service and the signature of the method gives a list of input and output parameter, i.e. elements of the data view (see section 2.3). Enterprise +ReceiveOrder() Sales Department Shipping Department +ProcessOrder() +SendGoods() Figure 2-5Functional view of an Enterprise Billing Department +SendBill() " 3",1" 4 5.,14 6! !&

169 !" #$%& ' ( ) * ' +,-",. / ",-" 3 Figure 2-5 shows the functional view of an Enterprise, where the Enterprise itself provides the service ReceiveOrder and the Departments provide the services ProcessOrder(), SendGoods, and SendBill. Since the name of the method allows only a very rough description of the service, some other UML diagrams can be used to further specify the functionality of the method, like for example activity diagrams, state machines, sequence diagrams, communication diagrams. Very often a services of a certain organizational entity is implemented using services of other organizational entities. The already mentioned diagrams can also be used in such a situation to describe the service composition. 2.6 Process View The task of the process views is to show, how the data, organizational, and functional views play together, i.e. to describe the whole business process. The UML activity diagram is a very suitable to provide such an overall view. When a business process is modelled, each function from the functional view is described as an action, each data element (input and output parameters of functions) are modelled as object nodes, the associations between functions and the organizational unit performing the function are provided by using partitions and arranging the functions in a certain way, external events triggering or controlling the business process and events generated by the business process are modelled as events, and the flow of control is defined by certain control nodes, like decision, fork and joint nodes. Customer Billing Department Sales Department Order Order Receive Order Process Order Customer Info Pay Bill Bill Send Bill Send Order Close Order Figure 2-6 Process view of a business process Figure 2-6 shows a sample business process with three organizational units, Customer, Billing Department, and Sales Department. The Sales Department provides the services Receive Order, Process Order, Send Order, and Close Order. The data elements used in the process are Order, Bill, and Customer Info. The flow of control is defined by a start node, an end node, a fork node and a joint node. " 3",1" 4 5.,14 6! &

170 !" #$%& ' ( ) * ' +,-",. / ",-" Modularity As stated above, it is important to have different levels of abstraction in each view, i.e. the view within an enterprise and the view spanning multiple enterprises. When modelling with UML the different levels of abstraction can be achieved by using the modularity concepts of UML. In case of the data, organizational, or functional view, it is possible to use the package concept. This means, that parts of the view are grouped in packages, which can be used in a more global view to represent the parts. The use of parts is similar to the use of single classes. In case of the process view, the concept of activities is used. This means, that parts of the process view are grouped in activities, which can be used in a more global view to represent the parts. The use of activities is similar to the use of actions. 2.8 Monitoring of the Process Execution In order to be able to monitor the business process, the monitoring engine needs a detailed description of the process. The key question therefore is, whether the UML 2.0 description of the business process provides enough information. Due to the fact that activity diagrams of the process view allow a very detailed description of the sequences of action, there should be no problem to monitor the process on a higher level. The question how accurate single actions can be monitored depends on the level of detail, which is used to describe the respective services of the organizational entities. As stated above, UML provides certain diagrams for that purpose, for example activity diagrams, state machines, sequence diagrams, communication diagrams. It therefore even seams possible to monitor the process on a detailed level, if the mentioned diagrams are used to specify the functionality of the respective services. 2.9 Automatic Generation of the Process View Compared to the monitoring issue, the task of automatically generating the process view requires an even more detailed description of the other views. UML 2.0 cannot provide such detailed descriptions Tool support UML is a standard in the field of specifying, constructing, visualizing, and documenting the artefacts of a software-intensive system. Therefore, there are many tools that support modeling based on UML. A list of companies that provide such tool can be found under the following URL: This list is by no means exhaustive and is not meant to provide any ranking for any UML tool or company. Currently, the tool support for UML2 is still rather weak and restricted to individual vendors such as Sparxsystems and Omondo (the latter of which provide a UML plug-in for Eclipse). However, it can be expected that tool support for UML 2 will greatly improve over the next 12 to 18 months. Regarding business process modeling, UML tool support in general stays far behind the functionality currently offered i.e. by the ARIS Toolset. Also, it can be argued that pure UML does not provide the type of abstraction level and the basic constructs used by business process modelers as first-class citizens. This limits the usability of UML for business process design to a certain, more technically oriented user community. Recent efforts such as OMG s Business Process Definiton Metamodel [13] tackle this restriction and attempt to provide a more adequate abstraction for business process modelling. However, tool support for BPDM is currently virtually non-existing a state that is likely to change over the next two to three years while the BPDM specification is maturing. In the longterm, UML-based approaches are interesting because they pave the way to the emergence of publicly available open source tools. " 3",1" 4 5.,14 6! #&

171 !" #$%& ' ( ) * ' +,-",. / ",-" Summary and Conclusion To the ATHENA project it is most crucial to be able to model the different views and to have sufficient support for modularity. With UML the data, organizational and functional views can all be modelled with class diagrams. For modelling the process view, activity diagrams are most suitable, especially with all their new features introduced by UML 2.0. Sine class diagrams as well as activity diagrams also support modularity, it can be said that UML 2.0 fulfils basic requirements of ATHENA. UML 2.0 also allows ATHENA to monitor the process execution, since its process view contains a lot of information and since it allows a detailed description of the services of the organizational entities. The last requirement of ATHENA, the automatic generation of the process view, however, is not supported by UML 2.0. Weaknesses of UML are the fact that UML as a general-purpose modeling approach is currently lacking primitives for intuitively describing business processes (BPDM is addressing this) and that the tool support (especially for UML 2) is still rather weak. Still, in the medium to long term, the fact that UML is an extensible open standard maes it attractive for the business process modeling community. As standardization attempts such as BPDM mature, we see a good chance that UML will also become a de-facto standard for business process modeling. " 3",1" 4 5.,14 6! $&

172 !" #$%& ' ( ) * ' +,-",. / ",-" 3 3 References [1] -, Unified Modelling Laguage, 2004, [2] Pan-Wei Ng, Effective business modeling with UML: Describing business use cases and realizations, The Rational Edge, 2003, library/905.html [3] R. Eshuis and R. Wieringa. An execution algorithm for UML activity graphs. In M. Gogolla and C. Kobryn, editors, Proc. UML 2001, Lecture Notes in Computer Science 2185, pages Springer, 2001 [4] R. Eshuis and R. Wieringa. A real-time execution semantics for UML activity diagrams. In H. Hussmann, editor, Proc. Fundamental Approaches to Software Engineering (FASE 2001), Lecture Notes in Computer Science 2029, pages Springer, 2001 [5] R. Eshuis and R. Wieringa. Verification support for workflow design with UML activity graphs. In Proc. International Conference on Software Engineering (ICSE 2002), pages ACM Press, [7] Bernd Oestereich, Christian Weiss, Claudia Schröder, Tim Weilkiens and Alexander Lenhard, Objektorientierte Geschäftsprozessmodellierung mit der UML, dpunkt.verlag, Heidelberg, 2003, [8] Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler and Stefan Queins, UML 2 glasklar, Hanser Fachbuchverlag, 2003, [9] Rob Davis, Business Process Modelling With Aris: A Practical Guide, Springer Verlag, 2001 [10] Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Ivana Trickovic, Sanjiva Weerawarana, Business Process Execution Language for Web Services, Version 1.1, 2003, [11] The OMG: Unified Modeling Language Specification, Version 1.5, [12] The OMG: UML 2.0 Superstructure Specification, [13] Iyengar et al. Business Process Definition Metamodel. Revised Submission to BEI RFP bei/ " 3",1" 4 5.,14 6! &&

173 Programme Integrating and Strengthening the European Research Strategic Objective Networked business and government Integrated Project / Programme Title Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application Acronym ATHENA Project No ATHENA Project Name Cross-Organisational Business Processes ATHEN A - Project No A2 WORKING DOCUMENT WD.A2.1 Annex 6 Title Agent and peer-to-peer technologies in the context of cross-enterprise business processes Authors Dr. Gerd Völksen, Dr. Jörg P. Müller Siemens AG, CT IC 6 Leading Partner: SAP Security Classification: Restricted (RE) October 2004 Version 1.0

174 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Table of Contents TABLE OF CONTENTS... II LIST OF FIGURES...IV 1 ABSTRACT INTRODUCTION Existing Approaches ARIS RosettaNet BPDM Pros and Cons Envisaged Solutions AGENT TECHNOLOGY OVERVIEW Definition of Agent The Agent Community OMG FIPA AgentLink Important Forms of IT Agents Software agents Autonomous agents Interactive agents Adaptive agents Mobile agents Coordinative agents Intelligent agents Wrapper agents Other forms of agents Single versus Multi-agent Systems Status of Agent Technology Overview Current usage of Agents Technologies Currently Being Used Key Issues for Agent Technology Agent Communication Agent Internals Life-Cycle Management Mobility AGENT SYSTEM OVERVIEW JADE/LEAP The Architectural model The Functional model _WDA21_Annex6.doc/ CONFIDENTIAL Page ii / 43

175 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date JADE in the mobile environment The Distributed LEAP Agent Platform Architecture and Technology Cougaar FIPA-OS PEER-TO-PEER TECHNOLOGY OVERVIEW The Pure Peer-to-Peer Approach The "Napster" Approach The Distributed Index Approach PEER-TO-PEER SYSTEM OVERVIEW Gnutella Freenet JXTA Chord Kademlia Tapestry KaZaA/FastTrack Manet Resource Management Framework AGENT- AND PEER-TO-PEER-BASED BUSINESS PROCESS APPROACHES REFERENCES _WDA21_Annex6.doc/ CONFIDENTIAL Page iii / 43

176 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date List of Figures Figure 1: Business Process Value Chain... 2 Figure 2: The Fipa-OS Architecture... 9 Figure 3: Client/Server Architecture... 9 Figure 4: The Pure Peer-to-Peer Approach... 9 Figure 5: The Peer-to-Peer Approach with a Centralized Index Server... 9 Figure 6: The Distributed Index Approach... 9 Figure 7: Resource Retrieval... 9 Figure 8: Gnutella Compared to the Napster Approach... 9 Figure 9: JXTA Communication Architecture... 9 Figure 10: Chord Node References in Fully and Sparsely Populated Rings... 9 Figure 11: Chord Peer Architecture... 9 Figure 12: Kademlia XOR Distances for Nodes 6 and Figure 13: Kademlia Peer Architecture Overview... 9 Figure 14: Tapestry Node Communication Architecture... 9 Figure 15: Tapestry Node Module Architecture... 9 Figure 16: KaZaA / FastTrack P2P Network Topology... 9 Figure 17: RMF-based Peer-to-Peer Architecture _WDA21_Annex6.doc/ CONFIDENTIAL Page iv / 43

177 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Abstract This paper presents an overview on Agent and Peer-to-Peer technology and its usefulness for business processes. Both technologies are suitable for distributed computing in various application domains and are, hence, promising candidates for modeling, executing, and monitoring business processes connecting collaborating companies. The paper further describes the technological basics of both technologies and it lists several representative platforms. Finally, it investigates the current market for business process platforms based on Agent and Peer-to-Peer technologies _WDA21_Annex6.doc CONFIDENTIAL Page 1 / 43

178 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Introduction Business processes are mainly modeled, executed, and maintained by workflow technology. During the past years, various workflow systems had been developed and applied within enterprises in order to automate work coordination and monitoring at a low-cost level. The transition from intra-enterprise to inter-enterprise business processes generates several new challenges in the focus of corporate identity, process adaptation, and technology. While the first two options concern a question of will, the technological aspect is mainly a question of standardization. Provided, partners overcome their traditional competition point of view and, hence, decide to harmonize some their business processes, the primary issue is what parts of the process pool need standardization and how this is achieved. Process Modeling Process Automation Process Monitoring Coordination Platform Communication Platform Figure 1: Business Process Value Chain As the above Figure expresses, the business processes need to be modeled, executed, and monitored on a common coordination platform. Since the processes go beyond the borders of single enterprises, the platform needs to be distributed. 2.1 Existing Approaches There are, of course, platforms, systems, or protocols available, which support business processes. In the following chapters, some of them are briefly discussed ARIS ARIS ( [2]) abbreviates "Architecture for Integrated Information Systems". It provides several different views at an enterprise: data view, functional view, organizational view, external service view, and process view. Main advantages of ARIS are ease of use, a powerful toolset, and good user support. Disadvantages are: no models for collaborative views as process APIs, security protocols, and information transfer channels and services _WDA21_Annex6.doc CONFIDENTIAL Page 2 / 43

179 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date ARIS is useful for modeling enterprise processes within a closed network. It is less well suited for inter-enterprise processes RosettaNet RosettaNet ( [31]) is the result of a standardization initiative including Adobe, BEA, Cisco, Dell, Ericsson, Fujitsu, HP, Hitachi, IBM, Infineon, Intel, Microsoft, Mitsubishi, Motorola, NEC, Nokia, Oracle, PeopleSoft, Qualcomm, SAP, Sharp, Siemens, Sony, Sun, TI, Toshiba, several telecommunication, logistics, and banking companies, and a few universities. RosettaNet defines standards for message and document exchange between collaborating companies. The central component is an XML-based partner interface process. Advantages: RosettaNet provides no proprietary solution. It rapidly enables connections between partners on the communication level. RosettaNet, however, does not support intra-enterprise processes as no APIs to internal processes are supported BPDM BPDM (Business Process Definition Model, [3]) is an Australia-based initiative supported by universities and government departments. BPDM defines meta-models for business process modeling. It applies UML2 elements and adds new ones. The BPDM specs are standardized by OMG. BPDM is just as RosettaNet no proprietary solution. It offers several elements for business process visualization and supports model-based system development. However, BPDM is currently at a premature state Pros and Cons As the examples are specific for either intra-enterprise processes or inter-company messaging or currently not yet in an applicable state, some efforts are needed to collect all mentioned benefits while avoiding the weak points of the mentioned solutions. Though a connector enabling interoperability between ARIS and RosettaNet appears as the easiest solution to achieve, it would still need two totally different systems to be maintained. Even different communication and coordination platforms would operate. Furthermore, such an integration would lack the view at the business process as a whole. 2.2 Envisaged Solutions The intention of this paper is the identification of base technologies for distributed platforms on top of which inter- and intra-enterprise processes can be modeled, run, and monitored. There mainly two approaches followed in this document: Agent technology Peer-to-Peer technology For both of them, technological overviews will be given and several platform examples are described. Additionally, there will be a state-of-the-art survey on the use of these technologies for business processes _WDA21_Annex6.doc CONFIDENTIAL Page 3 / 43

180 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Agent Technology Overview 3.1 Definition of Agent An agent can be a person, a machine, a piece of software, or a variety of other things. The basic dictionary definition of agent is "one who acts". However, for developing IT systems, such a definition is too general: IT-related agents need additional properties. Some of the properties that agents may possess in various combinations include: Autonomous - is capable acting without direct external intervention. It has some degree of control over its internal state and actions based on its own experiences. Interactive - communicates with the environment and other agents. Adaptive - capable of responding to other agents and/or its environment to some degree. More advanced forms of adaptation permit an agent to modify its behavior based on its experience. Sociable - interaction that is marked by friendliness or pleasant social relations, that is, where the agent is affable, companionable, or friendly. Mobile - able to transport itself from one environment to another. Proxy - may act on behalf of someone or something, that is, acting in the interest of, as a representative of, or for the benefit of some entity. Proactive - goal-oriented, purposeful. It does not simply react to the environment. Intelligent - state is formalized by knowledge (i.e., beliefs, goals, plans, assumptions) and interacts with other agents using symbolic language. Rational - able to choose an action based on internal goals and the knowledge that a particular action will bring it closer to its goals. Unpredictable - able to act in ways that are not fully predictable, even if all the initial conditions are known. It is capable of non-deterministic behavior. Temporally continuous - is a continuously running process. Character - believable personality and emotional state. Transparent and accountable - must be transparent when required, yet must provide a log of its activities upon demand. Coordinative - able to perform some activity in a shared environment with other agents. Activities are often coordinated via plans, workflows, or some other process management mechanism. Cooperative - able to coordinate with other agents to achieve a common purpose; nonantagonistic agents that succeed or fail together. (Collaboration is another term used synonymously with cooperation.) Competitive - able to coordinate with other agents, except that the success of one agent implies the failure of others (the opposite of cooperative). Rugged - able to deal with errors and incomplete data robustly. Trustworthy - adheres to Laws of Robotics and is truthful. An industry-standard definition of agent has not yet emerged. Most agree that agents bound for IT systems are not useful without at least the first three of the above properties. Others require IT agents to possess all of the properties listed above to varying degrees. At a minimum, an IT agent is generally regarded to be an autonomous entity that can interact with its environment. In other words, it must be able to perceive its environment through sensors and act upon its environment with effectors _WDA21_Annex6.doc CONFIDENTIAL Page 4 / 43

181 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date The Agent Community The main standardization efforts relevant for agent technology are the OMG viewing agents as extensions of agents, FIPA the standardization organization for agents and the World Wide Web Consortium dealing with negotiation protocols and security aspects. Moreover the Java community process deals with standardizing Java interfaces for agent name services and agent yellow pages OMG The OMG (Object Management Group[29]) is an open membership, non-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications as members. OMG has about 800 large companies in the computer industry and hundreds of smaller ones. Well-known specifications of the OMG include CORBA, OMG IDL, IIOP, and UML. Within the area of agent technology the OMG has two activities: The Mobile Agent Standard (MAF/MASIF) The MASIF standard was published in October 1997 ([26]), triggered by the necessity for interoperability between platforms of different vendors of agent systems, especially in the framework of mobile agents. Interoperability within mobile agent technology can be achieved by standardizing operations like agent transfer, class transfer, and agent management. The standard deals with Mobile Agent System Interoperability Facilities (also called MAF, an acronym for the original proposal, Mobile Agent Facility) allowing interoperability between agent systems written in the same language, but potentially by different companies. The specification is done using MAF-IDL to define the functionality of an agent platform. The standardized aspects are: o o o o o Agent Management Agent Transfer Agent and Agent System Names Agent System Types Location Syntax The Agent Platform Special Interest Grout (Agent PSIG) This SIG started working in September The identified tasks of the Agent Platform Special Interest Group are to extend the OMG Object Management Architecture (OMA) to better support agent technology, to create new OMG specifications or extend existing OMG specifications in the agent area, and to deal with agent modeling techniques like Agent UML to allow a better understanding of how to develop agent based applications. The areas of interest for this PSIG are among others multi-agent systems, agent modeling and specification, agent communication, security aspects within agent systems, mobility of agents and users and ontologies. There is a liaison between FIPA and OMG in order to transfer FIPA specifications to the OMG FIPA The core mission of the Foundation for Intelligent Physical Agents standards consortium (FIPA, [14]) is to facilitate the interworking of agents and agent systems across multiple vendors platforms. This is expressed more formally in FIPA's official mission statement: The promotion of technologies and interoperability specifications that facilitate the end-to-end interworking of intelligent agent systems in modern commercial and industrial settings. Note that the emphasis here is on practical commercial and industrial uses of agent systems. However, FIPA is also focusing on intelligent or cognitive agents, that is, software systems that may have the potential for reasoning about themselves and/or other systems that they encounter. The core message of FIPA is that through a combination of speech acts, predicate logic and public ontologies, it can offer standard ways of interpreting communication between agents in a way that respects the intended meaning of the communication. This is much more ambitious than, for example, _WDA21_Annex6.doc CONFIDENTIAL Page 5 / 43

182 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date XML, which only aims to standardize the syntactic structure of documents. To support this, FIPA has adopted and is working on specifications that range from architectures to support agents' communicating with each other, communications languages and content languages for expressing those messages and interaction protocols, which expand the scope from single messages to complete transactions. In the future, there are plans to extend this even further to cope with longer term relationships between agents. FIPA was formed in 1996 to produce software standards for heterogeneous and interacting agents and agent-based systems. In the production of these standards, FIPA requires input and collaboration from its membership and from the agent s field in general to build specifications that can be used to achieve interoperability between agent-based systems developed by different companies and organizations. FIPA is organized and structured according to two groups; those involved in the production and development of standards and those involved in the support mechanism of FIPA. FIPA undertakes its work at meetings that are held three times a year and also has close working relationships with other standards organizations, such as the Object Management Group (OMG). Architecture Board The FIPA Architecture Board is the authority within FIPA that is responsible for ensuring the consistency, accuracy and suitability of technical work that is being undertaken by FIPA. It is the FIPA Architecture Board s responsibility to oversee the work being undertaken by several Technical Committees. Technical Committees FIPA Technical Committees (TCs) are intended to carry out the technical work of FIPA. Their remit is defined by a work plan that is approved by the FIPA Architecture Board and contains a description of the work that the will undertake for a given period of time. Normally, a TC will either create new specifications and/or modify existing specifications. TCs are created by the FIPA Architecture Board in collaboration with the Board of Directors. To create or modify FIPA specifications, a work plan must be created which details the new specification to create or the modifications to make to existing specifications. This document should be submitted to the work plan reflector for comments and then to the FIPA Architecture Board for approval; the Architecture Board will either reject the work plan, assign it to an existing TC or create a new TC to deal with it. Currently, the following TCs are tasked with work: Ad-Hoc Fixed and mobile devices (such as mobile phones, desktop and pocket PCs) equipped with communication facilities such as Infrared, Bluetooth and Wireless LAN and technologies like Jini and UPnP, make the establishment of ad hoc networks of several devices both possible and increasingly commonplace. TC Ad Hoc s interest lies in ad hoc FIPA, that is, ad hoc networks, which consist of devices running either complete FIPA-compliant agent platforms, fragments of FIPA-compliant platforms or a combination of the two. TC Ad Hoc will either modify relevant existing FIPA Specifications, or create a new specification to ensure that interoperability between FIPA-compliant agent platforms and/or platform fragments can be maintained in ad hoc networks. FIPA has already addressed some of the problems related to wireless communication in the FIPA nomadic Application Support Specification, FIPA Device Ontology Specification, FIPA Message Buffering Service Specification, and FIPA Messaging Interoperability Services Specification. However, further specifications are required to address a number of issues in order to facilitate interoperability between agents operating on different platforms in ad hoc environments. Interaction Protocols The Interaction Protocols TC is working on a roadmap how FIPA should start a second generation of new interaction protocols. Several papers have shown the importance to develop new Interaction Protocols and that for the medium-term future language and protocols will be more agreed and standardized. The IP TC will collect common conversation policies for agents and will define how new In _WDA21_Annex6.doc CONFIDENTIAL Page 6 / 43

183 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date teraction Protocols should be developed. To this the TC tries to answer questions how to recognize more commonly used generic conversations. Other issues to reckon with are the formal semantics for the sequence of messages and the modeling of the Interaction Protocols Methodology This FIPA Technical Committee will focus on the identification of a methodology for developing multi-agent systems. Existing development methodologies have different advantages when applied to specific problems. It is therefore possible that the developer of a MAS would like to use phases or models or elements coming from different methodologies in order to build up a personalized approach for his own problem. In order to reuse contributions coming from existing methodologies we will adopt the method engineering as the referring paradigm. In this context the development methodology is constructed by the developer assembling pieces of the process (method fragments) from a method base. In this way he/she could obtain the best process for his/her specific need/problem. We will take method fragments (the composing elements of the development methodology) from several existing methodologies like: AOR, Cassiopeia, Gaia, Mase, Message, PASSI, Tropos, and so on, if these fragments are coherent with the FIPA architecture. Other novel and specific contributions will be considered as well. Modeling The FIPA Modeling Technical Committee (Modeling TC) was established to develop vendorneutral common semantics, meta-model, and abstract syntax for agent-based methodologies. The Objectives of Modeling TC are as follows: To facilitate advances in the state of the art of agent-based modeling. To enable developers to better understand how to model agent-based applications, including large-scale multi-agent systems. To recommend technology for adoption of common semantics, meta-model, and abstract syntax for agent-based development methodologies. To recommend technology for adoption that enable interoperability across the lifecycle of AUML tools designs/work products. To promote standard modeling techniques that increase rigor and consistency of specifications. To leverage and interoperate with specifications from FIPA and other standards organizations. To liaise with other appropriate organizations Ontologies The Technical Committee for Ontologies is concerned with standardizing methods for knowledge sharing and filtering through ontological representation that allow interoperating systems to automate message processing with respect to cross-referenced semantic classification. The particular focus will be to enable a structured, standardized approach towards the support of multiple ontologies within a content representation and concepts of relationships held within propositional content. Security The objective of the Security Technical Committee is to lead research and development of security for multi-agent and multi-domain agent systems. Security and agent security is a multi-faceted issue that covers (amongst other things): Understanding security requirements & properties of (agent) systems that operate in distributed, dynamic and open services environments Defining how to use agents and their peculiar properties in conjunction with any underlying infrastructure security Addressing a new generation of security issues that arises as automated, dynamic behavior and peer-to-peer interaction becomes more pervasive and as agents are promoted to act on our behalf _WDA21_Annex6.doc CONFIDENTIAL Page 7 / 43

184 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Semantics The Semantics TC is working on a new semantic framework to reflect the needs of verifiability and conformance. In particular, the objective is to adopt or define a semantic framework that can give an account of FIPA s existing CAs and IPs as well as a number of additional constructs such as contracts, agreements, policies, trust, agent descriptions and so on. It is important to note that actually developing the account of all of these is not part or the current effort: it is envisaged that subsequent work plans would address these specific areas. It is envisaged that any new semantic framework would focus on publicly visible behavior of agents and systems; not on internal mental models. Services This TC is concerned with providing more structure and support for services within the FIPA framework. The current notion of services within the FIPA Agent Management specification is too unstructured and does not provide for service composition, which is crucial for expressing service relationships and defining service flows. Since there are many different service models currently available (CORBA, Web Services, DAML- S, etc.), this TC aims to provide a service meta-model in which all of these service models can be expressed and grounded. This meta-model will be described as an extension to the FIPA Abstract Architecture and will be reified in the two prevalent services technologies of Web Services and DAML-S. Finally, this TC will provide an accounting for how current FIPA services can be realized in this metamodel. Special Issue Groups: FIPA for Business Applications The purpose of this SIG is To identify application areas that derive specific benefits from agent technology and FIPA. To identify the core benefits that FIPA offers over current industry practice in these areas and to identify the main challenges to specify/implement FIPA specifications in these areas. To initiate development and alignment of FIPA towards selected application areas. The initial focus of FIPA for Business Applications (F4BA) will be to survey publicly funded research projects to record experiences of using FIPA technology in different research projects, which implement FIPA technology on various application fields. The current F4BA document will form part of the input for that AgentLink AgentLink II is a Network of Excellence for agent based computing funded by the European Commission in the area of Information Society Technologies (IST). According to [1] AgentLink is a coordinating organization for research and development activities in the area of agent based computer systems funded by the European Commission. As such, AgentLink supports a range of activities aimed at raising the profile, quality, and industrial relevance of agent systems in Europe. AgentLink's activities are clustered into different special interest groups, namely on Agent-mediated electronic commerce Methodologies and software engineering for agent systems Intelligent information agents Agent based social simulation Multi-Agent Coordination and Control Intelligent agents for telecommunications applications and telematics Moreover there are special industrial activities to bring universities and industrial partners together to work on some topic. Furthermore AgentLink has established a summer school on agent technology with well-known invited speakers _WDA21_Annex6.doc CONFIDENTIAL Page 8 / 43

185 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Important Forms of IT Agents The agents found in IT systems have special requirements: they must execute as software, hardware, robotics, or a combination of these. Agent developers have identified several forms of agents that are important for IT system development. The list of agent characteristics presented earlier addresses some of these requirements. Additionally, since IT systems have special needs, software- and hardware-related forms must be considered. Those forms considered the most important to agent developers today are discussed below Software agents Software agents are a more specific kind of agent. At a minimum, a software agent is defined as an autonomous software entity that can interact with its environment. In other words, they are agents that are implemented using software. This means that they are autonomous and can react with other entities, including humans, machines, and other software agents in various environments and across various platforms. Basically, software agents are a methodological approach for software development. Tools, languages, and environments can be specifically developed to support the agent-oriented software engineering. However, an agent-oriented design can also be implemented using object-oriented tools, languages, and environments or any other tool, language, and environment that is capable of supporting software entities that are autonomous, interactive, and adaptive. In that sense, agents provide a design pattern including a set of predefined features and functions that implicitly implement agent properties, namely autonomy, interactivity, and adaptivity. Agent-based tools are preferable, primarily because the agent specific functions are inherent in the software rather than explicitly programmed. In other words, object technology can be used to enable agent-based technology, but the autonomous, interactive, and adaptive nature required by agents is not currently supported within OO technology. While these properties can be (and are being) added to the OO approach, the design functions for agents and agent-based software are not fully and directly supported. (Note: From this point on, the term agent will usually mean software agent. While many of the ideas and technology can be generalized to support machines and people, the emphasis in this study will be on software implementation.) Autonomous agents When an agent has a certain independence from external control, it is considered autonomous. Autonomy is best characterized in degrees, rather than simply being present or not. To some extent, agents can operate without direct external invocation or intervention. Without any autonomy, an agent would no longer be a dynamic entity, but rather a passive object such as a part in a bin or a record in a relational table. Therefore, autonomy is considered by the Foundation for Intelligent Physical Agents (see [14]) and the OMG's Agents Working Group (see [30]) to be a required property of agents. Autonomy has two independent aspects: dynamic autonomy and unpredictable autonomy. Agents are dynamic because they can exercise some degree of activity. An agent can have some degree of activity ranging from simply passive to entirely proactive. For example, while ants in the real world are basically reactive, they do exhibit a small degree of pro-activity when they choose to walk, rest, or eat. A supply-chain agent can react to an order being placed, yet be proactive about keeping its list of suppliers up to date. Agents can react not only to specific method invocations but to observable events within the environment, as well. Proactive agents will actually poll the environment for events and other messages to determine what action they should take. (To compound this, many agents can be engaged in multiple parallel interactions with many other agents magnifying the dynamic nature of the agent system.) Agents may also employ some degree of unpredictable (or non-deterministic) behavior. When observed from the environment, an agent can range from being totally predictable to completely unpredictable. For example, a real world ant that is wandering around looking for food can appear to be taking a random walk. However, once pheromones or food are detected, its behavior becomes quite predictable. In contrast, the behavior of a shopping agent might be highly unpredictable. Sent out to _WDA21_Annex6.doc CONFIDENTIAL Page 9 / 43

186 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date choose, negotiate, and buy a birthday present for your mother-in-law, the agent might return with something odd indeed or with nothing at all Interactive agents Interactive agents can communicate with both the environment and other entities and can be expressed in degrees. On one end of the scale, object messages (method invocation) can be seen as the most basic form of interaction. A more complex degree of interaction would include those agents that can react to observable events within the environment. For example, food-gathering ants do not invoke methods on each other; their interaction is indirect through physically affecting the environment. In other words, ants do not receive method invocations; they receive events regarding the state of the environment. Even more complex interactions are found in systems where agents can be engaged in multiple, parallel interactions with other agents. Here, agents begin to act as a society. Finally, the ability to interact becomes most complex when systems involving many heterogeneous agents can coordinate through cooperative and/or competitive mechanisms (such as negotiation and planning). While we can conceive of an agent that cannot interact with anything outside of itself, the usefulness of such an entity for developing agent-based systems is questionable. Therefore, interaction is considered by FIPA and the OMG's Agents Working Group to be a required property of agents Adaptive agents An agent is considered adaptive if it is capable of responding to other agents and/or its environment to some degree. At a minimum, this means that an agent must be able to react to a simple stimulus to make a direct, predetermined response to a particular event or environmental signal. Thermostats, robotic sensors, and simple search bots fall into this category. Beyond the simple reactive agent is the agent that can reason. Reasoning agents react by making inferences and include patient diagnosis agents and certain kinds of data-mining agents. More advanced forms of adaptation include the capacity to learn and evolve. These agents can change their behavior based on experience. Common software techniques for learning are neural networks, Bayesian rules, credit assignments, and classifier rules. Examples of learning agents would be agents that can approve credit applications, analyze speech, and recognize and track targets. A primary technique for agent evolution usually involves genetic algorithms and genetic programming. Here, agents can literally be bred to fit specific purposes. For example, operation plans, circuitry, and software programs can prove to be more optimal that any product that a human can make in a reasonable amount of time. An agent that cannot respond to its environment or to other agents is another kind of agent whose usefulness is questionable for developing agent-based systems. Therefore, adaptation is considered by FIPA and the OMG's Agents Working Group to be a required property of agents Mobile agents While stationary agents exist as a single process on one host computer, mobile agents can pick up and move their code to a new host where they can resume executing. From a conceptual standpoint, such mobile agents can also be regarded as itinerant, dynamic, wandering, roaming, or migrant. The main rationale for mobility is the improved performance that can sometimes be achieved by moving the agent closer to the services available on the new host. For example, if an agent wants to obtain information from several sources on different platforms, it could send information requests to each of the platforms using the equivalent of a remote procedure call (RPC). However, if the volume of information exchanged with the remote site is large, issues of traffic and bandwidth must be considered. Also, the agent might be able to process the remote data more effectively than those services offered at the remote site. In either or both of these cases, relocating the agent to each of the various platforms could be a more efficient way of processing. One disadvantage of such mobility is that the remote sites must provide the CPU cycles to support the mobile agent's processing. This not only brings an additional processing burden to the remote site, it also raises three issues: security, billing the agent for its CPU time, and unanticipated scalability problems _WDA21_Annex6.doc CONFIDENTIAL Page 10 / 43

187 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date The ability of an agent to transport itself from one environment to another is not a requirement for agenthood. Nevertheless, mobility is an important property for many agent-based systems and necessary for a certain class of application Coordinative agents Human organizations exist primarily to coordinate the actions of many individuals for some purpose. That purpose could be to create such structures as profitable business units, charitable organizations, ballet companies, or Little Leagues. Using human organizations as an analogy, systems involving many agents could benefit from the same pattern. Some of the common coordinative agent applications involve supply chains, scheduling, vehicle planning, problem solving, contract negotiation, and product design. Without some degree of coordination, such systems could not be possible-in either human or agent-based systems. Furthermore, the analogy requires that we consider a heterogeneous population of agents. Human organizations are not constructed with a population of identical individuals doing the same thing; instead, we diversify, delegate, negotiate, manage, cooperate, compete, and so on. The same approach needs to be employed in multiple agent systems. Careful consideration should be given to designing and structuring agent-based systems, however. This will increase the likelihood that agents will be coherent in their behavior. While this limits and controls agent spontaneity, it still preserves agentlevel flexibility Intelligent agents After decades, the term intelligent has still not been defined (or understood) for artificial system and applying the term now to agents may not be appropriate. Most tend to regard the term agent and intelligent agent as equivalent. Perhaps this is just an attempt to communicate that agents have more power that conventional approaches. For example, in comparison to relational tables or objects, agents can be thought of somewhat "smarter." Or, it could just be marketing hype. However, it would be fair to say that the notion of intelligence for agents could very well be different than for humans. We are not creating agents to replace humans; instead, we are creating them to assist or supplement humans. A different kind of intelligence, then, would be entirely appropriate. The current wisdom is that whatever the term intelligent agent means, such agents will require a basic set of attributes and facilities. For example, an intelligent agent's state must be formalized by knowledge (i.e., beliefs, goals, desires, intentions, plans, assumptions) and be able to act on this knowledge. It should be able to examine it beliefs and desires, form its intentions, plan what actions it will perform based on certain assumptions, and eventually act on its plans. Furthermore, intelligent agents must be able to interact with other agents using symbolic language. All this sounds like a model of rational human thinking - but we should not be surprised. Once again, agent researchers are using our understanding of how humans think as a model for designing agents. FIPA and the OMG's Agent Working Group do not have a standard definition of intelligent agent. However, the description above provides a general idea of the group's current direction Wrapper agents This agent allows another agent to connect to a non-agent software system/service uniquely identified by a software description. Client agents can relay commands to the wrapper agent and have them invoked on the underlying services. The role provided by the wrapper agent provides a single generic way for agents to interact with non-agent software systems. (Note: the wrapper agent would probably not be necessary for objects, that is, objects should still be able to coexist in the same environment.) The wrapper is considered important by FIPA and the OMG's Agents Working Group. It provides a bridge to legacy code and facilitates the reuse of code for an agent's process, or it transforms a static piece of code into an active processing entity. The legacy code needs to provide an API to be addressed by the wrapper. However, the legacy code is not aware of being applied by an agent, as it is not aware of any of its clients unless the client is requested to identify itself within a specific login or _WDA21_Annex6.doc CONFIDENTIAL Page 11 / 43

188 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date access process. As processing an agent's request, a wrapper can perform more than a one-to-one mapping of the agent language specific request into the API terminology. Moreover, it may map that request into a sequence of probably subsequently depending API calls, and then returns a result, which a regular client needed several calls for. Consequently, enriched agent languages and protocols like contract net or auctions can be applied to legacy code. The wrapper provides a formal description of its wrapped service and behaves towards the multiagent system as if it was the service, while hiding the connection details of the real service. Therefore, the wrapper registers and de-registers at the agent platform specific directories or look-up services just as all other agents do. Depending on the API of the wrapped service, the wrapper can reside on the location of the service or access the service from remote. The latter case holds especially for proprietary service hosts or embedded service software, which do not fit to familiar agent run-time platforms (Java Virtual Machines). The performance of the wrapper depends strongly on the API protocol and its interaction mode. However, synchronous access modes with their related delays can be handled by series of concurrent thread-based calls, which improve the overall throughput. The wrapper may compensate its access duration by the result quality Other forms of agents The kinds of agents listed above are the predominate forms considered for every agent-based system. More detailed examination of an application can identify other forms, such as facilitator agents, broker agents, manager agents, and so on. These forms can be more easily thought as roles that an agent can play rather than the fundamental approach designed into an agent. Agent class Autonomous agents Interactive agents Adaptive agents Mobile agents Coordinative agents Intelligent agents Wrapper agents Domain Polling of events and states, retrieval, processing a multitude of actions, monitoring of systems Distributed dynamic systems: broker bases systems, market-oriented applications, negotiation based systems, resource management systems, heterogeneous systems, multi-agent systems Self-modifying systems, learning systems: broker based systems, user profiling Dynamic, distributed systems, worm-based system, automated software update Multi-agent systems: distributed planning and execution, negotiation based systems, market- oriented systems, resource management systems Knowledge processing: knowledge management, fact and rule processing, fact and rule generation, control of systems in dynamic environment Provision of legacy software, databases, services, applications: integration of existing systems and agents 3.4 Single versus Multi-agent Systems Many of the early commercial agents were developed for information search. Here, individual agents were launched on a tether to gather predefined kinds of information and return them to the human requester. In other words, these agents were solo operations that had very little if any interaction with other agents. Such an approach certainly has its many uses. However, if we look at the human world, such an approach alone could not build the societies or support the organizations that humans have come to enjoy. Instead, we set up networks of people that interact for various purposes. Interaction among agents, then, is not sufficient to build agent societies; we need agents that can coordinate-either through cooperation, competition, or a combination of both. These agent "societies" are called multi-agent systems (MAS) _WDA21_Annex6.doc CONFIDENTIAL Page 12 / 43

189 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Multi-agent systems, then, are systems composed of agents coordinated through their relationships with one another. For example in a kitchen, the toaster "knows" when the toast is done, and the coffeemaker "knows" when the coffee is ready. However, there is no cooperative environment hereonly an environment with single agents. In a multi-agent environment, the kitchen becomes more than just a collection of processors. The appliances would be interconnected in such a way that the coffeemaker and the toaster would ensure that the coffee and toast are ready at the same time. Some points of the rationale for multi-agent systems are as follows: One agent could be constructed that does everything, but fat agents represent a bottleneck for speed, reliability, maintainability, and so on (i.e., there are no omnipotent agents). Dividing functionality among many agents provides modularity, flexibility, modifiability, and extensibility. Specialized knowledge is not often available from a single agent (i.e., there are no omniscient agents). Knowledge that is spread over various sources (agents) can be integrated for a more complete view when needed. Applications requiring distributed computing are better supported by MAS. Here, agents can be designed as fine-grained autonomous components that act in parallel. Concurrent processing and problem solving can provide solutions to many problems that, up until now, we handled in a more linear manner. Agent technology, then, provides the ultimate in distributed component technology. To support multi-agent systems, an appropriate environment needs to be established. MAS environments: provide an infrastructure specifying communication and interaction protocols. are typically open and have no centralized designer or top-down control function. contain agents that are autonomous, adaptive, and coordinative. Clearly, single-agent environments are much simpler, because designers do not have to deal with such issues as cooperation, negotiation, and so on. However, the large-scale requirements of industry necessitate approaches that employ coordination and distribution. As such, FIPA and the OMG's Agents Working Group are focusing primarily on multi-agent systems rather than single agents. 3.5 Status of Agent Technology Overview The emergence of agent technology is similar to the stories many other technologies (e.g. relational, object oriented, GUI). As such, some expect to some of history's lessons to repeat themselves ([6]): Agent technology is not a single, new, emerging technology-but rather the integrated application of multiple technologies. Agents are not necessarily a new, isolated form of application. Instead, it can add a new set of capabilities to existing applications. Initially, agent functions will emerge within applications, but later-with experience-will become part of the operating system or application environment. Agent applications may strengthen the human-computer interaction. Ultimately, applications that do not exploit agent support in the operating system will be severely disadvantaged. While destined for lofty goals, the current state of agent technology is that: It is still an active research area. Isolated pioneer products are emerging. The full set of technologies is not available _WDA21_Annex6.doc CONFIDENTIAL Page 13 / 43

190 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date The technologies are not integrated with one another. There is no consensus on how to support agents at the operating system level Despite the hype, agent technology is not in widespread use nor has it been widely accepted as an inevitable trend. There are early adopters who can demonstrate the value of agent technology Current usage of Agents The telecommunications companies have been the most active in this area, and indeed seem the group most committed to the agent paradigm. Their goal is to use agents to assist in complex system and network management tasks, such as load balancing, failure anticipation, problem analysis, and information synthesis. Mobile agents are particularly useful for dynamic upgrades of embedded system software by pushing or polling mechanisms. Further areas include: Decision and logistic support agents Interest matching agents User assistance agents Organizational structure agents Within these fields, various applications are being realized or planned by using agents: Enterprise applications (goal-oriented enterprise support like smart documents or work-flow, role and personnel management attaching roles and capabilities dynamically to people) Business-to-business applications (marketing and brokering of goods and services, team management) Process control (intelligent buildings like smart heating and cooling, facility security, plant management, robots) Personal agents ( and news filters, personal schedule management and personal automatic secretary as an extension to it) Information management tasks (searching for information, information filtering, information monitoring, data source mediation, interface agents and personal assistance) Nomadic computing applications (supporting the nomadic end user, simplified and faster service deployment, increased availability, reliability and support for disconnections) Technologies Currently Being Used Almost all of the systems being built today are being built with Programming language: Java or C++ Communication language (for communicating agents): KQML or FIPA ACL Represented as strings or XML documents Content language: KIF or SL1 Most mobile agents are moved by using Java serialization 3.6 Key Issues for Agent Technology As mentioned earlier, agent technology requires that agents be autonomous, interactive, and adaptive. To support these properties, the technology to support agents has to address many key issues. The following list is a compression of the OMG Agent Green Paper by [30] _WDA21_Annex6.doc CONFIDENTIAL Page 14 / 43

191 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Agent Communication Agent communication languages: o o o o KQML Arcol and FIPA KIF XML-based Message transportation mechanism o o o o o o CORBA OMG Messaging Services JAVA messaging service RMI DCOM Enterprise Java Beans Events Ontology communication o o o o UML MOF OKBC XML schema Agent interaction protocols o o Electronic Commerce Domain Specifications Community and Collaboration Framework Agent Internals Goal representation and manipulation Adaptation Procedural versus declarative process specifications Comprehension of an environment Life-Cycle Management Virtual existence or persistence History Dynamic and multiple classification Mobility Additional requirements for mobile agents o o o They require an agent server where they can run. They introduce the complexities of security and validating the authenticity of mobile code. They introduce management complexity on such issues as: _WDA21_Annex6.doc CONFIDENTIAL Page 15 / 43

192 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Where are they? How do you communicate with them when they are moving about? How do you bring them home when network failures occur? How do you ensure that they have a reasonable way of "timing out" and halting a process the task is time sensitive? If they must keep functioning despite adversity, how do you ensure they stay alive? o Naming and identification become very important. Adaptation of mobile agents Mobile agents and mobile computers _WDA21_Annex6.doc CONFIDENTIAL Page 16 / 43

193 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Agent System Overview The following table presents a brief overview on agent systems and platforms, their developers, the implementation language, and a very brief description. Product Company Language Description AgentBuilder Reticular Systems, Inc Java Integrated agent and agency development environment AgenTalk NTT/Ishida LISP Multi-agent coordination protocols Agent Building Environment Agent Development Environment IBM C++, Java Environment Gensym Java Environment Agentx International Knowledge Systems Java Agent development environment Aglets IBM Japan Java Mobile agents Concordia Mitsubishi Electric Java Mobile agents DirectIA SDK MASA C++ Adaptive agents Gossip Tryllian Java Mobile agents Grasshopper IKV++ Java Mobile agents Infosleuth MCC Java, Perl, Tk/tcl Cooperative information agent environment IGEN CHI Systems C/C++ Cognitive agent toolkit Intelligent Agent Factory Bits & Pixels Java Agent development tool Intelligent Agent Library Bits & Pixels Java Agent library JACK Intelligent Agents Agent Oriented Software Pty Ltd. JACK Agent Language Environment JADE/LEAP SAG CT Java Intelligent cooperative agents James SAG Portugal Java Mobile agents Jumping Beans Engineering Ad Astra Java Mobile components Kafka Fujitsu Java Agent library LiveAgent AgentSoft Ltd. Java Internet agent construction Microsoft Agent Microsoft Corporation Active X Interface creatures Swarm Swarm Development Group Objective C, Java Multi-agent simulation Versatile Intelligent Agents (VIA) Kinetoscope Java Agent building blocks Voyager Object Space Java Agent-enhanced ORB _WDA21_Annex6.doc CONFIDENTIAL Page 17 / 43

194 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date The following sections will describe the Agent platforms JADE/LEAP, Cougaar, and FIPA-OS in more detail. 4.1 JADE/LEAP JADE ([20]) is the middleware developed by TILAB for the development of distributed multi-agent applications based on the peer-to-peer communication architecture. The intelligence, the initiative, the information, the resources and the control can be fully distributed on mobile terminals as well as on computers in the fixed network. The environment can evolve dynamically with peers that in JADE are called agents, which appear and disappear in the system according to the needs and the requirements of the application environment. Communication between the peers, regardless of whether they are running in the wireless or wireline network, is completely symmetric with each peer being able to play both the initiator and the responder role. JADE is fully developed in Java and is based of the following driving principles: Interoperability JADE is compliant with the FIPA specifications ([14]). As a consequence, JADE agents can interoperate with other agents, provided that they comply with the same standard. Uniformity and portability JADE provides a homogeneous set of APIs that are independent from the underlying network and Java version. More in details, the JADE run-time provides the same APIs both for the J2EE, J2SE and J2ME environment. In theory, application developers could decide the Java run-time environment at deploy-time. Easy to use The complexity of the middleware is hidden behind a simple and intuitive set of APIs. Pay-as-you-go philosophy Programmers do not need to use all the features provided by the middleware. Features that are not used do not require programmers to know anything about them, neither add any computational overhead The Architectural model JADE includes both the libraries (i.e. the Java classes) required to develop application agents and the run-time environment that provides the basic services and that must be active on the device before agents can be executed. Each instance of the JADE run-time is called container (since it contains agents). The set of all containers is called platform and provides a homogeneous layer that hides to agents (and to application developers also) the complexity and the diversity of the underlying tires (hardware, operating systems, types of network, JVM). JADE is compatible with the J2ME CLDC/MIDP1.0 environment. It has already been tested on the fields over the GPRS network with different mobile terminals among which: Nokia 3650, Motorola Accompli008, Siemens SX45, PalmVx, Compaq ipaq, Psion5MX, HP Jornada 560. The JADE run-time memory footprint, in a MIDP1.0 environment, is around 100 KB, but can be further reduced until 50 KB using the ROMizing technique, i.e. compiling JADE together with the JVM. JADE is extremely versatile and therefore, not only it fits the constraints of environments with limited resources, but it has already been integrated into complex architectures such as.net or J2EE where JADE becomes a service to execute multi-party proactive applications. The limited memory footprint allows installing JADE on all mobile phones provided that they are Java-enabled The Functional model From the functional point of view, JADE provides the basic services necessary to distributed peerto-peer applications in the fixed and mobile environment. JADE allows each agent to dynamically discover other agents and to communicate with them according to the peer-to-peer paradigm. From the application point of view, each agent is identified by a unique name and provides a set of services. It can register and modify its services and/or search for agents providing given services, it can control its life cycle and, in particular, communicate with all other peers. Agents communicate by exchanging asynchronous messages, a communication model almost _WDA21_Annex6.doc CONFIDENTIAL Page 18 / 43

195 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date universally accepted for distributed and loosely coupled communications1, i.e. between heterogeneous entities that do not know anything about each other. In order to communicate, an agent just sends a message to a destination. Agents are identified by a name (no need for the destination object reference to send a message) and, as a consequence, there is no temporal dependency between communicating agents. The sender and the receiver could not be available at the same time. The receiver may not even exist (or not yet exist) or could not be directly known by the sender that can specify a property (e.g. all agents interested in football ) as a destination. Because agents identifies each other by their name, hot change of their object reference are transparent to applications. Despite this type of communication, security is preserved, since, for applications that require it, JADE provides proper mechanisms to authenticate and verify rights assigned to agents. When needed, therefore, an application can verify the identity of the sender of a message and prevent actions not allowed to perform (for instance an agent may be allowed to receive messages from the agent representing the boss, but not to send messages to it). All messages exchanged between agents are carried out within an envelope including only the information required by the transport layer. That allows, among others, to encrypt the content of a message separately from the envelope. The structure of a message complies with the ACL language defined by FIPA ([14]) and includes fields, such as variables indicating the context a message refers-to and timeout that can be waited before an answer is received, aimed at supporting complex interactions and multiple parallel conversations. To further support the implementation of complex conversations, JADE provides a set of skeletons of typical interaction patterns to perform specific tasks, such as negotiations, auctions and task delegation. By using these skeletons (implemented as Java abstract classes), programmers can get rid of the burden of dealing with synchronization issues, timeouts, error conditions and, in general, all those aspects that are not strictly related to the application logic. To facilitate the creation and handling of messages content, JADE provides support for automatically converting back and forth between the format suitable for content exchange, including XML and RDF, and the format suitable for content manipulation (i.e. Java objects). This support is integrated with some ontology creation tools, e.g. Protégé, allowing programmers to graphically create their ontology. JADE is opaque to the underlying inference engine system, if inferences are needed for a specific application, and it allows programmers to reuse their preferred system. It has been already integrated and tested with JESS and Prolog. To increase scalability or also to meet the constraints of environments with limited resources, JADE provides the opportunity of executing multiple parallel tasks within the same Java thread. Several elementary tasks, such as communication, may then be combined to form more complex tasks structured as concurrent Finite States Machines. In the J2SE and Personal Java environments, JADE supports mobility of code and of execution state. That is, an agent can stop running on a host, migrate on a different remote host (without the need to have the agent code already installed on that host), and restart its execution from the point it was interrupted (actually, JADE implements a form of not-so-weak mobility because the stack and the program counter cannot be saved in Java). This functionality allows, for example, distributing computational load at runtime by moving agents to less loaded machines without any impact on the application. The platform also includes a naming service (ensuring each agent has a unique name) and a yellow pages service that can be distributed across multiple hosts. Federation graphs can be created in order to define structured domains of agent services. Another very important feature consists in the availability of a rich suite of graphical tools supporting both the debugging and management/monitoring phases of application life cycle. By means of these tools, it is possible to remotely control agents, even if already deployed and running: agent conversations can be emulated, exchanged messages can be sniffed, tasks can be monitored, agent life-cycle can be controlled. The described pieces of functionality, and particularly the possibility of remotely activating (both from code and from console), even on mobile terminals, tasks, conversations and new peers, makes JADE very well suited to support the development and execution of distributed, machine-to-machine, multi-party, intelligent and proactive applications JADE in the mobile environment As already mentioned, the JADE run-time can be executed on a wide class of devices ranging from servers to cell phones, for the latter the only requirement being Java MIDP1.0 (or higher versions). In order to properly address the memory and processing power limitations of mobile devices _WDA21_Annex6.doc CONFIDENTIAL Page 19 / 43

196 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date and the characteristics of wireless networks (GPRS in particular) in terms of bandwidth, latency, intermittent connectivity and IP addresses variability, and at the same time in order to be efficient when executed on fixed network hosts, JADE can be configured to adapt to the characteristics of the deployment environment. JADE architecture, in facts, is completely modular and, by activating certain modules instead of others, it is possible to meet different requirements in terms of connectivity, memory and processing power. More in details, a module called LEAP allows optimizing all communication mechanisms when dealing with devices with limited resources and connected through wireless networks. By activating this module, a JADE container is split into a front-end, actually running on the mobile terminal, and a back-end running in the fixed network. A proper architectural element, called mediator, must be already active and is in charge of instantiating and holding the back-ends (that basically are entries in the mediator itself). To face workload problems it is possible to deploy several mediators each one holding several back-ends. Each front-end is linked to its corresponding back-end by means of a permanent bi-directional connection. It is important to note that there is no difference at all for application developers depending on whether an agent is deployed on a normal container or on the front-end of a split container, since both the available functionality and the APIs to access them are exactly the same. The approach has a number of advantages: Part of the functionality of a container is delegated to the back-end, thus making the front-end extremely lightweight in terms of required memory and processing power. The back-end masks, to other containers, the actual IP address assigned to the wireless device and, among the others, allows hiding to the rest of the multi-agent system a possible change of IP address. The front-end is able to detect a loss of connection with the back-end (for instance due to an out of coverage condition) and re-establish it as soon as possible. Both the front-end and the back-end implement a store-and-forward mechanism: messages that cannot be transmitted due to a temporary disconnection are buffered and delivered as soon as the connection is re-established. Several information that containers exchange (for instance to retrieve the container where an agent is currently running) is handled only by the back-end. This approach, together with a bitefficient encoding of communications between the front-end and the backend, allows optimizing the usage of the wireless link The Distributed LEAP Agent Platform Architecture and Technology The agent platform JADE was enhanced and modified to form LEAP (Lightweight Extensible Agent Platform, [25]). It was the first FIPA-compliant agent platform running on small mobile devices such as PDAs and mobile phones. The resulting JADE / LEAP platform is a useful step on the way to build suitable middleware and services for Ambient Intelligence. The LEAP development activity focused on restructuring the JADE core, compliant to Java 2 Standard Edition (J2SE), in order to match the LEAP requirements: To be lightweight enough to be deployed on small devices, such as mobile phones, supporting only a KVM with J2ME/CLDC instead of a standard JVM. That was realized by porting JADE containers to the limited KVM functionality. For instance, several classes and also the serialization mechanism had to be replaced by own mechanisms. Further techniques for reducing the storage requirement were: profiling, buffer size reduction, optimized string comparison, additional explicit garbage collection calls, and obfuscation of class identifiers. Finally romizing the code into the KVM reduced the heap memory by another 30%. Finally, LEAP version V1.0 required 27 Kbytes heap size and ran on mobile phones and palm size computers. To have a transport layer supporting transport protocols suitable also for wireless environments. The RMI-based LEAP intra-platform communication was replaced by our own transport protocol. The communication was extended (e.g. by a mediator to keep HTTP connections open) so that containers could communicate over GPRS and WLAN _WDA21_Annex6.doc CONFIDENTIAL Page 20 / 43

197 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date To be extensible such that, when deployed on a powerful machine, LEAP can provide optional functionality such as agent mobility and management GUIs. That was done by a restructuring of the JADE platform into mandatory and optional components. The platform was subsequently extended in order to work more efficiently in Ad hoc and P2P networks. By using e.g., a JXTA based service search instead of the DF, robustness of the platform could be improved. Bluetooth-based communication for short-range scenarios was added. 4.2 Cougaar Cougaar ([8]) is an Agent platform targeted at large-scale, distributed agent systems with focus on logistics. It has been developed over three years and has now a very elaborate working model. Cougaar has so much substance and therefore has a rather complicated setup that it could not be tested for this study. The evaluation is based on the papers provided with it. Cougaar (Cognitive Agent Architecture) is a blackboard architecture based agent system written in Java. Its development was funded by the US government, and it is now open source. It uses the concepts of tasks and resources. Tasks can be decomposed, performed directly, or delegated to another agent. These three options are provided by plug-ins, which extend Cougaar with domain specific functionality. Cougaar is an innovative software architecture that enables building distributed agent-based applications in a manner that is powerful, expressive, scalable and maintainable. In fact, Cougaar is a code baseline that has successfully demonstrated its utility at constructing dynamic, complex, distributed applications. Perhaps of even more significance than the software that implements its concepts, Cougaar represents a methodology, a tried and powerful approach towards designing and building distributed applications. Cougaar was developed for DARPA (Defense Advanced Research Projects Agency) under the Advanced Logistics Program or ALP. The architecture was developed by ALPINE, a consortium currently composed entirely of BBN Technologies, over a period starting in 1996 until Cougaar development and maintenance was then continued by BBN under a new DARPA program, Ultra*Log, over a period starting in 2001 until The focus of the Advanced Logistics Project has been to develop techniques to better capture and solve the difficult problems of military logistics planning and execution. The scope and complexity of the problem of military logistics is tremendous: Millions of different object types to be managed Tens of thousands of different interleaved discrete business processes Thousands of different organizations with their own physical plants, constraints and user requirements Complex, continual interplay between planning and execution Over a thousand legacy databases and systems with different data models and protocols The focus of Ultra*Log has been to make the Cougaar platform survivable, that is, to enhance the Cougaar platform with components offering: Robustness: A Cougaar application should survive the loss of any individual components and/or hardware substrate with minimal loss of functionality. This includes automatic recovery of lost agents, as well as various mechanisms to conserve resources and to use redundancies efficiently. Security: A Cougaar application should be capable of repelling various sorts of electronic attacks, should maintain information integrity, and should avoid exposing communications as much as possible. Scalability: The Cougaar infrastructure should not have any intrinsic scalability issues. It should be possible to implement Cougaar applications, which scale to the degree that the application logic allows. Standard software modeling techniques have proven inadequate to tackle a problem of this size _WDA21_Annex6.doc CONFIDENTIAL Page 21 / 43

198 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date and complexity. Standard software tools are unable to manage an ontology of so many distinct object types. The complexity of developing a standard top-down decomposition of the aggregate business processes involved defies monolithic modeling. Further, the interdependencies among different aspects of the model would tend to make such a model unmaintainable. Logistics systems have tended to treat planning and execution as entirely different realms, with different systems and architectures, due to the potentially chaotic feedback that execution can play on any plan. Cougaar was developed to tackle these challenges posed by the problems of military logistics head-on. But Cougaar is an approach to building software that transcends the domain of military logistics. Many complex domains can benefit from the approaches pioneered and embodied in Cougaar. While Cougaar was developed to handle a problem with all the complexities listed above, it is of potential value in any domain bearing any of the above complexities. For example, any of the following problem categories would benefit from being modeled in Cougaar: Problem domains that entail hierarchical decomposition and tracking of complex tasks Complex application domains involving integration of distributed separate applications and data sources Domains involving the generation and maintenance of dynamic plans in the face of execution Highly parallel applications with relatively loose-coupling and low-bandwidth communications between parallel streams Domains too complex to model monolithically, best modeled by emergent behavior of components We should note that while Cougaar was designed to address the requirements of military logistics planning, we have seen applications of Cougaar to many different domains some only tangentially related to military logistics, others completely separate. Nonetheless, this document will contain a flavor of military logistics in many of its examples and illustrations, as this is the domain to which Cougaar has been applied most broadly and successfully. It is important to keep in mind that the Cougaar technology is a domain independent architecture for large-scale distributed agent systems. 4.3 FIPA-OS FIPA-OS ([13]) is an open source implementation of the mandatory elements contained within the FIPA specification for agent interoperability. In addition to supporting the FIPA interoperability concepts, FIPA-OS also provides a component-based architecture to enable the development of domain specific agents that can utilize the services of the FIPA Platform agents. The primary aim of FIPA-OS is to reduce the current barriers in the adoption of FIPA technology by supplementing the technical specification documents with managed open source code. It has already been seen that the quality and functionality of this source code will improve by managing its evolution in the public domain, providing mutual benefit to all adopters and enabling progress in the agent paradigm. Developers using FIPA-OS are encouraged to provide extensions, bug fixes and feedback to help improve the planned future releases. FIPA-OS has been implemented using Java 1.2, and the distribution contains class and source files and documentation. It also includes simple test agents to access the agent platform services and some visualization software. Currently, a JDK 1.1 version of FIPA-OS is also available. FIPA-OS handles the initial bootstrapping required to enable agents on multiple, potentially heterogeneous, FIPA Agent Platforms to interoperate via the use of a web server. The ACC included in the current FIPA-OS distribution uses the web servers that it knows about to obtain the required MTP (Message Transport Protocol) addresses for the initial platforms with which it requires interoperability. The interaction with the web servers is performed at start-up only and not when each message is routed to a remote Agent Platform. In the situation where the ACC has to be restarted it uses an inform message to notify all known ACCs of its new MTP addresses. Likewise, the ACC assumes that remote ACCs will notify it of their new MTP addresses should they be changed due to them being reinitialized. High Level Architecture _WDA21_Annex6.doc CONFIDENTIAL Page 22 / 43

199 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date FIPA-OS is a component-orientated toolkit for constructing FIPA compliant Agents using mandatory components (i.e. components required by ALL FIPA-OS Agents to execute), components with replaceable implementations, and optional components (i.e. components that a FIPA-OS Agent can optionally use). The Figure below highlights the available components and there relationship with each other. Figure 2: The Fipa-OS Architecture The Database Factory, Parser Factory and CCL components are optional and do not have an explicit relationship with the other components within the tool-kit. The Planner Scheduler generally has the ability to interact with all components of an Agent, although not necessarily vice versa. MicroFIPA-OS is an embedded version which implements parts of the FIPA standard _WDA21_Annex6.doc CONFIDENTIAL Page 23 / 43

200 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Peer-to-Peer Technology Overview The Peer-to-Peer paradigm will be the upcoming technology for distributed computing. In contrast to closed systems based on Client/Server approaches, peers are treated as equal. A peer may provide both client and server functions and may act as both a consumer and provider of resources. What had been concentrated on servers will then be distributed among several peers. However, the distribution is not deterministic. A Peer provides a subset of all available functions only, while the full set of functions is available from the peer network as a whole. With features like replication and load balancing, peer networks are flexible and robust in managing and providing resources 1. Consequently, Peer-to-Peer systems gain several advantages compared to Client/Server architectures. The most important features Peer-to-Peer platforms need to provide are the strong points of server systems: Central point of control and administration State-of-the-art security management Scalability by well-known methods Rapid resource access by means of look-up support Business model based on central policies (e.g. based on session, time, or volume; billing and charging) These advantages inherently contain weaknesses of Client/Server architectures: Central point of failure implies requirements for high availability Restricted freedom for users due to provider control Client Client Client Server (Look-up Index) Resources Figure 3: Client/Server Architecture Though Client/Server architectures still have a necessity to exist and serve perfectly for a certain class of system, there is a different class of systems arising these days. These are characterized by: Huge number of resources Huge number of users 1 In the following, the term "resource" designates memory space and computing power provided by the computing system, but also data and services or applications provided to users _WDA21_Annex6.doc CONFIDENTIAL Page 24 / 43

201 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date High flexibility due to fluctuation of users and resources Centrally administrated systems are sometimes overstrained to fulfill these requirements. Therefore, the basic idea is to distribute the resources into the network. The following sections show a classification of Peer-to-Peer approaches. 5.1 The Pure Peer-to-Peer Approach The first approach was a purely distributed system. According to that, the network of peers hosts resources in some non-deterministic way. Though users are sure that resources are available, it is not right clear where to find them as the central look-up index has been dropped. Gnutella is a familiar example of a pure Peer-to-Peer platform. Peer Resource Peer Peer Resource Figure 4: The Pure Peer-to-Peer Approach Advantages of this approach are: No expenses for server acquisition and maintenance No central point of failure Highest level of freedom for users However, this approach also includes some disadvantages, as some significant characteristics are lost. The main reason is that resources need a look-up before they can be used. Without a look-up index, all peers need to be asked for a certain resource since it is not fixed when and where peers are present and, hence, resources hosted by them are available for use. Consequently, the network has to be scanned for a resource, which is achieved by a flooding or broadcast mechanism. Therefore, the efforts for look-ups grow with the number of peers in the network in a super-proportional way. Difficult to scale, flooding of the network implied Inefficient use of network resources (cables, routers, ) No supervision of content Unresolved security problems No business model It is mainly the security gap, which makes pure Peer-to-Peer systems not really suitable for professional usage as peers may come and go randomly. Furthermore, a unique view of the peer network is impossible and the kind of content is out of control of any instance. Though pure Peer-to-Peer systems are useful from the academic point of view in order to learn about communication protocols, no real business in open networks is possible _WDA21_Annex6.doc CONFIDENTIAL Page 25 / 43

202 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date The "Napster" Approach The most well-known Peer-to-Peer system was Napster and caused by the Napster success, Peer-to-Peer gained a negative taste in the entertainment business community while it was appreciated by the music consumers. Under a technological point of view, Napster was no real Peer-to-Peer platform, but it managed to overcome some of the disadvantages of the pure Peer-to-Peer systems. The basic Napster idea was to install a resource look-up index on a central server, which helped users to identify the particular peers where desired resources especially MP3 files are located. Peer Resource Peer Server Look-up Index Peer Resource Figure 5: The Peer-to-Peer Approach with a Centralized Index Server Still, resources are distributed and also replicated as several users may host several equivalent resources on their machines. The main functions were registration of and query for a resource at the index server. Therefore, users can retrieve and find references to related peers hosting the record copies. The exchange of the resources proceeded directly among the peers in a mutual manner. The advantages of the Napster approach are. Relatively straight forward to scale Central supervision of content feasible Business model possible (advertising) Reduced (but not minimized) server costs Efficient registration and retrieval Still disadvantages exist: Central point of failure Restricted freedom for users through provider control Server(s) for hosting the look-up index still required _WDA21_Annex6.doc CONFIDENTIAL Page 26 / 43

203 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date The Distributed Index Approach As on the one hand, a central server for the look-up index is a weak point but, on the other hand, no index server implies flooding of the network, the basic idea to overcome this dilemma is to distribute and replicate the look-up index, as well. Peer Index Peer Ressource Ressource Peer Index Figure 6: The Distributed Index Approach While the main question "Where do I find a desired resource?" is easy to answer when the related index entry is found, distribution of the look-up index prepends a further question: "Where do I find the index entry that references a desired resource?" The solution is Distributed Hash Table (DHT). Hash functions are chaotic functions that map any data randomly into an integer range [0,, N-1]. To retrieve a resource from a peer network applying a distributed index approach, the following steps have to be executed: Calculate a peer identifier from a resource specification using a hash function. The resource specification may be a list of keywords describing the desired resource. The peers are supposed to host resource descriptions that are close to the resource specification. Query the identified peers for resource descriptors matching the resource specification, and for related resource hosting peers. Receive a list of identifiers of peers hosting resources and matching resource descriptors. Query the resource hosting peers for the resources related to the resource descriptors. Receive the desired(?) resources. Open questions arise from this brief description regarding the assignment of peer identifiers, the model of resource specifications and resource descriptors, and the connection technique between the peers. However, the Figure below gives a graphical taste of the protocol for resource retrieval _WDA21_Annex6.doc CONFIDENTIAL Page 27 / 43

204 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date My peer Hash functions Indexhost1 Indexhost2 Resourcehost1 Resourcehost2 {Keyword1, Keyword2} {Indexhost1, Indexhost2} {Keyword1, Keyword2} {Keyword1, Keyword2} Resourcehost1, ResourceDescr1 Resourcehost2, ResourceDescr2 ResourceDescr1 ResourceDescr2 Resource1 Resource2 Figure 7: Resource Retrieval An equivalent protocol is needed to store resources into the peer network. In this case, there has to be some additional calculations to gain replication of both the resource descriptors with the identifiers of the resource hosting peers and the resources themselves. Especially, it is not required to store and replicate the resources into the network. Sometimes it is more desirable keep the resource at the owner's peer while just replicating the resource descriptor. The protocols for storing and retrieving resources will turn simpler in this special case. Advantages of the distributed index approach are: Well scaling, without network flooding No server costs High level of freedom for the users No central point of failure Central control of peers and content in closed (corporate) networks. Still there are some weak points to mention: Security problems are still unsolved _WDA21_Annex6.doc CONFIDENTIAL Page 28 / 43

205 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Difficult to create a business model This approach still leaves freedom to the platform designers with respect to the selection of index and resource hosting peers, hashing, and functional extensions and features for security and replication. The following Chapter presents some well-known Peer-to-Peer platforms with various characteristics as described in the above classification _WDA21_Annex6.doc CONFIDENTIAL Page 29 / 43

206 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Peer-to-Peer System Overview According to the Peer-to-Peer technology overview, this Chapter will focus on DHT-based Peerto-Peer platforms only. The peer-to-peer systems listed below are briefly presented in the following subchapters: Gnutella Freenet JXTA Chord Kademlia Tapestry KaZaA / FastTrack Manet RMF 6.1 Gnutella Once free access to the Napster servers collapsed, people researched other methods of file sharing such as Napigator, which scoured the Internet for underground servers. But these often turned out to have very low user population, poor bandwidth and be ill administered with a tendency to crash. The Gnutella protocol ([18]) was created as a way around this. Instead of initially knowing where to send its requests for file queries (i.e. to the server), it queries other users that are using the protocol around it who respond as to whether they have the file and then pass the request along to the next user. Once an IP address of the best person that has the file is selected then a direct connection between the two can be made. Kelly Truelove ([35]) states that the two main types of outgoing/incoming messages are: - The broadcast transmission of queries across transient sites and the routing back of responses. The broadcast transmission of "is anybody out there?" pings and the routing back of "I'm here" responses. HTTP is used for the file transfer essentially allowing computers to participate as servers. Peers act as web-site servers that can be connected to directly after the discovery of their IP address. Another comparison is that they work like a search engine, which hunts out dynamic content that may disappear in 5 minutes or 5 days. Other uses of Gnutella (besides mp3 hunting) take advantage of its up-to-the-minute snapshot of the content on the web. Systems like search-engines can be deployed using it at their heart _WDA21_Annex6.doc CONFIDENTIAL Page 30 / 43

207 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Figure 8: Gnutella Compared to the Napster Approach 6.2 Freenet While Freenet ([15]) comprises no search mechanisms but rather concentrates on aspects such as anonymity of publishers and consumers of information and resilience against censorship, it is often quoted as an inspiration to the systems based on distributed hash tables. Every peer in Freenet provides some space for data storage (the data store). A key is assigned to every dataset published in Freenet and recorded in the data store along with the encrypted information itself and the address of the peer it was received from. To store or access data in Freenet, every query has to be assigned a key. Every peer inspects its data store upon reception of a query to determine the address of the peer associated with the stored key that is (numerically) closest to the key of the query. It then forwards the query to this peer. In case the target of the query can not be reached using this route, an error message is propagated back to the peer that chooses the route associated to the second closest matching key and so on. Instead of flooding the network, only a single message is propagated through the network to access a resource, following a depth first search strategy always using the route most likely leading to the destination. The data transmitted through Freenet is stored along the path of a request while older information is removed from a peer's data store using a "least recently used" strategy. This mechanism ensures that information moves through the network towards regions of more frequent requests for a particular set of data. The multihop propagation of actual data is chosen for privacy reasons and results in an increased amount of network traffic and access latencies. On the other hand, the mechanisms of Freenet show strong self-organizational properties that lead to optimized path lengths to access certain data as it is replicated towards the origin of requests. 6.3 JXTA JXTA ([22]) has been created to address short comings of current peer-to-peer systems, Li Gong describes the main features as being:- Interoperability: Easily locate and connect peers through different mediums and systems. Platform Independence: Classless and independent from programming languages such as Java or C and from Operating systems such as Windows orlinux _WDA21_Annex6.doc CONFIDENTIAL Page 31 / 43

208 IP- Project ATHENA IP- Project - No ATHENA - Project Cross-Organisational Business Processes ATHENA - Project Number A2 Document Working Document WD.A2.1 Annex 6 Date Ubiquity: For use on range of digital devices such as PC s, PDA s, routers and servers. At its core it is actually several protocols, but works roughly the same way as Gnutella by establishing connections to nearby peers that have advertised their availability. Other ways include:- LAN-based discovery: A broadcast over a LAN requests a response from other peers to register with. Discovery through invitation: An already registered member can invite new peers to join the connection. Cascaded discovery: Discovering one peer can lead to proxy connection to other peers. Discovery via rendezvous points: Like the traditional server that knows where some connected peers are. So basically a starting point if all else fails. But although it has been designed with less emphasis on file searching and more on the low level protocols for applications, it can be used for this. The messages that are sent around peers are formed into XML messages. So any application will need some kind of a built-in XML encoder and parser to read and create JXTA packets. Wireless systems PDA s and possibly mobile phones will use suns own MicroXML which can understand and create simple tags. Because the coding has been very versatile, the XML encoder/parser can easily be replaced with an emerging technology s encoder/parser, should xml become obsolete. Figure 9: JXTA Communication Architecture 6.4 Chord Chord ([9]) is a pure P2P lookup protocol for the Internet. Its only function performs a mapping from abstract peer identifiers to IP addresses. Just as other P2P systems, Chord uses the random selection of peer IDs forming the overlay network. A peer ID is fixed for a peer once it has been selected. Consequently, IP addresses may change caused by DHCP whenever a peer hooks into the _WDA21_Annex6.doc CONFIDENTIAL Page 32 / 43