Enterprise Interoperability III: New Challenges and Industrial Approaches

Enterprise Interoperability III Kai Mertins • Rainer Ruggaber • Keith Popplewell Xiaofei Xu Editors Enterprise Inter...

Author: Kai Mertins | Kai Mertins | Rainer Ruggaber | Keith Popplewell | Xiaofei Xu

87 downloads 1715 Views 9MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Enterprise Interoperability III

Kai Mertins • Rainer Ruggaber • Keith Popplewell Xiaofei Xu Editors

Enterprise Interoperability III New Challenges and Industrial Approaches

123

Editors Professor Dr.-Ing.Kai Mertins Fraunhofer IPK Pascalstraße 8–9 10587 Berlin Germany

Dr. Rainer Ruggaber SAP AG Vincenz-Prießnitz-Straße 1 76131 Karlsruhe Germany

Professor Keith Popplewell Future Manufacturing Applied Research Centre Coventry University Priory Street Coventry CV1 5FB UK

Professor Xiaofei Xu School of Computer Science and Technology Harbin Institute of Technology 92 West Da-Zhi Street Harbin P.R. China

ISBN 978-1-84800-220-3

e-ISBN 978-1-84800-221-0

DOI 10.1007/978-1-84800-221-0 British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library Library of Congress Control Number: 2008922193 © 2008 Springer-Verlag London Limited Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms of licences issued by the Copy-right Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. The use of registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made. Printed on acid-free paper 9 8 7 6 5 4 3 2 1 springer.com

Preface Kai Mertins1, Rainer Ruggaber2, Keith Popplewell3 and Xiaofei Xu4 1

2

3

4

Fraunhofer IPK Berlin, Pascalstr. 8-9, 10587 Berlin, Germany General Chairperson of I-ESA’08 [email protected] SAP AG, Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe, Germany General Co-Chairperson of I-ESA’08 [email protected] Future Manufacturing Applied Research Centre, Coventry University, Priory Street, Coventry, CV1 5FB, UK Chairperson of I-ESA’08 International Programme Committee [email protected] School of Computer Science and Technology, Harbin Institute of Technology, 92 West Dayhi Street, Harbin, P.R. China 150001 Co-Chairperson of I-ESA’08 International Programme Committee [email protected]

Interoperability in the context of enterprise applications is the ability of a system or an organisation to work seamless with other systems or organisation without any special effort. The capability to interact and exchange information both internally and with external organisations (partners, suppliers, customers) is a key issue in the global economy. It is fundamental in order to speed up production of goods and services at lower cost, while ensuring higher levels of quality and customisation. Despite the fact of many efforts spend in the past decade to overcome interoperability barriers in the industry non interoperability cause an enormous cost for all business partners. Studies show: More than 40 % of IT-costs are devoted to solve interoperability problems. This book provides knowledge for cost savings and business improvement as well as new technical solutions. I-ESA'08 (Interoperability for Enterprise Software and Applications) is the fourth of a series of conferences, this time under the motto "Science meets Industry". The I-ESA’08 Conference was organised by Fraunhofer IPK and DFI (Deutsches Forum für Interoperabilität e.V.) jointly promoted by the INTEROPVLab (European Virtual Laboratory for Enterprise Interoperability - www.interopvlab.eu) and the EIC (Enterprise Interoperability Centre - www.eiccommunity.org). World's leading researchers and practitioners in the area of Enterprise Interoperability contributed to this book. You will find integrated approaches from different disciplines: Computer Science, Engineering and Business Administration.

vi

Preface

The structucture of this book Enterprise Interoperability III: New Challenges and Industrial Approaches was inspired by the ATHENA Interoperability Framework. The House of Enterprise Interoperability is designed top-down from Business to Process and Service Execution aligned with the important topics for Semantics and Ontology’s. Common basis of the levels are the aspects of Systems Engineering, Modelling as well as Architectures and Frameworks.

Business & Strategies, Cases Cross Organisational Collaboration and Cross Sectoral Processes Service Design and Execution

Ontology’s and Semantics for Interoperability Interoperability in Systems Engineering Modelling and Meta Modelling Methods and Tools for Interoperability Architectures and Frameworks for Interoperability Fig.: Enterprise Interoperability House of I-ESA’08

Kai Mertins, Berlin Rainer Ruggaber, Karlsruhe Keith Popplewell, Coventry Xiaofei Xu, Harbin January 2008

Acknowledgements

We like to thank all the authors, invited speakers, reviewers, Senior Programme Committee members, and participants of the conference that made this book a reality and the I-ESA'08 a success. We express our gratitude to all organisations which supported the I-ESA'08 preparation especially Interop V-Lab and its German Pole DFI as well as the Enterprise Interoperability Centre. We are deeply thankful to the local organisation support notably Thomas Knothe, Amparo Roca de Togores, Anett Wagner, Sebastian Zabre and Nikolaus Wintrich for their excellent work for the preparation and the management of the conference.

Contents

Part I - Business and Strategies, Cases An Approach for the Evaluation of the Agility in the Context of Enterprise Interoperability S. Izza, R. Imache, L. Vincent, and Y. Lounis ...........................................................3 Industrialization Strategies for Cross-organizational Information Intensive Services Ch. Schroth.............................................................................................................15 SME Maturity, Requirement for Interoperability G. Benguria, I. Santos ............................................................................................29 Information Security Problems and Needs in Healthcare – A Case Study of Norway and Finland vs Sweden R.-M. Åhlfeldt and E. Söderström...........................................................................41 Impact of Application Lifecycle Management – A Case Study J. Kääriäinen, A. Välimäki .....................................................................................55 Part II - Cross-organizational Collaboration and Cross-sectoral Processes A Service-oriented Reference Architecture for Organizing Cross-Company Collaboration Ch. Schroth.............................................................................................................71 Patterns for Distributed Scrum – A Case Study A. Välimäki, J. Kääriäinen .....................................................................................85 Understanding the Collaborative Workspaces G. Gautier, C. Piddington, and T. Fernando..........................................................99 Models and Methods for Web-support of a Multi-disciplinary B2(B2B) Network H. Weinaug, M. Rabe ...........................................................................................113

x

Contents

Platform Design for the B2(B2B) Approach M. Zanet, St. Sinatti ..............................................................................................125 Trust and Security in Collaborative Environments P. Mihók, J. Bucko, R. Delina, D. Palová ............................................................135 Prototype to Support Morphism between BPMN Collaborative Process Model and Collaborative SOA Architecture Model J. Touzi, F. Bénaben, H. Pingaud.........................................................................145 Heterogeneous Domains’ e-Business Transactions Interoperability with the use of Generic Process Models S. Koussouris, G. Gionis, A. M. Sourouni, D. Askounis, K. Kalaboukas..............159 Matching of Process Data and Operational Data for a Deep Business Analysis S. Radeschütz, B. Mitschang, F. Leymann............................................................171 Methods for Design of Semantic Message-Based B2B Interaction Standards E. Folmer, J. Bastiaans ........................................................................................183 Part III - Service Design and Execution An Adaptive Service-Oriented Architecture M. Hiel, H. Weigand, W.-J. Van Den Heuvel .......................................................197 FUSE: A Framework to Support Services Unified Process N. Protogeros, D. Tektonidis, A. Mavridis, Ch. Wills, A. Koumpis ......................209 Adopting Service Oriented Architectures Made Simple L. Bastida, A. Berreteaga, I. Cañadas..................................................................221 Making Service-Oriented Java Applications Interoperable without Compromising Transparency S. De Labey, E. Steegmans ...................................................................................233 A Service Behavior Model for Description of Co-Production Feature of Services T. Mo, X. Xu, Z. Wang ..........................................................................................247 An Abstract Interaction Concept for Designing Interaction Behaviour of Service Compositions T. Dirgahayu, D. Quartel, M. van Sinderen .........................................................261 Preference-based Service Level Matchmaking for Composite Service Y. Shiyang, W. Jun, H. Tao...................................................................................275 Ontological Support in eGovernment Interoperability through Service Registries Y. Charalabidis.....................................................................................................289 Towards Secured and Interoperable Business Services A. Esper, L. Sliman, Y. Badr, F. Biennier.............................................................301

Contents

xi

Part IV - Ontologyies and Semantics for Interoperability Semantic Web Services based Data Exchange for Distributed and Heterogeneous Systems Q. Wang, X. Li, Q. Wang......................................................................................315 Ontology-driven Semantic Mapping D. Beneventano, N. Dahlem, S. El Haoum, A. Hahn, D. Montanari, M. Reinelt..329 Self-Organising Service Networks for Semantic Interoperability Support in Virtual Enterprises A. Smirnov, M. Pashkin, N. Shilov, T. Levashova ................................................343 Semantic Service Matching in the Context of ODSOI Project S. Izza, L. Vincent .................................................................................................353 Ontology-based Service Component Model for Interoperability of Service Systems Z. Wang, X. Xu......................................................................................................367 Supporting Adaptive Enterprise Collaboration through Semantic Knowledge Services K. Popplewell, N. Stojanovic, A. Abecker, D. Apostolou, G. Mentzas, J. Harding.............................................................................................................381 Part V - Interoperability in Systems Engineering Semantic Web Framework for Rule-Based Generation of Knowledge and Simulation of Manufacturing Systems M. Rabe, P. Gocev................................................................................................397 Semantic Interoperability Requirements for Manufacturing Knowledge Sharing N. Chungoora, R.I.M. Young ................................................................................411 Collaborative Product Development: EADS Pilot Based on ATHENA N. Figay, P. Ghodous ...........................................................................................423 Contribution to Knowledge-based Methodology for Collaborative Process Definition: Knowledge Extraction from 6napse Platform V. Rajsiri, A-M. Barthe, F. Bénaben, J-P. Lorré, H. Pingaud..............................437 SQFD: QFD-based Service Quality Assurance for the Lifecycle of Services S. Liu, X. Xu, Z. Wang ..........................................................................................451 Coevolutionary Computation Based Iterative Multi-Attribute Auctions L. Nie, X. Xu, D. Zhan ..........................................................................................461 Knowledge Integration in Global Engineering R. Anderl, D. Völz, Th. Rollmann .........................................................................471

xii

Contents

Part VI - Modelling and Meta-modelling Methods and Tools for Interoperability A Framework for Executable Enterprise Application Integration Patterns Th. Scheibler, F. Leymann....................................................................................485 Experiences of Tool Integration: Development and Validation J-P. Pesola, J. Eskeli, P. Parviainen, R. Kommeren, M. Gramza ........................499 Interoperability – Network Systems for SMEs K. Mertins, Th. Knothe, F.-W. Jäkel.....................................................................511 Engineer to Order Supply Chain improvement based on the GRAI Meta-model for Interoperability: an Empirical Study A. Errasti, R. Poler...............................................................................................521 Proposal for an Object Oriented Process Modeling Language R. Anderl, J. Malzacher, J. Raßler .......................................................................533 Enterprise Modeling Based Application Development for Interoperability Problem Solving M. Jankovic, Z. Kokovic, V. Ljubicic, Z. Marjanovic, Th. Knothe........................547 IS Outsourcing Decisions: Can Value Modelling Be of Help? H. Weigand...........................................................................................................559 Process Composition in Logistics: An Ontological Approach A. De Nicola, M. Missikoff, L. Tininini.................................................................571 Interoperability of Information Systems in Crisis Management: Crisis Modeling and Metamodeling S. Truptil, F. Bénaben, P. Couget, M. Lauras, V. Chapurlat, H. Pingaud ...........583 A Novel Pattern for Complex Event Processing in RFID Applications T. Ku1, Y. L. Zhu, K. Y. Hu, C. X. Lv....................................................................595 Part VII - Architectures and Frameworks for Interoperability Enterprise Architecture: A Service Interoperability Analysis Framework J. Ullberg, R. Lagerström, P. Johnson .................................................................611 Logical Foundations for the Infrastructure of the Information Market M. Heather, D. Livingstone, N. Rossiter ..............................................................625 Meeting the Interoperability Challenges of eTransactions among Heterogeneous Business Partners: The Advantages of Hybrid Architectural Approaches for the Integrating Middleware G. Gionis, D. Askounis, S. Koussouris, F. Lampathaki ........................................639 A Model-driven, Agent-based Approach for a Rapid Integration of Interoperable Services I. Zinnikus, Ch. Hahn, K. Fischer.........................................................................651

Contents

xiii

BSMDR: A B/S UI Framework Based on MDR P. Zhang, S. He, Q. Wang, H. Chang ...................................................................665 A Proposal for Goal Modelling Using a UML Profile R. Grangel, R. Chalmeta, C. Campos, R. Sommar, J.-P. Bourey .........................679 Index of Contributors ...........................................................................................691 Index of Keywords ...............................................................................................693

Part I

Business and Strategies, Cases

An Approach for the Evaluation of the Agility in the Context of Enterprise Interoperability S. Izza(1), R. Imache(2) L. Vincent(1), and Y. Lounis(3) (1)

(2)

(3)

Ecole des Mines de Saint-Étienne, Industrial Engineering and Computer Science Laboratory, OMSI Division, 158 cours Fauriel, 42023, Saint-Etienne, Cedex 2, France. {izza, vincent}@emse.fr University of Boumerdes, Department of Informatics, LIFAB, Boumerdes, Algeria. [email protected] University of Tizi-Ouzou, Department of Informatics, Tizi-Ouzou, Algeria. [email protected]

Abstract. Today the concept of agility has become popular and is still growing in popularity in the management and technology literatures. How do we really define an agile information system? How do we know if an information system is agile? And how do we evaluate the agility in the context of enterprise information systems? This paper tries to answer some of these questions. It precisely aims to present the concept of agility of information systems and also provides an approach for the evaluation of this agility, namely POIRE approach that evaluates the agility as an amalgamation function that combines the agility measure of five complementary aspects that are Process, Organizational, Informational, Resource and Environmental aspects. Finally, this paper studies the role of interoperability in achieving agility and also the rapprochement of the concept of interoperability with the concept of agility. Keywords: Enterprise Information System; Business; Information Technology; Agility; POIRE; Agility Evaluation; Fuzzy Logic; Interoperability.

1 Introduction In the last few years, the concept of agility has become popular and is still growing in popularity in the management and technology literatures. On the management front, enterprises are daily facing pressures to demonstrate agile behaviour according to the dynamic environment. On the technology front, resources deployed to manage and automate information systems are facing flexibility and leanness issues in order to make easier the first front.

4

S. Izza, R. Imache L. Vincent, and Y. Lounis

The purpose of this paper is to investigate the notion of agility and the role of interoperability in achieving business agility. Also, this paper provides some measuring agility principles that can be exploited in the context of enterprise interoperability and some discussions on the relation between interoperability and agility. This paper is organized as follows: Section 2 introduces some of the important related work on the concept of agility. Section 3 presents the POIRE (Process, Organization, Information, Resource and Environment) approach for measuring agility in general, with a focus on the relation that exists between interoperability and agility. Section 4 describes the agility evaluation in the context of enterprise interoperability. Finally, section 5 presents some conclusions and outlines some important future work.

2 Related Work 2.1 The Concept of Agility The concept of agility originated at the end of the eighties and the early nineties in the manufacturing area in the United States. Agile Manufacturing was first introduced with the publication of a report by [8] entitled "21st Century Manufacturing Enterprise Strategy". Since then, the concept was used for agile manufacturing and agile corporations. The concept was extended to supply chains and business networks [2], to enterprise information systems [15] and also to software development [1]. Despite the age of the concept, there is no consensus yet on a definition of agility. According to [4], most of the agility concepts are adaptations of elements such as flexibility and leanness, which originated earlier. In developing their definitions, [4] draw on the concepts of flexibility and leanness to define agility as the continual readiness of an entity to rapidly or inherently, proactively or reactively, embrace change, through high quality, simplistic, economical components and relationships with its environment. According to [5], being agile is generally result in the ability to (i) sense signals in the environment, (ii) process them adequately, (iii) mobilize resources and processes to take advantage of future opportunities, and (iv) continuously learn and improve the operations of the enterprise. In the same idea, [9] interpreted agility as creativity and defined the enterprise agility as the ability to understand the environment and react creatively to both external and internal changes. In the same way, [11] interpret agility of information systems as the ability to become vigilant. Agility can also be defined in terms of the characteristics of the agile enterprise [20]: (i) sensing: the ability to perceive environmental conditions; gather useful information from the system and readily detect changes and the ability to anticipate changes; (ii) learning: the ability to effectively modify organizational behaviours and beliefs through experience and the ability to use information to improve the organization; (iii) adaptability: the ability to effect changes in systems and structures in response to (or in anticipation of) changes in environmental condition; (iv) resilience: robustness to diversity and variability, and the ability to recover from changes; (v) quickness: the ability to

An Approach for the Evaluation of the Agility in the Context of Enterprise Interoperability 5

accomplish objectives in a short period of time; pace at which changes are accomplished, and the rate of movement within organizational systems; (vi) innovation: the ability to generate many solutions to a problem; (vii) concurrency: the ability to effectively perform related activities at the same time with the same assets; and (viii) efficiency: the ability to use minimal resources to accomplish desired results. Currently it is well established that the agility can be studied through two complementary perspectives: the management (or business) perspective and the IT (information technology) perspective [3] [5]. First, the concept of agility in the management perspective is often synonym of the concept of alignment, of effective and efficient execution of business processes [7]. Another view of agility can be expressed in terms of an enterprise’s abilities to continually improve business processes [18], or as "the capacity to anticipate changing market dynamics, adapt to those dynamics and accelerate change faster than the rate of change in the market, to create economic value". Second, in the IT perspective, agility of information systems is often studied through IT solutions that compose information systems. Currently, it is well established that IT and business are related and enterprises invest more and more in IT to drive current business performance, enable future business initiatives, and create business agility [17]. There are many works, in both academia and industry, that studied the impact of IT on business agility [17]. These works present two distinct and opposing views in relation to the impact of IT investment on business agility. The first view is that IT can stabilize and facilitate business processes but can also obstruct the functional flexibility of organizations, making them slow and cumbersome in the face of emerging opportunities. In such systems, business processes are often hardwired by rigid predefined process flows. The second view portrays IT applications as disruptive influences, often dislodging efficiently working processes and leading to widespread instability that reduces the effectiveness of the organization's competitive efforts [13]. These two opposing views need resolution for managers who face a continually changing IT-driven business environment. Being agile is a compelling catch cry but may lead to a complex and confusing interaction between stability and flexibility [17]. 2.2 Approaches for Characterizing and Measuring Agility There are also some works that treats the agility issues within enterprises and they mainly concern the strategizing of agility [7], the identification of the capabilities of agility [19], the identification of the agility levels [14], and the proposition of conceptual agility frameworks [16], and the measurement of the agility [21]. [7] studied the agility in the strategy point of view and mentions that there are three main points for strategizing agility: (i) the exploitation strategy, (ii) the exploration strategy, and (iii) the change management strategy. The exploitation strategy concerns the environmental and organizational analysis, the enterprise information and knowledge systems, the standardized procedures and rules, and the information services. The exploration strategy is related on the alternative futures of information systems, the existing communities of practice, the flexibility of project teams, the existence of knowledge brokers, and the possibility of cross-

6


project learning. The change management strategy depends on the ability to incorporate the ongoing learning and review. [19] distinguish three interrelated capabilities of agility: (i) operational agility: is the ability to execute the identification and implementation of business opportunities quickly, accurately, and cost-efficiently; (ii) customer agility: is the ability to learn from customers, identify new business opportunities and implement these opportunities together with customers; and (iii) Partnership agility: is the ability to leverage business partner's knowledge, competencies, and assets in order to identify and implement new business opportunities. This distinction is in line with the multiple initiatives proposed in the literature: (i) internally focused initiatives (operational agility), (ii) demand-side initiatives (customer agility), and (iii) supply-side initiatives (partnership agility). Concerning the identification of agility levels, [14] argues that systems can be agile in three different ways: (i) by being versatile, (ii) by reconfiguration, and (iii) by reconstruction. Being versatile implies that an information system is flexible enough to cope with changing conditions as it is currently set up. If current solutions are not versatile enough, reconfiguration will be needed; this can be interpreted as pent-up agility released by a new configuration. If reconfiguration is not enough, reconstruction will be needed; this means that changes or additions have to be made to the information system. Furthermore, [14] proposed a framework that discusses how agility is produced and consumed. This is closely related to the level of agility that can be interpreted as a result of an agility production process to which resources are allocated. These agility levels are then used in order to consume agility when seizing business opportunities. Additionally, he outlines that when consuming agility within a business development effort, in many situations agility is reduced. This means that we are confronted to negative feedback that indicates how much enterprise's agility is reduced by this business development effort. An important agility framework, which concerns the management perspective, is that proposed by [16]. In this framework, we begin with the analyses of the change factors, where a required response of the enterprise is related to the enterprise's IT capability. Then, an enterprise's agility readiness is determined by its business agility capabilities. These latter are the reasons behind the existence or non existence of agility gaps. If there is a mismatch between the business agility needs and the business agility readiness, there is a business agility gap. This has implications for the business agility IT strategy. Another important work is by [12] who studied the agility in the socio-technical perspective. In this latter, the information system is considered as composed of two sub-systems: a technical system and social system. The technical subsystem encompasses both technology and process. The social subsystem encompasses the people who are directly involved in the information systems and reporting structure in which these people are embedded. To measure information system agility using the socio-technical perspective, [12] use the agility of the four components: technology agility, process agility, people agility, and structure agility. Hence, [12] argue that the agility is not a simple summing of the agility of the four components, but it depends on their nonlinear relationship. Furthermore, [22] mention the importance of preservation of agility through audits and people education. This


latter aspect is important because most of organizations continually need education for continuous agility. Finally, [21] proposed a fuzzy logic knowledge-based framework to evaluate the manufacturing agility. The value of agility is given by an approximate reasoning method taking into account the knowledge that is included in fuzzy IFTHEN rules. By utilizing these measures, decision-makers have the opportunity to examine and compare different systems at different agility levels. For this purpose, the agility is evaluated accordingly to four aspects: (i) production infrastructure, (ii) market infrastructure, (iii) people infrastructure and (iv) information infrastructure. Although all these works are important, our work is mostly closed to those proposed by [12] and [21]. In the following, we propose to extend these last researches to the evaluation of the agility of information system, and in particular in the context of enterprise interoperability perspective.

3 The POIRE Framework Based our research on the work of [12] and [21], we suggest framework, called POIRE (Process, Organization, Information, Environment). In the following, we will briefly expose the main POIRE and then we will focus on the evaluation of the agility in enterprise interoperability.

the following Resource and dimensions of the context of

3.1 POIRE Dimensions We suggest for our agility framework (POIRE) the following dimensions that are necessary in the context of measuring the agility of enterprise information systems (Figure 1):

8


interacts with Environment (E)

Organization (O)

provides is sent to, is received from

uses

uses

Information (I)

contains

Resource (R) uses

manipulates

Process (P)

Fig. 1. POIRE dimensions for enterprise information system agility

x

x

x

x

Process dimension (P): This dimension deals with the enterprise behaviour i.e. business processes. It can be measured in terms of time and cost needed to counter unexpected changes in the process of the enterprise. Agile process infrastructure enables in-time response to unexpected events such as correction and reconfiguration. It can be measured by their precision, exhaustively, non redundancy, utility, reliability, security, integrity, actuality, efficiency, effectiveness, and feasibility. Organization dimension (O): This dimension deals with all the organizational elements involved in industry, i.e. structure, organization chart, etc. It can be measured by their hierarchy type, management type, range of subordination, organizational specialization, intensity of their head quarter, nun redundancy, flexibility, turnover, and exploitability. Information dimension (I): This dimension deals with all the stored and manipulated information within the enterprise. It concerns the internal and external circulation of information. It can be measured from the level of information management tasks, i.e. the ability to collect, share and exploit structured data. It can be measured by their accuracy, exhaustively, non redundancy, utility, reliability, security, integrity, actuality, publication, and accessibility. Resource dimension (R): This dimension is about the used resources within the enterprise. It can mainly concern people, IT resources, and organizational infrastructures. It can be measured by their usefulness, necessity, use, reliability, connectivity and flexibility. Concerning the people, which constitute in our opinion the main key in achieving agility within an enterprise, it can be assessed by the level of training of the


x

personnel, the motivation/inspiration of employees and the data accessible to them. Environment dimension (E): This dimension deals with the external factors of the enterprise, including customer service and marketing feedback. It can be measured by the ability of the enterprise to identify and exploit opportunities, customize products, enhance services, deliver them on time and at lower cost and expand its market scope. It can be measured by their reactivity, proactivity and accuracy.

3.2 POIRE Metamodel Figure 2 shows the POIRE metamodel. As illustrated, the agility is evaluated according to a certain number of agility factors which are determined using a set of agility evaluation criteria for each dimension of the information system. These criteria are measured thanks to some identified metrics, that concern a given aspect (or dimension) of the information system. The evaluation of the metrics is practically based on the evaluation of a certain number of questions that are defined within a questionnaire of the corresponding dimension. Furthermore, agility factors and criteria are not independent in the way that they may mutually influence each other. Information System

Questionnaire

concerns

c

concerns

Agility grid

c on

er

ns

contains

Information System Dimension

Question

concerns

c

er

ns

evaluates

evaluates

concerns

Agility Factor

c on

Aglity Criteria influences

influences

Fig. 2. POIRE metamodel

Metric

10


3.3 POIRE Methodology In order to evaluate the agility, we begin with the analysis of the information system and the determination of the target information system grid. Then, we customize the questionnaire and we apply the linguistic variable concept of fuzzy logic to evaluate the different metrics that allows determining the agility criteria and also the real agility grid. Once the real and target grids are compared, we conclude with an HAIS (High Agility of the Information System) message, or we make the necessary adjustments in the case where there is an AAIS (Average Agility of the Information System) or LAIS (Low Agility of the Information System). Figure 3 briefly illustrates the main principle of the proposed methodology.

Analyze and/or modify the I.S.

I.S

Determine the target I.S. agility

target agility grid

Customization

Fulfill the questionnaire

questionnaire

Evaluate agility metrics

real agility metrics

Evaluate the real agility grid

adjustments

real agility grid

Compare between target and real agility grids

H.A.I.S

A.A.I.S LAIS

Define corrections

Fig. 3. POIRE methodology

4 Agility Evaluation in the Context of Enterprise Interoperability A basis for assessing agility in a context of interoperability is still at its beginning; hence, we notice the fact that the concept of agility is still being investigated and refined with time and context of the enterprise. In the present work, according to the preceding sections, agility evaluation concerns all the dimensions of agility; hence, for each agility dimension, we suggested a list of pertinent points that must be considered in order to evaluate the agility of enterprise information systems. In the same way, we conducted a study in order to learn about the role of interoperability in achieving the agility, and also in order to better identify the rapprochement that may exist between these two concepts and that is not yet discussed in our opinion in the literature. Let’s recall that interoperability is the ability for two heterogeneous components to communicate and cooperate with one another despite differences in languages, interfaces, and platforms [23] [24]. In order to insure true

An Approach for the Evaluation of the Agility in the Context of Enterprise Interoperability11

interoperability between components or systems, the syntactic interoperability [25] and the semantic interoperability [10] [23] must be specified. For the purpose of studying the rapprochement between agility and interoperability, we identified several metrics within the five above dimensions that are related to the interoperability aspect. Then we evaluated them using maturity grids, basing on CMMI model (with five maturity levels) and using sample examples taken from industrial realities. The idea is to understand how to endow the enterprise with the ability to maintain and adjust its interfaces, in terms of agility of interoperability, at different levels of abstraction of its dimensions under unexpected changes and conditions. Figure 4 illustrates the principle of the rapprochement between interoperability and agility using maturity grids. Maturity Interoperability Level 0 1 2 Grid 3 4 5

Maturity Grid

A

A

M

B

M

B

e

C

e

C

t

D

t

D

r i

E F

r i

E F G

G

c

c

Agility Level 0 1 2 3 4 5

H

H

I

I

Legend: : Real : Target : Ideal

Fig. 4. Evaluating the role of interoperability in achieving the agility with grids

Due to the data complexity and the large number of details concerning the conducted experiment, we briefly describe the main obtained results. First of all, we can retain that interoperability can be seen as one important property of agility. Furthermore, agility can be considered as a non linear function of interoperability. This may be explained in theory by the fact that the interoperability which is correlated to complexity influences the agility in two ways. First, with no interoperability there will be no agility, while with excessive interoperability, and thus with excessive complexity, agility will also decline as illustrated in figure 5. We also notice that there is an asymptotic equilibrium that is defined as the tendency of the agility of the system during its life cycle.

12


Agility

Asymptotic equilbrium

Interoperability

Fig. 5. Relating agility and interoperability - theoretical tendency

In addition, we can notice that practically we have some turbulence in the agility grids due to the happening of some changes (technology changes, business changes, strategic changes, organizational changes) in the enterprise (Figure 6). These changes lead to breaking zones that need appropriate management in order to conduct the enterprise during this state of transition.

Agility

Asymptotic equilbrium

Breaking zone (changes in technology in the IT teams, … )

Fig. 6. Relating agility and interoperability – practical tendency

Interoperability

An Approach for the Evaluation of the Agility in the Context of Enterprise Interoperability13

5 Conclusions We have presented in this paper an approach of the evaluation of the agility in the context of enterprise interoperability. We have precisely presented the main principles of POIRE framework. We also studied the role of interoperability and also its rapprochement with agility. We notice that implementing syntactic and semantic interoperability yields in an increase in agility by making easier the process of reconfiguration when adapting the information system to unpredictable changes. However, there is an asymptotic equilibrium for the agility level after a certain degree of interoperability. The future work will concern the exploitation of this framework in large realities in order to validate it and will also concern the investigation in more details of other forms of agility properties such as vigilant information systems, lean information systems, outsourced information systems and also information systems in the context of the Enterprise 2.0 wave.

References [1]

Abrahamsson P., Warsta J., Siponen M.T. and Ronkainen J., "New Directions on Agile Methods: A Comparative Analysis". Proceedings of ICSE'03, 2003. pp. 244254. [2] Adrian E., Coronado M. and Lyons A. C., "Investigating the Role of Information Systems in contributing to the Agility of Modern supply Chains". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 150162. [3] Ahsan M. and Ye-Ngo L. The relationship between IT infrastructure and strategic agility in organizations. In proceedings of the Eleven Americas Conference on Information Systems. N. C. Romano, Jr. editor, Omaha, NE. 2005. [4] Conboy K. and Fitzgerald B., "Towards a Conceptual Framework of Agile Methods: A Study of Agility in Different Disciplines". ACM Workshop on Interdisciplinary Software Engineering Research, Newport Beach, CA, November 2004.. [5] Desouza, K. C., "Preface". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. [6] Dove R., "Response Ability: the Language, Structure and Culture of Agile Enterprise". New York, Wiley, 2001. [7] Galliers R. D., "Strategizing for Agility: Confronting Information Systems Inflexibility in Dynamic Environments". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 1-14. [8] Goldman S. et al., "21st Century Manufacturing Enterprise Strategy". Brthlehem, PA: Iacocca Institute, Lehigh University. 1991. [9] Goranson H. T., "The Agile Virtual Enterprise, Cases, Metrics, Tools". Quorum Books. 1999. [10] Heiler S., "Semantic Interoperability". ACM Computing surveys, vol. 27, issue 2, pp. 271-273, 1995. [11] Houghton R. J. et al., "Vigilant Information Systems: The Western Digital Experience". In Desouza K. C. editor, Agile Information Systems: Conceptualization,

14

[12]

[13]

[14]

[15]

[16]

[17] [18]

[19]

[20]

[21]

[22]

[23] [24]

[25]


Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 222-238. Lui T-W. and Piccoli G., "Degrees of agility: Implications from Information systems Design and Firm Strategy". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 122-133. Lyytinen K. and Rose G. M., "The disruptive nature of IT innovations: The case of Internet computing in systems development organizations". MIS Quarterly, 277 (4), 2003. pp. 557. Martensson A., "Producing and Consuming Agility". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 41-51.. Mooney J. G. and Ganley D., "Enabling Strategic Agility Through Agile Information Systems". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 97-109. Oosterhout M. V., Waarts E., Heck E. V. and Hillegersberg J. V., "Business Agility: Need, Readiness and Alignment with it Strategies". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 52-69. Ross J. W. and Beath C. M., "Beyond the business case: New approaches to IT investment". MIT Sloan Management Review, 43 (2), 2002. pp. 51-59. Rouse W. B., "Agile Information Systems for Agile Decision Making". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 16-30. Sambamurthy V., Bharadwaj A. and Grover V., "Shaping agility through digital options: Reconceptualising the role of information technology in contemporary firms". MIS Quarterly, 27 (2), 237-263. 2003. Stamos E. and Galanou E., "How to evaluate the agility of your organization: Practical guidelines for SMEs". VERITAS. 2006. Available at: http://www.veritaseu.com/files/VERITAS_D6_1_Agility_Evaluation_ Handbook.pdf. Tsourveloudis et al., "On the Measurement of Agility in Manufacturing Systems". Journal of Intelligent and Robotic Systems, Kluwer Academic Publishers Hingham, MA, USA, 33 (3) 2002. pp. 329 - 342 . Wensley A. and Stijn E. V., "Enterprise Information Systems and the Preservation of Agility". In Desouza K. C. editor, Agile Information Systems: Conceptualization, Construction, and Management. Elsevier, Burlington, USA, ISBN 10: 0-7506-8235-3, 2007. pp. 178-187. Wegner P., "Interoperability". ACM Computing surveys, vol. 28, issue 1, 1996. Wileden J. C. and Kaplan A., "Software Interoperability: principles and practice". Proceedings of the 21st International Conference on Software Engineering (ICSE), pp. 675-676, ACM, 1999. Wileden et al., "Specification level interoperability". Proceedings of the 12th International Conference on Software Engineering (ICSE), pp. 74-85, ACM, 1990.

Industrialization Strategies for Cross-organizational Information Intensive Services Christoph Schroth1, 2 1

2

University of St. Gallen, MCM Institute, Bumenbergplatz 9, 9000 St. Gallen, Switzerland SAP Research CEC St. Gallen, Blumenbergplatz 9, 9000 St. Gallen, Switzerland [email protected]

Abstract. Cross-organizational collaboration is about to gain significant momentum and facilitates the emergence of a globally networked service economy. However, the organization and implementation of business relationships which span across company boundaries still shows considerable weaknesses with respect to productivity, flexibility and quality. New concepts are therefore required to facilitate a comprehensive industrialization by improving the formalization, standardization and automation of related concepts and methodologies. In this work, we briefly elaborate on a specific case of governmental administration in Switzerland, which represents a cross-organizational service industry with significant potential for performance enhancement. We present a reference architecture for service-oriented business media which allow the different involved stakeholders to organize and implement cross-company collaboration as efficiently as possible. By applying this reference architecture to the case of public administration, we show that “Lean” service consumption and provision between organizations can be realized: Similar to the manufacturing context, the seven major kinds of “waste” (defects, overproduction, excessive inventory, transportation, waiting, motion, over-processing) are reduced. Keywords: Engineering interoperable systems, Requirements engineering for the interoperable enterprise, Interoperability issues in electronic markets, Interoperability performance analysis, Interoperable enterprise architecture

1 Introduction Cross-organizational collaboration is about to gain significant momentum and facilitates the emergence of a globally networked service economy. The relentless march of improvements in the cost-performance ratio of information technology today already provides companies the opportunity to execute such crossorganizational business relationships electronically and to thus extend market

16

Christoph Schroth

reach, save time, cut costs and respond to customer queries more agilely [1, 2]. However, the organization of such business relationships still shows considerable weaknesses with respect to productivity, flexibility and quality. Business processes are often unstructured, unclear terminology prevents from a common understanding, functional as well as non-functional parameters are rarely formalized and standardized, and the frequently manual execution lead to a huge variability and hard manageability of results. New concepts are therefore required to facilitate a comprehensive industrialization by improving the formalization, standardization and automation of related concepts and methodologies. In this work, we first of all present clear definitions of relevant terms and also elaborate on the research approach applied (Section two). We also briefly revisit traditional product manufacturing with respect to the major advancements which facilitated its industrialization over time. In section three, we present a reference architecture for service-oriented, electronic business media which allow for improving the organization and implementation of cross-organizational business relationships. Section four is devoted to the application of this reference architecture to an exemplary use case in the field of public administration. We show that “Lean” service consumption and provision between organizations can be realized: Similar to the manufacturing context, the seven major kinds of “waste” (defects, overproduction, excessive inventory, transportation, waiting, motion, over-processing) are reduced significantly. Section five concludes the work with a brief summary and an overview of selected related research work.

2 Definition of Terms and Research Approach Numerous scholars [3, 4, 5] have worked on differentiating services from products, resulting in various kinds of characteristics which they consider as unique to the world of services. The service definition underlying this work is as follows: A service is considered as activity that is performed to create value for its consumer by inducing a change of the consumer himself, his intangible assets or his physical properties. In specific, information intensive services (IIS) can be described as activities that are conducted by either machines or humans and deal with the “manipulation of symbols, i.e. collection, processing and dissemination of symbols – data, information and decisions” [4, p.492]. The focus of this study lies on IIS which are provided and consumed across corporate boundaries (e.g., the collaborative creation of documents or order and invoice processes). Studies of cross-organizational collaboration can be traced back several centuries: In the 18th century, Smith [6] argued that the division of labour among agents facilitates economic wealth. Through their specialization on limited scopes of duties, productivity can be improved as the repeated execution of the same activity helps tapping existing potential for optimization. Malone [1] describes in which way decreasing costs for communication and transportation (also referred to as transaction costs [7]) enabled this division of labour and made organizations evolve from isolated, small businesses over large hierarchies to decentral markets. Today, organizations try to lower the costs of collaborating through information

Industrialization Strategies for Cross-organizational Information Intensive Services

17

exchange even more. The term industrialization is used in various contexts and with very different meanings. In this work we refer to industrialization as the application of scientific means to be able to formalize, standardize and automate the creation of customer value with the final goal to improve performance (measured on the basis of the indicators productivity, quality and flexibility [8]). 18th/ 19th century Watt, Whitney, Bessemer

-

Power machinery, interchangeable parts, division of labor

-

However, no interrelation of different processes, no consideration of the single workers

Early 20th century Taylor, Ford, Sloan

-

Holistic view on production processes Introduction of the „production-line approach“ Separation of process planning and execution

Late 20th century Ohno, Krafcik

-

Lean Manufacturing to reduce waste (superfluous overhead) Simultaneous improvement of productivity, quality and flexibility

Worker specialization Focus on both productivity and flexibility (Sloan)

Fig. 1. Industrialization of traditional product manufacturing

The industrialization of traditional manufacturing (Fig. 1) can trace its roots back to the work of inventors such as James Watt in the 18th century who developed techniques to make steam engines significantly faster, safer, and more fuelefficient than existing devices. During the 18th and also the 19th century, the general focus of industrialization was mainly on the development of power machinery, interchangeable parts, and the division of labour. A more holistic perspective that takes into account overall production processes and also the management of workers did not emerge until the early 20th century: Taylor [9], Ford and Sloan introduced scientific means to the analysis of production processes, promoted the production-line approach (to enable mass-production) and focused on both productivity and manufacturing flexibility. In the second half of the 20th century, the first “Lean” manufacturing systems emerged [8]. As opposed to the traditional, buffered approach (where inventory levels are high, assembly lines have built-in buffers against partial system breakdowns and utility workers are kept on the payroll to buffer against unexpected demand), the Lean Manufacturing approach aims to reduce superfluous overhead (represented by the seven kinds of “waste”: defects, overproduction, excessive inventory, transportation, waiting, motion, over-processing). In this way, all relevant performance indicators (productivity, quality, flexibility) could be improved.

18

Christoph Schroth

3 A Reference Architecture for Seamless Cross-Organizational Collaboration As briefly introduced above, electronic, cross-organizational collaboration shows significant weaknesses with respect to performance indicators such as quality, flexibility and productivity. The reference architecture introduced in this section facilitates the organization and implementation of electronic media for efficient and effective collaboration: For this purpose, we leverage Schmid’s Media Reference Model (MRM) [10]: The concept of media can first of all be defined as enabler of interaction, i.e. they allow for exchange, particularly the communicative exchange, between agents. The MRM comprises the three major components Physical Component (physical basis of the medium), Logical Component (logical sphere between interacting agents) and Organizational Component (social interaction organization). It further consists of a dedicated layer and phase model which builds upon these three components and allows for systematically modelling, understanding and reorganizing media. Organizational Component

Physical Component (Service-Bus) t

Information Objects Interaction Rules Registry Roles Coor-

dinati on

Software Web Client

Publi c Servi ce 1

Logical Componen

Form ats

Bus

Publi c Servi ce 2

Services

Publi c Servi ce n

Routing Abo Directory Error Handling Event Catalogue

Fig. 2. Service-Oriented Business Medium Reference Architecture

Fig. 2 visualizes the major components of our service-oriented reference architecture: As a part of the MRM’s Organizational Component, the structural as well as process-oriented organization of the agents’ interaction is defined (“Coordination” in Fig. 2). For the structural organization, electronic media need to provide a registry of participating agents as well as a role model defining rights and obligations for each of them. Also, the information objects (e.g., documents) need to be specified in a common way to ensure seamless interaction between the agents (who assume the above mentioned roles). In terms of process-oriented organization, a cross-organizational status- and action approach is leveraged: Each of the roles may execute certain actions (consume or provide services) depending on the current status of the collaboration and on a set of generally valid business rules. Adhering to the principle of modularization, atomic interaction patterns are introduced which can be assembled towards more high-level business processes [11]. Pieces of the process-oriented organization can be automated on the basis of finite state machines (FSM): Perceived events may change their state and trigger a sequence of further events, representing a sub-process.


19

This organizational component is complemented by the Logical Sphere (LComponent) which ensures that agents can seamlessly interact on the basis of a common understanding. Semantics and the structure of exchanged pieces of information represent one major element of this component. The description and the underlying understanding of interaction patterns as well as role model semantics represent further elements of this component. As a third component, the C-Component enables the interaction of the different stakeholders by providing the technology (the physical means) for exchanging messages and relies on the principles of Event-Driven Architectures. It may be considered as a cross-organizational operating system as it provides services for Information Routing, Error and Exception Handling, Data Validation and Transformation, Security, User Directory (supporting the retrieval of adequate business partners), Event/ Catalogue Services (storing information about all supported events and related user rights) as well as services allowing for diverse kinds of information dissemination (Unicast, Publish-Subscribe etc.). Besides these operational services, the C-Component also features coordination services which implement the logic of the above outlined finite state machines (devoted to automating specified pieces of the process-oriented organization). Finally, the actual agents (stakeholders interacting with the help of an electronic medium) encapsulate the services they offer with the help of Web Services-based, standardized adapters which enable them to connect and thus use existing, often proprietary applications. For stakeholders who do not use local software application, Web-based clients are provided. This reference architecture is elaborated in more detailed in [12]. Adapters play a crucial role with respect to both scalability and flexibility of our reference architecture: In the course of the HERA project [13], different “ecosystems” of agents have been found to interact on the basis of proprietary information objects, different role models and interaction patterns as well as rules. To account for such individual requirements in electronic collaboration while still ensuring global connectivity and interoperability, adapters are essential to mediate between the diverse spheres. Adapters may thus not only be used to shield specificities of one agent from the common medium (see Fig. 2), but may also act as a mediator between two or more different electronic business media: In this way, users which are connected to different media (e.g., as they belong to different business ecosystems) can interact with the help of an adapter which translates different data formats or other elements of our reference architecture. In [12], a thorough analysis of this cross-media connectivity (architectural recursivity) is provided.

20

Christoph Schroth

4 Industrialization of IIS in the Case of Swiss Public Administration 4.1 The Collaborative Process of Creating Tax Declarations in Switzerland In this section, we elaborate on a case study that has been conducted in the course of the Swiss government-funded project HERA [13] which aims at an improvement of the tax declaration procedure in Switzerland. It serves as a specific case for the interaction of certain stakeholders who mutually consume and provide IIS in order to achieve a common goal: There are mainly four stakeholders involved in the cross-organizational creation of a tax declaration. First, a company itself aims at submitting a tax declaration that complies with laws, is consistent with the forms issued by the various cantons (Swiss states) and is optimized with respect to the resulting tax load in an as efficient way as possible. Accountants can either be represented as company-internal departments or external service providers. They create comprehensive financial statements and also provide consulting services with respect to profit appropriation strategies. Auditors have to be organizationally separated from accountants (by law) to ensure their independency. They examine and verify compliance of financial statements and profit appropriations. Finally, the cantons (states) receive the completed tax declaration and initiate the assessment/ enactment process. Municipalities play a certain role within the tax declaration process in some of the Swiss cantons, but are left out in this work due to space constraints. During this procedure of creating a tax computation, the division of labour among the players induces the need for coordination and information exchange between them which follows certain choreographies. As a consequence, numerous documents are passed from one stakeholder to the other and are thereby processed in different ways until they reach the end of their respective “lifecycles”. Today, all stakeholders interact with each other via different communication channels. Some information is exchanged in paper format; other documents are transferred via e-Mail or proprietary electronic interfaces. Resulting media breaks, the lack of standardized interfaces and the strong involvement of humans into information processing induces high transaction costs and increases the risk of errors, thereby limiting service quality. Also, services are only rarely subject to quantifiable performance metrics. The study has shown that especially nonfunctional properties of services such as delivered quality or exact time required for completion are usually not provided in a clear, formal and quantifiable way. Also, the cross-organizational process varies from canton to canton as the individual states determine the boundary conditions of the tax declaration procedure. The heterogeneity prevents from standardization with respect to terminology, processes, and pieces of information and therefore deteriorates the productivity of seamless collaboration across the stakeholders’ boundaries. Frequently, decisions have been found to be made on the basis of best practices instead of formalized rule sets.


21

4.2 “Lean” IIS Management through the Reduction of Waste By applying the reference architecture introduced above and deploying an electronic business medium (referred to as HERA Bus) for the support of the collaborative tax declaration scenario, “waste” can be reduced significantly. The following paragraphs elaborate and highlight the respective reductions which will be achieved in the course of the HERA project [13]. Waste of defects: In the governmental administration case outlined above, defects are one of the most relevant sources for waste and therefore reduced service performance. Paper-based information exchange, proprietary interfaces and application interconnections as well as a huge degree of human involvement induce the risk of information processing errors. Especially the mapping between different data formats (which requires significant effort) may lead to incorrect interpretation of certain pieces of information (as they are rarely subject to widely accepted standards) which, in turn, result in defective documents (“waste”). The introduction of an electronic business medium which complies with the reference architecture outlined above will reduced error rates dramatically: As a part of the O-Component, first of all, the information objects the agents deal with are clearly specified and standardized. Through formalization and standardization, uncertainty in the mutual interaction and thus also errors are reduced. The semantics of exchanged pieces of information (part of the L-Component), for example, are also clearly determined through a standard which has been created and agreed upon prior to the medium’s establishment. The “semantic gap” which frequently exists between the different information objects which the diverse agents are used to work with is bridged through the above mentioned software adapters which account for the translation from proprietary, locally used standards into the commonly comprehensible format and the other way around. Besides elements of the O-and L-Component of our framework, the C-Component also contributes to the reduction of “defective” results of electronic interaction: The service bus acts similar to a cross-organizational operating system and features services for error detection (on a physical level, e.g. XML schema processing errors, time limit overruns, routing errors etc.), error removal and exception handling. Data Validation Services account for the integrity of transmitted data. Overproduction and Excessive Inventory: As opposed to other scholars [4], we found that inventory does not only exist in the case of physical goods, but also in the information processing context. According to our definition, service inventory represents all the work-in-progress and steps toward service accomplishment that have been performed and stored before the actual service consumer arrives. According to [14], such inventory must be reduced to a minimum to avoid costs such as those incurring for storage, management, processing, maintenance and the decrease of its value over time. On the other hand, it allows firms to “buffer their resources from the variability of demand and reap benefits from economies of scale” [14, p.56] and to avoid a phenomenon which s frequently referred to as “Lean Sinking”. To find an adequate balance between the two, the “push-pull boundary” [14, p.56] must be easily adjustable (and should be

22

Christoph Schroth

placed in a way ensuring that as much as possible work is done only in response to actual demand). The reference architecture which is currently being setup in the course of the HERA project supports firms in optimally managing their information service inventory and preventing it from becoming excessive. The business medium which can be considered as “intermediary” will, for example, provide accountants with services that reduce their information inventory while increasing their responsiveness to customer demands: A dedicated service allows them to access up-to-date, electronic forms for completing tax computations (which is within the scope of the service they perform for their clients). In this way, they are provided support to streamline their inventory (which usually consists of large piles of possibly out-dated, paper-based forms that need to be filled manually). For their key customers, they may already pre-fill relevant information which reduces service lead times on the one hand, but also costs time (for the pre-performed process step) and may eventually represent waste in case the client decides to engage another accountant. With the help of our novel architecture, agents such as accountants may also improve their services’ quality over time. Old client data can be stored at the intermediary to allow for plausibility checks and automated prefilling of forms at the next time the service is consumed. However, this information needs to be maintained, requires storage capacity, security mechanisms, must be processed correctly and may finally go to waste, inducing the need for a thorough and individual trade-off once again. The increased automation through service orchestration (e.g., by means of the presented finite state machines), high transparency and adherence to clear interaction rules (part of the O-Component) redundantize certain activities which are now done ahead of demand. The creation of a proposal for the tax“Ausscheidung” across the different states which accommodate at least one of a taxable company’s premises, for example, is today often done although it is not necessarily needed by entities involved in later process steps. This kind of overproduction can be avoided by the establishment of the institutional intermediary which enforces the application of clear rules and also provides high transparency with respect to the work that has already been done and process steps that still need to be performed. Transportation: In the traditional product manufacturing context, the transportation of goods is regarded as an activity that must be reduced to a minimum as its does not add customer value but costs time and bears the risk that goods are lost or damaged. In the field of IIS, transportation means the transfer of symbols (or pieces of information) from one agent to another. Transportation can also occur internally at a specific agent as he transmits data from one employee to the other before sending it out to another, external party. Especially during the transportation of paper-based information as it is frequently conducted today, information may get lost. Apart from that, the routing of the different dossiers (comprising all the documents currently relevant for one dedicated client) represents considerable effort as people need to seek and contact the next destination. Our approach reduces the transportation of information considerably: First of all, paper-based information representation is fully avoided and replaced by


23

electronic information systems (the electronic service bus and the software adapters for connecting local applications to it). In this way, transportation of information becomes standardized and also highly quicker. Intermediate information storages are reduced as well. In the heterogeneous IT application landscape as it is in place today, documents often reside in diverse folders, databases and outboxes until they are transferred (and possibly also transformed) for processing in other information systems on the path to the actual receiver. In this way, both the above discussed risk for errors and the time required for “transportation” is increased, limiting quality and productivity of the agents’ interaction. The electronic business medium which is implemented in the course of the HERA project will now provide a uniform means for exchanging documents. Events (encapsulating pieces of information) are created by local applications, are then transformed into the commonly comprehensible format and can then be transmitted via the bus without any other intermediate stops. Besides this, the reduction of routing uncertainty also contributes to improved transportation conditions. Today, significant time is being spent to identify the desired receiver for a certain piece of information among a number of agents. With the help of a comprehensive role model (featuring related rights and obligations) as well as formalized business rules which represent constraints for the agents’ interactions, in combination with an unambiguous user registry and corresponding addressing schemes, routing uncertainty can be avoided: Agents are only enabled to send specified pieces of information to determined receivers which is, from a CComponent perspective- automatically performed by a routing service, thereby leading to a reduced time period required for information transportation. Waiting: The idle time between single steps towards service accomplishment, leading to human resources or equipment that do not operate at full capacity represent another kind of waste. In the IIS context, such waiting times also exist and are often induced by the unpredictability of approaching work load through customer requests and also the lack of formally defined non-functional properties of services. As opposed to the highly productive manufacturing sector, formal and quantifiable parameters defining service quality or exact time required for completing rarely exist [14]. Our reference architecture which is now being applied in the public administration context provides all stakeholders involved in a collaborative tax computation a huge degree of transparency and thus allows them to schedule their activities accordingly. Again, different architectural elements contribute to the overall reduction of this kind of waste: As part of the OComponent, formalized and standardized service descriptions (regarding functional as well as non-functional parameters) will facilitate a more accurate collaboration. The electronic business medium is enabled to automatically monitor and also enforce such parameters and can take immediate action (such as sending reminders or offering alternative services) in case a certain service does not work appropriately. This transparency of service characteristics combined with services for monitoring and enforcement (provided as part of the C-Component) enhance predictability and dependability of electronic interaction and thus reduce the “waste” of waiting.

24

Christoph Schroth

Waste of motion: In manufacturing, ineffective work procedures represent one of the causes for manual efforts that do not add value from a customer’s point of view. In the context of IIS, not the physical motion, but the superfluous processing of information (which can be well compared to motion) either through human users of machines represents a significant source of waste as well. One example for the reduction of inefficient information processing is a service which orchestrates all the above discussed operational services of the medium as soon as a message is to be transferred via the bus. The sequence of services for security (e.g. decryption), data validation, routing, publish-subscribe message dissemination, re-encryption and transfer to the software-adapter of the message receiver is highly automated and thus very efficient. Human involvement or superfluous information processing can thus be reduced to a minimum. Over-processing: Over-processing, induced for example by over-fulfilment of customer requirements, may result in useless consumption of resources such as time or inventory. As described above, the definition of clearly formalized services which inform their potential consumers about non-functional properties will reduce the risk of over-processing.

Waste of defects

• Electronic, standardized encapsulation of services, interoperable data formats, uniform terminologies will reduce information processing errors

Overproduction

• Process-automation, high transparency and adherence to clear rules redundantizes certain process steps which are now done ahead of demand

Excessive inventory

• Services that allow for electronic download and filling of tax computation forms reduce existing, paper-based inventory and allow for pre-performing certain steps

Transportation

• Information transportation is automated, controlled centrally and is performed according

Waiting

• Formalized service parameters, combined with monitoring and enforcement services provided by

to strict, previously defined routes the medium will improve transparency of the process-oriented organization

Waste of motion

• Superfluous processing of information can be reduced through standardization and partial automation of service orchestrations

Over-processing

• The formalization and standardization of non-functional as well as functional service properties will facilitate the reduction of over-processing

Fig. 3. The reference architecture facilitates the reduction of seven kinds of waste

5 Conclusion The growing relevance of information intensive services for most of the developed countries’ economies on the one hand, and their weaknesses with respect to key performance indicators on the other hand induce an immediate need to identify and apply means to facilitate a comprehensive wave of industrialization [15, 16, 17, 18, 19]. Challenges such as high variability or unquantifiabiliy do not represent inherent characteristics, but major hurdles which need to be taken down on the path


25

to a global industrialization. To identify proper means for the industrialization of IIS, we have first of all analyzed methods that have been successfully applied in the traditional product manufacturing context. In particular, we elaborated on the key principles and the central impacts of the Lean Manufacturing concept. Diverse scholars already presented interesting approaches to the challenges of increasing productivity, flexibility and quality of services in general and also of IIS in particular. In [19], the authors present an elaborate framework for measuring service performance which supports the enhancement of services productivity. In [20], process analysis, a method typically applied in traditional operations management is transferred to the field of information intensive services. In this way, the authors argue, business processes that are performed as parts of a service can be analyzed and reorganized in a systematic and detailed fashion. In [14], Chopra and Lariviere introduce the notion of “service inventory” and elaborate on its significant role for the level of service performance. According to the authors, basically three factors can be considered as general determinants of service performance: The placement of the push-pull-boundary (the size of inventory, i.e. work-in-progress or unfinished, stored information which is created prior to a customer’s request), the level and composition of resources (i.e. the people and the equipment that the provider utilizes to perform a service), and finally the service access policies (used to govern how customers are able to make use of a service) have significant impact on services performance. In [22], Levitt proposed a comprehensive production-line approach “as one by which services could significantly improve their performance on both cost, largely through improved efficiency, as well as quality.” [23, p. 209] He believed that service businesses which adopt the (mass) production-line approach could gain a competitive advantage by leveraging a low-cost leadership strategy. Levitt [22] regarded the following four key principles as crucial for the realization of his idea: First, employees should perform limited discretionary action to drive “standardization and quality, i.e. consistency in meeting specifications.” [23, p. 209] Second, by following the principle of division of labour, processes are broken down into groups of tasks which allow for the specialization of skills. “This narrow division of labour made possible limited spans of control and close supervision. It also minimizes both worker skill requirements and training time.” [23, p.209] Third, the systematic “substitution of equipment for labour aligned with well conceived use and positioning of technology led to efficient, high-volume production at acceptable quality levels.” [23, p.209] Last, standardization “allows predictability, preplanning, and easier process control which, in turn, provides uniformity in service quality.” [23, p. 209] In this work, we follow a rather operational approach and propose a reference architecture for the adequate organization and implementation of electronic media for the provision and consumption of service across company boundaries. The architecture comprises an organizational component (role models, associated rules, registries and information objects), a logical component (enabling a common understanding between interacting agents rather than only allowing for the exchange of mere data) as well as a physical component (the actual services which implement the “ideas” of the organizational component). We applied this reference architecture to the case of governmental administration in Switzerland and showed

26

Christoph Schroth

that thereby defects, overproduction and excessive amounts of inventory, unnecessary transportation, waste of time, superfluous effort of employees as well as over-processing can be significantly reduced (see Fig. 3). Future work will be devoted to applying and investigating the reference architecture and its benefits in other scenarios in order to gain more insights into optimal organization and implementation of cross-organizational information intensive services.

References [1] [2] [3] [4]

[5] [6] [7] [8] [9] [10]

[11] [12]

[13] [14] [15] [16] [17] [18]

[19]

Malone, T. (2001). The Future of E-Business. Sloan Management Review, 43 (1), 104. Porter, M. (2001). Strategy and the Internet. Harvard Business Review, 79 (3), 63-78. Hill, T. P. (1977). On goods and services. Review of Income and Wealth, 23, 315-38. Apte, U., Goh, C. (2004). Applying Lean Manufacturing Principles to InformationIntensive Services, International Journal of Service Technology and Management, 5 (5/6), 488-506. Fitzsimmons J. A., Fitzsimmons, M. J. (2003). Service management. New York: McGraw-Hill. Smith, A. (1776). An Inquiry into the Nature and Causes of the Wealth of Nations. U.K. Coase, R.H. (1937). The Nature of the Firm, Economica, 4 (16), 386-405. Krafcik, J. F. (1988). Triumph of the lean production system, Sloan Management Review, 30 (1), 41-52. Taylor, F. W. (1911). The Principles of Scientific Management. New York: Harper Bros. Schmid, B. F., Lechner, U., Klose, M., Schubert, P. (1999). Ein Referenzmodell für Gemeinschaften und Medien. in: M. Englien (Hrsg.), J. Homann (Hrsg.): Virtuelle Organisation und neue Medien. Lohmar : Eul Verlag - Workshop GeNeMe 99, Gemeinschaften in neuen Medien.- Dresden.- ISBN 3-89012-710-X, 125-150. Müller, W. (2007). Event Bus Schweiz. Konzept und Architektur, Version 1.5, Eidgenössiches Finanzdepartement EFD, Informatikstrategieorgan Bund (ISB). Schmid, Beat F., Schroth, Christoph (2008). Organizing as Programming: A Reference Model for Cross-Organizational Collaboration. Proceedings of the 9th IBIMA Conference on Information Management in Modern Organizations, Marrakech, Morocco. HERA project, available online at: http://www.hera-project.ch, accessed in 2007. Chopra, S., Lariviere, M. A. (2005). Managing Service Inventory to Improve Performance, MIT Sloan Management Review, 47 (1), 56-63. Schmid, B. F. Elektronische Märkte- Merkmale, Organisation und Potentiale, available online at: http://www.netacademy.org, accessed in 2007. McAfee, A. (2004). Will Web Services Really Transform Collaboration. Sloan Management Review, 46 (2), 78-84. Karmarkar, U. S. (2004). Will you survive the services revolution, Harvard Business Review, 82 (6), 100-110. Malone, T. W. (2004). The Future of Work: How the New Order of Business Will Shape Your Organization, Your Management Style, and Your Life. Boston, MA, USA: Harvard Business School Press. Schroth, C. (2007). Web 2.0 and SOA: Converging Concepts Enabling Seamless Cross-Organizational Collaboration. Proceedings of IEEE CEC'07/ EEE '07, Tokyo, Japan.


27

[20] Harmon, E., Hensel, S., Lukes, T. (2006). Measuring performance in services, The McKinsey Quarterly, No. 1. [21] Karmarkar, U. S., Apte, U. M. (2007). Operations Management in the information economy: Information products, processes, and chains. Journal of Operations Management, Vol. 25, 438-453. [22] Levitt, T. (1972). Production-line approach to service, Harvard Business Review, 50 (5), 20-31. [23] Bowen, D. E., Youngdahl, W. E. (1998). “Lean” service: in defense of a productionline approach, International Journal of Service Industry Management, 9 (3), 207-225.

SME Maturity, Requirement for Interoperability Gorka Benguria, Igor Santos European Software Institute, Parque tecnológico de Zamudio # 204, E-48170 Zamudio, Spain [email protected], [email protected]

Abstract. Nowadays and in the future, the capacity of being able to use the latest means of interaction has become a critical factor not only to increase earnings but also to stay in the market. The objective of this paper is to present a strategy for becoming and staying interoperable in SME (Small and Medium Enterprise) environments. SMEs used to be flexible, adaptable and innovative in their products, but they have difficulties to adopt ICT in disciplines not directly related with their products. This strategy relays in three pillars: an Improvement Cycle to guide the establishment and the maintenance of the interoperable status; An Interoperability Maturity Model as a repository of good practices for being interoperable; An Assessment Method to be able to measure the level of interoperability and being able to establish feasible goals. Keywords: Strategy and management aspects of interoperability, Managing challenges and solutions of interoperablity, Business models for interoperable products and services

1 Introduction The development and delivery of products and services implies the establishment of relationship with external parties like providers, partners, administration and clients. This has not changed since the appearance of the ancient Sumerian civilization, and even before (Some authors [1] date the history commerce from 150,000 years ago). What has changed a lot is the way in which those relationships are carried out and the complexity of these relationships. In most cases, the motivation for this evolution relays in the business need for: increasing earnings and staying competitive. The evolution of the way in which the different roles interact to complete the delivery of a product or service implies the introduction of further prerequisites for the interacting roles in order to take part in the information exchange. It is not that long ago when it was only required to be able to speak and perform some basic

30

Gorka Benguria, Igor Santos

calculations for engaging in any kind of trade. However, the introduction of the written documents, the more recent introduction of the telephone and finally the advent of information and communication technologies (ICT) have brought about a huge set of prerequisites in some trading models (e.g. eCommerce, eBanking, etc). This huge set of prerequisites has made these relationships extremely complex, but on the other hand, effectiveness and profitability have increased dramatically. These prerequisites could include the acquisition of hardware and software, the establishment of new procedures, the modification of the existing ones, and even changes in the organisational culture. Nowadays and in the future, the capacity of being able to use the latest means of interaction has become a critical factor not only to increase earnings but also to stay in the market. This is true, for virtually any kind of organisation, from large to micro enterprises. It is important to underline that the adoption of new means of interaction is not a one shot effort, new means of interaction will appear in the future and organizations should be able to integrate them in line with their business objectives. Interoperability is defined as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” [2] but how can we support SME to better interact with their partners, clients, providers, administrations, and so on? The objective of this paper is to present a strategy for becoming and staying interoperable in SME (Small and Medium Enterprise) environments. In this paper, the definition of the SME given by the European commission is taken as a reference. This is, enterprises which employ fewer than 250 persons and which have either an annual turnover not exceeding 50 million euro, or an annual balance sheet total not exceeding 43 million euro [3][4]. SMEs are a key element of the European economy [5] as they employ half of the workforce and generate half of the value added. The European commission has stressed their importance several times as they are the focus of the second action of their strategy in line with the Lisbon strategy [6]. Besides, they have some characteristics that require specific strategies, different from those applicable to large companies. SMEs used to be flexible, adaptable and innovative in their products, but they have difficulties to adopt ICT [7] in disciplines not directly related with their products (e.g. how they sell them, how they offer them, etc). This strategy for becoming and staying interoperable relays in three pillars as shown in the next figure (Fig. 1): x

x

An Improvement Cycle to guide the establishment and the maintenance of the interoperable status. SME are flexible by definition but even if they are used to change they do not perform that evolution in a managed way. Becoming and staying interoperability is an ambitious goal, but usually SME do not have the budget to address this kind of huge improvement initiatives. Therefore it should be approached progressively with small and result oriented interactions. An Interoperability Maturity Model as a repository of good practices for being interoperable. Practices that could be adopted by the organisations in the continuous effort for being interoperable. The maturity model

SME Maturity, Requirement for Interoperability

x

31

establishes a roadmap that is capable of guiding the SME from the chaos to the greater stages of interoperability. It takes into account the characteristics of the SME, and tries to prioritise the outdoor interoperability, in contrast to the indoor interoperability. An Assessment Method to be able to measure the level of interoperability of an organisation for knowing the current state and being able to establish feasible goals. This method takes into account the SME constraints and establishes mechanisms to reduce the time and the effort required to complete the assessment. Instead of performing a huge assessment it focus the assessment in different stages of interoperability. The focus of the assessment could be determined based on a short questionnaire based autoevaluation.

Fig. 1. Elements of the Strategy

The paper is structured in three sections presenting the three pillars of the strategy. Then the case study that will be used to validate the strategy is presented. Finally, the paper is concluded with a description of the expected results and benefits, the related work and the preliminary conclusions from the strategy definition.

2 Improvement Cycle Increasing organisational capability of being interoperable is not a question of jumping directly from the bottom level to the top level. Although often perceived as such, it is imperative that organisational personnel refrain from viewing process improvement as a one-time investment. The marketplace is constantly changing its needs which means that organisational requirements must change to meet the needs of the market [8]. Since long time, improvement cycles have been used with the object of supporting organisations in the process of constantly adapting their way of work whenever business needs change. Improvement cycles help organisations in performing this continuous evolution in a systematic and controlled way.

32


Becoming and staying interoperability is an ambitious goal, but usually SME do not have the budget to address this kind of huge improvement initiatives. Therefore it should be approached progressively with small and result oriented interactions. The improvement cycles describe the set of phases to carry out by organizations willing to enhance their capabilities. Besides, they used to provide a set of good practices for each phase that increase the probability of succeeding with the improvement initiative. Along the time, several improvement cycles have appeared in different domains: x

x

x

PDCA (Plan-Do-Check-Act): In 1939 the statistician Walter Shewart published a continuous cycle (the Shewart Cycle) [9] for following improvement efforts at any stage. W. Edwards Deming popularised this cycle by applying it to the manufacturing industry in Japan in the 1950’s. The Japanese referred to the approach as the Deming Cycle and nowadays it is often referred to as the Plan-Do-Check-Act (PDCA) cycle [10]. IDEAL Model [11] (Initiating, Diagnosing, Establishing, Acting and Learning): The Software Engineering Institute (SEI) developed the IDEAL model for managing CMM®-based (Capability Maturity Model) software process improvement programmes. The IDEAL model has gained widespread acceptance in the CMM® community based on its close link to the Capability Maturity Model for Software. RADAR (Results, Approach, Deploy, Assessment and Review): This is the improvement cycle of the EFQM excellence model. In the same way IDEAL is closely related to CMM®, this improvement cycle is also closely related with the EFQM excellence model [12].

Taking as a basis the Shewart cycle and adding some inputs from other improvement cycles, such as IDEAL and RADAR, a customised improvement cycle was developed as the strategy for becoming and staying interoperable for in SME Environments. This cycle takes into account the SMEs features (specialisation, constrained resources, etc) and the interoperability issues (security, changing standards, etc) in the identification and definition of the good practices. x

x

x

Identify Objectives: In line with the business needs and priorities this phase identifies the interoperability objectives that will be addressed in the next improvement initiative. SME do not have budget or patience to address long term improvement projects. These objectives must be valuable, concrete and achievable in the short term. Of course these small initiatives should be managed and aligned in a common direction. Measure Current State: It is necessary to clearly understand the current situation with respect to the capability of being interoperable to be able to establish coherent improvement objectives, and to check the advance in the interoperability practices once the improvement initiative has finished. For SME this measurement should be fast and focussed in specific issues, trying to avoid extensive and expensive assessments of all the organisational aspects. Plan: Once the current state and the interoperability objectives are known, it is possible to define and schedule the set of activities that will bring the


x

x x

33

organisation from the current to the objective situation. In SME the most probable situation is not to have dedicated resources. We will have to use shared resources, resources that should continue performing their day to day activity while participating in the initiative. In the same line, it will be useful to plan activities to keep the attention over the initiative, like prototypes evaluation, presentation, and so on to avoid the lost of interest due to the day to day pressures. Act: Follow the defined plan, monitor the performance and re-plan when needed. In SME environment is crucial to keep the motivation of the people working in the initiative and the interest of the people that could be potentially affected. Check Results: Once the improvement activities have been carried out, the next step is to confirm that those activities have achieved the expected results. Transfer Results: At the end of each improvement initiative it is advisable to stop for a while and gather the lessons learnt from the improvement initiative. Besides, based on the analysis of the experience, in some special cases, it could be decided to institutionalise the improvement initiative to other areas of the organisation.

Usually, in large organisations the most critical aspect of the improvement initiative is to get the management commitment. Fortunately, in SMEs the improvement initiative usually starts from the management and the commitment is guaranteed since the beginning. But, in those special cases in which this condition is not met it is important to gain and maintain those commitments. The success at this point is to ensure the alignment of the improvement initiative and the business objectives. In the other side, we have the commitment of the workers. This commitment is also difficult to gain and maintain. The success at this point is to ensure the alignment of the improvement initiative with the personal and professional objectives of the staff affected by the improvement initiative.

3 Maturity Model The term maturity model was popularized by the SEI when they developed the CMM® in 1986. These models are aimed at evaluating and measuring processes within organizations and identifying best practices useful in helping them to increase the maturity of their processes. Several models have been developed in different disciplines and focusing on different levels of the enterprise: the Service-Oriented Architecture Maturity Model [13], the European Interoperability Framework [14], the Extended Enterprise Architecture Maturity Model [15], the Levels of Information Systems Interoperability [16] and the Organisational Interoperability Maturity Model [17] are the main models surveyed for this work. Unfortunately, existing maturity models don’t address the issue of interoperability directly or, if they do it, they focus on certain levels (e.g.:

34


organisational, systems) and are not directly applicable to SME. The maturity model introduced here establishes the roadmap for the adoption of better interoperability practices. The model takes into account that SME could be in a chaotic state where there are not processes not roles defined, and it defines a staged approach that guides SME from the lower chaotic levels to the interoperable state. It depicts 6 interoperability stages of the organization and 4 process areas subject to improvement. The next figure (Fig. 2) shows the structure of this model. The process areas are common to each interoperability level. At each level, different objectives are set within each process area. Each objective is achieved through the fulfilment of certain practices that in the end will determine the interoperability level. These practices are in turn defined by sub-practices and work products.

Fig. 2. Structure of the Maturity Model

The process areas have been defined according to the main dimensions of the enterprise defined in [18]: x x x x

Business processes: Specification, execution, improvement and alignment of business strategy and processes. Organization: Identification, specification, enactment and improvement of all organizational structures. Products and services: Specification and design of the organisation’s products and services. Systems and technology: Identification, specification, design, construction or acquisition, operation, maintenance and improvement of systems.

As shown in the previous figure (Fig. 2), the following maturity levels are proposed: x x

Initial: no processes have been defined and are performed based on memory. Performed: informal definitions of strategies and processes on a per project/department basis.


x x x

35

Modelled: definition of the collaboration and e-business strategy on a per project/department basis and the consequent definition of most processes. Integrated: definition of the strategy concerning interoperability and the institutionalization of formal and complete processes. Interoperable: processes have well defined measures and data from monitoring is analyzed and used for further improvement iterations.

The process areas contain the good practices for being interoperable, while the interoperability level proposes an improvement roadmap. The roadmap is necessary because the amount of good practices contained in the model is too big for being adopted at the same time. More over, as it has been already mentioned, it is not advisable for SME as it will take lot of time, stop the business activity, consume a great amount of resources and it will have a high probability of failure.

4 Assessment Method This section describes the method that will be used to assess the degree to which an organisation has adopted the good practices contained in the interoperability maturity model introduced in this paper. The assessment method defines the activities, roles, and work products to be used during the assessment in order to produce a profile representing the interoperability maturity of the organisation. Besides, the assessment produces a set of strengths and improvement actions that could be used to identify improvement opportunities that could foster the organisation capacity of being interoperable. When the assessment method is used inside the improvement cycle, it provides a sound base for the initial evaluation and the final confirmation of the results. This method takes into account the SME constraints and establishes mechanisms to reduce the time and the effort required to complete the assessment. Instead of performing a huge assessment it focus the assessment in different stages of interoperability. The focus of the assessment could be determined based on a short questionnaire based self-assessment. There exist other formal assessment methods that have been used as basis for the definition of this method such as the ones used with CMMI® [19][20][21] y SPICE [23]. CMMI® and SPICE are software maturity models, and they provide formal assessment methods to support the evaluation of a software intensive organisation against the model practices. A similar approach will be used for the evaluation of the interoperability maturity model. There are other assessment approaches usually used in business improvement initiatives such as the SWOT Analysis (Strengths, Weaknesses, Opportunities and Threats) [24], but these approaches are not specifically designed for working with a reference model. Therefore, they are not useful for benchmarking the improvements achieved by the initiative against an exemplar model. The activities of the method are structured in four main phases: x

Assessment Preparation: The purpose of the assessment preparation is to ensure that all aspects of the assessment planning have been carried out properly. Taking into account SME constraints, this phase include activities

36


x x x

to reduce the scope of the assessment in order to being able to complete it in less than a week. This is performed through a self-assessment that helps to obtain a fast image of the strengths and weaknesses of the SME. Assessment Execution: The purpose is to determine in a systematic way the capacity of the processes under evaluation. Assessment Reporting: The purpose is to ensure that the results of the communication have been correctly communicated and archived. Assessment follow-up: The purpose of the assessment follow-up is to learn from the gathered experiences along the evaluation in order to improve future evaluation.

From these four main phases the three first phases are mandatory and should be performed in any evaluation. The last phase is optional, but recommendable. It is possible to realise an assessment without this phase, but recording and archiving the lessons learnt will improve the quality of the following assessments.

5 Case Study Nowadays, one of the trends in many markets is the customized provisioning of end products to the final customer. The perception that the purchased product meets perfectly the needs and desires of customers is an essential value for them. For example, in the automotive industry OEM (Original Equipment Providers) can produce up to 100.000 distinct cars and there is a choice of 10.000 different combinations of colors, engine, equipment and other aspects for each model [22]. Similar cases can be applied to industries like furniture, textile, etc. Besides, the organisations continue to have the constant need for increasing earnings and being competitive. The implications of this market trend are the increasing complexity of products and the relationships among providers. In order to keep pace with this demanding environment organizations are forced to increase efficiency along the supply chain. The main objective is to minimize costs through reduced stocks through the integration of the different partners in the supply chain, from the raw material suppliers to the final vendors. Information and communication technologies focused on B2B (Business to Business) processes can be really helpful at this stage. Large firms adopted standards for data interchange like EDI (Electronic Data Interchange) years ago and now, with the widespread use of web technologies, they are starting to adopt web-enabled B2B platforms. In this scenario, the smaller companies providing materials to these large scaled enterprises are obliged to conform to the new established rules if they don’t want to be ruled out of the market. The focus of this case study is the middle-tier SME that provides assembled materials (doors) to OEMs or retailers (furniture development organisations)(Fig. 3). This SME in turn also interacts with upper tier’s suppliers which may provide them raw materials (wood) or components (handles). All the companies in this chain comprise the extended supply chain of industries like automotive, furniture, textile, electronics, etc.


37

Fig. 3. Mid-tier SME supplier

The final aim of the case study is to understand the interoperability barriers of the mid-tier supplier with its upper tier suppliers and the final customer and to provide a solution that will overcome those identified problems. For this purpose these are the steps that will be followed: x x x x x x

Identification of the business objectives of the SME, in this case the doors development company. In this case those related with the improvement of their relationship with their clients, the furniture development companies. Identification of different types of interoperability barriers at different enterprise levels. Mechanisms and channels for asking RFQ (request for quotations); and mechanisms for monitoring the state of their issued orders. Definition of an improvement planning based on the desired situation. Deployment of necessary ICT infrastructure for the fulfilment of the plan. Verification and validation of the results. Transfer of the results through dissemination activities.

This case study is primarily focused on the testing of the interoperability maturity model and the assessment method. Therefore, only one improvement cycle will be performed in the SME. The testing of the improvement cycle is a much longer activity that could not be performed in the context of the project.

6 Results and Business Benefits The expected results from the application of the strategy for becoming and staying interoperable in SME environment are the modification of the organisational culture towards a more interoperability oriented attitude. The organisation should proactively find, evaluate and integrate new ways of interacting with other organisations in order to support their business objectives. Besides, this strategy takes into account the changing nature of the business context and provides a continuous improvement cycle that takes into account this evolution and supports the organisation in this constant activity. The usage of an interoperability maturity model, and performance of assessments against that model, will allow the organisation to benchmark their progresses along the time towards the ideal situation represented by the interoperability maturity model.

38


7 Related Work The approach introduced in this paper is in line with the many existing quality models. These quality models are composed of a set of good practices that characterize leading organizations in a certain domain. Initiatives like the MBNQA (Malcolm Baldridge National Quality Award) [25], EFQM (European Foundation for Quality Management) [12], ISO 9000 [26] and Six Sigma [27] are focused on business process quality. On the other hand, initiatives like ITIL (Information Technology Infrastructure Library) are focused on delivery of good quality IT services. Other initiatives like CMMI (Capability Maturity Model Integration) [28] or SPICE [29] and other examples mentioned in previous sections of this document are models focused on improving certain areas of the organizations and their focus is not always on interoperability. The strategy introduced here aims to serve as a holistic approach to interoperability in SME. It introduces interoperability practices embracing all the areas within an organization, and structures them in a staged approach to support all kind of SME, from those that remain in the chaos to those that have already adopted some of the best practices that support the interoperability. Besides, it provides practices that take into account the characteristics of the SME when applying the model to become them more interoperable.

8 Conclusion SMEs are a key element in the European community, they are employing the majority of the people and producing half of the gross value added. However, they seem to have problems for adopting ICTs. ICTs are evolving very fast, and they are changing the way to do business. Moreover, today there are certain kinds of trades that cannot be done without using ICT (e.g. eCommerce, eBanking, etc). The capacity of being able to use the latest means of interaction has become a critical factor not only to increase earnings but also to stay in the market. This is true, for virtually any kind of organisation, from large scaled enterprises to micro enterprises. The capacity of being able to use the latest means of interaction has become a critical factor not only to increase earnings but also to stay in the market. This is true, for virtually any kind of organisation, from large to micro enterprises. It will be an error to think that it will be enough to buy proper computers and software in order to support those new ways of doing business. Those new ways of doing business usually require changes in way of work of the organisation; in fact they could affect the processes, the people and the infrastructures of the organisation. Therefore, an improvement effort for increasing the interoperability of an organisation should be carefully evaluated, planned and executed. It is important to underline that this is not a one shot effort, new means of interaction will appear in the future and organizations should be able to integrate them in line with their business objectives.


39

This paper has presented a strategy for becoming and staying interoperable in SME environment. The motivation for the development of this strategy was the lack of a suitable strategy for introducing interoperability practices in an SME in a continuous way. This strategy takes as a basis three pillars that have shown to be successful in other domains: x x x

Improvement Cycle to guide the improvement activities Maturity Model as a source of good practices Assessment Method to establish a basis for the comparison

These three pillars have been adapted to the introduction of the interoperability practices in SMEs taking into account the interoperability issues and the SMEs advantages and difficulties. In order to verify the adequacy of these instruments as building blocks of the strategy for becoming and staying interoperable in SME environments. A scenario for the use case has been identified. It has been decided to centre the validation of the strategy in a SME taking part in a supply chain. Nowadays the supply chain management is one of the most demanding domains with respect to interoperability related technologies and approaches.

Acknowledgement This paper summarises some early results from the ServiciosB2B project. This work was partially funded by the Ministry of Industry, Commerce and Tourism of the Spanish Government through the Programme for the Promotion of Technical Investigation (PROFIT). We would like to thank our partners for their great feedback and collaboration during the execution of the project.

References [1] [2] [3] [4]

[5] [6] [7]

Watson, Peter (2005). Ideas: A History of Thought and Invention from Fire to Freud. HarperCollins. ISBN 0-06-621064-X. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, Institutes of Electrical and Electronics Engineers, New York, NY 1990 European Commission, “The new SME definition User guide and model declaration”, http://ec.europa.eu/enterprise/enterprise_policy/sme_definition/sme_user_guide.pdf European Commission, “COMMISSION RECOMMENDATION of 6 May 2003 concerning the definition of micro, small and medium-sized enterprises, (2003/361/EC) Manfred Schmiemann, “SMEs and entrepreneurship in the EU”, Statistics in focus, European Commission, INDUSTRY, TRADE AND SERVICES, 24/2006 European Commission, “Time to move up a gear: The new partnership for growth and jobs”, Communication from the Commission to the spring European Council, 2006 European Commission, “i2010 – A European Information Society for growth and employment”, COMMUNICATION FROM THE COMMISSION TO THE COUNCIL, THE EUROPEAN PARLIAMENT, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS, 2005

40


[8]

David A. Reo, Nuria Quintano, Luigi Buglione, “Measuring software process improvement: there’s more to it than just measuring processes”, ESI, FESMA 99, September 1999. Walter Andrew Shewhart, “Statistical Method from the Viewpoint of Quality Control. New York: Dover”, 1939, ISBN 0-486-65232-7 W. Edwards Deming, “Out of the Crisis”, MIT Center for Advanced Engineering Study, Cambridge, MA, 1986.ISBN: 0262541157 CMU/SEI-96-HB-001, “IDEALSM: A User’s Guide for Software Process Improvement”, Bob McFeeley, February 1996 EFQM. “The EFQM Excellence Model – Improved Model, European Foundation of Quality Management”, 1999 SONIC, “SOA Maturity Model”, http://www.sonicsoftware.com/soamm European Commission. (2004). “European Interoperability Framework for PanEuropean e-Government Services” J. Schekkerman, “Extended Enterprise Architecture Maturity Model”, Version 2.0, 2006, http://www.enterprise-architecture.info/Images/E2AF/Extended%20Enterprise %20Architecture%20Maturity%20Model%20Guide%20v2.pdf C4ISR Interoperability Working Group, Department of Defense. “Levels of Information Systems Interoperability (LISI)”. Washington, DC: 1998 Thea Clark, Richard Jones, "Organisational Interoperability Maturity Model for C2", 1999 Command and Control Research and Technology Symposium, June 1999 ATHENA Integrated Project. (2005). “Framework for the Establishment and Management Methodology”. Deliverable D.A1.4 CMU/SEI-2006-HB-002, “Standard CMMI® Appraisal Method for Process Improvement (SCAMPISM)”, Version 1.2:, SCAMPI Upgrade Team CMU/SEI-95-TR-001, ESC-TR-95-001, “CMM Appraisal Framework (CAF)”, Version 1.0, Steve Masters, Carol Bothwell, February 1995 CMU/SEI-2001-TR-033, “CMM®-Based Appraisal for Internal Process Improvement (CBA IPI)” Version 1.2, Donna K. Dunaway, Steve Masters, November 2001, ESCTR-2001-033 Sachon, M., Albiñana, D. (2004). “Sector español del automóvil: ¿Preparado para el e-SCM?”. EBCenter PwC-IESE. On-line at www.ebcenter.org ISO/IEC TR 15504-3:1998(E), “Information technology - Software process assessment - Performing an assessment”. Learned, E., Christensen, C. Andrews, K. and W. Guth. “Business Policy :Text and Cases”, Homewood, R. Irwin, 1969 NIST, "Baldrige National Quality Program, Criteria for Performance Excellence", http://www.quality.nist.gov/Business_Criteria.htm ISO/IEC, “Quality management systems - Fundamentals and vocabulary“, ISO 9000:2005, 2005 Peter S. Pande et al, Robert P. Neuman, Roland R. Cavanagh, “The Six Sigma Way: How GE, Motorola, and Other Top Companies are Honing Their Performance (Hardcover)“, Publisher: McGraw-Hill; April 27, 2000, ISBN: 0071358064. CMU/SEI-2006-TR-008, “CMMI® for Development, Version 1.2” , CMMI-DEV, V1.2, ESC-TR-2006-008Conclusion ISO/IEC TR 15504-2:1998(E), “Information technology - Software process assessment – Reference Model.”

[9] [10] [11] [12] [13] [14] [15]

[16] [17] [18] [19] [20] [21]

[22] [23] [24] [25] [26] [27]

[28] [29]

Information Security Problems and Needs in Healthcare – A Case Study of Norway and Finland vs Sweden Rose-Mharie Åhlfeldt and Eva Söderström School of Humanities and Informatics, University of Skövde, P.O. Box 408, Skövde, Sweden rose-mharie.ahlfeldt;[email protected]

Abstract. In healthcare, the right information at the right time is a necessity in order to provide the best possible care for a patient. Patient information must also be protected from unauthorized access in order to protect patient privacy. It is also common for patients to visit more than one healthcare provider, which implies the need for crossborder healthcare and a focus on the patient process. Countries work differently with these issues. This paper is focused on three Scandinavian countries, Norway, Sweden and Finland, and their information security problems and needs in healthcare. Data was collected via case studies, and the results were compared to show both similarities and differences between these countries. Similarities include the too wide availability of patient information, an obvious need for risk analysis, and a tendency to focus more on patient safety than on patient privacy. Patients being involved in their own care, and the approach of exchanging patient information are examples of differences. Keywords: Information security, healthcare informatics, patient safety, patient privacy

1 Introduction Information Technology (IT) in healthcare has the potential to increase the welfare of the citizens as well asb improve the efficiency of the healthcare organizations. The demands on the healthcare sector in the Nordic countries come from: an aging population, a need for seamless service processes, an increasing demand of care in the patients’ homes, a demand for more information and participation, etc. [1]. Even if the Nordic countries are at the forefront with regard to the use of IT and the Internet in the society as a whole, the implementation of IT in healthcare has been slow [1]. When IT solutions are applied in healthcare, especially in a distributed fashion, information security is a critical issue [2], [3].

42

Rose-Mharie Åhlfeldt and Eva Söderström

The aim of this paper is to identify similarities and differences concerning the problems and needs of information security in a distributed healthcare domain. The research method used was two minor case studies in Norway and Finland. The results were compared with a previous, similar study in Sweden [4], also incorporating an existing information security model. The contribution is a holistic view of information security, which is necessary when preparing for and alleviating problems and needs in the future. In particular, the holistic view is a necessary contribution when patient information is transferred between different healthcare providers. The paper is structured as follows: Information security and the Info Sec model are presented in chapter 2, while chapter 3 introduces the state-of-the-art information security in healthcare. Chapter 4 includes the research approach, and chapter 5 presents the results of the study. Chapter 6 discusses and compares the results with the Swedish study. A summarizing discussion is given in chapter 7.

2 Information Security Model Information security concerns security issues in all kinds of information processing. According to SIS [5], information security is defined as the protection of information assets, and its aim is to maintain confidentiality, integrity, availability and accountability of information. In order to achieve the four characteristics, both technical and administrative security measures are required. Administrative security concerns the management of information security; strategies, policies, risk assessments etc. It includes structured planning and implementation of security work, and concerns the organizational level and thus the organization as a whole. Technical security concerns measures to be taken in order to achieve the overall requirements. It is subdivided into physical security (physical protection of information) and IT security (security for information in technical information systems). IT-security is further divided into computer security (protection of hardware and its contents) and communication security (protection of networks and media used for communication). A visual overview of the characteristics and security measures is presented in an information security model (Figure 1), The model combines the mentioned concepts.

Information Security Problems and Needs in Healthcare

Confidentiality

Availability

Integrity

43

Accountability

Characteristics

Information Security Security measures

Technical security

IT security

Computer Security

Administrative security

Physical security

Communication Security

Fig. 1. Information Security Model

With information security in the middle, the four characteristics are at the top, and the security measures are placed at the bottom. The latter ones are gathered directly from the SIS conceptual classification [5].

3 Information Security in Healthcare Swedish healthcare is currently undergoing extensive changes. It is to some extent moving out of the hospitals and is instead being carried out in other forms and locations. Patients with complex care needs acquire extensive care activities, for instance, in their homes. They have contact with several different healthcare providers, both within municipalities and county councils. These changes increase the requirements for secure communication, as well as cooperation between several different organizations and authorities. The National Board of Welfare [6] identifies cooperation and information transfer between different healthcare providers as a risk area for patient safety. Computerized systems as well as all media useful for patient information transmission between different healthcare providers constitute risk factors. The Board claims that healthcare providers must offer systematic measures in order to achieve sufficiently secure routines for the exchange of patient information [6]. IT-systems are extended to more and more users, but proper functions that control unauthorized access to patient information are still lacking. The Swedish Data Inspection Board declares in its report that county councils, in practice, have little or no control of who has access to information about specific patients [7]. Depending on the authorization method used, various additional measures and routines may be required to force the users into making active choices when accessing sensitive data about a specific patient. These demands are not unique for Swedish healthcare. Even if traditions and legal aspects differ between countries, the main problems are the same. Strong authentication, derived services such as authorization, access controls, accountability, integrity and confidentiality are importunate demands to achieve [8], [9], [10]. In a distributed healthcare domain, there is also a particular need for

44


a process-oriented approach [11]. Our research is focused on the patient process, since it expands beyond the boundaries of one organization, and consequently leads to patient information being available to more actors. There is a need for better awareness, improved procedures, improved software, and so on [12]. The main purpose of information security in healthcare is twofold: to achieve a high level of patient safety, i.e. to provide patients with the best care with the right information at the right time; and to achieve a high level of patient privacy; i.e. to protect sensitive patient information from unauthorized access. It is difficult to achieve both aims simultaneously, and one of them is often compromised. Hence, a balance between them is necessary in healthcare [13]. Patient safety is here related to availability and integrity, while patient privacy is related to confidentiality and accountability. We return to the relationship between the two concepts in the results.

4 The Case Studies The research was constructed as two minor case studies with a total of four interviews. The aim of the case studies was twofold: to investigate how healthcare management perceives current information security from a holistic perspective, and to explore their view of information security when patient information is exchanged. The studies were conducted at a national level in Norway and Finland. Three groups were in focus: 1) What main problems and needs, alternatively positive effects of information security, exist in healthcare from a national perspective? 2) What problems and needs, alternatively positive effects, exist when patient information is being exchanged between different healthcare providers? 3) How can the present balance between patient safety and patient privacy be recognized and what tendency can be discerned for the future? From each country, one interest organization (In Norway KITH – The Norwegian Centre for Informatics in Health and Social Care [14], in Finland STAKES – The National Research and Development Centre for Welfare and Health [15]) and one information security manager from a large hospital were selected. The respondents were selected for their good knowledge and experience of Norwegian and Finnish healthcare respectively. The studies used semi-structured interviews and were based on a set of main questions. Nine questions, derived from the Info Sec model, concern information security from a holistic view, the exchange of patient information between different healthcare providers, as well as the balance between the need for availability of patient information and protecting patient privacy. The questions are numbered from 1 to 9. The first one is divided into four parts: 1a - 1d. The four respondents were noted as A – D, with A and B from Norway, and C and D from Finland. The answers from A and the first question are hence noted as A1a, A1b and so on in Figure 2. All the answers are structured in a similar manner.


45

5 Results This chapter presents a summary of the results from the three main questions stated in the applied case study. 5.1 Problems and Needs The questions were structured to address general problems and needs first, before the specific questions about security during patient information exchange. We follow this structure when accounting for the results. The answers from the questions 1, 3, 4, 6, 7 and 8 concerning problems and needs have been classified and illustrated into the Info Sec Model in Figure 2. 1a Information Security Problems – spontaneous Both Norwegian respondents mentioned the problem of unavailable patient information, within as well as across organizations. They also emphasized that only those who need the information should have access to it. Respondent C identified employees as the weakest link, but that this is difficult to define. There are too many deficiencies concerning, for example, audit logs, regulations for encryption of information inside healthcare provider organizations, and medical doctors being reluctant to ask for consent. Respondent D claimed that the major problem is a lack of knowledge concerning the applications’ security level. Suppliers may have said one thing, but the reality is something else.

Fig. 2. Results from questions 1, 3, 4, 6, 7 and 8 indexed and classified in the Info Sec Model

1b Information Security problems – administratively The respondents mentioned that lack of knowledge, human behavior and comprehension are the main administrative problems. There is a lack of resources

46


for information security activities and insufficient routines to meet the security requirements. Furthermore, systems monitoring is also a problem. It is too expensive to have 24-hour monitoring, although this really is necessary. 1c Information Security problems – physical security “Open” hospitals are a major physical security problem in both Norway and Finland. Although new hospitals in Norway equip their entrances with cameras etc., it is still very easy to enter the wards, where much information is visible, both physically and on screens, according to respondent B. Hospitals in Finland use group logins to buildings, and computers have been stolen from the central store, according to respondent D. Respondent C pointed out that physical security in small and medium size healthcare centers is not adequate. 1d Information Security problems – IT security Authentication and access level problems are obvious in both Norway and Finland. Norway has implemented smart cards for the network, but it is an expensive technique with usability problems, such as users forgetting the cards at home, and not bringing them to other computers. Norway also lacks an automatic tool for checking logs, which is unacceptable since the access levels are too wide according to respondent B. Respondent C claims that their whole password system is not very secure at all. Outsourcing is also a narrow area: “You cannot easily see what you can outsource. You can outsource the technology but you cannot outsource the rest of the responsibility. It has to be included in the contract (respondent C). Respondent D mentioned problems such as too many uncontrolled output sockets in the systems and external partner access to the systems. 3 Present substantial security problems with cross border healthcare information from a patient process view In Norway, the information is attached to one organization and almost limited for legal reasons. Technically, systems are hard to integrate, and structured information is difficult to transfer between the systems. According to respondent B, although they can transfer information, this is not allowed according to their legislation. In one region, all healthcare organizations (except municipalities) have the same system, making it easy to transfer information between them. Finland also has interoperability problems, which are technical in a short-term sense. The main problems are semantic, according to respondent C. Respondent D claims that sending information between hospitals and healthcare centers is a minor problem. Instead, the main problem is serving the systems of the many organizations. 4 and 6 Future substantial security problems with cross border healthcare information from a patient process view and the security measures for solutions The Norwegian respondents agree on the importance of the technology working and being thought through from the start. Risk analysis is needed for the whole healthcare sector, and consequences should be dealt with. The main problem is the daily work for the ordinary co-operators according to respondent A: “It is important to find a balance”. Responsibility issues are also important for the


47

future, such as: obtained consent, documentation and information duty, and distribution to the research community. In Finland, respondent C states that the next generation of health record systems will be more consistent and more accessible, but changing IT will take more than one generation. According to respondent C, finding one general definition of merging data is too difficult. Information overflow is another problem: “The medical doctors still have a maximum of 15 minutes for the patient and five minutes for discussion. They do not have time to check all the information” (respondent C). Respondent D also mentioned the problem with a high service level agreement. To solve these problems, Norwegian respondents suggested supporting as well as presenting tools, improved analysis tools for checking logs, and more education concerning network applications. The Finnish respondents emphasized the need for electronic healthcare information, and respondent C suggested a reorganization of the whole healthcare sector. Furthermore, tools for checking quality will be more common and useful as well as necessary for the healthcare sector in order to improve the quality of care. Respondent D suggested the need for standards and service agreements. 7 and 8 Future security problems concerning availability of health information and measures for solutions Confidentiality aspects are a common risk factor concerning the availability of healthcare information for all respondents. The Norwegians stress that the availability of many patients’ health records is too broad, revealing a need to revise authorization allowance. Respondent A pointed out the risk for criminal blackmail, particularly for well-known persons: “At present, we have a peaceful regime both in Norway and Sweden, but in other types of political regimes, our openness can be of great importance and be misused”. The Finnish respondents also worry about how to control access levels, for example: “We have to think about how we control the access to patient information and other data because the access is very wide” (respondent C). The political situation was also considered: “Political situations outside Scandinavia, health and fitness records and of course the access, is controlled by law, but we have seen that a law can be changed in some weeks like in the UK” (respondent C). The Norwegian respondents suggest the solution of maintaining basic principals concerning privacy and data protection. The access control systems must be improved: “We must implement a “need-to-know-model” even if it is administratively both intensive and expensive” (respondent A); and “We have to do risk analyses in order to set requirements for privacy” (respondent B). In Finland, respondent D emphasizes that patients must have control over their own records, while respondent C is more focused on technical issues: “New technology must be implemented, for instance the new generation of PKI”.

48


5.2 Positive Aspects This section follows the same structure as the previous one in terms of first presenting the results in Figure 3, addressing general positive aspects, before proceeding with the specifics about the exchange of patient information. The answers from questions 2 and 5 concerning the positives aspects are presented in Figure 3.

Fig. 3. Results from questions 2 and 5 concerning the positive aspects

2 Present positive aspects of information security in healthcare In both Norway and Finland, patients are allowed to read their own patient records, implying: “power of citizens” (respondent C). When paper-based records were used, patients did not have this opportunity. The computerization of patient records is the most positive aspect of information security in healthcare according to all the respondents: “More people can have access to information quickly and simultaneously, and depending on IT, we can log everyone who has accessed the record and compared with the paper based system, this is very positive” (respondent B); “People cannot do whatever they want, with IT you have more orderliness” (respondent D). 5 Future positive aspects of information security in healthcare Future positive aspects will be more or less the same as previously mentioned. Even though improvements are still needed, there is a sense of faith that the healthcare sector will succeed. Information is available for healthcare actors who really need it, both internally and externally. The duty of information is improved and easier to implement with IT than paper-based systems. Hence, IT development must continue in healthcare. 5.3 Patient Safety and/or Patient Privacy? Answers from question 9 are classified according to patient safety and patient privacy regulations. These concepts have extended the upper part of the Info Sec


49

model and become related to the upper four characteristics of information security (Figure 4). The results indicate how patient safety and patient integrity often contradict one another, but also the desire to balance them. Three respondents claim the current focus priority is on patient privacy, since legislation is focused on protecting this issue. One respondent considers that patient safety dominates healthcare, while patient privacy dominates legislation.

Fig. 4. Result from question 9 - the balance between patient safety and patient privacy

All the respondents state the necessity of achieving a balance between the two concepts, even if two of the respondents want it to lean more towards safety. It should be possible to achieve a high level of patient safety and an acceptable level of patient privacy. Respondents A and D claim that in the future there will be a balance between privacy and safety: “We must try to find the right way. Sometimes we have to focus more on patient safety and sometimes on patient privacy” (respondent A): and “Patient safety is more technically focused and therefore easier to solve. The privacy part is more complex” (respondent D). Respondents B and C state that the focus would move towards patient safety in the future: “Safety and quality is coming and will be measured” (respondent C). Respondent B adds that even if privacy seems to be less in focus at the present time, in the near future, the pendulum will probably swing back.

6 Discussion and Comparison with the Swedish Study The results from the case studies are now compared to a similar study in Sweden. For details about the Swedish study, we refer to [4]. The analysis is organized according to the categories: information security problems and needs, positive aspects of information security in healthcare, and patient safety and patient privacy. 6.1 Problems and Needs The three countries have approximately the same social structure. They also basically have the same problems and needs concerning information security in healthcare. With regard to technical security, they share the problems concerning

50


authentication techniques, even if Norway is somewhat further with their smart cards. All three countries also lack authorization techniques and tools for log management. In administrative security, the main problems are: a too wide availability of patient information, incomplete work routines, a lack of security awareness and a lack of risk analyses. The integration dilemma is also a common problem. Legislation must be adapted to the new requirements, and the responsibilities for patient information must be revised. Thus far, Norway and Finland have implemented more standards and policies than Sweden, while the Swedish study did identify the need for strategies, policies and standards. In Norway and Finland, patients have the right to access their logs and consequently have more control of their own information. This is currently not possible in Sweden, but the proposed “Data Protection Act” will enable patients to be admitted access to their logs if possible, but they will not have the right to claim them. 6.2 Positive Aspects All countries agree that the most positive aspect concerning information security in healthcare is the computerization of healthcare records. Security issues still remain, but the positive aspects are clear; information availability for healthcare staff both internally and externally, more efficient care flow, and improved quality of care and patient safety. Norway and Finland emphasize the positive aspect of more power to the patients, but this is – as mentioned – not possible in Sweden. 6.3 Patient Safety and Patient Privacy Our research shows similarities concerning the balance between patient safety and patient privacy, even though the respondents disagree on which one the present focus is directed. They agree that legislation is focused on privacy, while organizations focus on safety. The Norwegian and Finnish respondents all state the necessity of achieving a balance between the two concepts. The Swedish respondents are divided; three want a balance while two claim the focus should be on patient safety. All the countries claim that in the future the focus will shift to patient safety, while one also mentioned the importance of privacy. 6.4 Comparison Summary The similarities between the countries concern problems and needs, positive aspects, as well as patient safety versus patient privacy, which is illustrated in table 1. Table 1. Similarities between the three countries Category

Similarities

Problems and needs

Lack of an authorization techniques (technical security) Lack of log management techniques (technical security)


51

Too wide availability of patient information (adm. security) Incomplete work routines (adm. security) Lack of security awareness (adm security) Need for risk analyses (adm security) Positive aspects

Computerization of healthcare records

Patient safety and patient privacy

No consensus on the current focus between the countries Legislation is focused on privacy while organizations emphasize safety Tendency to focus more on safety in the future

The computerization of healthcare records, which is a main issue in all three countries, results in availability of information, better care flow, and improved quality of care. There are also differences, illustrated in table 2. Table 2. Differences between the three countries Differences

Sweden

Norway

Finland

Authentication technique problems

Ongoing pilot project with smart cards

Further advanced with smart cards implementation, e.g. communications networks.

Further advanced with smart cards implementation

Exchange of patient information

Few standards and policies

More standards and policies

More standards and policies

Patients’ own access to information

Patients lack the right to access their logs, thus little power to patients

Patients have the right to access their logs, thus more power to patients

Patients have the right to access their logs, thus more power to patients

Patient privacy and Patient safety

No consensus among respondents

Balance is needed

Balance is needed

The first three rows of the table indicate problems and needs, the third row includes positive aspects, and the fourth concerns the discussion of privacy versus safety. Even though the countries share the problems of authentication techniques, they differ in how far advanced they are addressing them. Information exchange is also, in part, a common dilemma, but the countries differ as well in how advanced they are in dealing with the issue. Interestingly, Norway and Finland both allow patients to access their logs. The general similarities should allow Sweden to do the same, but as mentioned, this will require legislative changes.

52


7 Summarizing Discussion The aim of this paper is to identify problems and needs concerning information security in a distributed healthcare domain. Two minor case studies were conducted in Norway and Finland, and the results were compared to a similar preexisting Swedish study. Consequently, this research provides a more holistic, international overview. The results were presented and classified according to the Info Sec model. Furthermore, the need to relate and analyze patient safety and patient privacy was also emphasized. There are many similarities between the Norway, Finland and Sweden. The differences are mainly found at a more abstract level. Sweden has only recently conducted a National Strategy for IT in Healthcare, while both Norway and Finland have worked in a more structured way for a longer period of time. Both Norway and Finland are more centralized in their healthcare IT-development. Another interesting difference is the lack of patient involvement in Sweden compared to both Norway and Finland. The respondents claim that patient involvement is a useful preventive measure to protect patient privacy. When patients have the right to see who has accessed their records, the healthcare staff is more careful about avoiding misuse. However, protecting privacy is a very individual task, because people have different attitudes about the matter of privacy and even personal opinions can change depending on the situation. The involvement of patients could therefore be a good complement to the protection of their own privacy. This is a challenge for all three countries, but particularly for Sweden since it does not allow patients to access their records in the same way as in Norway and Finland. Patient safety and patient privacy in healthcare must be accomplished in order to achieve good quality of care and maintain the trust of the patients. This implies that information security must be taken seriously and the balance between these two concepts should be given careful consideration. However, the healthcare sector in general needs to look at and implement, more extensively, the existing security standards, framework and best practice, such as ISO/IEC 17799, ITIL etc. Ongoing work to incorporate the ISO/IEC 17799 into the healthcare sector (ISO 27799) exists, but further efforts are needed to adopt other frameworks into the sector as well. Furthermore, future research needs to follow the developments in how the countries address both the problems and differences, nationally, as well as in how they collaborate to identify common solutions. In addition, guidelines for establishing and achieving successful collaboration across national borders should be developed, which can also help establish better links with other countries as well. Such activities will be useful not the least since the mobility of students, the work force and organizations keeps increasing.

References [1]

Norden, (2005). Health and Social Sectors with an ”e”. A study of the Nordic countries. TemaNord 2005:531. Nordic Council of Ministers, Copenhagen. ISBN 92893-1157-6.


53

[2]

Computer Sweden, 2006. Computer Sweden/Dagens Medicin, IT i vården, 2006-1122 (in Swedish). [3] Ministry of Health and Social Affairs, 2006. Nationell IT-strategi för vård- och omsorg. ISBN 91-631-8541-5 (in Swedish). [4] Åhlfeldt, R-M. and Söderström, E. 2007. Information Security Problems and Needs in a Distributed Healthcare Domain - A Case study. In Proceedings of The Twelfth International Symposium on Health Information Management Research (iSHIMR 2007), Sheffield, UK, July 18 – 20, 2007, pp 97-108. ISBN: 0 903522 40 3. [5] SIS, 2003. SIS Handbok 550. Terminologi för informationssäkerhet. SIS Förlag AB. Stockholm (in Swedish). [6] National Board of Health and Welfare, 2004. Patientsäkerhet vid elektronisk vårddokumentation. Rapport från verksamhetstillsyn 2003 i ett sjukvårdsdistrikt inom norra regionen. Artikelnr: 2004-109-11 (in Swedish). [7] Data Inspection Board, 2005. Ökad tillgänglighet till patientuppgifter. Rapport 2005:1 [on-line]. Available from: http://www.datainspektionen.se [Accessed 1 November 2005] (in Swedish). [8] CEN TC 251, prENV 13729, 1999 Health Informatics Secure User Identification Strong Authentication using Microprocessor Cards (SEC-ID/CARDS), 1999. [9] Smith, E. and Eloff, J. H. P. 1999. Security in healthcare information systems current trends. International Journal of Medical Informatics 54, pp. 39-54. [10] Blobel, B. and Roger-France, F., 2001. A systematic approach for analysis and design of secure health information systems. International Journal of Medical Informatics 62, pp. 51-78.

[11] Poulymenopoulou, M., Malamateniou, F. and Vassilacopoulos, G., 2003 Specifying Workflow Process Requirements for an Emergency Medical Service. Journal of Medical Systems, 27(4), pp. 325-335. [12] Louwerse, K., 1998. Availability of health data; requirements and solutions Chairpersons' introduction. International of Medical Informatics, 49, pp. 9-11. [13] Utbult, M., Holmgren, A., Larsson, R., and Lindwall, C. L., 2004. Patientdata - brist och överflöd i vården. Teldok rapport nr 154. Almqvist & Wiksell, Uppsala (in Swedish). [14] KITH, 2007, Web-page. Available from: http://www.kith.no [Accessed sep, 2007]. [15] STAKES, 2007, Web-page. Available from: http;//www.stakes.fi [Accessed sep, 2007]. [16] ISO/IEC 17799, 2000. Information Technology – Code of practice for information security management. Technical Report. International organization for standards, Geneva, Switzerland. [17] ITIL, 2008, Web-page. Available from: http://www.itilofficialsite.com/home/home.asp [Accessed Jan, 2008].

Impact of Application Lifecycle Management – A Case Study J. Kääriäinen1, A. Välimäki2 1

2

VTT, Technical Research Centre of Finland, Oulu, Finland [email protected] Metso Automation Inc, Tampere, Finland [email protected]

Abstract. Lifecycle management provides a generic frame of reference for systems and methods that are needed for managing all product related data during the product’s lifecycle. This paper reports experiences from a case study performed in the automation industry. The goal was to study the concept of Application Lifecycle Management (ALM) and gather and analyse first experiences when a company is moving towards distributed application lifecycle management. The results show that several benefits were gained when introducing an ALM solution in a case company. This research also produced a first version of an ALM framework that can be used to support practical ALM improvement efforts. In this case, the experiences show that lifecycle activity should manage artefacts produced in different stages in a project lifecycle and keep all activities in synchronised. The challenge resides in how to generate efficient company-specific implementations of ALM for complicated real-life situations. Keywords: Industrial case studies and demonstrators of interoperability, Interoperability best practice and success stories, Tools for interoperability

1 Introduction The ability to produce quality products on time and at competitive costs is important for any industrial organization. Nowadays, companies are seeking systematic and more efficient ways to meet these challenges. Globalization and the use of subcontractors are becoming norms in current business environments. This shift from the traditional one-site development to the networked development environment means that product development is becoming a global complex undertaking with several stakeholders and various activities. In this kind of environment, people are likely to have difficulties in understanding each other and have problems to share a common view towards product related data. Therefore,

56

J. Kääriäinen, A. Välimäki

companies have to search for more effective procedures and tools to coordinate their ever-complicating development activities. Modern approaches for product development need to take into account the business environment, and the product’s whole lifecycle must be covered, from the initial definition up to maintenance. Such a holistic viewpoint means efficient deployment of lifecycle management. Setting up a comprehensive, smoothly running and efficiently managed product development environment requires effective lifecycle processes and tool support. In practice, this means the deployment of concepts of Product Lifecycle Management (PLM) and from a SW development point of view, Application Lifecycle Management (ALM). In literature and among tool vendors, the term PLM has been settled [1]. Within the past few years, the concept, “Application Lifecycle Management” (ALM) has emerged to indicate the coordination of activities and the management of artefacts during a SW product lifecycle, such as requirements, designs, source code, builds, documents, etc. ALM is quite a new term and therefore there are no extensive publications that deal with the term. However, tool vendors have recently used this term to indicate tool suites or their approaches that provide support for the various phases of a SW development lifecycle. While ALM is quite a new term, there is an apparent need to report practical ALM experiences from industry. This paper reports experiences from a case study performed in a company operating in the automation industry. This case study is a part of the broader ALM improvement effort in a case company where the aim is to systematize ALM in distributed development projects that develop SW for SW intensive systems. The previous solution for ALM was not good enough for the needs in future. The company expects that the new ALM solution will improve project visibility and efficiency. In this case study, the goal was to gather and analyse first experiences when a company is moving towards distributed ALM. Also, the whole concept of ALM is somewhat unclear and therefore, the aim of the research was to also create an ALM framework that can be used to evaluate the current state of ALM solution in a target organization and to detect ALM elements that possibly need to be improved. The experience data was collected from the real users of ALM in the case company. The results reported in this paper present the results of current state analysis and the perceptions of the project members when they estimated the impacts of new ALM solution on their daily work. This paper is organised as follows: In the next section, background and concept of ALM are identified. Then, in Section 3, the research approach is described comprising a description of industrial context and research settings. In Section 4, results are introduced. Finally, results are discussed and conclusions are drawn up with some final remarks.

2 Related Research Application Lifecycle Management (ALM) is quite a new term and therefore it is difficult to find definitions for it. One approach for this is standards, such as ISO/IEC 12207 that present lifecycle approaches for software development. Doyle [2] argues that ALM is a set of tools, processes and practices that enable a

Impact of Application Lifecycle Management – A Case Study

57

development organization to implement and deliver to such software lifecycle approaches. In practice, this means that some kind of solutions for ALM exist in every company even though toolsets that are specially marketed as ALM suites were introduced just a few years ago. Schwaber [3] defines that the three pillars of ALM are traceability, process automation and reporting. The role of ALM is to act as a coordination and product information management discipline. The purpose of ALM is to provide integrated tools and practices that support project cooperation and communication through a project’s lifecycle (Fig. 1). It breaks the barriers between development activities with collaboration and fluent information flow. For management, it provides an objective means to monitor project activities and generate real-time reports from project data.

Fig. 1. Application communication.

Lifecycle

Management

facilitates

project

cooperation

and

Doyle & Lloyd [4] identify requirements definition and management as one of the most critical disciplines in ALM. One focal point of requirements management is requirements traceability. It was actively researched in the 90’s and in early 2000. For example, in [5, 6, 7]. Traceability provides a means to identify and maintain relationships between developmental artefacts and therefore, facilitates reporting, change impact analysis and information visibility through the product lifecycle. The roots of ALM tools are in Configuration Management and Integrated Development Environments [8]. However, the problem with CM systems is that they are overly focused on code, and fail to provide a more comprehensive view of the project, especially in terms of its requirements [9]. An important landmark on the road towards ALM tools was the rethinking that requirements and other developmental artefacts started being taken seriously by CM tool vendors [10]. Therefore, to meet the changing needs of the industry, configuration management systems had to be merged into infrastructures that will support the entire SW development life cycle [9, 11, 12].

58


Shaw [13] argues that with traditional toolsets, traceability and reporting across disciplines is extremely difficult. Same data is often duplicated into various applications that complicate the traceability and maintenance of data. According to Doyle & Lloyd [4], having the results of processes recorded in the same repository as the development artifacts are managed in is easy to produce a relevant set of related metrics that span the various development phases of the lifecycle. Traditionally, vendors have attempted to support lifecycle management with ALM tools by moving to a single repository or by suggesting practitioners move to a single vendor for all ALM tools [13]. These solutions could be very comprehensive and well integrated. The downside of these solutions is that they lock a company into a single vendor. Another approach that aims to be more vendor-independent is called an “Application integration framework”. They are used as platforms to integrate several applications needed during the software development lifecycle. Examples of this kind of framework are Eclipse and ALF projects [14]. Schwaber [3] states that ALM does not necessarily require tools. Traditionally, lifecycle activities have been handled by partly using manual operations and solutions. For example, handouts between different functions can be controlled using a paper-based approval process. However, these activities can be made more efficient through tool integration with process automation.

3 Research Approach This section discusses industrial context, phases and methods used in this research. 3.1 Industrial Context The case company operates in the automation industry. The company produces complex automation systems where SW development is a part of system development. Product development in the case company is organized according to product lines. This research focuses on two product lines that consist of several products that are partly developed in different sites. The case was further focused on two teams each having 5 to 6 projects running in parallel. Depending on projects, the projects are geographically distributed over 2 or 3 sites. The same processes and tools are used in all projects. Previously, projects have followed a partly iterative development process. Currently, projects have adopted the agile development method, Scrum. The company is in first iteration in ALM improvement. Previously, the company’s ALM solution for distributed development comprised several somewhat isolated databases to manage project related data, such as version control, document management and fault management systems. The geographic distribution as well as increasing complexity and efficiency demands forced the company to seek more integrated solutions to coordinate distinct project phases and to provide a centralised project database for all project related data. In practice, this meant the deployment of a commercial ALM tool with the Scrum process.


59

3.2 Research Settings This research has been carried out in the following phases: research planning, questionnaire, interviews and analysis of results. A two-step approach was used for data collection. First, a questionnaire was made for project managers and project members. The respondents were asked for current practices related to ALM, opinions on how the introduced ALM solution has affected daily work compared to previous solutions and opinions about things that are important for efficient application lifecycle management. They were also asked about their ideas for the kinds of challenges a distributed environment would set for operation. Based on the related research, the elements of ALM were identified. This framework has been used for organizing a questionnaire and interviews and for analysing the case results. The elements of the preliminary ALM framework are: x

x

x

x

Creation and management of project artefacts: How different data items are created, identified, stored and versioned on various phases of a project lifecycle? All project data should be securely and easily shared for all stakeholders. Team communication should be supported. Traceability of lifecycle artefacts: How traceability in a project lifecycle is handled? Traceability provides a means to identify and maintain relationships between artefacts and, therefore, facilitates reporting, change impact analysis and information visibility through the product lifecycle. Reporting of lifecycle artefacts: How the solution supports reporting on a project lifecycle? The solution should facilitate the gathering, processing and the presentation of process and configuration item-related information for an organization. Process automation and tool integration: How well the tools support lifecycle processes and what kind of tool integrations there are? An ALM solution should support the procedures of the project and facilitate fluent data exchange and queries between various development and management tools.

After the questionnaire, project managers from the projects were selected as representatives who were interviewed using semi-structured interviews. The main structure of the interview framework was similar to the structure of the questionnaire discussed above.

4 Results This section presents results obtained from the industrial case study. Fig. 2 and Fig. 3 illustrate respondents satisfaction to the earlier and new solution based on ALM elements. After that, each element is analyzed and presented as follows: x x

ALM framework element: Issue needs to be addressed in ALM solution. Solution: Description how the issue is supported by the previous ALM solution and new ALM solution.

60


x

Rate (1=poor, 10=excellent)

Experiences: Experiences gained from the usage of the solution. Strengths / weaknesses / improvement ideas in general in this solution based on case data. 10,0 9,0 8,0 7,0 6,0 5,0 4,0 3,0 2,0 1,0 0,0 Previous solution

New ALM solution

Fig 2. Respondents’ satisfaction to previous and new solution.

10,0 Rate (1=poor, 10=excellent)

9,0 8,0 7,0 6,0

Previous solution

5,0

New ALM solution

4,0 3,0 2,0 1,0 0,0 Creation and management of project artefacts

Traceability of lifecycle artefacts

Reporting of lifecycle artefacts

Process automation and tool integration

ALM issues

Fig. 3. Respondents’ satisfaction to the previous and new solutions based on ALM elements.

ALM framework element: Creation and management of project artefacts. Solution: x

x

Previous solution: Local CM systems, central document management database, programming tools, central system/SW fault management database, central test document database. Also e.g. design tools, word processing tools and project management tools were used. New ALM solution: Integrated ALM suite with central database for storing and versioning lifecycle artefacts. Covers project management, requirements management, configuration management, programming environment, project portal and document management. In addition, there is a central test document database and central system fault management database. Also e.g. design tools and word processing tools are used.

Experiences: New ALM solution is a single vendor integrated solution. Previously, projects used separate somewhat isolated databases, e.g. for document


61

Rate (1=poor, 10=excellent)

management, configuration management and task management which was found to be complicated and difficult to keep synchronised. The ALM tool selection was affected in that the vendor in the new solution was the same as the vendor of the old CM system and therefore, the terminology of the new tool was somewhat familiar to the users. In the new solution, SW project artefacts such as management documents, requirements, tasks, design files, source code, builds and test documents can be stored into a central repository. Fig. 4 presents ratings on how well the respondents felt that previous and new solutions supported the management of different project artefacts. 10,0 9,0 8,0 7,0 6,0 5,0 4,0 3,0 2,0 1,0 0,0

Previous solution New ALM solution

Project planning and management documents

Requirements specifications

Design documents

Source code, builds

Defects, bugs

Test plans, cases, reports

Project data elem ents

Fig. 4. Respondents satisfaction to the previous and new solutions based on the management of SW project artefacts.

The respondents felt that the solution facilitates information sharing and communication because there is a single project portal for sharing the project data. At this point, it is worth noticing that globalization is nowadays a must, there is no real option for this. Therefore, the company had the challenge of working in a global environment “locally”, i.e. without the problems of geographical dispersion. Here information technology had a big role in providing the means to reduce geographic barriers. One downside of the solution is that the requirements management features of the solution is insufficient, even improved considerably if compared to the old solution. Current templates that were used in the solution for data capturing were not sufficient but they possibly need to be extended/tailored in the near future for the needs of the project. This is understandable because each organisation, product or project is unique with its own needs and characteristics. For example, attributes regarding requirements classification is missing from the standard process template as well as the visualisation of the hierarchy of the information (requirements – tasks) was poor. Results also show that the use of communication tools can facilitate informal team communication and in some cases also store discussion history (e.g. chat-tool). Furthermore, since the overall management has to coordinate the development efforts and resources it is important to be able to synchronize and prioritize different development projects with each other.

62


ALM framework element: Traceability of lifecycle artefacts. Solution: x

x

Previous solution: Traceability information was collected and stored as logical links (e.g. embedded into file/item names or comment field) or physical links (physical links between databases) between artefacts. Instructions for traceability existed. New ALM solution: The solution provides technical capabilities for linking various lifecycle artefacts stored in a central ALM database. In addition, logical and physical links between other databases. Instructions for traceability exist.

Experiences: According to results, previously traceability was more difficult when project data was dispersed over several somewhat isolated databases. In practice, this meant that traceability information was mostly collected and stored as logical links between artefacts. Respondents defined that insufficient traceability can cause various problems e.g. it slows down the testing, complicates bug fixing and makes it more difficult to find out reasons for changes. To make traceability workable, trace capture and reporting should be as easy/automated as possible or the capture and maintenance of traces is too time-consuming which leads to invaluable, out-of-date information. Respondents also felt that a distributed development environment requires that instructions for traceability should be welldocumented and communicated to ensure that traceability information remains upto-date. Respondents stated that the new ALM solution provides good possibilities for more automated traceability when the process templates will be tailored to better support traceability and reporting according to the needs of the company/project. This provides a possibility to gather traceability information as a part of the development process. A central project database provides a means for central trace storage in a global environment. This means that project personnel have a consistent view to project data and their interrelations. Examples of the lifecycle artefact traceability needs that came up in this study were: requirements – tasks – subtasks – code – build, bug – code – build and traceability of changes. In this case, SW is just one part of a complex system product. Therefore, the ALM solution should interface with HW and system level information management systems, e.g. with a system requirements management system and system version database. ALM framework element: Reporting of lifecycle artefacts. Solution: x x

Previous solution: Predefined and tailored reports from databases. New ALM solution: The ALM solution provides predefined reports, e.g. based on process templates. It is also possible to modify existing reports and create new reports based on the items stored in a central repository.

Experiences: ALM solution generates predefined or tailored project lifecycle reports from a central ALM database and thus facilitates data consolidation. Now there are better project management reports than previously. Previously, reports were based on schedules and feature statuses. Now Scrum method based reports


63

are based e.g. on effort, remaining effort, iterative development and working SW. Report sharing and visibility are supported in a distributed development environment and therefore, project personnel and management can easily follow project status. However, the overall process template was not sufficient for the project and therefore also reports need to be extended in the future to better meet the needs of the project. Respondents defined some examples of project reports that are useful for their work as follows: sprint burn down chart, product backlog composition, found/resolved/inspected bugs, report about remaining work (hours). ALM framework element: Process automation and tool integration. Solution: x x

Previous solution: Separate process guide, tool-specific process support and automation. Some integrations between databases (point-to-point integrations built in a company). New ALM solution: Tight integration between different tools provided by ALM tool: requirements/task management, version control, build, defect management, project management, word processing, spreadsheet application. Solution provides standard process templates and their tailoring possibilities. Tailored templates can be used for configuring ALM system. Process guidance can be accessed from project portal (integrated into ALM tool). Wiki-based company-internal process instructions. Sprint retrospectives according to Scrum to continuously improve practices.

Experiences: The respondents felt that an integrated toolset with process support is important. The new ALM solution supports this by providing an integrated environment that utilises central project repository. Furthermore, it was stated that tool integration should also work in a distributed development environment. For example, developers should have fluent access to a distributed version control system via their local SW development tools. The solution also enables the use of predefined or tailored process templates that are used to configure an ALM system. According to respondents, the use of standard process templates is problematic since the needs of the company and project may vary. Current standard templates represent both ends of the process spectrums, agile (lightweight process that adheres to the principles of Agile Alliance) and CMMI (supports appraisal to CMMI level 3)[19]. Respondents felt that some kind of combination of basic templates and practices could be the answer to this. One respondent answered that tailoring could cause also problems if the ALM solution is updated (new version) in the future and if a new version will not work with a tailored template. Furthermore, the project produces SW that is part of a broader system product and therefore some respondents also raised the question about the integration with system/HW –level information management solutions (e.g. system fault database, test document database, system version database). Thus, ALM interfaces with system lifecycle management systems (i.e. PLM systems). Scrum process instructions can be accessed from the ALM solution. However, they were too general and therefore, there are also wiki-based company-internal process instructions.

64


5 Discussion This paper presents a case study where the impact of application lifecycle management was evaluated. Previously, teams have used several separate systems to manage project related data. This caused challenges in coordinating development work and maintaining product related data. Therefore, the case company decided that the previous solution was not good enough for its needs in the future. The company tries to face challenges with the new ALM solution that provides a more integrated frame for the management of project data. The company expects that the new ALM solution will improve efficiency by better project decisions and a decrease in quality costs in distributed projects. This research also aimed to clarify the concept of ALM by producing a framework that can be used to evaluate the current state of ALM solution in target organization and to detect ALM elements that possibly need to be improved. Based on the results presented in the previous sections, the ALM framework elements are presented in Fig. 5. “Creation and management of project artefacts” element is the foundation for ALM. Other elements enable efficient cooperation and communication environment. The future research should study the framework’s position related to maturity and appraisal models, since these models, such as SWCMM (Capability Maturity Model) or ISO 15504, provide ability for an organization to assess its work process practices. Traceability of lifecycle artefacts

Tool integration

Communication Creation Creationand andmanagement management ofofproject projectartefacts artefacts

Reporting of lifecycle artefacts

Process automation

Fig. 5. Principal elements of ALM framework.

The results of the case study show that successful implementation of a centralized ALM solution has many advantages for SW projects. The project members are more satisfied with the new ALM solution than with the previous solution even though there are still some challenges that need to be solved in future improvement efforts. The results show that a central project database was the foundation for successful ALM. The most successful ALM issues were traceability and reporting. The importance of these issues for ALM has also been discussed in [4] and [2]. Also, communication related arguments were strong in this study. Communication solutions and practices are needed to facilitate informal communication and project data visibility. The project used a predefined Scrum process template to configure ALM solution to support agile working methods.


65

However, responses show that predefined process templates may need to be adapted according to the needs of the project. The worst deficiencies are in requirements management activities of the solution. This is critical since requirements management has been identified as one of the most critical disciplines in ALM [4]. The adaptation of product information management practices to a project environment has been discussed in literature, e.g. from SCM point of view in [15] and [16]. Therefore, the challenge is how to generate efficient company-specific implementations of ALM. Results also show that if SW development is a part of system product development, then interfaces with system/HW lifecycle management (i.e. PLM, CM) need to be handled or e.g. the traceability of SW to system or HW entities remain insufficient. This viewpoint has also been detected e.g. in [17] and [18].

6 Conclusions Planning and deployment of lifecycle management is challenging. It is a common belief that lifecycle management solutions are restricted to support the creation of very large and complicated systems. The important aspect of the lifecycle management is its conception as a generic frame of reference for systems and methods that are needed for facilitating product lifecycle activities. This concept provides a rich framework for the coordination of all kinds of engineering and development work, from agile-types of development to traditional waterfall-types of development. Since each organization and project tends to have its own characteristics and needs, the challenge resides in how to generate efficient, company-specific implementations of lifecycle management for complicated, reallife situations. This paper reports experiences from the case study performed in a company operating in the automation industry. This case study is a part of improvement effort in a case company where the aim is to systematize Application Lifecycle Management (ALM) in distributed development projects that develop SW for SW intensive systems. Even though the new ALM solution is considerably better than the previous solution and the direction is right, there remains some challenges that need to be handled in upcoming ALM improvement efforts. The next step will be that the projects will study the possibilities to tailor standard process templates in the near future. According to results, the following benefits of ALM were gained in this case: x x x x

Central storage place for all project-related data provided foundation for project cooperation and communication. Better communication within the team members of the project (data sharing, visibility even in distributed environment). Better lifecycle traceability of developmental artefacts to facilitate e.g. bug fixing and testing. Easier lifecycle reporting to increase project transparency (what is the real status of the project).

66


x x

Clear processes with fluent tool support that streamline time-consuming lifecycle activities. Better integration of applications that are used for producing, managing and reporting project related data.

References [1] [2] [3] [4] [5]

[6]

[7] [8]

[9]

[10]

[11]

[12] [13]

[14] [15]

Sääksvuori A, Immonen A, (2004) Product Lifecycle Management, Springer-Verlag Berlin Doyle C, (2007) The importance of ALM for aerospace and defence (A&D), Embedded System Engineering (ESE magazine), Vol. 15, Issue 5, 28-29 Schwaber C, (2006) The Changing Face of Application Life-Cycle Management, Forrester Research Inc., White paper, August 18 Doyle C, Lloyd R, (2007) Application lifecycle management in embedded systems engineering, Embedded System Engineering (ESE magazine), Vol. 15, Issue 2, 24-25 Gotel O, Finkelstein A, (1994) An Analysis of the Requirements Traceability Problem, Proceedings of the First International Conference on Requirements Engineering, 94-101 Ramesh B, Dhar V, (1992) Supporting systems development by capturing deliberations during requirements engineering, IEEE Transactions on Software Engineering, Vol. 18, No. 6, 498 –510 Ramesh B, Jarke M, (2001) Toward Reference Models for Requirements Traceability. IEEE Transactions on Software Engineering, Vol. 27, No. 1, 58-93 Weatherall B, (2007) Application Lifecycle Management - A Look Back, CM Journal, CM Crossroads – The configuration management community, January 2007, http://www.cmcrossroads.com/articles/cm-journal/application-lifecycle-management%11-a-look-back.html (available 18.10.2007) Kolawa A, (2006) The Future of ALM and CM, CM Journal, CM Crossroads – The configuration management community, January 2006. http://www.cmcrossroads.com/articles/cm-journal/the-future-of-alm-and-cm.html (available 18.10.2007) Estublier J, Leblang D, van der Hoek A, Conradi R, Clemm G, Tichy W, WiborgWeber D, (2005) Impact of software engineering research on the practice of software configuration management. ACM Transactions on Software Engineering and Methodology (TOSEM). ACM Press, New York, USA, Vol. 14, Issue 4, 383– 430 Heinonen S, Kääriäinen J, Takalo J, (2007) Challenges in Collaboration: Tool Chain Enables Transparency Beyond Partner Borders, In proceedings of 3rd International Conference Interoperability for Enterprise Software and Applications 2007, Funchal, Portugal Yang Z, Jiang M, (2007) Using Eclipse as a Tool-Integration Platform for Software Development, IEEE Software, Vol. 24, Issue 2, 87 - 89 Shaw K, (2007) Application lifecycle management for the enterprise, Serena Software, White Paper, April 2007, http://www.serena.com/Docs/Repository/company/Serena_ALM_2.0_For_t.pdf (available 18.10.2007) Eclipse web-pages, www.eclipse.org (available 18.10.2007) Buckley F, (1996) Implementing configuration management : hardware, software, and firmware, IEEE Computer Society Press, Los Alamitos


67

[16] Leon A, (2000) A Guide to software configuration management, Artech House, Boston [17] Crnkovic I, Dahlqvist AP, Svensson D, (2001) Complex systems development requirements - PDM and SCM integration, Asia-Pacific Conference on Quality Software [18] Välimäki A, Kääriäinen J, (2007) Product Managers’ Requirement Management Practices As Patterns in Distributed Development, 8th International PROFES (Product Focused Software http://www.liis.lv/profes2007/www.lu.lvDevelopment and Process Improvement) conference, Latvia [19] Guckenheimer S, (2006) Software Engineering with Microsoft Visual Studio Team System, Addison-Wesley

Part II

Cross-organizational Collaboration and Cross-sectoral Processes

A Service-oriented Reference Architecture for Organizing Cross-Company Collaboration Christoph Schroth University of St. Gallen, MCM Institute and SAP Research CEC, Blumenbergplatz 9, 9000 St. Gallen, Switzerland [email protected]

Abstract. Today, cross-company collaboration is about to gain significant momentum, but still shows weaknesses with respect to productivity, flexibility and quality: Point-to-point, Electronic Data Interchange (EDI)-based approaches or Managed File Transfer installations provide only limited functional richness and low reach as they often represent proprietary island solutions. A new generation of providers of software (Multienterprise/ Business-toBusiness (B2B) Gateway solutions) and services (Integration-as-a-Service and B2B Project Outsourcing) for multienterprise interaction is about to emerge today and allows for richer interaction while reducing the costs for electronic transactions heavily. However, these products and services still exhibit weaknesses with respect to both managerial and technological aspects. In this work, we present and thoroughly discuss a service-oriented reference architecture for business media that overcome the drawbacks of today’s B2B software products and services. Based on the IEEE Recommended Practice for Architectural Description (IEEE 1471-2000) in combination with Schmid’s Media Reference Model, this reference architecture provides four main views: community (structural organization), process (process-oriented organization), services and infrastructure. Keywords: Support for cross-enterprise co-operative Work, Service oriented Architectures for interoperability, Interoperable enterprise architecture, Architectures and platforms for interoperability, Interoperable inter-enterprise workflow systems

1 Motivation Cross-organizational electronic collaboration is about to gain significant momentum, but still shows weaknesses with respect to productivity, flexibility and quality [1, 2, 3, 4]. Existing, point-to-point, EDI-based approaches or Managed File Transfer (MFT) installations provide only limited functional richness and low reach as they often represent proprietary island solutions. Such message-oriented

72

Christoph Schroth

B2B communities are frequently industry-driven or lead by a large, dominant participant which has lead to a multitude of different standards of different scope and granularity over time [5]. These substantially different standards prevent from a common understanding of exchanged data among a wide mass of organizations, while high cost and complexity of existing solutions impede a fast adoption by potential users. Today, a new generation of providers of software (Multienterprise/ B2B Gateway solutions) and services (Integration-as-a-Service and B2B Project Outsourcing) for multienterprise interaction is about to emerge today and allows for richer interaction while reducing the costs for electronic transactions heavily. Integration service providers such as Advanced Data Exchange, GxS, Seeburger, Sterling Commerce and TietoEnator already offer hosted multitenant environments for reliable and secure communication, trading-partner management, technical integration services and application services [6, 7, 8, 9]. However, these products and services still exhibit weaknesses with respect to both managerial and technological aspects. Limited functional richness, focus on automation rather than business innovation as well as an inherent enterprise- rather than multienterprise perspective represent only some of the remaining challenges towards business media for efficient and effective cross-organizational interaction. In this work, we present and thoroughly discuss a service-oriented reference architecture for business media that overcome the drawbacks of today’s B2B software products and services. Based on the IEEE Recommended Practice for Architectural Description (IEEE 1471-2000) in combination with Schmid’s Media Reference Model, this reference architecture provides four main views: community (structural organization), process (process-oriented organization), services and infrastructure. The remainder of this work is organized as follows: In section two, we elaborate on the state-of-the-art in multienterprise electronic interaction and also discuss the major shortcoming of existing solutions. In section three, after presenting an adequate formal foundation, we propose our service-oriented reference architecture. Section four concludes the work with a brief summary and an outlook on future work.

2 State-of-the-Art in Multienterprise Electronic Interaction and Shortcomings A first differentiation (see Fig. 1) of existing business media for the support of cross-organizational electronic interaction can be made between e-commerce solutions (automating a company’s information transactions with its buyers and sellers) and solutions for IT extension (extensions of corporate IT infrastructures to third-party service providers, e.g. Business Process Outsourcing (BPO), Softwareas-a-Service (SaaS)). Besides their intended purpose, the second differentiation can be made along their functional capabilities. Batch-oriented point-to-point integration has been the predominant integration scenario for many years [7]. Stand-alone EDI translators and Managed File Transfer solutions (MFTs) represent major examples for solutions related to this era: “A stand-alone EDI translator is a software application that an enterprise typically licenses from an EDI software provider or subscribes

A Service-oriented Reference Architecture for Organizing Cross-Company Collaboration 73

from a Value-Added Network (VAN). The translator interprets incoming EDI information […] and converts it into the format or formats used by the enterprise's in-house systems and applications” [8, p.8-9]. Such approaches stem from the time when EDI was the predominant form of cross-organizational transaction message format (as opposed to the proliferating XML standard). “MFT software enables companies to automate, compress, restart, secure, log, analyze and audit the transfer of data from one endpoint to another” [8, p. 7]. Such message-oriented B2B software products have a limited functional scope and are frequently tailored to proprietary needs and not adequate to support heterogeneous processes or applications. To allow for richer functionality and thus high “reach” to a multitude of trading partners with different requirements, generic multienterprise/B2B gateway software is currently gaining momentum [8]. “Multienterprise/B2B gateway software (see Fig. 1) is a form of integration middleware that is used to consolidate and centralize a company's multienterprise data, application and process integration and interoperability requirements with external business partners.” [8, p.5] SaaS BPO Supply Chain/ E-Commerce

Company A

IT extension

Company B

Company C

Business Medium

3. 4. 5.

Software EDI Translators Managed File Transfer Multienterprise/ B2B Gateway SW

1. 2.

Service IaaS B2B Project Outsourcing

Fig. 1. Classification of cross-organizational electronic interaction

A remarkable market has emerged for “B2B integration capabilities that are hosted in a multitenant environment and delivered as a service rather than as software. Traditionally known as EDI VANs, we now call these hosted offerings IaaS [Integration-as-a-Service], in the spirit of SaaS, and we call vendors that offer such services (usually in one role relative to other roles) integration service providers. By definition, to be considered an integration service provider, a vendor must offer hosted multienterprise integration and interoperability services.” [8, p.

74

Christoph Schroth

9]. IaaS providers usually offer services in the fields of communication, trading partner management, technical integration (towards internal systems) and different application services. As opposed to the mere outsourcing of technical infrastructure, B2B Process Outsourcing (B2BPO) also comprises the outsourcing of a complete B2B project (including the workforce and their structural as well as process-oriented organization). Table 1. B2B Software and Services Market Overview (extracted from [6, 7, 8, 9]) Vendor

Software Multienterprise/ B2B Gateway SW

MFT Suites

Service EDI Translators

Accenture Adv. Data Exch.

B2BPO

x

x

x

Axway

x

x

Click Commerce

x

x

x x

Covisint Crossgate

IaaS

x x

x

DICentral

x

x

E2Open

x

x

EasyLink

x

eZCom Software

x

GxS

x

x x

Hubspan Inovis

x

x

nuBridges

x

x

Seeburger

x

Sterling Com.

x

x

x

x

x

x

x

x

x

x x

x

x

x

SupplyOn

x

TietoEnator

x

Tumbleweed

x

x x

x

Table 1 provides an overview of 19 selected vendors (mainly drawing on an analysis of more than 100 vendors conducted by Gartner [8]) which are active in at least one of the five above discussed fields of activity. A clear trend can be identified towards IaaS, i.e. the Internet-based, hosted offering of B2B integration capabilities (ideally in a multitenant environment). More and more vendors (worldwide already more than 100) are entering this promising market which is expected to grow significantly. In this work, we focus on managerial as well as technological aspects of IaaS. Many of the existing solutions in this area show weaknesses with regard to mainly the following three aspects:


Cross-enterprise view: Many solutions focus on shared business functionality rather than bridging existing gaps between enterprises and allowing them to seamlessly interact. Innovation potential: As elaborated in [7], existing approaches support the automation of cross-corporate interaction but do not enable users to tap the full potential business innovation. First trends towards innovation enablement can be “observed by looking at communities of data exchange where third parties are beginning to offer a range of business services as value added to the [mere] document exchange services” [7, p. 8]. “Richness” and “Reach”: Many “B2B communities” are still being setup as stand-alone island solutions for specific purposes. However, the frustration of organizations in establishing and supporting multiple, single-purpose portals and partner communities grows. “These communities and their underlying networks are not configured to support heterogeneous processes or applications.” [7, p.6]. According to Gartner research, firms desire integration services supporting “multiple protocols, multiple data formats, multiple onboarding approaches, higher-order integration features (for example, in-line translation, data validation and business process management), BAM (for example, process visibility and compliance management) and hosted applications (for example, catalogues and global data synchronization” [6, p.4]. Summing up, besides a lack of crossenterprise perspective and innovation potential, existing solutions only provide limited richness (functional scope) and reach (amount of connected organizations).

3 A Service-Oriented Reference Architecture 3.1 The IEEE Recommended Practice for Architectural Description To thoroughly elaborate on our reference architecture, we leverage the “IEEE Recommended Practice for Architectural Description” (IEEE 1471-2000 [10]) which has also been used by Greunz [11] to describe electronic business media. The standard considers architecture as „fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution“[10, p. 3]. As depicted in Fig. 2, systems are subject to an architecture. To be able to describe these adequately and systematically, there are architectural descriptions. As a central element, viewpoints exist: In order to reduce complexity and to maximize the benefit for certain groups of stakeholders, an architectural description selects one or more viewpoints, from which the system is then analyzed. A viewpoint is considered as „pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis“[10, p. 4]. The goal is to codify a set of concepts and interrelations in order to be able to adequately present and analyze certain concerns. „A concern expresses a specific interest in some topic pertaining to a particular system under consideration […]. Concerns arise in relation to human interests. These humans are called system stakeholders“[11, p. 16] who are

76

Christoph Schroth

individuals, teams or whole organizations who have a specific interest in a system. A viewpoint defines the conventions which underlie the creation, symbolization and analysis of a view „by determining the language (and notations) to be used to describe the view, and any associated modelling methods or analysis techniques to be applied to these representations of the view“ [11, p. 17]. Corresponding to the selection of viewpoints, an architectural description is divided into one or more views. Each view is thereby the representation of the overall system, but from the perspective of a set of specific, interrelated concerns. The relation between viewpoint and actual view can thus be compared with the relation between a class and one of its instances in the programming context. Due to space constraints, the remaining IEEE 1471-2000 artefacts shall not be discussed in detail. For the description of the reference architecture presented in this paper, the differentiation between viewpoints, concerns and actual views is of central importance. Missi +

+

1

Environme + influences

+

Syste

has Architectur + described by

+ is important

+

1

Architectural

+

1

Stakehol

+

1 +

1

Rati

+ participates

is

Library +

has

0

+

1 + used to

Conce 1

1

+

View

+

1 +

View 1

+ participates

1

+ consists 1

+ establishes

Mod 1

+

Fig. 2. IEEE Recommended Practice for Architectural Description (IEEE 1471-2000, [24])

3.2 Schmid’s Media Reference Model After discussing the essentials of describing architectures, Schmid’s Media Reference Model shall be used to specify and adapt the so far generic IEEE 14712000 meta-model to electronic business media, in particular in cross-organizational contexts. According to Schmid [12, 13, 14], media can basically be defined as follows: They are enablers of interaction, i.e. they allow for exchange, particularly the communicative exchange between agents. Such interaction enablers can be structured into three main components (Fig. 3): First, a physical component (CComponent) allows for the actual interaction of physical agents. This component


can also be referred to as carrier medium or channel system. Second, a logical component (L-Component) comprises a common “language”, i.e. symbols used for the communication between agents and their semantics. Without such a common understanding, the exchange of data is possible (with the help of the CComponent), but not the exchange of knowledge. Third, an organizational component (O-Component) defines a structural organization of agents, their roles, rules which impact the agents’ behaviour as well as the process-oriented organization of agents’ interactions. Layers

Community Viewpoint

Structural Organization

O Process Viewpoint

Processes/ Interactions

Service Viewpoint

Services/ Interfaces

L

C Infrastructure Viewpoint

Channel/ Service Platform Phase

Inform

Signal

Negotiate

Execute

Fig. 3. Schmid’s Media Reference Model [10]

Together, these basic three components have been identified to constitute various kinds of media. Among others, it is appropriate to describe electronic media such as those deployed to support cross-organizational collaboration. Based on these components which already represent a first, scientific approach to modelling, understanding and reorganizing media, a layer/ phase reference model has been introduced as well. The Media Reference Model (MRM) [12, see Fig. 3] comprises four different layers (which all represent dedicated views on media) and structures the use of media into four sequential phases. Similar to the emerging field of software engineering in the software context, the MRM aims to provide a comprehensive, coherent and systematic framework for the description and analysis of various media. The Community View (first layer) thereby accounts for the set of interacting agents, the organization of the given agents’ population, i.e. the specific roles of involved stakeholders, the situations in which they act as well as the objects with which they deal. Summing up, it models the structure of the social community sphere in a situation-dependent, but static fashion. The Process View (Implementation Aspects) deals with the modelling of the process-oriented organization of agents and can also be referred to as “Interaction Programming” [12]. It is also called implementation view as it connects the needs of the

78

Christoph Schroth

community with the means provided by the carrier medium and thus implements the “community-plot” on the basis of the carrier medium. The Service View (Transaction View) models the services provided by the carrier medium which can be used in the different interaction steps to reach the respective interactions’ goals. The Infrastructure View models the production system, which creates the services provided by the service view, i.e. in the case of electronic media the actual underlying information technology. The above discussed three major components can seamlessly be integrated into the MRM: The upper two views (Community Aspects and Implementation Aspects) represent the organizational component (O-Component) which accounts for the structural as well as process-oriented organization. The lower two layers are mapped to the physical component (C-Component) which focuses on the creation and provision of services. Last, the logical component (L-Component) concerns all four layers as it ensures that interaction of agents is based on a common understanding of exchanged symbols. 3.3 Service-Oriented Reference Architecture In this section, we describe the service-oriented reference architecture from the four views which have been identified as essential in the context of electronic media: Community, Processes, Services and Infrastructure. 3.3.1 Community View The concerns [10] addressed by the community view comprise the following: Who are the agents interacting over the electronic business medium? As a first element of our reference architecture, a registry of the different stakeholders must be available to ensure that organizations can publish their business profiles and are also enabled to find adequate trading partners. Particularly in multitenant environments, frequently groups of agents emerge which are also referred to as B2B communities: They represent a set of organizations that have negotiated certain business conditions as well as access right to possibly sensitive information. As a part of IaaS solutions, applications are thus required to manage profiles and access rights. What are their exact roles and the rights/ obligations associated to the roles? The different agents using the medium are assigned certain roles in order to reduce complexity of community management. Different agents may assume the same rule, depending on their properties and capabilities. Associated to these roles are clearly formalized rights and obligations which impose constraints on the agents’ activities. Which services are provided/ consumed by these roles? Besides the agents’ identities/ profiles and the specified roles which they may assume, the services they provide need to be determined to ensure an efficient organization. The mere process-oriented view which is often leveraged when analyzing an organization is not adequate to model services in the context of our reference architecture. In fact, collaborative tasks which have been identified shall be structured and decomposed into subtasks (i.e. services) according to the criteria proposed by Parnas [15] in the software programming context: First, rather than starting with a process or workflow and determining subtasks/ services as sequential parts of this process, organizational engineers are supposed to


encapsulate those design decisions which are difficult or likely to be subject to change in the future: “We have tried to demonstrate by examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing”[15]. Second, organizational services need to hide as much proprietary information as possible. By shielding information and complexity from the outside world, services are quickly exchangeable (since service interaction only is conducted via simple interfaces) and their specialization is facilitated. As a third important criterion which we transfer from software engineering to the organizational context, hierarchies need to be adopted where appropriate: Tasks are first of all broken down into subtasks/ services which reside on a first level. Similar to composite Web Services, such services than can often be composed out of other, more basis and focused services. “We have a hierarchical structure if a certain relation may be defined between the modules or programs and that relation is a partial ordering. The relation that we are concerned with is “uses” or “depends on”[…]. The partial ordering gives us two additional benefits. First, parts of the system are benefited (simplified) because they use the service of lower levels. Second, we are able to cut off the upper levels and still have a usable and useful product”[15]. Which information objects are exchanged between the agents? Today, pieces of information are frequently specified from a rather technical point of view. Countless standards already exist for XML-based electronic documents. In our reference architecture, we propose a holistic view which comprises both semantic and syntactical considerations and considers actual implementation (e.g., on the basis of XML) a separate issue (which is to be coped with in the service view). In [16], we thoroughly describe the meta-model as well as an implementation of a novel approach to modelling electronic documents based on generic, semantic building blocks (thereby complying with the principle of modularization). 3.3.2 Process View The process view mainly deals with two major concerns: How do individual agents behave and how is the overall service choreography (i.e. the interaction from a comprehensive, bird’s eye view), defined? With respect to this processoriented organization, a first differentiation must be made between imperative and declarative organizational styles: The collaboration of agents (across corporate boundaries) can be organized by prescribing the logic and the control (adhering to an imperative style) or by only pre-determining the logic (i.e. “what” has to be accomplished). The choice for an imperative or rather declarative process-oriented organization depends on certain external requirements. In case stable, standardized processes determine the interaction of agents, an imperative organization is appropriate. In cases where the actual interaction of stakeholders depends on various situational, unforeseeable factors, context-sensitive parameters or individual preferences and restrictions which vary over time, a process-oriented organization which prescribes both logic and control elements is not adequate. In

80

Christoph Schroth

such environments, more declarative “interaction programming” is needed which is merely based on specifications of “what” has to be achieved during the interaction rather than “how” (e.g. in which exact order). Independent of the decision for an imperative or a declarative process-oriented organization, our reference architecture foresees the utilization of atomic and generic process building blocks (also referred to as interaction patterns) which can be assembled towards complex cross-organizational processes. In this way (again complying with the principle of modularization), both operational flexibility and interoperability can be improved. On the basis of commonly agreed building blocks (such as those used in the case of the UN/CEFAT Modelling Methodology [16]), different parties can seamlessly model and negotiate their collaborative business processes. In the context of the HERA research project [17], an exemplary, declarative process-oriented organization is currently being setup with the help of fine-granular interaction patterns defined in the “Event Bus Schweiz”- standard [18]. 3.3.3 Services View The two major concerns addressed by the services view are: Which are the services provided by the electronic medium and which services are required to connect to it? Second, which are the interfaces of these services and how are they described? In the course of several studies, two basically different service classes have been identified. Operational services enable interaction (provide basic communication functionality), while coordination services facilitate (as they read and interpret exchanged information and act accordingly) interaction. We propose the following (non-exhaustive) set of operational services [18] as part of our reference architecture: Services supporting diverse information dissemination patterns (e.g., Publish/subscribe, Unicast, etc.), directory services (allowing for publishing and retrieving business partners and their respective profiles), event catalogue services (especially in case of declarative process-oriented organizations, the documentation of all events (messages) which may be disseminated via the medium is of central importance), transformation services (accounting for mediation of electronic artefacts which adhere to different format standards), security services (encryption and decryption), operating services (for media administration purposes), error services (automatic failure detection and removal), routing services, and validation services (e.g., for evaluation of correctness and integrity of exchanged information). Besides these enabling services, a set of coordination services is required to partially automate the process-oriented organization and to provide certain application functionality. In the course of the HERA project [17], which aims at improving the collaborative scenario of creating tax declarations, coordination services such as automated document completeness control, due date monitoring (each exchanged document is evaluated with respect to due dates for a response message; in case time-limits are not met, the service issues reminders and may also take other, pre-determined action) and process visibility (visualization of status and other key parameters of the cross-organizational interaction in order to improve transparency and thus also manageability) have been employed.


3.3.4 Infrastructure View The main two concerns addressed by the infrastructure are: Which technology shall be used to implement the medium as defined before? Which design principles are to be employed during implementation? Again, to account for the principle of modularization, our reference architecture foresees a decentral organization of electronic media which are primarily devoted to fulfilling the requirements of their respective ecosystems. In the HERA case, for example, a dedicated medium is currently being established for the purpose of collaborative tax declaration scenarios in Switzerland. The requirements with regard to all the four views of our architecture highly vary between different ecosystems and (today) prevent from a globally standardized common electronic medium for seamless interaction. We rather rely on the principle of decentrality and modularization. To allow for connectivity across the different media, though, we propose the standardization of a minimal set of common services. The “Event Bus Schweiz” initiative [14, 18] represents a first infrastructural example for a nationwide network of (sub-) event-buses which only need to adhere to common routing protocols and message formats to allow for interaction across sub-buses. As a further part of the infrastructure view, we propose the separation of actual media technology and access channel technology. For accessing instances of our reference architecture, dedicated software adapters (for connecting legacy software to the medium) or Web-based interfaces exist. Organizational Component

Physical Component (Service-Bus) t

Information Objects Interaction Rules Registry Roles Coor-

Form ats

dinati on

Software Web Client

Logical Componen

Bus

Publi c Servi ce 1

Publi c Servi ce 2

Publi c Servi ce n

Services

Routing Abo Directory Error Handling Event Catalogue

Fig. 4. Service-Oriented Reference Architecture

4 Conclusion In this work, we have analyzed the weaknesses of existing approaches to supporting the electronic interaction across corporate boundaries. On the basis of the IEEE Recommended Practice for Architectural Description as well as Schmid’s Media Reference Model, we then proposed a comprehensive reference architecture for business media which surpass today’s solutions. Fig. 4 visually summarizes the main artefacts of this architecture. As part of the organizational component, a registry, role models, business rules and specified information objects are

82

Christoph Schroth

leveraged to determine the structural and the process-oriented organization. The Logical Component (marked red) ensures that all artefacts are subject to standards and thus ensures seamless interaction on the basis of knowledge exchange rather than on data exchange. As a third component, the service bus actually enables and facilitates interaction on the basis of operational as well as coordination services. Finally, the actual agents encapsulate the services (and their related specifics) they offer with the help of standardized software adapters (alternatively, the medium can be accessed with the help of Web Clients).

References [1] [2] [3] [4]

[5]

[6] [7] [8]

[9]

[10] [11] [12]

[13] [14]

[15] [16]

McAfee, A. (2004). Will Web Services Really Transform Collaboration. Sloan Management Review, 46 (2), 78-84. Malone, T. (2001). The Future of E-Business. Sloan Management Review, 43 (1), 104. Porter, M. (2001). Strategy and the Internet. Harvard Business Review, 79 (3), 63-78. Schroth, C. (2007). Web 2.0 and SOA: Converging Concepts Enabling Seamless Cross Organizational Collaboration. Proceedings of the IEEE Joint Conference CEC'07 and EEE '07, Tokyo, Japan. Frenzel, P., Schroth, C., Samsonova, T. (2007). The Enterprise Interoperability Center– An Institutional Framework Facilitating Enterprise Interoperability. Proceedings of the 15th European Conference on Information Systems, St. Gallen, Switzerland. Lheureux, B. J., Malinverno, P. (2006). Magic Quadrant for Integration Service Providers, 1Q06. USA: Gartner Research Paper. White, A., Wilson, D., Lheureux, B. J. (2007). The Emergence of the Multienterprise Business Process Platform. USA: Gartner Research Paper. Lheureux, B. J., Biscotti, F., Malinverno, P., White, A., Kenney, L. F. (2007). Taxonomy and Definitons for the Multienterprise/B2B Infrastructure Market. USA: Gartner Research Paper. Lheureux, B. J., Malinverno, P. (2007). Spider Diagram Ratings Highlight Strengths and Challenges of Vendors in the B2B Infrastructure Market. USA: Gartner Research Paper. IEEE Computer Society (2000). IEEE Recommended Practice for Architectural Description; IEEE Std. 1471-2000. Greunz, M. (2003). An Architecture Framework for Service-Oriented Business Media. Dissertation, University of St. Gallen. Bamberg, Germany: Difo-Druck. Schmid, B. F., Lechner, U., Klose, M., Schubert, P. (1999). Ein Referenzmodell für Gemeinschaften und Medien. in: M. Englien (Hrsg.), J. Homann (Hrsg.): Virtuelle Organisation und neue Medien. Lohmar : Eul Verlag - Workshop GeNeMe 99, Gemeinschaften in neuen Medien.- Dresden.- ISBN 3-89012-710-X, 125-150. Schmid, B. F. Elektronische Märkte- Merkmale, Organisation und Potentiale, available online at: http://www.netacademy.org, accessed in 2007. Schmid, B. F., Schroth, C. (2008). Organizing as Programming: A Reference Model for Cross-Organizational Collaboration. Proceedings of the 9th IBIMA Conference on Information Management in Modern Organizations, Marrakech, Morocco. Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules, Communications of the ACM, 15 (12), 1053 – 1058. Schroth, C., Pemptroad, G., Janner, T. (2007). CCTS-based Business Information Modelling for Increasing Cross-Organizational Interoperability. Proceedings of the


3rd International Conference on Interoperability for Enterprise Software and Applications, Madeira, Potugal. [17] HERA project, available online at: http://www.hera-project.ch, accessed in 2007. [18] Müller, W. (2007). Event Bus Schweiz. Konzept und Architektur, Version 1.5, Eidgenössiches Finanzdepartement (EFD), Informatikstrategieorgan Bund (ISB).

Patterns for Distributed Scrum – A Case Study A. Välimäki1, J. Kääriäinen2 1

2

Metso Automation Inc, Tampere, Finland [email protected] VTT, Technical Research Centre of Finland, Oulu, Finland [email protected]

Abstract. System products need to be developed faster in a global development environment. More efficient project management becomes more important to meet strict time-to-market and quality constraints. The goal of this research is to study and find the best practices to distributed Scrum, which is an agile project management method. The paper describes the process of mining distributed Scrum organizational patterns. The experiences and improvement ideas of distributed Scrum have been collected from a global company operating in the automation industry. The results present issues that were found important when managing agile projects in a distributed environment. The results are further generalized in the form of an organizational pattern which makes it easier for other companies to reflect on and to apply the results to their own cases. Keywords: Industrial case studies and demonstrators of interoperability, Interoperability best practice and success stories, Tools for interoperability, The human factor in interoperability

1 Introduction Globalization is the norm in current business environments. This shift from traditional one-site development to a networked development environment means that product development is becoming a global, complex undertaking with several stakeholders and various activities. People operating in global development environments may have difficulties to communicate and understand each other. Furthermore, the overall coordination of activities is more complicated. Therefore, companies have to search for more effective procedures and tools to coordinate their ever-complicated development activities. Distributed development has recently been actively researched. For instance, in [1] and [2] and lately published as a special issue in IEEE Software [3]. From a project management point of view, distributed development has been studied e.g.

86

A. Välimäki, J. Kääriäinen

in [4]. They present in their study drivers, constraints and enablers that are leading organizations to invest project management systems in today’s increasingly distributed world. As one interesting result, they divide top issues in distributed development as follows: strategic issues, project and process management issues, communication issues, cultural issues, technical issues, and security issues. One response to an ever-complicated environment is the rise of so called agile methods [5]. These methods or approaches value the following things [6]: x x x x

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

At first glance, these issues seem to be only suitable for small teams operating in a local environment. Some time agile methods were applied just for local development, but nowadays their potential for supporting more effective global development environments has been detected. The usage of agile methods in distributed development environment has been studied and reported e.g. in [7, 8, 9]. Ramesh et al. [7] report case studies conducted in three companies. Companies combined agile methods to distributed development environments. The article first lists the challenges in agile distributed development that relate to the aspects of communication, control and trust. Then the article reports successful practices observed in three organizations that address these challenges. As a conclusion the success of distributed agile development relies on the ability to blend the characteristics of both environments, agile and distributed. Sutherland et al. [8] report a case study of a distributed Scrum project. They analyze and recommend best practices for distributed agile teams. They report integrated Scrum as a solution for distributed development. Farmer [9] reports experiences when developing SW in a large, distributed team. The team worked according to slightly modified Extreme Programming (XP) practices. Farmer [9] states that the major factors that contributed to their success were: x x x

Team consisted of some of the top people in the company Team were permitted to find their own way Team got support from management when it was needed

Our paper reports experiences from a case study performed in a company operating in the automation industry. The goal of our research is to study the challenges and find practices to support project management in distributed Scrum (Fig. 1) projects which use the Application Lifecycle Management (ALM) (Fig. 2) solution. The Scrum approach has been developed for managing the systems development process. It is an empirical approach applying the ideas of industrial process control theory to systems development resulting in an approach that reintroduces the ideas of flexibility, adaptability and productivity. In the development phase the system is developed in Sprints. Sprints are iterative cycles where the functionality is developed or enhanced to product new increments. Each

Patterns for Distributed Scrum – A Case Study

87

Sprint includes the traditional phases of software development: requirements, analysis, design, evolution and delivery phases. [5] Doyle [10] presents that ALM is a set of tools, processes and practices that enable a development organization to implement software lifecycle approaches. PREGAME PHASE

DEVELOPMENT PHASE

POSTGAME PHASE

Regular updates

Goals of next Sprint

Product backlog list

Planning

Sprint backlog list

No more requirements

System testing

Final release

Integration Documentation

Requirements

Priorities

Effort estimates

Analysis Design Evolution Testing Delivery

SPRINT

High level design/ Architecture Standards Conventions Technology Resources Architecture

New product increment

Fig. 1. Scrum overview [5].

Application ApplicationLifecycle LifecycleManagement Management Maintenance Maintenance

Release Release

Integration&&verification verification Integration

Codingand andunit unittesting testing Coding

Project manager

Design Design

Requirementsdefinition definition Requirements

Product manager

Developer

Project management Requirements management Configuration management

Architect

Fig. 2. Application communication.

Traceability Traceability Reporting Reporting Process Processautomation, automation,tool toolintegration integration

Lifecycle

Management

facilitates

Tester

project

cooperation

and

88


This paper is organised as follows: In the next section, research approach is described comprising a description of industrial context and research settings. In the Section 3, results are presented. Finally, results are discussed and conclusions are drawn up.

2 Research Approach This section discusses industrial context and research settings used in this research. 2.1 Industrial Context This case study has been carried out in a global company operating in the automation industry. Previously, projects have followed partly iterative development process. Based on the positive experiences, the case project has gone further and deployed the Scrum method. The company operates in a multi-site environment and in the future, the work is globalizing more and more. Therefore, the challenges of a global development environment were also under investigation. This study reports first experiences from the distributed Scrum in the case company. Distributed Scrum practices are applied with the Application Lifecycle Management (ALM) solution. The paper discusses experiences gained from distributed Scrum projects and reports successful practices as patterns to make them more easily exploitable for other companies. 2.2 Research Settings The research has been carried out as a case study with the following phases: research planning, questionnaire, interviews, analysis of results. A two-step approach was used for data collection. First, a questionnaire was sent to scrum masters and other team members. The questionnaire was organized according to the following Scrum practices and artifacts: x x x x x x

Product backlog Scrum planning Scrum backlog Sprint and Daily Scrum Sprint review Scrum of Scrums

The respondents were asked about their opinions on how Scrum practices and artifacts have affected their daily work in a distributed development environment. They were also asked about their ideas regarding what kinds of challenges a distributed environment would set for operation. After the questionnaire, a few key persons from the scrum teams were selected as representatives who were interviewed using semi-structured interviews.


89

The results from the questionnaire and interviews were filtered and organized according to Scrum practices and artifacts and analysis viewpoints as follows (analysis framework): x

Practice or artifact: -

People: Issues that relate to people and organization. Process: Issues that relate to working methods, practices. Tool: Issues that relate to tools.

After this, patterns [11] were used to present suggested solutions to overcome the challenges in the organization Patterns make it easier for other companies to reflect on and to apply the results to their own cases. The patterns will be presented according to the following format: x x x x x x

ID: Name: Problem: Context: Solution: Consequences:

An ID number of a pattern. A short name of a pattern. A detailed description of a problem. A context where a problem exists. Activities that will solve the problem. Results and trade-offs when the pattern is applied.

3 Results This section presents the results obtained from an industrial case study. Issues that present needs or challenges for Distributed Scrum are classified according to analysis framework presented in the previous section. Patterns that describe suggested practices to overcome the challenges of distributed project management were developed based on these results and literature inventory. In this paper, some patterns are presented as examples. 3.1 Experiences from an Industrial Case Study This section presents results of the questionnaire and interviews organized according to the analysis framework. Results reflect issues that the respondents and interviewees found important for distributed project management. For each Scrum practice or artifact issues are mapped with people, process or tool -viewpoint based on the analysis (see Tables 1 to 6). In the end of issues there is a link to a related organizational pattern, e.g. (P Org) is an abbreviation from the words Pattern: “Organize needed Scrum roles in each site”, (P Kick-off) is “Have a kick-off meeting”, (P Rel) is “Make a release plan with some sprints”, (P ALM) is “Establish Application Lifecycle Management tool”, (P Infra) is “Establish a fast and reliable infra”, (P Comm) is “Establish efficient communication methods”, (P Know) is “Knowledge transfer”, (P Visual) is “Visualize status of project”, (P Daily) is “Have many Daily Scrums”.

90


Table 1. Scrum artifact: Product Backlog. Viewpoint

Issues

People

- The Product Owner role is very important since it acts as an internal customer for a development project. - In distributed development the replication of Scrum roles through sites is essential to ensure fully functional Scrum teams in every site. (P Org) - Knowledge transfer is especially important in a distributed environment. More detailed information about domain and product backlog items is needed to ensure understanding in a global environment. (P Know) - In a global environment, team members have to rely on more formal communication and IT means. (P Know & P Comm) - Project personnel need to learn new community working methods in order to make Scrum work. (P Org & P Comm & P Kick-off)

Process

- Product backlog process should allow collecting and processing ideas. Ideas, if accepted for development, will be used for creating backlog items. (P ALM)

Tool

- Common secure and integrated repositories for all project data. (P ALM) Items need to be classified and organised hierarchically. (P ALM) Process support should enable the process and form tailoring, e,g, new item attributes, tailored status models, adding hierarchy, etc. (P ALM) Infrastructure and efficient as well as reliable network connections are a must when using a central project database in a distributed environment. (P Infra) Table 2. Scrum practice: Sprint Planning.

Viewpoint

Issues

People

Estimation of task is challenging, especially for new developers when team support or support from an architect is needed. It is challenging to make a task estimation when there are other responsibilities like maintenance work. All participate, all exchange ideas and information and all share responsibility which is good team work. Constant travelling of team members is needed to have a good Sprint Planning meeting in distributed development. (P Comm)

Process

A presentation of a product owner is important to understand the goal of a sprint. (P Kick-off)


Preparing for the next print planning is needed and all related information is needed to clarify items in a distributed development. (P Know) Tool

Better video conference and net meeting tools will decrease the need of travelling. (P Comm) Table 3. Scrum artifact: Sprint Backlog.

Viewpoint

Issues

People

Different concepts are in use with architects and programmers. (P Know)

Process

Task splitting is a good method to clarify the size of a sprint.

Tool

Easy to see what is needed by sprint backlog list. (P ALM) Table 4. Scrum practice: Sprint and Daily Scrum.

Viewpoint

Issues

People

“Daily scrum” -practice was found useful for internal communication and information sharing (e.g. ongoing tasks, problems etc.). (P Daily) Sprint –practice was found good since it increases the attitude that SW needs to work (for every sprint).

Process

These practices enforce the scrum team to follow the procedure that has many advantages (e.g. values functional SW, increases communication, increases personal responsibility).

Tool

Respondents felt that a common sprint overview report would be good (common template to show the status). (P Daily) If distributed Daily scrum is practiced then adequate IT means are needed to facilitate formal and informal communication (e.g. chattool, project news, central ALM). (P Comm) Table 5. Scrum practice: Sprint Review.

Viewpoint

Issues

People

The Product Owner is a very important person in a review.

Process

Review provides a good possibility to find weaknesses from software and plans. Easier to illustrate how the system works and what kind of deficiencies there are. Sprint retrospective collects improvement ideas for the project (e.g. process).

Tool

Efficient communication tools are needed. (P Comm)

91

92


Table 6. Scrum practice: Scrum of Scrums. Viewpoint

Issues

People

-

Process

If the team is large then it is more efficient to have local daily scrums and then a global scrum of scrums with key persons present (network connection). (P Daily) In a distributed environment some sort of a summary report would be good to show and share to present project status for teams. This is especially important when people use different accent although the language is same. (P Daily)

Tool

Net meeting is a good tool to use. (P Comm) A chat-tool could be an alternative for a conference phone. (P Daily)

Fig. 3 illustrates respondents’ opinions related to Scrum claims. 5,0

Rate (1=disagree, 5=fully agree)

4,5 4,0 3,5 3,0 2,5 2,0 1,5 1,0 0,5 0,0 1

2

3

4

5

6

7

Claims

1 2 3 4 5 6 7

Distributed Scrum improves the visibility of the project status in relation to the previous procedure. Distributed Scrum accelerates the handling of changes in relation to the previous procedure. Distributed Scrum improves the management of features through the entire project lifecycle in relation to the previous procedure. Distributed Scrum improves understanding of requirements in relation to the previous procedure. Distributed Scrum improves the team communication in relation to the previous procedure. Distributed Scrum improves the utilisation of the knowledge possessed by the entire team in relation to the previous procedure. Distributed Scrum improves the commitment to the goals of the project in relation to the previous procedure.

Fig. 3. Respondents’ opinions about Scrum related claims.


93

3.2 Preliminary Patterns Derived from a Case Study The answers were analyzed and after that some organizational patterns were created (later a pattern) based on gathered information and related research materials. Some of the important patterns from the viewpoint of a distributed project management and Scrum are described below. ID: P Kick-off(1) & Name: Have a kick-off meeting (only name) ID: P Rel(2) & Name: Make a release plan with some sprints x x x

Problems: One big project plan could be a risk in distributed development. Solution: Split your project in many sprints. Iterative and incremental sprints improve the visibility of a project and improve the motivation of team members. Also working software is a good measurement of a sprint. Consequences: Sprints make it easier to plan your project and to change it, if needed. Visibility of a project is also better when you can see the results in the end of each sprint, in a sprint review meeting. In the end of a sprint it is also possible to have a retrospective meeting in which a process can be changed if it is really needed.

ID: P Org(3) & Name: Organize needed Scrum roles in each sites x x

x

Problems: Communication between different sites. Solution: Replicate needed Scrum roles in every site (e.g. Scrum master, a college of Product owner, Architect, IT Support, Quality assurance etc.) A person with the same kind of role can communicate efficiently between sites and inside his/her own site. Also architecture of a product has an effect on the division of responsibilities and roles as well as which phase of development work is made in which site. Consequences: Distributed development needs formal communication and a clear communication organization. A college of a product owner helps e.g. with understanding of feature lists and related specifications. A Scrum master in each site is also a key person. One person can have many roles in a project.

ID: P ALM(4) & Name: Establish Application Lifecycle Management tool x x

Problems: Separate Excel files are difficult to manage and project data is difficult to find, manage and synchronize between many sites Solution: A common Application Lifecycle (ALM) Management solution for all information in a project e.g. Product Backlog, Sprint Backlog, Sprint Burn Down Chart also e.g. source code, data of faults, requirements, testcases, other documents etc. An ALM solution includes e.g. storage places for artifacts and guidelines for common processes and effective user rights methods and role based views in use to see certain data. It also includes a possibility for global access regardless of a time and a place. ALM can consist of databases based tools which might have too simple GUI and other properties. ALM can also be a group of dedicated tools which have been integrated with each other.

94


x

Consequences: An ALM solution costs quite a lot of money and use of ALM needs training. With ALM, time is saved when information is found more quickly and common processes make work more efficient. Anyhow, a lot of work is needed to ensure that only needed information is visible to different user groups

ID: P Infra(5) & Name: Establish a fast and reliable infra ( P Infra) (only name) ID: P Comm(6) & Name: Establish efficient communication methods (only name) ID: P Know(7) & Name: Knowledge transfer x x

x

Problems: Lack of knowledge about domain and features to be developed. Solution: Domain knowledge can be distributed by visitors in different sites. Also features with short specifications and possible diagrams in Sprint Backlog improve knowledge transfer. Detailed specifications should be made latest during the earlier sprint. Consequences: Distributed development requires more traveling and a change of information. Specifications are also needed to clarify the contents of each feature.

ID: P Visual(8) & Name: Visualize status of project x x x

Problems: Status of project is not known. Solution: Use of Sprint burn down charts, trends of bugs, tasks, test-cases etc. from ALM solution. Working software in the end of Sprint is also a good measurement. Consequences: Iterative development with good measurements and a requirement of working software in the end of Sprint visualize the status of a project very well.

ID: P Daily(9) & Name: Have many Daily Scrums x x

x

Problems: One Daily Scrum is not always enough. Solution: Scrum of Scrums is used to manage big groups. One Daily Scrum could be enough for a small group with good communication tools e.g. conference phones, web cameras, video conferences, chat tools. With foreigners, written logs can be one solution e.g. chat logs or common documents. Consequences: Written logs are sometimes easier to understand. Scrum can be scaled with the use of Scrum of Scrums in a distributed development.

5 Discussion The results obtained from this case study indicate some important issues for a distributed Scrum in distributed development. The importance of distributed Scrum


95

has also been reported in other studies in industry, e.g. in [8]. Fairly simple solutions are sufficient when operating in a local environment with Scrum. However, in this distributed Scrum case study, secure shared information repositories as ALM solution and electronic connections (e-meetings, teleconferencing, web cameras, chat, wiki) were seen as essential solutions to support a collaborative mode of work. This has also been indicated in other case studies related to global product development, for instance, in [1] and [7] (e.g. intranet data sharing, teleconferencing). The results of this case study show that successful implementation of distributed Scrum has many benefits for case projects. The team members are more satisfied with the newly distributed Scrum than with the previous solution even though there are still some challenges that need to be solved in future improvement efforts. The results show that the most successful distributed Scrum issues have been improvements in visibility, management of features, communication, and commitment to the goals of the project. The importance of these issues for distributed development has also been discussed in [12]. Communication problems have been resolved by utilizing Scrum of Scrums, Daily Scrums and other Scrum practices and also other communication means. These issues have also been discussed both in [13] and [14]. Other major issues that emerged from the needs for more effective distributed agile project management: x x x x x

Enforcement to a global common process that is tool-supported. Same ALM solution for every site. Training of new methods and tools is important for the consistent usage of tools and practices. Product Owner should represent as a customer and interact with development personnel. Resolve knowledge transfer problems in distributed development environment: -

x

Local Product Owners and Scrum masters are needed for each site to facilitate knowledge sharing. Clear Product/Sprint Backlog items that will be specified more detail during previous Sprint. Specifications should be able to contain rich information in order to facilitate understanding (figures, diagrams). Ability to travel when it is needed. Efficient communication means.

Resolve visibility problems using Scrum based reports e.g. burn down charts, trends of bugs, tasks, test-cases, remaining effort etc. Working software in the end of Sprint visualize the status of a project very well.

96


6 Conclusions An efficient project management process is very important for companies. The goals and plans of a project must be communicated and working software must be developed in a product development faster and more efficiently than earlier, even in a distributed development environment. This paper presents a research process for mining organization patterns in order to improve an agile project management process, Scrum, in distributed development. The research method has included a framework based on Scrum practices and artifacts and the results of questionnaires and interviews have been described in the form of a table. Furthermore, the results have been generalized in the form of organizational distributed Scrum patterns and a list of important issues. The important issues from the view of people, processes and tools in different phases were studied. The results emphasise that distributed Scrum is possible to implement with the help of an ALM solution and distributed Scrum patterns. The key issue is also that the ALM solution provides global access and it changes distributed development partly back to centralized development. Of course, all distributed Scrum and other distributed agile patterns haven’t been found yet and also distributed Scrum doesn’t solve all the problems in distributed development. But at least this is a start for research to find distributed Scrum patterns. Organizational patterns seem to be one good method for describing solutions to a problem. Generalized patterns make it easier for other companies to reflect on and to apply the results to their own cases. Future research directions will be the analysis of experiences with the current patterns in future development projects, the improvement of the patterns and the creation of new patterns according to the feedback gained from projects.

References [1] [2]

[3]

[4] [5]

[6] [7]

Battin RD, Crocker R, Kreidler J, Subramanian K, (2001) Leveraging resources in global software development, IEEE Software, Vol. 18, Issue 2, 70 – 77 Herbsleb JD, Grinter RE, (1999) Splitting the organisation and integrating the code: Conway’s law revisited, Proceedings of the 1999 International Conference on Software Engineering, 16-22 May 1999, 85 – 95 Damian D, Moitra D, (2006) Guest Editors' Introduction: Global Software Development: How Far Have We Come?, IEEE Software, Sept.-Oct. 2006, Vol. 23, Issue 5, 17 - 19 Nidiffer E, Dolan D, (2005) Evolving Distributed Project Management, September/October 2005 IEEE Software Abrahamsson P, Salo O, Ronkainen J, Warsta J, (2002) Agile software development methods: Review and Analysis. Espoo, Finland: Technical Research Centre of Finland, VTT Publications 478, http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf www.agilealliance.org, (available 10.07.2007) Ramesh B, Cao L, Mohan K, Xu P, (2006) Can distributed software development be agile? Communications of the ACM, Vol. 49, No. 10


[8]

[9] [10] [11] [12] [13] [14]

97

Sutherland J, Viktorov A, Blount J, Puntikov J, (2007) Distributed Scrum: Agile Project Management with Outsourced Development Teams, Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS) Farmer M, (2004) DecisionSpace Infrastructure: Agile Development in a Large, Distributed Team, Proceedings of the Agile Development Conference (ADC’04) Doyle C, (2007) The importance of ALM for aerospace and defence (A&D), Embedded System Engineering (ESE magazine), June 2007, Vol. 15, Issue 5, 28-29 Coplien JO, Harrison NB, (2005) Organizational Patterns of Agile Software Development, Pearson Prentice Hall Leffingwell D, (2007) Scaling Software Agility, Addison-Wesley Schwaber K, (2004) Agile Project Management with Scrum, Microsoft Press Schwaber K, (2007) The Enterprise and Scrum, Microsoft Press

Understanding the Collaborative Workspaces Gilles Gautier, Colin Piddington, and Terrence Fernando Future Workspaces Research Centre, University of Salford, Salford, M5 4WT {g.gautier, c.piddington, t.fernando}@salford.ac.uk

Abstract. Despite the concept of working collaboratively being very popular, its implications on the organisational structures and on the human requirements are not completely understood. As a result, the advanced technologies used to enhance collaborative work have often had a limited or even a negative impact on the work efficiency. Common issues often involve human factors, such as the acceptance of the new product by the users, the lack of communication between users and the working culture. As a consequence, a better understanding of the human needs would facilitate the development of better tools to support group work as well as more efficient organisations. Therefore, this paper compares the organisation and the human perspectives on collaboration in order to identify the barriers to implementing it. In particular, it focuses on issues related to the life cycles, organisation structure, information flow and human motivation. It also introduces the case of virtual organisations and their difficulty to generate efficient collaboration. Keywords: Socio-technical impact of interoperability, The human factor in interoperability, Knowledge transfer and knowledge exchange

1 Introduction Due to a lack of understanding of the implications of collaboration, it is often believed that new technologies will enhance collaboration by supporting the organisational processes [1]. But psycho-sociologists have demonstrated since the 19th century the importance of the social relationships between the workers [2]. Indeed, it appears clearly in the literature that social interactions are necessary to build trust and to generate a shared understanding of the project aims and processes. These are among the main features of collaboration [3] and [4]. Efficient technological workspaces for collaboration should therefore combine the support of the organisation processes and of the workers. So far, these two objectives are usually considered independently because of the difficulty to integrate both [5]. Consequently, the social and psychological features of the

100

Gilles Gautier, Colin Piddington and Terrence Fernando

workers are not represented in enterprise models where the humans are only seen through their roles in supporting the processes. As a result, the workers are often reluctant to integrate new technologies in their workspaces because they are associated to a change of their working culture. A better understanding of the working environment and its influence on the work efficiency would therefore permit the creation of better workspaces and the integration of more user-friendly technologies. In addition, it might be necessary to limit the intrusion of IT in the workspace in order to better respect the human nature. These issues are discussed in this document which starts with an introduction to collaboration before introducing the organisation’s and worker’s viewpoints on the need for collaborative workspaces. Finally, the role of the technology in supporting group work is discussed in the last section. The discussions of this paper are based on a competency-oriented decomposition of the organisation structure that is presented in the third chapter.

2 Understanding Collaboration As defined by Montiel-Overall [4], “collaboration is a trusting, working relationship between two or more equal participants involved in shared thinking, shared planning and shared creation”. This notion of collaboration is difficult to implement by enterprises because it implies quite open communications and social relationships between the participants, as explained in the group working theories. Consequently, organisations rarely achieve collaboration when they try to generate it. Instead, as will be explained in the next section, their non flexible structures and IPRs limits them to work cooperatively, which is not as beneficial for the group work. Therefore, collaboration necessitates the building of a team over four stages (Fig. 1) that have been identified by Tuckman [6]. First, the forming phase is when people join and set up the roles of each others. This is an observation phase strongly influenced by the leaders of the group and the structure of the participants’ roles [7]. In the second phase, called the storming phase, everyone tries to assure his position and the authority of the leaders is challenged. Conflicts arise between the members of the group. In the norming phase, people become closer and often start sharing a social life. The roles are clear in the group, and discussions become productive. Finally, the performing stage is when the collaborators are fully aware of the group structure, of each others’ roles and objectives, as well as of their capacities and ways of working. Like other researchers before him, Tuckman finally realised that as the group becomes closer, the efficiency of the work increases in parallel with the motivation of the collaborators. Those stages can be explained partially by the need to share an awareness of the working group between the collaborators, as explained by the Johari window [8]. This common knowledge, which is called the open area, is limited when the group forms, and it soon integrates a shared understanding of the roles of everyone (forming phase), and the objectives of all the participants related to the collaborative work (storming phase). In the norming phase, the group becomes stronger and share some social experiences outside work that allow them to

Understanding the Collaborative Workspaces

101

understand each others better, so that they can communicate more efficiently and trust more easily. This social need is the main difference between collaboration and cooperation, where only the understanding of the working group structure is essential. As a consequence, the performing phase can hardly be achieved.

Formin g

Storming

Norming

Performing

Fig. 1. The evolution of the roles in a collaborative team

Of course, any set of people cannot become a highly collaborative group. Among others, Kurt Lewin has shown that there is a need for an interdependence of fates and tasks between collaborators [9]. This corresponds to Vroom [10] theory that will be later introduced. Indeed, people not only need to share a common objective, but also a shared reward. If the work of everyone benefits only a few, this contradicts the instrumentality element of Vroom’s theory. The interdependence of the collaborators is then called negative, because their objectives conflict with each others. This can lead to the end of the group work due to a lack of communication, and to a lack of information sharing. On the opposite, positive interdependence enhances participation, discussions, friendship and decreases aggressive behaviours. It enables the collaborators to achieve Tuckman’s performing phase and the high productivity observed by Fayol [2] and Mayo [11].

3 The Organisational Layers Collaboration is usually required for particular projects in order to support interoperability between the stakeholders. During these projects, organisations usually adopt traditional pyramidal structures with managerial roles at the top and functional roles at the bottom. The top level roles mainly concentrate on the project objectives and processes, while the bottom ones are usually focussed on one skill or competence. Consequently, project organisational structures can be decomposed in three layers that are introduced here from top to bottom in order to explain the environment of the collaboration: x

The Project Manager (PM) has a management and control function in the overall project. He is responsible for the achievements of the project, and he must make sure that the organisation’s project objectives will be met. Therefore, he defines the processes that will be followed during the project in

102


order to meet a customer or product demand (time and cost) and he also defines the conditions that will allow to start or finalise each phase of the project. Finally, he is responsible for finding and managing the functional resources necessary to support the project processes (Fig. 2). He is not usually concerned by human factors aspects and mainly considers the employees at functional levels as the actors of the processes. Identify a set of objectives

Define the project processes

Determine resource allocation

Fig. 2. Simplistic view of the Project Manager’ successive tasks

x

The Management Team (MT), led by the project manager, is in charge of the integration of several competencies/functions during a particular phase of the project. A Competency Representative is present in the team for each competence involved in this phase. The first task of the management team is to match the processes defined by the project manager with the corporate competencies. Consequently, the MT must build a common understanding between its members in order to allow them to take better decisions when a conflict has to be solved. If some competencies are missing in the organisation, then a virtual organisation is created by acquiring competencies through outsourcing or sub-contracting (Fig. 3). The management team is where collaboration is the most likely to appear because a shared understanding is required to take better decisions and the competency representative have full control on the IPRs of their competencies. Build up a shared understanding

Identify relevant competencies

Build up a VO if required

Fig. 3. Simplistic view of the Management Team' successive tasks

x

The Skills Silos are vertical structures responsible for the development of the competence. Thus, they contain the organisation knowledge for each competency involved in the project. The competency representative, who represents the silo in the management team, is at the top of the silo, possibly supported by other levels of managers. At the bottom of the silo, the employees with the functional competencies/skills act according to the decisions made by their managers. They have a limited understanding of the overall project and they usually have little contacts with other silos, which disable the possibility to build up an inter-silos team. Consequently, the functional


103

levels do not usually get involved in any collaboration with other silos, and most of the wrong decisions and interoperability issues appear at these levels.

The above components permit a simplistic representation of an organisation structure for one phase of a project. This simplistic view is nonetheless sufficient to highlight the need for collaboration in the management team in order for them to share a common understanding of the project and to assure that every view point concerned will be considered equally throughout the project. In fact, late problem discovery has proved to be extremely costly in many industrial cases and they are regularly due to a limited understanding of the consequences of decisions made during previous management meetings. Similarly, collaboration at the silo level is essential to permit the workers to share cross project knowledge and experience in order to allow faster problem resolution or innovation [12]. The organisation structure presented here corresponds to a snapshot in time, but the management teams change throughout the project, as well as the involvement of the skills silos.

4 The Life Cycles The Product Life Cycle is the time line representation of a set of sequential phases from the birth to the death of a product or service. This addresses conceptualisation through design, to production, to deployment, and finally replacement (Fig. 4). The Product Life Cycles are extended by the maintenance and recycling to face the increasing demand for “through life services” [13] and [14] as well as environmental issues. In this line, some advanced work in standards and PLCS (Product Life Cycle Support) has already been done in the USA Department of Defense and in the UK as traditional manufacturers change their business from product manufacture to through life service (Leasing). In addition, the building sector is following a similar path with PPP (Private, Public Partnerships). Therefore, the outcome of a life cycle is often not only a product but also a service. This demands a far reaching collaborative way of working across organisations in order to consider the requirements at maintenance and recycling levels as early as at the design phase. Conceptualisati

Design

Production

Deployment

Maintenance

Recycli

Fig. 4. Example of product life cycle

In order to save time, these phases are often parallelised which means that a phase can start before the previous one has been completed. This specific adaptation of the product life cycle is used by the project management processes. The overlapping period between the start of a phase and the termination of the previous one is only possible after a Maturity Gate (Fig. 5) meeting where the

104


representatives of several competencies meet to assess the risk of change of starting a new phase of the project. Each overlapping phase corresponds to a high risk period where any changes in the previous phase can become extremely time consuming and costly to accommodate in later phases. The chairman of these meetings is the project managers, so that he can control the project from the clients’ perspective.

Conceptualisati M

Design M

Production M Deployment M Maintenance M

Recycling

Fig. 5. Example of project management process

Decisional Gates occur within planned meetings and chaired by the project manager, and whose outcomes are critical for the project because they aim at solving or avoiding problems. As a consequence, they usually happen within a phase of the project, and even might involve representatives of later phases, such as maintenance managers. Decisional gate intent is to limit delays in the project progress by the identification of optimised ways to progress. Nevertheless, the participants of these meetings are the competency representatives and they usually need to consult with their skills silos in order to resolve specific difficulties or assemble additional data. Since these consultations cannot usually be made during the meetings, the decisional gates often consist of a series of meetings that result in action lists for the competency representatives and their skills silos. If the meeting workspace could be connected to the skills silos workspaces, then it would be possible to make decisions faster by discussing solutions with the relevant silos during the course of the meeting. Two types of meetings can be differentiated - the planned meetings that are held throughout the project management process to assess progress and to mediate on problem resolution, and the reactionary ones that are needed to address urgent issues - they only influence the technology used and not the roles of the stakeholders, as the solution requires near real time performance. For reactionary meetings, mobile technologies might be useful to improve the reactivity of the organisation where meeting participants are not available or needed locally, even if these technologies could limit the level of interaction between the participants to the meeting.


105

5 The Processes and the Motivation Once the objectives of each phase of the project and the conditions to parallelise phases have been defined, the project manager aims at generating the processes that will have to be followed within each phase of the project in order to achieve the corresponding objectives. Roles are defined and assigned in accordance with the management teams. The view of the organisation, which is often the one of the project manager, is project-based and sees the employees as the actors of the processes. As a consequence, human factors are little considered by the higher levels of the organisation and the structure of the organisation tends to become rigid. However, Henri Fayol [2] has identified since the end of the 19th century the role of the administrative part of an organisation as supporting the employees. He also highlights the importance of giving structure to the employees, and the benefits of self-organisation which is often supported by social relationships. As an example, his miners organised themselves in small groups according to their friendships and relationships. The groups were more stable and more productive thanks to the increased motivation of the employees. This is consistent with the group building theories discussed above, which notice the increasing importance of informal relationships over time while structure is essential at the beginning (Fig. 1). On the opposite, the scientific management of work proposed by Taylor [15] and which corresponds to the decomposition of work into processes has shown some limits. Indeed, it increases sickness and absenteeism due to the lack of motivation of the employees. Nowadays, the French automotive sector and its high suicide rate is a good example of the consequences of such an approach. Therefore, it is crucial to support both structured and informal relationships when trying to develop collaboration. It is also essential to make the distinction between an employee and its roles in the organisation. This permits, for example, the consideration of the worker’s motivation by understanding his personal objectives, interests or culture. Indeed, it is sometimes believed that humans are not naturally inclined to work and they must see a personal gain in order to do it [10]. The most studied theory in motivation science is the hierarchy of needs developed by Maslow [16]. He presents the human needs in a five-level hierarchy. Those needs are determinant for human behaviours because they act as motivators as long as they are not fulfilled. From bottom to top, the five levels are: physiological needs, safety needs, love needs, esteem needs, and self-actualisation needs. The physiological needs are the ones that trigger homeostatic and instinctive behaviours. The safety needs include security, order and stability. The love needs correspond to our social lives and look for relationships. The esteem needs involve appreciation and recognition concerning abilities, capabilities and usefulness. Finally, the self-actualisation needs refer to our desire for self-fulfilment. The needs in the highest levels only act as motivators if the lower levels are already fulfilled. After a level of needs is fulfilled, lower needs become less important and higher ones are predominant. Even if the hierarchy is supposedly independent from any culture, the importance of each need can depend on the past

106


experiences of the people. As an example, a lack of love during childhood can lead to psychological illness and to a depreciation of love needs. As demonstrated by Herzberg et al. [17], the lowest levels needs are often seen as required ones by the workers. He considers those as hygiene factors, which are responsible for disaffection at work. As a consequence, unfilled hygiene factors can lead an employee to perform his tasks poorly or to leave his job. The highest levels of Maslow’s hierarchy of needs act as motivators that make the employees produce more effort to achieve the objectives associated to their roles in the organisation. In order to keep employees motivated, any work must therefore target the three factors that influence human’s motivation according to Vroom [10]: expectancy (be sure that his role is valuable in the project, and that others’ participations will lead to the achievement of the general objective), instrumentality (effort is rewarded accordingly to the effort produced) and valence (reward is appropriate to the employee’s need). To summarise, supporting the motivation of the employee must be considered as important as supporting the processes he is involved in when implementing collaborative tools. However, motivation evolves over time, and it is difficult to predict. It starts with a need for security before moving to self-development. Besides, an innovative organisation will benefit from more flexibility because a major issue is to integrate innovative methods and techniques in the organisations. Not being able to integrate the innovation could limit the user’s motivation because he would have the feeling that his effort were vain, which contradicts with Vroom’s requirements.

6 Virtual Organisations Contractual terms surround most collaborations and describe the constraints to protect the organisation and its customers and to build trust. Indeed, from an organisation viewpoint, trust mainly refers to the respect of the contractual agreement because this data is quantifiable and therefore tangible [18]. As part of the contract the organisation must define what can be shared, which is usually easier than to identify what needs to be protected (Intellectual Proprietary Rights). However, it limits collaboration because companies tend to share the minimum information, and it becomes difficult to build a common understanding of the project. Consequently, innovation is reduced and the decisions are easily made with an incomplete understanding of their consequences. This is particularly relevant in cross-organisations collaborations.


107

Fig. 6. The roles of an employee

Additional issues appear when considering the employee viewpoint, such as the workload or conflicts between roles for several organisations. Indeed, enterprise models are often project-based, and they cannot capture the conflicts between organisations. The example of an employee having to share his time between his main organisation and a virtual one is given in Fig. 6. He can play roles in both organisations independently for each others, and these roles can conflict with each others in terms of workload, IPR or objectives. The decisions of the employee, based on his manager’s advice or on his motivation, will then influence his choices. Therefore, there is a need when representing Virtual Organisations to add details about the involvement of the worker in external activities. Virtual Organisations are mainly necessary when an organisation does not have the full resources necessary to build a successful project. Two configurations are presented in Fig. 7 to illustrate some extremes of inter-silos relationships. In the first one, the Virtual Organisation is formed by the combination of skill silos that still work for their main organisations (Fig. 7-a). As explained before, the information exchanges between the stakeholders are controlled and limited to the minimum. Each organisation occasionally allocates some working hours for the workers, who mainly work for their own organisation. As a consequence, innovation is also limited by the lack of understanding between silos, and it is usually derived from the collaboration objectives. This is typical of supply chains and short term collaborations (partnering). In the second configuration, the virtual organisation tends to become autonomous from its parent organisations (Fig. 7-b). It creates its own working culture and the communications between its skill silos are less constrained. The workers tend to be fully allocated to the Virtual Organisation, and IPRs protection becomes less important. As a consequence, innovation is facilitated by the shared understanding between the silos. Since the links with their original organisations are weaker and less controlled, the Virtual Organisation ultimately becomes independent and works as a new organisation (merger or new business).

108


Organisation A

Organisation

(a)

B

Virtual Organisation A+B

(b)

Fig. 7. Examples of Virtual Organisation

Partnering intends to limit the possible drawbacks of collaborations due to the compartmentalisation of the knowledge and the development of a blame culture building a dependency of faith between organisations. This approach promotes similar values as inter-personal collaborations, such as equality, transparency and mutual benefits [19], and it also aims at generating win-win co-operations based on each organisation’ strengths.

7 Information Flows When considering the information flows, Virtual Organisations are where collaboration has the most impact because this is where the information shared is the most carefully selected and protected for commercial or privacy reasons. The competency representatives, due to their managerial roles, usually have the responsibility for defining what can be shared with other silos. Consequently, any sharing of new information must be validated by the relevant competency representative. However, as discussed before, the need for inter-silo collaboration often involves the participation of employees at bottom levels. Consequently, data is needed to be exchanged in the shared data environments via the demilitarised zones of the parent organisations. They must keep control on it through their competency representatives, even in emergency situations. The IT collaborative workspaces must allow communication across the organisation, but the IT tools developed on top of them often support their competences and their culture-based organisations. As a consequence, they store their data in a way adapted to these competences, taking into consideration the processes during which the data has to be accessed, or used, and manipulated by the corresponding disciplines. APIs are then used to extract the required view of the information and to translate the data stored into standardised or contractually agreed information so that it can be shared with other silos (Fig. 8). However, translations are often accompanied by loss of information and inter-silo interoperability is not then fully achieved. Data incompatibility remains a major


109

problem, even between silos sharing similar applications between silos because the software versioning, the platform used or the configuration can be responsible for incompatibilities at the data level [1].

Applicatio A PI Inform ation store



Fig. 8. Distribution of the product data between the skills silos

A solution to solve skills silos interoperability issues is proposed by IT: specifying the processes more carefully and completely in order to be sure that every situation has been considered and limiting the human initiative, which is unpredictable but innovative. However, this theory must be based on the strong assumption that any task can be detailed as a set of processes, because the workers involved in these processes would trust them and they would loose the ability to identify problems. As a consequence, any issue would be discovered very late and have huge financial consequences, as it was the case for the production of the Airbus A380. Besides, people would loose their ability to innovate because the structure of the organisation would be too rigid to integrate any development. Finally, the workers would not need to communicate with each others in order to achieve their objectives because of the processes efficiency. Their isolation would not allow them to build a shared understanding of their project and would compromise any intent to implement collaboration. Consequently, the implementation of tools to support processes should be modified in order to allow for the development of informal relationships between the workers. The support tools should focus on intra-silo work, where communications are already easy and efficient because people share similar background and working cultures.

8 Conclusion The above decomposition of the organisations’ structures during projects permits to highlight that the real challenge for supporting collaborative organisations is to generate social interactions between skills silos. Not only it would increase the motivation of the workers, but it would also facilitate innovation and facilitate

110


interoperability. IT is indeed extremely useful to automate processes and to support personal work, but its current scientific approach seems to be quite inefficient for supporting the social aspects of collaboration and its faults have increased financial consequences. Limiting the role of IT to a knowledge sharing tool and inter-silos communication enhancer would therefore allow for the development of informal interactions between the stakeholders at any level. This could facilitate the early problem identification, innovation and the building of trust. However, socialcomputing must still progress and prove that supporting the workers thanks to IT is not only a dream but that it can become true. This will be an objective of the CoSpaces project, which plans to develop user-centric technological workspaces based on the user’s working context.

Acknowledgments The results of this paper are partly funded by the European Commission under contract IST-5-034245 through the project CoSpaces. We would like to thank also Sylvia Kubaski and Nathalie Gautier for their useful resources concerning the psycho-sociological area, as well as all the industrial partners of the CoSpaces project for their information about current industrial practices and challenges and the research partners for their enlighten knowledge sharing.

References [1]

Prawel, D.: Interoperability isn’t (yet), and what’s being done about it. In: 3rd International Conference on Advanced Research in Virtual and Rapid Prototyping, pp. 47--49. Leiria, Portugal (2007) [2] Reid, D.: Fayol: from experience to theory. Journal of Management History, vol.1, pp.21--36 (1995) [3] Schrage, M.: Shared minds: The new technologies of collaboration. Random House, New York (1990) [4] Montiel-Overall, P.: Toward a theory of collaboration for teachers and librarians. School library media research, vol 8. (2005) [5] Klüver, J., Stoica, C., Schimdt, J.: Formal Models, Social Theory and Computer Simulations: Some Methodical Reflections. Journal of Artificial Societies and Social Simulation, vol. 6, no. 2 (2003) [6] Tuckman, B.: Developmental sequence in small groups. Psychological bulletin, vol. 63, pp. 384-399 (1965) [7] Belbin, M.: Management Teams, Why they Succeed or Fail. Heinneman, London (1981) [8] Luft, J., and Ingham, H.: The Johari Window: a graphic model for interpersonal relations. University of California Western Training Lab (1955) [9] Brown, R.: Group Processes. Dynamics within and between groups. Blackwell, Oxford (1988) [10] Vroom, V.: Work and Motivation. Jon Wiley & Sons, New York (1964) [11] Mayo, E.: The Social Problems of an Industrial Civilization. Ayer, New Hampshire (1945)


111

[12] Lu, S., Sexton, M.: Innovation in Small Construction Knowledge-Intensive Professional Service Firms: A Case Study of an Architectural Practice. Construction Management and Economics, vol. 24, pp. 1269--1282 (2006) [13] Gautier, G., Fernando, T., Piddington, C., Hinrichs, E., Buchholz, H., Cros, P.H., Milhac, S., Vincent, D.: Collaborative Workspace For Aircraft Maintenance. In: 3rd International Conference on Advanced Research in Virtual and Rapid Prototyping, pp. 689—693. Leiria, Portugal (2007) [14] Ward, Y., Graves, A.: Through-life management: the provision of integrated customer solutions by Aerospace Manufacturers. Report available at: http://www.bath.ac.uk/management/research/pdf/2005-14.pdf (2005) [15] Taylor, F.W.: Scientific Management. Harper & Row (1911) [16] Maslow, A.: A theory of human motivation. Psychological Review, vol. 50, pp. 370-396 (1943) [17] Herzberg, F., Mausner, B., Snyderman, B.B.: The motivation to work. Wiley, New York (1959) [18] TrustCom: D14 Report on Socio-Economic Issues. TrustCom European project, FP6, IST-2002-2.3.1.9 (2005) [19] Tennyson, R.: The Partnering toolbook. International Business Leaders Forum and Global Alliance for Improved Nutrition (2004)

Models and Methods for Web-support of a Multi-disciplinary B2(B2B) Network Heiko Weinaug, Markus Rabe FhG IPK, Pascalstrasse 8-9, 10587 Berlin, Germany {heiko.weinaug, markus.rabe}@ipk.fraunhofer.de

Abstract. B2B manufacturing networks offer significant potentials for service providers, which can offer and operate services with the complete network instead of connecting to each single company to be involved. The term multi-disciplinary B2(B2B) characterizes this business-to-network relationship. The FLUID-WIN project is developing and using new business process models and methods as base for the related tools’ development for the smooth integration of logistic and financial services into a B2B manufacturing network. Keywords: Business Aspects of Interoperability, Business Process Reengineering in interoperable scenarios, Enterprise modeling for interoperability, Modeling cross-enterprise business processes, Modelling methods, tools and frameworks for (networked) enterprises

1 Introduction European enterprises have increased the degree of outsourcing, steadily, in the last decade leading to many more partners along the supply chain. In combination with smaller batch sizes and delivery requests on shorter notice, the coordination requirements are tremendous for all the companies involved. The number of processes to be synchronised has increased, significantly. Nevertheless, investigations demonstrate that up to 30% of the administrative effort can be saved by establishing electronic interchange mechanisms in the supply chain [10]. A very efficient additional effect could be achieved by connecting the B2B network with service providers. This approach has been described by Rabe and Mussini and introduced as the business-to-B2B or B2(B2B) mechanism [6,12,13]. Obviously, financial services providers can offer services based on the electronic invoices circulating in the B2B network. Also, logistic service providers can provide services based on the electronic transportation documents available through the B2B network, taking into account current order information that includes announced or expected delays as well as forecast information.

114

Heiko Weinaug, Markus Rabe

However, there is a need for a systematic approach and easily applicable instrument as a prerequisite to establish multi-disciplinary B2(B2B) services and to develop supporting tools for multi-enterprise B2B networks. Especially, the approach has to handle the large set of enterprises included in B2B manufacturing networks, whereas each has its own wishes, constraints and might be embedded in various other B2B networks. Moreover, the processes of the services providers have to be synchronized and integrated with the network processes. Beside the organizational aspects, the approach has to manage the different local and networkbound IT solutions as well as their relation to each other, to the processes and the actors during the service use. The FLUID-WIN project, partially funded in the sixth European Framework Programme, aims to the development a service integrating a B2(B2B) model and a prototype of the related e-commerce application. The FLUID-WIN consortium has decided to use the business processes modelling (BPM) as the main instrument related to certain steps in the development sequence to achieve the objectives. For this purpose, the Integrated Enterprise Modelling (IEM) Method [3] was used to set up a model of the B2(B2B) business process model. For example, during the field study phase a “Template Model” and various “As-is Models” were modelled to document mainly the results of the interviews done with the companies, thus helpimg to identify the user requirements, potentials and restrictions. All processes, constraints and potentials were merged into one “General Model”, which again was base for the definition of the “FLUID-WIN B2(B2B) Business Process Model”. The FLUID-WIN B2(B2B) Business Process Model represents the definition of a “To-be Model” that describes the new processes and methods as a base for the process and platform implementation through upcoming software development tasks. Based on the BPM models, the “Interdisciplinary Service Model” and the “Network Model” were developed as instrument to set-up and configure the service workflows and their related business actors in the FLUID-WIN platform.

2 The B2(B2B) Background and its Interoperability Challenges The FLUID-WIN consortium members found out that the integration of the business processes among companies belonging to a manufacturing network and companies providing logistic or financial services have major potentials, especially for manufacturing networks that are geographically distributed across state borders, where transportation duration is significant (days to weeks) and where cross-border payment and trade finance are far from being smooth. This is fertilized by connecting these service providers to the manufacturers’ B2B platform. This B2(B2B) approach is in contrast to the “traditional” way of connecting each single company with each related service provider. The effort saving through the new approach is significant, as interfaces with customers, suppliers, financial service providers and logistic service providers (figure 1) are replaced by one single interface to the new B2(B2B) platform. In this context, “multidisciplinary” indicates that the services to be integrated into the network are from other domains,

Models and Methods for Web-support of a Multi-disciplinary B2(B2B) Network

115

such as finance or logistics. Moreover, the new approach has to tackle crossdiscipline processes. This, of course, induces a high focus on the Interoperability topic on its various levels. Generally, interoperability is defined as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” [2]. In this context “system” can mean IT systems, but of higher importance are enterprises and other organizational units interacting with each other. To explain the challenges related to Interoperability, a framework for modelling cross-organisational business (CBP) processes from the ATHENA research project is used. The CBP framework was developed to provide modelling support for the business and technical level as well as for the transformation to executable models [1]. With respect to the modelling dimension this framework incorporates three levels:

Fig. 1. Network relations addressed by the B2(B2B) Approach

The Business level represents the business view on the cooperation and describes the interaction of the partners in their cross-organizational business process as base for the analysis of business aspects, like involved partners and their responsibilities. At this level, all FLUID-WIN Process Models cover the processes of 1) the B2B collaboration within a supply chain (manufacturing), 2) the business interaction with logistic service providers (B2B to LSP), 3) the business interaction with financial service providers (B2B to FSP), and 4) the support of new integrative services by functionalities of the FLUID-WIN Platform.

116


The Technical level represents the complete CPB control including the message exchange. Thereby, different task types can be distinguished: those which are executable by IT systems and those that are executed, manually. The challenge for the B2(B2B) Business Process Model is to use – as far as possible – standardised descriptions for the information exchange, like the XML Common Business Library [11], which later can be reused for platform programming and implementation. Furthermore, the model has to serve as 1) a base for the technical definition of services, 2) a supporting documentation for the development of the FLUID-WIN Platform concepts and software, and 3) for the generation of crossdomain classes, and as base for the customization and orchestration of services. On the Execution level the CBP is modelled in the modelling language of a concrete business process engine, e.g. a model based on the Business Process Execution Language (BPEL). It is extended with platform-specific interaction information, e.g. the concrete message formats sent or received during process execution. For example, the B2(B2B) Business Process Model has to deliver on the Execution level 1) support for FLUID-WIN Platform execution (e.g. help functionalities) and 2) integration of model concepts and platform architecture. Beside the results from the ATHENA projects, existing reference models and available standards were investigated to be used in FLUID-WIN. There are few commonly accepted approaches for models in the manufacturing supply network area. The Supply Chain Operations Reference (SCOR) model was designed for the effective communication among supply chain partners [8]. SCOR is a reference model, as it incorporates elements like standard descriptions of processes, standard metrics and best-in-class practices. However, still SCOR has no broad and common acceptance in industries, and the authors have experienced in their studies that most of the companies under consideration – especially the smaller ones – did not have any skills with respect to SCOR. The Value Reference Model (VRM) model version 3.0 provided by the Value Chain Group [9] follows a broader and more integrative approach than SCOR and supports the seamless and efficient management of distributed research, development, sales, marketing, sourcing, manufacturing, distribution, finance and other processes. Summarizing, VRM has a more substantial approach than SCOR. However, VCOR has not even reached the industrial awareness of SCOR.

3 Template Model, As-is Models and the General Model The authors have developed an approach for the analysis of supply chain networks, which was based on reference models and a guideline with several components [5]. This approach has been successfully applied for the analysis of requirements and potentials in regional supply networks [4]. For a number of field studies that were performed in the first months of the FLUID-WIN project, the approach was adapted to the specific needs of the service workflow investigation. In four different cross-European networks the field studies have involved 6 manufacturers, 2 Logistic Service Providers (LSP) and 5 Financial Service Providers (FSP) [6]. Different types of models have been used as efficient instrument to reach the


117

project aims. During the field studies these were the “Template Model”, the various “As-is Models” and the merged “General Model”, respectively. The Template Model provided an orientation during the interviews as a “guide” for relevant processes and topics. It served also as a base for modelling of the As-is Models. The As-is Models describe and document the results of the interviews done with the companies and thus helped to identify the user requirements, potentials and restrictions. Finally, the General Model includes the outcome of all the As-is Models and forms a unique interdisciplinary model, enabling an overview of the processes in all three domains (manufacturing, finance and logistics) and their relations among each other.

4 B2(B2B) Business Process Model The FLUID-WIN B2(B2B) Business Process Model is based on the requirements that have been derived from the field studies. It represents the definition of a “Tobe Model” that describes the new processes and methods as a base for the process and platform implementation through upcoming software development tasks. The model is an integrative framework in which all the workflows, interactions between the domains, services, functionalities and software modules involved are visualized. Hence, the description of the model has been done with a “servicefunctionality-module” approach. In order to clearly understand the model concept it is necessary to have a clear impression and definition of the terms “service”, “functionality” and “module” as they are used in this context. Services define the typical and ideal workflow provided by business service providers to other business partners, namely the interactions with their clients. Services are under the responsibility of service providers such as LSPs or FSPs and have their own workflows. Functionalities are the supporting elements which enable the users of the services to carry out electronically the activities supported by the B2(B2B) platform. The FLUID-WIN project develops a prototype for such B2(B2B) platform, which is called the FLUID-WIN Platform. The definition of the functionalities is, obviously, an important prerequisite for the FLUID-WIN Platform specification, as they define the workflow within the FLUID-WIN Platform. Functionalities describe how the FLUID-WIN Platform supports the service workflow and its participants. Exemplary, the functionality “Logistic Forecast Propagation” supports a certain step within logistic Transportation Service by gaining, transferring and providing logistical forecast information. Functionalities and services are strongly interrelated and depend on each other. A module is simply a piece of software within the B2(B2B) platform (i.e. user interface, database, logic etc.) made up of the FLUID-WIN supporting functionalities. According to the “service-functionality-module” approach, first the services were defined comprehensively during the development phase. Then the necessary functionalities of the FLUID-WIN Platform were identified and methodologically

118


specified depending on the requirements of the services. Finally, based on the generated functionalities, the modules were indicated. Based on these prerequisites the framework structure of the FLUID-WIN B2(B2B) Business Process Model has been developed. The highest level of the model is shown in figure 2. It contains six main areas, which are highlighted by numbers. Area 1 describes three symbolic enterprises related to different roles of manufacturing companies. Together they form a typical supply chain and represent the B2B network. These manufacturers are using the services provided by the service providers. The influence of these services on the physical material flow is displayed in the area 6 of figure 2 (e.g. transportation of goods performed either by the LSPs or by the companies themselves). The manufacturing supply chain is assumed to be organised by a supply chain execution tool which communicates with the local ERP software (relates to area 3). For this purpose, any SCE supporting tool such as I2, SAP APO, SPIDER-WIN etc. is suitable [7]. The control and information exchange integration through the supply chain is enhanced by the logistic as well as the financial participants using their own techniques, software and methods. Hence, the model areas 2 and 4 contain the process description of the services from the providers’ point of view, but related to the cross-domain information flow during the complete service. The model contains the LSP-provided services Transportation, Warehouse and Combined Logistics service. Related to financial services provided by the FSP the model contains Invoice discounting and Factoring service. Based on the field studies, these services have been selected for the prototypical implementation as they promise a high market importance. However, the architecture of the model and the platform allow for the definition of additional services at any time.

Fig. 2. FLUID-WIN B2(B2B) Business Process Model (Level 0)

Each service is described and modelled in a separate workflow. However, the modelling of the service workflows in domain-oriented model areas enables the


119

identification of common activities between the services as well as domain interactions. This is especially important for the common understanding and consensus building among the various involved parties (domain experts, platform users, and software developers). Figure 4 demonstrates the general structure of modelling services on an exemplary cut-off view from the transportation service workflow (detailing the area 2 in figure 2). The service workflow is clustered in four particular areas (figure 3): 1. The ideal service workflow describes each activity along the whole business process. This information is mainly used to define the workflow templates in the Interdisciplinary Service Model. 2. The responsible person or organization is identified for each activity of the business process. This is important, because the user interface definition of the platform has to support those actions. The information in relation to the service work sequence is also used to define the Network Model parameters later. 3. The identification of local IT and B2B support helps to define the right gateway functions to bridge between the FLUID-WIN Platform and the local IT and to identify the right place to source required data. 4. The most important part is the alignment of functionalities to certain processes within each service workflow. Each activity in the service workflows is interrelated with certain functionalities managing the service task supported by the FLUID-WIN Platform. The processes in area 5 (figure 2) explain these functionalities, their related information exchange, their configuration and dependencies in detail. The structure of the FLUID-WIN B2(B2B) support is indicated in figure 4, which consists of 3 different parts. 1. Ideal service workflow

Transportation service

Actors

2. Responsible Organization

FLW connection to local systems

3. Local IT

4. Platform functionalities FLW functionalities required to support the service workflow Specification and Delimitation of FLW functionalities

Fig. 3. A cut-off from the LSP’s Transport Service Workflow with Activities and Levels

120


Fig. 4. Areas and described Functionalities in the Functionality Level of the FLUID-WIN B2(B2B) Business Process Model

In the top part of the figure 4, the enabler processes for the FLUID-WIN Platform are indicated. There are enabler processes ensuring trust and security mechanisms and processes which enable the addition of new services into the Platform. The second part of the B2(B2B) support level explains the processes for the platform configuration and customization. The responsibility of these processes is to compile, configure and coordinate the whole network including the services according to the data entered by the users. Hence, these processes mainly relate to the Network Model and Interdisciplinary Service Model. As the service is then ready to use, the third part of the B2(B2B) support level defines all 13 functionalities in detail. The aim of the modelling task within this area was the specification of the content and the operation of each functionality as well as the information exchange and the interdependencies between different functionalities. The methods to be developed (calculations, logics etc.) and the related software modules were identified.

5 Interdisciplinary Service Model and Network Model The FLUID-WIN B2(B2B) model targets to flexibly support service processes attached to a B2B network with low customization effort. For this purpose, there is the necessity for generalized models as well as for company- and service-specific models. In order to establish a general, re-usable base for the services in the FLUID-WIN platform, an Interdisciplinary Service Model is defined that specifies


121

workflow templates which implement the functionalities and the parameters that can be adjusted with these templates.

Fig. 5. Relation between the B2(B2B) Model, the Interdisciplinary Service Model and the Network Model

The instantiation, parameterization, and connection of the workflow templates is conducted with the support of the Interdisciplinary Service Modeller, which then in turn results in the definition of operating services, which are used by a Service Engine to drive the B2(B2B) business processes in the FLUID-WIN Platform (figure 5) The service workflows are implemented without relationship to the companies, and are therefore templates which form the Interdisciplinary Service Model and need to be customized before they can be used in operation. In order to establish concrete B2(B2B) services, the Network Model with information about the network members is required (e.g. company name, location, user’s roles and access rights, interoperability parameters, etc.). This information is static, i.e. it does not depend upon the services that the company uses or will use in the future. In order to operate on the platform, Template Workflows are instantiated and configured with respect to the involved companies as well as with data specific for the service. The Interdisciplinary Service Modeller is used to enter this information.

6 Summary and Outlook The area addressed by FLUID-WIN is one of the areas where companies have still significant room for cost improvements. For example, although transport cost are still rather low, logistic processes and the related information processing represent

122


a considerable and growing factor. Performance indicators of a supply chain should be extended beyond the traditional ones like availability of goods, low inventory, physical transportation cost and IT investment. More emphasis should be put on low coordination cost and connectivity cost, improved reactivity to unpredicted changes, and transparency of selective information while hiding information from unauthorized partners. The FLUID-WIN B2(B2B) model and the supporting platform conduct a significant step forward to optimize the synchronisation of money flow and delivery. This paper highlights that supply chain control platforms for multi-disciplinary B2(B2B) Networks are a good option to increase flexibility and reduce cost, and the most efficient way to create such coordination service is the method of Business Process Modelling. It can be used very efficiently in distributed environments such as supply networks. Thereby, differently styled and structured models can be used in different development phases for specific purposes (e.g. gaining information from field studies; structuring service workflows and their relation to the supporting B2(B2B) platform; set templates for service configuration). Within modelling SCOR is a good base to define the terminology and basic supply network model elements, and also compatibility with SCOR is advantageous for more widely accepted templates. Methods to combine models enable Europe-wide and even transcontinental collaboration while designing and optimizing supply chains.

Acknowledgements This work has been partly funded by the European Commission through the IST Project FLUID-WIN (IST-2004-027 083). The work reported here has involved all project partners Joinet (Italy), Régens Information Technology (Hungary), AcrossLimits (Malta), Lombardini (Italy), TS Motory (Slovakia), Fundación Labein (Spain), Technical University of Kosice (Slovak Republic), mb air systems (UK), Tecnicas de calentamiento (Spain) and ITW Metalflex (Slovenia).

References [1]

[2] [3] [4]

Greiner, U.; Lippe, S.; Kahl, T.; Ziemann, J.; Jäkel, F.-W. (2007) Designing and Implementing Cross-Organizational Business Processes – Description and Application of a Modelling Framework. In: Doumeingts, G.; Müller, J.; Morel, G.; Vallespir, B. (eds.): Enterprise Interoperability - New Challenges and Approaches. London: Springer 2007, pp. 137 - 147 IEEE (2007) IEEE Standard computer dictionary: A compilation of IEEE standard computer glossaries. Institute of Electrical and Electronics Engineers, New York Mertins, K.; R. Jochem (1999). Quality-oriented design of business processes. Kluwer Academic Publishers, Boston Rabe, M.; Mussini, B. (2005) Analysis and comparison of supply chain business processes in European SMEs. In: European Commission (Hrsg.): Strengthening competitiveness through production networks - A perspective from European ICT


[5]

[6]

[7]

[8] [9] [10] [11] [12]

[13]

123

research projects in the field ‘Enterprise Networking’. Luxembourg: Office for Official Publications of the European Communities, pp. 14-25 Rabe, M.; Weinaug, H. (2005) Methods for Analysis and Comparison of Supply Chain Processes in European SMEs. 11th conference on Concurrent Engineering (ICE), München, pp. 69-76 Rabe, M.; Weinaug, H. (2007) Distributed analysis of financial and logistic services for manufacturing supply chains. In: Pawar, K.S.; Thoben, K.-D.; Pallot, M.: Concurrent innovation: An emerging paradigm for collaboration & competitiveness in the extended enterprise. Proceedings of the 13th International Conference on Concurrent Enterprising (ICE’07), Sophia Antipolos (France), pp. 245-252 Rabe, M.; Gocev, P.; Weinaug, H. (2006) ASP supported execution of multi-tier manufacturing supply chains. In: Proceedings of the International Conference on Information Systems, Logistics and Suppy Chain ILS’06, Lyon (France), CD-ROM Publication SCC (2006) Supply-Chain Operations Reference Model. Supply-Chain Council, http://www.supply-chain.org, visited 10.11.2006 VCG (2007) Value Reference Model. Value Chain Group. http://www.valuechain.org/, visited 08.11.2007 VDI (2005) Datenaustausch per EDV läuft oft mangelhaft. VDI Nachrichten No. 24, 17th June 2005, p. 24 XCBL (2007) XCBL, XML Common Business Library. www.xcbl.org/ (visited 30.05.2007) Rabe, M.; Mussini, B.: ASP-based integration of manufacturing, logistic and financial processes. In: XII. Internationales Produktionstechnisches Kolloquium, Berlin, 11.-12. October 2007, pp. 473-487. Rabe, M.; Mussini, B., Weinaug, H.: Investigations on Web-based integrated services for manufacturing networks. In: Rabe, M.; Mihok, P. (eds) New Technologies for the Intelligent Design and Operation of Manufacturing Networks. IRB, Stuttgart 2007.

Platform Design for the B2(B2B) Approach Michele Zanet1, Stefano Sinatti2 1

2

Joinet, Bologna (Italy) [email protected] University of Bologna, Phd Student (Italy) [email protected]

Abstract. Business-to-business or “B2B” is a term commonly used to describe the transaction of goods or services between businesses, enabled through a platform that allows for the interaction between customers and suppliers. Today, the new challenge is the integration of financial and logistics services into the business relationship without having to install thousands of peer-to-peer interfaces. The authors follow an approach that introduces a new level of business, that has been called B2(B2B). The purpose of this paper is to describe briefly the design of the FLUID-WIN project that targets this new approach, and to sketch the components to be developed in order to integrate the activities between significantly different business entities. Keywords: Decentralized and evolutionary approaches to interoperability, Design methodologies for interoperable systems, Interoperability of E-Business solutions, Interoperable inter-enterprise workflow systems, Tools for interoperability

1 Introduction The FLUID-WIN project aims to achieve a web platform for providing financial and logistic services to a manufacturing network that already uses a B2B platform for supply chain management [1]. This paper aims to present a particular aspect of this project, that is the design of the FLUID-WIN platform. From the point of view of technology the platform offers the management of an information flow connected to a material flow and the associated financial and logistic flows. The single flow is related to a series of activities that without the support of a platform, such as that offered by FLUID-WIN, would require the installation of a series of one-to-one interfaces for a single report. Every member of the network would require as many interfaces as the number of partners in the network with which it relates to, and this level of costs is unacceptable.

126

Michele Zanet, Stefano Sinatti

The significant progress that FLUID-WIN implies, involves switching from a one-to-one network to a new model where the platform is the only channel of communication through which it will be possible to efficiently implement the exchange of information between the three main domains : manufacturing, logistics and finance.

Methods Platform Services

FF

Finance

FF

L, FF L,

Logistics

M, L, L, FF M,

M, L, L, FF M,

M, L, L, FF M,

Impact and support of Fluid-WIN to the sector

Manufacturing

M = Manufacturing L = Logistic F = Financial

Fig. 1. Information categories exchanged between the platform and the sectors

Therefore, the main objective of FLUID-WIN is to interact on a single platform among manufacturing B2B network providers and logistical and financial service providers (Fig. 1), applying the new B2(B2B) approach [2]. This paper has been prepared when the project has not been completed yet, and when the detailed platform design was still in process. Nevertheless, the software architecture has been defined, and the components that implement the platform are Network Modeler, User Interface, Interdisciplinary Modeler, and Service Engine. In the following, the architecture of the platform is described, the base technologies used are characterized, and the software components of the platform are explained.

2 Architecture Overview A logical scheme of the platform is depicted in Fig. 2. The general architecture is composed of the following modules: x x x x

Network Modeler Interdisciplinary Modeler User Interface Service Engine

The first two components are designed to model the entities involved in the communication and the rules by which they interact. The User Interface and the Service Engine components are designed to manage certain documents and events within the network.

Platform Design for the B2(B2B) Approach

127

Fig. 2. The FLUID-WIN platform

In addition to the platform, another set of software components called “gateway” are part of the FLUID-WIN architecture. The gateways aim to implement domain-dependent communication. Thus, the three gateways relate to the FLUID-WIN domains manufacturing (B2B), Logistics and Finance. Gateways have to face and to solve the interoperability challenges of the FLUID-WIN approach. There are two major levels of interoperability: x x

Internal interoperability concerns the communication among the FLUIDWIN modules (for instance communication between the FLUID-WIN platform and the logistic gateway). External interoperability concerns the communication between the different FLUID-WIN modules and the legacy systems of the FLUID-WIN users . The FLUID-WIN interoperability is realized by the implementation of gateways and adapters that work between the FLUID-WIN Platform and the external application domains.

3 Technologies for Development and Technologies for Design The choice of technology for the platform development has a strong impact on interoperability. Especially for the internal interfaces, we must therefore consider: x

Abstracted: Service is abstracted from the implementation

128


x x x

Published: Precise, published specification functionality of the service (not of the implementation of the service) Formal: Formal contract between endpoints places obligations on provider and consumer Relevant: Functionality presented at a granularity recognized by the user as a meaningful service

The modeling of these properties is possible through the use of technology offered by Web services. Thus, the platform itself was developed with the following instruments: x x

Eclipse 3.2, with Web Tools Platform 1.5 development environment [3] J2EE 1.4, that fully supports the use of Web services [4]

For the deployment, the following tools have been selected: x x x x

The FLUID-WIN Platform will be implemented in Java, Enterprise Edition 1.4. The J2EE Application Server will be BEA Web-Logic Server 9.2. [5] The application will run on a server with Linux or Sun Solaris as OS. The B2B gateway and the FLUID-WIN Platform have a DBMS layer (IBM Informix).

Thus, the platform is a WebService which exposes a number of methods available through gateways that are mandated to route messages to the outside world. In Fig. 3, a conceptual scheme is reported of the protocols and tools used for communication among network entities:


129

FLUID-WIN PLATFORM

APPLICATION SERVER

Apache Axis/SOAP Server

BEA WebLogic

SOAP/HTTP

WEB-SERVER

Inner Firewall

GATEWAY SOAP/HTTPS

inte rne t

Outer Firewall

Database Server

Authorization

HTTPS

BROWSER

Fig. 3. Platform infrastructure

For the design tasks at the FLUID-WIN consortium partners, the Integrated Enterprise Modelling (IEM) method [6] was used to define and exchange the business processes. The Universal Modelling Language (UML) [7] is used to define and describe workflow protocols for the exchange of messages between the gateway, the platform and the outside world. The development environment for UML is Enterprise Architect, an advance software modeling tool for UML 2.1 [8].

4 Components for Modelling The software components for modelling are the Network Modeler and the Interdisciplinary Service Modeller. These two components have the main objective to define the parties involved in the B2(B2B) network, the parties involved in specific workflows and the “rules of the game” applied when operating the platform’s functionalities. In particular, the Network Modeler is used to model the players in the B2(B2B) process, assigning roles and defining constrains that will drive the collaborative activities. The Network Modeler is expected to have structural similarities with the modelling engines of the SPIDER-WIN project, that facilitated the exchange of relevant manufacturing execution information along the supply chain [9, 10]. Therefore, partners expect that they can re-use the structural parts of the specification from the SPIDER-WIN project, while the content parts will need to be specified newly, leading also to the development of a completely new modeller.

130


The Interdisciplinary Service Modeller has been conceived for the modelling of the domain concept to be handled in a given network context, where this context is defined through the Network Modeller. The Interdisciplinary Service Modeller will enable to define the interdisciplinary process activities and to map them to the process elements and events that trigger the actions managed by the Service Engine. Another fundamental aspect to be considered is the modeling of processes through which certain documents can be obtained. This is possible through the socalled Workflow and Report Templates that are included within the Interdisciplinary Service Modeler. The above mentioned processes are defined by a number of states and methods implemented in the platform, and used by workflows whose final output will be a document (e.g. logistic order, request for quotation, quality measurement document, etc.). A WorkFlow Template is composed from a set of states, transitions, rights, outgoing and incoming events, functions, notifications, constraints and changes to the database. Through customizable external input it is possible to obtain a workflow as shown in Fig. 4, which is an example of a Workflow Template on a Logistic Order, specifying the possible states and the transitions between these states.


131

LOGISTIC ORDER – TEMPLATE WORKFLOW

f: {F1}; i:{I1}, r:{LCU } f :{ F 3 }; r:{LCU}; o :{ O 3 } f:{F2 }; i: {I1}, r:{LCU} f :{ F2 }; i: { I1 }, r:{LSP }

CREATED

f: {F4}; r:{LSP }

f: { F2 }; i:{I1}, r:{ LSP } CH ANG E by LSP

f :{ F 4 }; r :{LCU }; o:{O1}

f:{F2}; i: {I1}, r:{LCU } CON FIRMED

f:{F 4}; r:{LSP }; o:{O3}

CHANG E by LSP's CUSTOMER

f :{ F3 }; r :{ LCU }; o :{ O3}

f :{

F3 }; r:{LCU}; o:{O 3}

f :{F 5}; r:{LSP }

CANCELLED

FULFILLED

f :{F 6}; r:{SYS }

C LO SED

Fig. 4. Examplary workflow template (logistic order)

5 Components for Managing The components for the management are Service Engine and User Interface. The main task of these components is the management of documents and events within the network. The Service Engine manages all messages that are exchanged with B2B and legacy applications, storing and updating the central repositories, fulfilling the required elaboration to propagate message data through the singlediscipline domains, and towards interested network players. Moreover, the Service Engine collaborates with software agents in charge of detecting events and transporting messages, and it defines the basic routing elements for control flow semantics, based on an XML/XSL.

132


The User Interface allows authorized users to interact through a series of actions granted to them by their partners. An example of the first draft User Interface is shown in Fig. 5.

Fig. 5. Example User Interface

6 Summary The step from the “classical” B2B approach to the new B2(B2B) concept requires the development of a platform that centralize services and therefore communications between various entities. Therefore, a technology is mandatory that offers a single language-independent development environment. The project has selected Web services for this purpose. The successful exploitation of the B2(B2B) concept requires x x x x x x

a business process model of the B2(B2B) concept, that forms the base of the implementation and supports the customization in a concrete network, an Interdisciplinary Service Model that defines the Workflow Templates implementing the states and transitions on the platform, a Network Model that defines the players in a concrete platform, a Service Engine that operates the workflow, a B2B gateway that connects the platform to a B2B platform (which then connects to a multiplicity of manufacturers), finance and logistic gateways that allow for the attachment of specific IT systems from the service domains, and


x

133

user interfaces to directly access the platform, taking into account that the majority of services will be used without direct access to the platform, as information is exchanged through the gateways and platforms among the existing legacy systems.

References [1]

FLUID-WIN: Finance, Logistic and Production Integration Domain by Web-based Interaction Network. European Project FP7-IST-027083, www.fluid-win.de [2] Rabe, M.; Mussini, B.: ASP-based integration of manufacturing, logistic and financial processes. In: XII. Internationales Produktionstechnisches Kolloquium, Berlin, 11.-12. October 2007, pp. 473-487. [3] Eclipse Foun¬da¬tion, Eclipse 3.2: http://www.eclipse.org/, visited 05.11.2007, also http://help.eclipse.org/help32/index.jspX (Documentation) [4] Sun Microsystems, J2EE 1.4, 2004. http://java.sun.com/j2ee/1.4/docs/tutorial/doc/ [5] BEA Web-Logic Server 9.2: http://edocs.bea.com/wls/docs92/index.html, visited 05.11.2007 [6] Mertins, K.; Jochem, R.: Quality-oriented design of business processes. Kluwer Academic Publishers, Boston, 1999. [7] UML 2.1: http://www.uml.org/, visited 05.11.2007 [8] Enterprise Architect: http://www.sparxsystems.com.au/, visited 05.11.2007 [9] Rabe, M.; Mussini, B.; Gocev, P.; Weinaug. H.: Requirements and potentials of new supply chain business processes in SME networks - Drivers for solution developments. In: Cunningham, P.; Cunningham, M. (Hrsg.): Innovation and the Knowledge Economy: Issues, Applications, Case Studies. Amsterdam: IOS Press 2005, Vol. 2, S. 1645-1652. [10] Rabe, M.; Gocev, P.; Weinaug, H.: ASP Supported Execution of Multi-tier Manufacturing Supply Chains. In: Proceedings of the International Conference on Information Systems, Logistics and Suppy Chain ILS’06, Lyon (France), 14.-17. Mai 2006, CD-ROM Publication. [11] FLUID-WIN consortium: New Business Processes Specifications. Deliverable D13, 28.09.2007, www.fluid-win.de

Trust and Security in Collaborative Environments Peter Mihók, Jozef Bucko, Radoslav Delina, Dana Palová Faculty of Economics, Technical University Košice, NČmcovej 32, 040 01 Košice, Slovakia {peter.mihok, jozef.bucko, radoslav.delina, dana.palova}@tuke.sk

Abstract. It is often stated in literature that trust is of critical importance in creating and maintaining information sharing systems. The rapid development of collaborative environments over the Internet has highlighted new open questions and problems related to trust in web-based platforms. The purpose of this article is to summarize how trust can be considered in collaborative environments. Partial results of the field studies of two European IST projects, FLUID-WIN and SEAMLESS, are presented. Identity management problems and trusted operational scenarios are treated. Key words: trust, security, information sharing, collaboration, web-based platform, identity management, trusted scenario

1 Introduction Trust is considered as a basic success factor for collaboration. Modern ICT based collaboration environments allow companies to realize a number of competitive advantages by using their existing computer and network infrastructure for the collaboration of persons and groups. The collaborating actors (manufacturers, suppliers, customers, service providers) must feel confident that their transaction processes are available, secure and legal. Trust building mechanisms vary according to their complexity and acceptability, especially among companies with low IT skills. Appropriate selection and user-friendly implementation can enhance trust and efficient use of web-based business platforms. In this contribution we examine trust and trust building mechanisms in different contexts. Organizations and projects are looking for ways to optimize their supply chains in order to create a competitive advantage. Consequently, the same organizations are modifying their business processes to accommodate the demands that information sharing requires. Information sharing can reduce the cost of failure and operational cost. Furthermore, it can improve the scheduling quality and the efficiency of current resources. It also provides intangible benefits such as

136

Peter Mihók, Jozef Bucko, Radoslav Delina, Dana Palová

improved quality with increased customer and shareholder satisfaction. However, integrating and sharing information in inter-organizational settings involves a set of complex interactions. The organizations and institutions involved must establish and maintain collaborative relationships in which information and data of sensitive and critical nature are transferred outside of the direct control of the organization. The sharing processes can involve significant organizational adaptation and maintenance. Trust and security mechanisms are often stated in literature as being of critical importance in the creation and maintenance of an information sharing system. In the past decades there is a rapid increase of information sharing systems based on different electronic services (e-services) offered through web-based platforms. Trust and security aspects in the development of such platforms are in the center of the research activities of European FP6 and FP7 projects, e.g. networks of Living Labs and Digital Ecosystems, projects SECURE, SERENITY, SWAMI, HYDRA, etc. In this paper we will restrict our attention to two types of collaborative environments: electronic marketplaces and manufacturing networks. Our research is based on our results and experiences in the FP6 IST projects SEAMLESS and FLUID-WIN. The SEAMLESS project studies, develops and tests an embryo of the Single European Electronic Market (SEEM) network, where a number of e-registries are started in different countries and sectors. The SEEM vision is towards a web-based marketplace where companies can dynamically collaborate without cultural, fiscal and technological constraints. The FLUID-WIN project targets business-to-business (B2B) manufacturing networks and their interactions with the logistics and financial service providers. This cross-discipline service integration concept is called business-to-(B2B), or shorter B2(B2B) [19]. Within that context the project aims to develop an innovative platform, which can integrate data and transfer them among all the various partners, in order to improve the competitiveness and to make the business processes of the integrated network as efficient as possible. After introducing the basic concepts related to trust and security we deal with the problem of the secure access to the platforms and additional trust mechanisms considered within the projects.

2 Basic Concepts In the context of collaboration it is of importance to differentiate between trust and security. The basic concepts and terms are defined as a base for the further discussion. Trust is a seemingly very abstract factor and as a complex notion, synonymous to confidence, it has a lot of meanings depending on the context where it is considered. By WordNet [28] the word trust relates to: x x x x

Reliance, certainty based on past experience Allow without fear Believe to be confident about something Trait of believing in the honesty and reliability of others

Trust and Security in Collaborative Environments

x

137

Confidence, a trustful relationship

Another definition describes trust as confident reliance. “We may have confidence in events, people, or circumstances, or at least in our beliefs and predictions about them, but if we do not in some way rely on them, our confidence alone does not amount to trust. Reliance is a source of risk, and risk differentiates trusting in something from merely being confident about it. When one is in full control of an outcome or otherwise immune from disappointment, trust is not necessary” [27]. Trust is usually specified in terms of a relationship between a trustor and trustee. The trustee is the subject that trusts a target entity i.e. the entity that is trusted. Trust forms the basis for allowing a trustee to use or manipulate resources owned by a trustor or may influence a trustor’s decision to use a service provided by a trustee. Based on the survey of Grandison and Sloman [13], trust, in the eservices context, is defined as: “the quantified belief by a trustor with respect to the competence, honesty, security and dependability of a trustee within a specified context”. Also distrust is defined as: “the quantified belief by a trustor that a trustee is incompetent, dishonest, not secure or not dependable within a specified context”. The level of trust has an approximate inverse relationship to the degree of risk with respect to a service or a transaction. In many current business relationships, trust is based on a combination of judgment or opinion based on face-to-face meetings or recommendations of colleagues, friends and business partners. However, there is a need for a more formalized approach to trust establishment, evaluation and analysis to support e-services, which generally do not involve human interaction. Comprehensive surveys on the meaning of trust can be found e.g. in [17] and [13] as well as in the book on Trust in E-Services [24]. Whereas, security is “a wish” of being free from danger, the goal is “bad things don't happen”. Computer security is the effort to create a secure computing platform, designed in a way that users or programs can only perform actions that have been allowed. This involves specifying and implementing a security policy. The actions in question are often reduced to operations of access, modification and deletion. Schneier [21] defines security “like a chain; the weakest link will break it. You are not going to attack a system by running right into the strongest part. You can attack it by going around that strength, by going after the weak part, i.e., the people, the failure modes, the automation, the engineering, the software, the networks, etc.” In the context of information-sharing computer systems, everything reduces to access to appropriate information. Provision (or disclosure) of information is the key element. A simple transfer of data is between two parties, a sender and a receiver, and includes the following key steps: preparation of data; transfer a copy of the prepared data; use the copy of data received. More complex transactions can be composed from such simple data transfers. Dependability is an ability to avoid failures that are more frequent or more severe than it is acceptable (to avoid wrong results, results that are too late, no results at all, results that cause catastrophes). Attributes of dependability are:

138


x x x x x

Availability – readiness for correct service Reliability – continuity of correct services Safety – absence of catastrophes Integrity – absence of improper results Maintainability – ability to undergo modifications and repairs

Security can be defined [14] as the combined characteristics of: confidentiality (i.e., absence of unauthorized disclosure of information), availability to conduct authorized actions, and also integrity (i.e. the absence of unauthorized system alterations). Security and dependability overlap, and are both required as base for trust. Unfortunately and most confusingly, the terms dependability and security are sometimes used interchangeably or, else, either term is used to imply their combination. In fact, because security and dependability are distinct but related and partially overlapping concepts, the term trustworthiness is being increasingly used to denote their combination. The main technical mechanisms that have strong influence on the trust in networked based systems include: x x x

Identity management Access control Data encryption and security

The identity management systems provide tools for managing partial identities in the digital word. Partial identities are subsets of attributes representing a user or company, depending on the situation and the context. Identity management systems must support and integrate both techniques for anonymity and authenticity in order to control the liability of users. The access control is the enforcement of specified rules that require the positive identification of the users, the system and the data that can be accessed. It is the process of limiting access to resources or services provided by the platform to authorized users, programs, processes or other systems according to their identity authentication and associated privilege authorization. Finally, data encryption and security are related to cryptographic algorithms, which are commonly used to ensure that no unauthorized user can read and understand the original information. The concept of asymmetric cryptography, (also called Public Key Cryptography), was described for the first time by Diffie and Hellman [6]. In contrast to the symmetric cryptography in which we have the same secret key for encryption and decryption, we now have one public key eP (encryption key) and one private key dP (decryption key) for each person P. While the public key eP can be published to the whole world, the private key dP is to be treated as a secret and only person P knows it. An important characteristic of such a cryptography system is that it is computationally infeasible to determine the private key given the corresponding public key. The advantage of asymmetric cryptography is the enormously reduced effort for key management. A disadvantage is the velocity. The asymmetric cryptography can serve as base for the digital signature. The Public Key Infrastructure (PKI) provides the identification of a public key with a concrete person via the certificate. The PKI is the system of technical and administrative arrangements associated with issuing, administration, using and


139

retracting of public key certificates. The PKI supports reliable authentication of users across networks and can be extended to distributed systems that are contained within a single administrative domain or within a few closely collaborating domains.

3 Trust and Security on Web-based Platforms In an open and unknown market place with a high number of unknown participants, assurance and trust are difficult but very important. There is a growing body of research literature dealing with online trust, in which e-commerce is one prominent application. Several studies contend that e-commerce cannot fulfil its potential without trust (e.g. [8], [11], [15], [20]). Lee and Turban [16] highlight lack of trust as the most commonly cited reason in market surveys why consumers do not shop online. On an open consultation on “Trust barriers for B2B e-marketplaces” [7] conducted by the Enterprise DG Expert Group in 2002, several important barriers were identified. From the report we can find that the most important trust barriers are issues regarding the technology (security and protection), trust marks and dispute resolution absence, online payment support, lack of relevant information about partners, products, contract and standardization issues. A trust building process must be set up to resolve these issues. Trust usually is conceptualised as a cumulative process that builds on several, successful interactions [18]. Each type of process increases the perceived trustworthiness of the trustee, raising the trustor’s level of trust in the trustee [3]. It is not known exactly which trust-building processes are relevant in an e-commerce context. It is suggested that, in this setting, trust building is based on the processes of prediction, attribution, bonding, reputation and identification [3]. Reputation has a very high relevance in a trust-building process on e-commerce markets [1]. According to the Chopra and Wallace classification, identification based trust refers to one party identifying with the other, for example in terms of shared ethical values. Identification builds trust when the parties share common goals, values or identities. In e-commerce, these attributes perhaps may relate to corporate image [2] or codes of conduct. These results are more focused on trust impact than on factors, which build trust. According to several research activities, the research on significance and acceptance of trust building mechanisms is still missing and is necessary for future development in this field. This absence has been examined in the Seamless project [22]. The results are presented in Deliverable D1.2 “Trusted Operational Scenarios” of the project, see also [5]. Though operating within a closed supply chain system, locally spread information technology destinations (users of manufacturer, supplier and financial service institutions) need to be linked, which brings up the need for trust, privacy and security. It is to be expected that security is at least of equal importance than in an open system, as limitation of access plays a vital role. There are several trust and security best practices scattered throughout the Internet and material is constantly updated daily, if not hourly, based on the latest threats and

140


vulnerabilities. Security standards are not “one size fits all.” Responsible, commercially reasonable standards vary, depending on factors such as company size and complexity, industry sector, sensitivity of data collected, number of customers served, and use of outside vendors. Security standards exist for several types of transactions conducted, and new ones are on the way all the time. A further checklist to meet trust and security requirements is to meet local legislation in terms of data protection and privacy regulation. Financial transactions need to meet local and also foreign standards if they are to be accepted by a provider. With respect to the FLUID-WIN project and its platform mainly two security and trust building mechanisms can be differentiated: 1. 2.

Mechanisms based on workflow design, policies and contractual issues. Technical solutions ensuring a save login and data exchange.

Both mechanisms are strongly related and build upon each other. Based upon the results of a mail-based survey the following ten key success factors for an established information sharing system were determined [10]: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Centralized Information Sharing Control Maintain and Update Information Sharing Rules Significant Exchange of Information Defined Use of Information Collaboration with Suppliers Cooperative Competition End-to-End Connectivity Formed Supply Alliances Replace Traditional Communication with IT Share Frequently with Suppliers

Trust, which did not occur as a factor among them, is replaced by contractual agreements defining the limitations of the transferred information usage. However, the challenge within the FLUID-WIN idea is the high number of actors from different domains as well as their technical connection within the B2(B2B) concept. For secure access to the FLUID-WIN Platform it could be convenient to use digital signatures (private keys), which are saved at a secure device (chip card, USB key) and protected by other safety elements (PIN and static password). It is necessary to take the existence of a digital signature couple as granted, the first one for access and cryptography and the second one for designation. The strength of this securing form is the fact that the method of digital signature cannot be breached by “brute” force at the present time. The weakness of this security method is insufficient knowledge of this method and infringement of all safety rules that are related to the physical security of digital signature storage site and safety elements, which allow its operation. Therefore, it is necessary to work out the security policy, in which the method of usage, security principles and risks of improper use of this method will be exactly specified. The digital world uses the same principles of electronic signature data identification (in case of a digital signature it is the public key):


x

x

x

141

Uniqueness of the line – based on the agreement about a public key between the key owner and the verifier of the signature. This way of connection is unequivocal under opinion of both parties. Duly conducted agreement protects both parties and is one of the arguments in the case of cause. This application of digital signature is possible in the so-called closed systems. This method is used in the electronic banking services at present. Triangle of trust – in open systems, the owner of the key has not often the possibility to meet with the verifier of the signature to make an agreement concerning the relevant public key. In this case it is suitable to use the third party principle. Certification – a dedicated authority assures the unequivocal identification of the public key with a concrete person (its owner), on the basis of a certified application of the owner. In this application the basic identification data and relevant public key are listed.

Therefore, the necessary condition of active employment of electronic signature technology, which allows the transition to electronic document interchange in open systems, is the existence of certification authorities. To the basic services defined by the e-signature mechanisms belong: x x x

Registration services – contact with certificate applicant, verification of data conformity (data in the application form for issue of certificate and data concerning the identity of an applicant). Issuing of certificates – on the basis of an agreement with an applicant and verification of all necessary data the certificate for public key is issued. Revoke of certificates and publication of the cancelled certificates list – in case that an unauthorized person obtains the private key, it is required to cancel the certificate before its validity date. The certification authority is obliged to keep and publish lists of valid and cancelled certificates.

However, financial service providers have their own security policies. Especially larger financial institutions are hard to be convinced to adapt their policy as precondition to use the FLUID-WIN Platform. Rather, it is likely that the FLUID-WIN Platform has to accept the policies of the certain Financial service providers, even if is this means that FLUID-WIN has to implement a set of different security mechanisms depending on the requests of each financial service provider.

4 Conclusion E-services like web-banking, web-shopping, web-auctions, e-government, e-health, e-manufacturing, e-learning are becoming part of everyday life for citizens everywhere. As a basis for deciding to use the service trust is becoming a major impediment. To fill the gap between identities and their level of trust is one of the eight major issues in developing identity management for the next generation of distributed applications and use of e-services [24]. A lot of interesting questions

142


and problems are considered in the recent publications [4],[5],[10],[12] and can be found as public deliverables of the projects [9],[22],[23],[25] and [26].

Acknowledgements This work has been partly funded by the European Commission through IST Project SEAMLESS: Small Enterprises Accessing the Electronic Market of the Enlarged Europe by a Smart Service Infrastructure (No. IST-FP6-026476) and IST Project FLUID-WIN: Finance, logistics and production integration domain by web-based interaction network (No. IST-FP6-27083). The authors wish to acknowledge the Commission for their support. We also wish to acknowledge our gratitude and appreciation to all the Seamless and Fluid-Win project partners for their contribution during the development of research presented in this paper.

References [1]

Atif, Y.: Building Trust in E-Commerce, IEEE Internet Computing, Jan-Feb (2002), 18-24 [2] Ba, S., Pavlou, P.A.: Evidence of the effect of trust building technology in electronic markets: Price premiums and buyer behaviour. MIS Quarterly Vol. 26 No. 3. (2002) 243-268 [3] Chopra, K., Wallace, W.: Trust in Electronic Environments, Proceedings of the 36th Hawaii International Conference on Systems Sciences (HICSS), (2003) [4] Delina, R., Azzopardi, J., Bucko, J., Frank, T., Mihok, P.: Financial Services in Webbased Platforms. In: Managing Worldwide Operations and Communications with Information Technology, Proc. IRMA Conference Vancouver (Canada), ed. Koshrow M. (2007) 1273-1274 [5] Delina, R., Mihok, P.: Trust building processes on web-based information-sharing platforms. In: Proceedings of the 13th International Conference on Concurrent Enterprising, ICE’2007, eds. K.S. Pawar, K-D. Thoeben and M. Pallot, Sophia Antipolis, France (2007) 179-186 [6] Diffie,W., Hellman,M.: New directions in cryptography, IEEE Transactions on Information Theory. (1976). Available at: http://crypto.csail.mit.edu/classes/6.857/papers/diffie-hellman.pdf (11.10.2007) [7] EU Commission: Open consultation on “Trust barriers for B2B emarketplaces” Presentation of the main results. (2002) Available at: http://europa.eu.int/comm/ enterprise/ict/policy/b2bconsultation/consultation_en.htm (25.05.2007) [8] Farhoomand, A., Lovelock, P.: Global e-Commerce – Texts and Cases, Prentice Hall (2001) [9] FLUID-WIN Finance, logistics and production integration domain by web-based interaction network. FP6 IST STREP 27083 funded by European Commission. Available at: www.fluid-win.de [10] Frank, T. G., Mihók, P.: Trust within the Established Inter-Organizational Information Sharing System. In: Managing Worldwide Operations and Communications with Information Technology, Proc. IRMA Conference Vancouver (Canada), ed. Koshrow M. (2007) 132–135 [11] Friedman, B., Kahn, P., Howe, D., Trust Online, Communications of the ACM, Vol. 43, No. 12 (2000) 34-40


143

[12] Giuliano, A., Azzopardi, J., Mihók, P., Bucko, J., Ramke, Ch.: Integration of financial services into multidisciplinary Web platforms. To appear in: Ambient Intelligence Technologies for the Product Lifecycle: Results and Perspectives from European Research, IRB Stuttgart (2007) [13] Grandison, T., Sloman, M.: A survey of trust in Internet applications, IEEE Communications Surveyes and Tutorials, 4(4) (2000) 2-16 [14] IEEE Standard computer dictionary: A compilation of IEEE standard computer glossaries. Institute of Electrical and Electronics Engineers, New York (2007) [15] Jones, S., Wilikens, M., Morris, P., Masera, M.: Trust requirements in e-business: A conceptual framework for understanding the needs and concerns of different stakeholders. Communications of the ACM, Vol. 43, No. 12 (2000) 81-87 [16] Lee, M., Turban, E.: A Trust Model for Consumer Internet Shopping, International Journal of Electronic Commerce, Vol. 6, No. 1 (2001) [17] McKnight, D.H. and Chervany, N.L.: The Meanings of Trust. MISRC 96-04, University of Minnesota, Management Informations Systems Research Center, University of Minnesota, (1996) [18] Nicholson, C., Compeau, L., Sethi, R.: The Role of Interpersonal Liking in Building Trust in Long-Term Channel Relationships, Journal of the Academy of Marketing Sciences, Vol. 29, No. 1 (2001) 3-15 [19] Rabe, M.; Mussini, B.: ASP-based integration of manufacturing, logistic and financial processes. In: XII. Internationales Produktionstechnisches Kolloquium, Berlin, 11.-12. October 2007, pp. 473-487. [20] Raisch, W.: The E-Marketplace – Strategies for Success in B2B Ecommerce, McGraw-Hill (2001) [21] Schneier, B.: Security in the real world. How to evaluate security technology. In: Computer Security 15/4 (1999) 1-14 [22] SEAMLESS: Small enterprises accessing the electronic market of the enlarged Europe by a smart service infrastructure. FP6 IST STREP 26476 funded by European Commission. Available at: www.seamless-eu.org [23] SECURE: Secure environments for collaboration among ubiquitious roaming entities. Available at: http://www.dsg.cs.tcd.ie/dynamic/?category_id=-30 (visited 01.11.2007) [24] Song, R., Korba, L., Yee, G.: Trust in E-Servuces, Technologies, Practices and Challenges, Idea Group Publ. (2007) [25] SWAMI: Safeguards in a world of ambient intelligence, final report. (2006) Available at: http://swami.jrc.es (visited 01.06.2007) [26] TRUSTe: Security guidelines 2.0. (2005) Available at: http://www.truste.org/pdf/Security Guidelines.pdf (visited 23.05.2007) [27] UNMC: Glossary. (2007), www.unmc.edu/ethics/words.html (31.05.2007) [28] WordNet: Word net search; Trust. (2007) Available at: http://wordnet.princeton.edu/ perl/webwn?s=trust&sub=Search+WordNet&o2=&o0=1&o7=&o5=&o1=1&o6=&o4 =&o3=&h (visited 21.05.2007)

Prototype to Support Morphism between BPMN Collaborative Process Model and Collaborative SOA Architecture Model Jihed Touzi, Frederick Bénaben, Hervé Pingaud Centre de Génie Industriel, Ecole des Mines d’Albi-Carmaux Route de Teillet 81013 ALBI Cedex 9 {Jihed.touzi, Frederick.benaben, Herve.pingaud}@enstimac.fr

Abstract. In a collaborative context, the integration of industrial partners deeply depends of the ability to use a collaborative architecture to interact efficiently. In this paper, we propose to tackle this point according to the fact that partners of the collaboration respect SOA (Service-Oriented Approach) concepts. We propose to design such a collaborative SOA architecture according to MDA (model-Driven Approach) principles. We aim at using business model (the needs) to design a logical model of a solution (logical architecture). The business model is a collaborative business model (in BPMN, at the CIM level), while the logical model is a collaborative architecture model (using UML, at the PIM level). This paper presents the theoretical aspects of this subject, the mechanisms of morphism and the dedicated translation rules. Finally, we show the prototype of a demonstration tool embedding the transformation rules and running those principles. Keywords: transformation, ATL prototype, collaborative process, meta-model, morphism.

1 Introduction The application of model-driven development facilitates faster and more flexible integration by separating system description to different levels of abstraction. The global MDA approach shows that is possible to separate concerns by splitting implementation choices from specifications of business needs. Specifically, the Model Driven Interoperability (MDI) paradigm [1][2][3] proposes to start from an Enterprise Modelling level that means at Computation Independent Model (CIM) level, defining the collaboration needs of a set of partners and to reach a Platform Independent Model (PIM) level defining a logical architecture of a collaborative solution. Finally the Platform specific Model (PSM) can be generated. The three models are in closed connections and passing from one layer to another one, must

146

Jihed Touzi, Frederick Bénaben, Hervé Pingaud

be facilitated by vertical transformation rules. Previous research works have shown the benefits of this new paradigm. The PIM4SOA project [4] defines a PIM metamodel based on SOA. In this work, it is possible to generate a PIM model from a Processes, Organization, Product, * (POP*) model. The weak point of this work is that there is no description of the needed morphism between the CIM model and the PIM model. Other research works like [5] and [6] focus principally on the identification of the two meta-models (CIM and PIM). The Morphism (which contains the definition of the transformation rules) is missed or shortly described. In this paper we intend to identify a morphism between a collaborative process model and a collaborative SOA architecture. In our PhD work [3] we are actually developing a prototype that transforms a BPMN collaborative process into a collaborative SOA architecture. The generated UML model can be enriched by an additional knowledge about the collaboration (services description, exchanged messages details, etc.). This paper is organized as follows. Section 2 defines morphism between two models, while section 3 defines the needed meta-models of the BPMNCollaborative SOA architecture transformation. Transformation rules are illustrated in section 4 and finally we present in section 5 the architecture of the developed prototype to support the defined morphism.

2 Definition of a Morphism We aim to establish a morphism between a BPMN collaborative process model and a collaborative SOA architecture model. Fig 1 shows how to represent schematically the notion of morphism: A, B represent respectively source and target model and M is the morphism.

M

Fig. 1. Morphism between A and B models

Morphism allows obtaining a model B from a model A. It is based on the concepts of mapping and transformation [7]. If we consider that one model is composed of a set of elements: x

Mapping is a relation that aims to establish correspondences between elements of two models without modification. The definition of one mapping needs the availability of the two models. The establishment of one mapping needs firstly to define the meta-models that define the models.

Prototype To Support Morphism between BPMN and Collaborative SOA

x

147

Transformation is a function that transforms (or modifies) one source model to a target model. The source model is unchanged and there is generation of new model: the result of the transformation.

Mappings can be of different types [7]: A 1-to-1 mapping puts in correspondence one element of a model with exactly one element of the other model. However, there are other cases in which we map single elements in the source model with a sub-graph in the second model (1-to-n) or, even, a sub-graph to sub-graph (m-to-n).

3 Definition of the Meta-Models In this section, we define the needed meta-models of the BPMN-Collaborative architecture transformation. 3.1 Definition of BPMN Collaborative Process Meta-Model The first meta-model is of the collaborative process. The meta-model of Fig 2 regroups basic BPMN elements (like gateway, events, message flow…) and other specialized components (like pools or tasks that explicitly refer to collaboration entities). The BPMN formalism aims to support process management for technical and business stakeholders by providing a graphical notation that is rather intuitive and able to represent complex process semantics. As a specialized element the Collaborative Information System (CIS) pool refers to a mediation actor of the collaboration that offers a set of added value services. As example: choosing a supplier from a list of suppliers concerned with a customer order, checking payment transactions, etc. The defined meta-model respects our vision of the collaboration, based on the use of a mediator that facilitates interoperability issues between partners.

148


Fig. 2. Collaborative process meta-model (source meta model)

3.2 Definition of Collaborative SOA Architecture Meta-Model The collaborative SOA architecture meta-model described in Fig. 3 is closed and inspired from the PIM4SOA meta-model [4]. Three packages are proposed corresponding to three views: x x

x

Services view: services that are used in the collaboration are described; they are business reachable computing functionalities with a known location on the communication network. Information view: data are exchanged by messages between services, they are defined here in their structure by a data model, and also as a communication utility by identification of the emission and reception services Process view: interaction amongst services and coordination aspects are specified by the control of processes described here


149

Fig. 3. Meta model of the SOA collaborative architecture (target meta model)

4 Definition of the Transformation Rules The described source and target meta-models of the morphism are further detailed and justified in [3]. It is not possible to explain here, due to limited space constraints, the objects and the relations that rely them in each meta-model. However, we hope that the following dedicated to the mappings of those metamodels that lead to the transformation rules will give some lights about the equivalences that are used. Transformation rules are classified in two categories: 1.

Basic generation rules are used in a first time to create elements of the target model. Most of these rules are defined by a direct mapping between meta model elements.

150


2.

Binding rules are applied in a second time to draw the links between the elements resulting from the previous phase. Existing relations in the source model are transformed into relations in the target model.

4.1 Basic Generation Rules Fig. 4, Fig. 5 and Fig. 6 try to summarise the set of rules (also called derivation laws) that are applied during transformation. The rules are represented by circles located in the middle of two class diagrams. The class diagrams are subgraphs which are parts of the primitive meta models. On the left part of each figure is the subgraph of the source meta model, and on the right part is the subgraph of the target meta model. The rules have to be interpreted in the following manner: “When an object is identified in the collaborative process model, it belongs to meta-model class of the left side subgraph linked to the rule. Then, it will be transformed in an object instantiated from the class of right side of the figure. We mean that it will become an object in the SOA collaborative architecture”. The service view of the SOA collaborative architecture is represented in Fig 4. On the left part, the pool and lane classes are mapped on the different entities services of the right part (partners or CIS services). Rs1 rule gives the links from tasks in the collaborative process model to services listed in the registries, either specific to the collaboration or generic ones. Rs2 to Rs4 rules provide solutions for the structure and organisation of services. Rs5 shows the need for an additional knowledge to fill services description. With the same logic, Fig. 5 introduces two transformation rules applied for the information view. As indicated before, the transformation is not sufficiently developed in this domain (business process is not the good way to modelize informations of the collaboration). Transformation provides syntactic indications that help to create business objects (Rules Ri1 and part of Ri2). However, the problem of translation refers to semantic interpretation that we do not include in this part of the study (Remaining part of Ri2 is probably not a robust solution).


151

Fig. 4. Localisation of transformation rules for basic generation of the service view

Fig. 5. Localisation of transformation rules for basic generation of the information view

152


In contrast Fig. 6 is the most developed part of the transformation procedure with nine rules. The “process view” package has been designed using specifications of the BPEL meta model language. BPEL (Business Process Execution Language) is one of the most popular candidates for specification of web services process execution. Some of the rules in Fig. 8 are adaptations of recommendations provided by BPMI when they address the problem of BPMN graph conversion to BPEL well defined XML sentences [8]. It concerns rules Rp3 to Rp6, and rules Rp8 to Rp9. Rules Rp1, Rp2 and Rp7 participate to the definition of coordination activites.

Fig. 6. Localisation of transformation rules for basic generation of the process view


153

4.2 Binding Rules The binding rules can be used to build the interactions between the elements of the target model coming from the basic generation rules appliance. The links could be inside a target model package or between two different packages (dependence). The goal is to define in the target model the necessary relations that exist in the source model. The relations may be of different types like inheritance, composition, aggregation or simple association. Three binding rules Rb1 to Rb3 are given in the following as an exemple. Rb1: sequence ordering A sequence element issued from Rp3 rule is associated with two basic activities into the same process package. Rb2: information processing A service from service package is related to a business object of the information package. Rb3: service identification A basic activity of the process package is linked to a service of the service package.

5 Prototype Development

Fig. 7. Technical architecture of the developed prototype

154


Fig. 7 shows the technical architecture of the prototype, developed to implement our proposition. It is based on three open source tools that run in the Eclipse¤ platform. Intalio designer¤ is a BPM tool that helps user to specify the BPMN model. The Atlas Transformation Language (ATL)¤ can use a process model in the XML format coming from the BPM tool in input, and produce the UML model of the collaborative architecture in output. It is the heart of our transformation prototype. The TOPCASED¤ tool is a computer aided software environment that can perform a graphical edition of the UML model. The ATL tool allows generating a UML model from an XML file that represents the process model. The rules presented previously are coded with ATL. The following gives examples of the ATL code. 5.1 Examples of ATL Code The following ATL code generates the structure of the collaborative architecture (three packages: services, information and processes): rule generatePackages { from a : BPMN!Collaborativeprocess to out :UML2!Model ( name}> =

As we known, the service levels of composite services depend on the component services and the composite structure. In section 5, we will present an automatic approach to generate service level providing model of composite service. 4.3 Service Level Matchmaking Model Based on the preference model and the service level providing model, we present a service level matchmaking model, through which a service level mostly satisfying consumer’s preference can be matched. Definition 8(Service Level Selection Model). For a service level providing model QService and a preference model, Service Level Matchmaking Model is defined as Max { preference} . {QService}

According to the definition 8, we present the service level matchmaking algorithm: Input: Preference, QService᧷ Output: The services level matching preference mostly. Description: 1. set MaxPreference as 0; 2. for each element <ServicePricei, ServiceLeveli> in QService: 1). compute SatisfactionGradei through ServiceLeveli ;

282

Ye Shiyang, Wei Jun, Huang Tao

2). compute AcceptablePricei := PricingFunction(SatisfactionGradei); 3). Preferencei := AcceptablePricei - ServicePricei 4). if Preferencei> MaxPreference { MaxPreference := Preferencei; service level = ServiceLeveli; } 3. Return service level.

5 Service Level Automatic Generating approach for Composite Service In this section, we first present a Service Level Enable Composite Service Description Model, which describes the factors influencing service level provide model of composite service. Then we define the semantic of service level composition and the semantic of QoS property composition. Through executing the above composition semantic, the service providing model of composite service can be generated automatically. 5.1 Service Level Enable Composite Service Description Model Definition 9(Available Services). For a composite service with n component services, Available Services is a set {QServiceSet1, QServiceSet2, …, QServiceSetn}, where QServiceSeti is the available services for component servicei, and QServiceSeti is also a set {QServicei,1, QServicei,2, …, QServicei,m}. Definition 10(Composite Service Structure Expression, CSSE). CSSE describes the structure of a composite service which is formally defined as follows: QServicek::=QServiceiyQServicej … Sequential Structure; QServicek::=QServicei෺Servicej …Parallel Structure; QServicek::=QServicei෻QServicej …Choice Structure; Loop Structure can be unfolded as in [2] to be Sequential Structure. CSSE is illustrated by the Figure 2.

or

and

Service i Service k ::=

Service k ::=

Service i

Service j

Service k ::=

Service i

Service j

Service j

Sequential Structure

Parallel Structure

Choice Structure

Fig. 2. Composite Service Structure Expression

Definition 11(Service Level Enable Composite Service Description Model, QCServcie). QCServcie is defined as a pair . As an example, Travel Order Service can be described as following:

Preference-based Service Level Matchmaking for Composite Service

283

TravelOrderService=<0DS6HDUFK6HUYLFH෺ &DU5HQWDO6HUYLFH ෻ %XV7LFNHW2UGHU6HUYLFH y+RWHO2U GHU6HUYLFH^^$YDLODEOHV6HUYLFHMapSearchService},^$YDLODEOHV6HUYLFHCarRentalService}, ^$YDLODEOHV6HUYLFHBusTicketOrderService}, ^$YDLODEOHV6HUYLFHHotelOrderService}`>; $YDLODEOHV6HUYLFHMapSearchService ^)P4P!)P4P!)P4P!` $YDLODEOHV6HUYLFHCarRentalService ^)F4F!)F4F!` $YDLODEOHV6HUYLFHBusTicketOrderService ^)E4E!)E4E!)E4E!` $YDLODEOHV6HUYLFHHotelOrderService ^)K4K!)K4K!` 4P ^3P/P!3P/P!3P/P!` 4K ^3K/K!3K/K!` 3P/P! ^5HVS7LPHื $YDLODELOLW\ุ 7KURXJKSXWุ 5HSXWDWLRQุ 6HFXULW\ WUXH`! 3K/K! ^5HVS7LPHื $YDLODELOLW\ุ 7KURXJKSXWุ 5HSXWDWLRQุ 6HFXULW\ WUXH`!

5.2 Service Level Composition Semantic In this subsection, we give service level composition semantic for the three different composition structures. The service level composition semantic is based on the composition semantic of QoS properties. We first give the composition semantic of QoS properties. 5.2.1 QoS properties composition semantic. Different QoS properties have different composition semantics under different composition structures. We categorize the QoS properties and give a QoS properties composition semantic table. Add-able: A QoS property is Add-able if the QoS property value of a composite service is the sum of its component services’ corresponding QoS property values. For instance, the response time in sequential composition structure is Add-able. Multiply-able: A QoS property is Multiply-able if the QoS property value of a composite service is the multiple of its component services’ corresponding QoS property values. For example, availability under sequential structure and parallel structure is multiply-able for the reason that availability is a probability, and the composite service is not available unless both of the component services are available. For example, the availability of a composite service is 72% if the availabilities of the component services are 80% and 90% respectively. And-able: A QoS property is And-able if the QoS property value of a composite service is true if and only if both of its component services’ corresponding QoS property values are true. Security is an And-able QoS property because the composite service is not secure unless both of the component services are secure. Max-able: A QoS property is Max-able if the QoS property value of a composite service is the maximum value of its component services’ corresponding QoS property values. Response time under parallel structure is a Max-able QoS property.

284


Min-able: A QoS property is Min-able if the QoS property value of a composite service is the minimum value of its component services’ corresponding QoS property values. Throughput under parallel structure and sequential structure is such kind of property. Average-able: A QoS property is Average-able if the QoS property value of a composite service is the average value of its component services’ corresponding QoS property values. An example is reputation under parallel structure and sequential structure. Table 1. QoS properties composition semantic. Add-able AttrVal i AttrVal j

And-able

Multiplyable

AttrVal i & & AttrVal

Max-able j

Min-able

Average-able

max ( AttrVal i , AttrVal j ) min ( AttrVali , AttrVal j ) avg ( AttrVal i , AttrVal j )

AttrVali u AttrValj

AttrValiy

RespTime Availability

Security

Throughput

Reputation

Availability

Security

RespTime Throughput

Reputation

AttrValj AttrVali ෺ AttrValj

5.2.1 Semantics of Service Level Composition A composite service will provide new service levels though composing component services with different service levels. We analyze the semantic of service level composition in the following: 1) Semantic of Service Level Sequential Composition QServicek::=QServiceiyQServicej QServiceiyQServicej=y= QiyQj={, , … , }y{, , … , } i

i

j

j

={y}, where kෛ [1,mi], lෛ [1,mj] y=< Pi,k, {AttrExpi,k}>y< Pj,l, {AttrExpj,l}>=< Pi,k+ Pj,l, {AttrExpi,k}y{AttrExpj,l}> =< Pi,k+ Pj,l, {AttrExpi,kyAttrExpj,l}> =< Pi,k+ Pj,l, {( Attri,k AttrOPi,k AttrValuei,k)y(Attrj,l AttrOPj,l AttrValuej,l)}> =< Pi,k+ Pj,l, {(Attri,k AttrOPi,k (AttrValuei,k yAttrValuej,l)}>

Where Attri,k and Attrj,l are the same QoS property, AttrOPi,k and AttrOPj,l are the same operator. The semantic of AttrValuei,k yAttrValuej,l is introduced in table1. 2) Semantic of Service Level Parallel Composition QServicek::=QServicei෺ QServicej QServicei෺ QServicej=෺ = Qi෺ Qj ={, , … , }෺ {, , … , } i

i

j

j

={෺ }, where kෛ [1,mi], lෛ [1,mj] ෺ =< Pi,k, {AttrExpi,k}>෺ < Pj,l, {AttrExpj,l}>=< Pi,k+ Pj,l, {AttrExpi,k}෺ {AttrExpj,l}> =< Pi,k+ Pj,l, {AttrExpi,k෺ AttrExpj,l}>


285

=< Pi,k+ Pj,l, {( Attri,k AttrOPi,k AttrValuei,k)෺ (Attrj,l AttrOPj,l AttrValuej,l)}> =< Pi,k+ Pj,l, {(Attri,k AttrOPi,k (AttrValuei,k෺ AttrValuej,l)}>

The semantic of AttrValuei,k෺AttrValuej,l is also introduced in table1. 3). Semantic of Service Level Choice Composition QServicek::=QServicei෻ QServicej QServicei෻ QServicej=෻ = Qi෻ Qj={, , … , }෻ {, , … , } i

i

j

j

={, , … , ෻ , , … , } i

i

j

j

6 Experiments and Evaluation We have implemented this approach in a Web Service platform OnceServiceExpress developed by Institute of Software, Chinese Academic of Science. In OnceServiceExpress, we study the performance of our preference model and the effectiveness of our service level matchmaking mechanism. 6.1 Experimental Setup Service consumers and service providers run on two machines respectively, with the configuration of CPU Pentium IV 2.8G Hz, 512M memory, windows professional operating system and JDK 5.0. The number of service consumers ranges from 1 to 200, and each service consumer has different preferences to a particular service level. The composite service is composed of four component service. The number of available services of a component service ranges from 1 to 200. Every available component service has 10 service levels. 6.2 Experiments and Evaluation First, we study the performance of our preference model comparing with WSPolicy. In the first experiment, we fix the number of available services of each component service with 200. We study the performance changing as the number of service consumer increasing from 1 to 200. In the second experiment, we fix the number of service consumer with 200. We study the performance changing as the number of available services of each component service increasing from 1 to 100. Figure3 a) and b) show the experiment results respectively.

PDW FKL QJ W L PH PV

PDW FKL QJ W L PH PV

2XU 3U HI HU HQFH 0RGHO :6 3RO L F\ 0RGHO

QXPEHU RI FRQVXPHU V

Fig. 3. a) influence of consumer number

2XU 3U HI HU HQFH 0RGHO :6 3RO L F\ 0RGHO

QXPEHU RI DYDL O DEO H VHU YL FHV

b) influence of available services

286


Figure 3 a) shows that the time of matchmaking using our preference model increases linearly when the number of service consumers increases, while the time of matchmaking using WS-Policy model increases exponentially. Figure 3 b) shows a similar result when the number of available services increases. As illustrated in figure 3, the preference model presented in this paper is very efficient. Then, we verify the effectiveness of our service level matchmaking approach. We evaluate the service consumer’s preference by varying the available services and varying the service levels of available services. Each component service has 200 available services and each available service has 10 different service levels. As shown in Figure 4(a), we set the changing rate of available service to be varying from 1 to 100 per second. We notice that as changing rate increases, our service level matchmaking model maintains a high level consumer preference without any reduce, while in static model, service consumer preference decrease constantly. This is mainly because that when changing rate of available services increases, the service levels provided by composite service change rapidly, and the probability of that the service level matched by static model conforming to service consumer’s preference becomes more smaller. Figure 4(b) shows the influence of changing service level of available services. The changing rates of service level are set in the range from 1 to 100 per second. We can see that with our model the service consumer preference maintains a high level consumer preference when changing rates of service level increases. Compare with Figure 4(a), service consumer preference decrease slowly in this situation in static model. The reason is service levels provided by composite service changed more slowly when changing the service levels of available service. As a result, the probability of that the service level selected by static model conforms to service consumer’s preference decreases slowly.

SU HI HU HQFH

SU HI HU HQFH

RXU PDW FKPDNL QJ 0RGHO

VW DW L F PDW FKPDNL QJ PRGHO

RXU PDW FKPDNL QJ 0RGHO VW DW L F PDW FKPDNL QJ

1R RI FKDQJL QJ DYDL O DEO H VHU YFL HV SHU VHFRQG

Fig. 4. a) available services changing

1R RI FKDQJL QJ O HYHO V RI DYDL O DEO H VHU YL FH SHU VHFRQG

b) levels of available services changing

As shown in the above experiments, our proposed service level matchmaking mechanism can effectively satisfy service consumer’s preference.

7 Conclusion In this paper, we present a service consumer preference model. The preference model considers both the service level and the price of service level by introducing the notion acceptable price. Moreover, the model gets a better efficiency because of avoiding service level enumeration. We also proposed a service level automatic


287

generating approach for composite service. Based on service levels of component services and composite service structure expression, this approach can determine the service levels of a composite service automatically and dynamically. After that, a service level matchmaking model is proposed. In contrast to other work in this area, our approach can maintain a high level consumer preference because it considers the changing of available component services and determines its service levels dynamically. Experiment results show that this approach is efficient and effective. In the future work, we plan to optimize our service matchmaking mechanism. On one hand, we plan to study the influence boundary when an available component service or a service level becomes invalid; on the other hand, we plan to analyze the incremental influence when adding a new available service.

Acknowledgement This Work is supported by the National Natural Science Foundation of China under Grant No. 60673112, the National Grand Fundamental Research 973 Program of China under Grant No.2002CB312005 and the High-Tech Research and Development Program of China under Grand NO. 2006AA01Z19B.

References [1]

Zeng L., Benatallah B., Dumas M., Kalagnanam J., Sheng Q. Z.: Quality driven web services composition. Proc. 12th Int’l Conf. World Wide Web (WWW), 2003 [2] Zeng L., Benatallah B.: QoS-aware middleware for web services composition. IEEE Transactions on Software Engineering, 2004, 30(5): 311-327. [3] Serhani M., Dssouli R., Hafid A.: A QoS Broker Based Architecture for Efficient Web Services Selection [A]. Proc of the IEEE Int'l Conf on Web Services (ICWS'05)[C].2005. [4] Comuzzi M., Pernici B.: An Architecture for Flexible Web Service QoS Negotiation. Proceedings of 9th IEEE EDOC Conference, Enschede, The Netherlands, September 2005 [5] Wohladter E., Tai S., Thomas A., Rouvellou I., Devanbu P.: GlueQoS: Middleware to Sweeten Quality-of-Service Policy Interactions, ICSE 2004, Edinburgh, UK. [6] Gimpel H., Ludwig H., Dan A., and Kearney R.: PANDA: Specifying Policies for Automated Negotiations of Service Contract, Research Report RC22844, IBM T.J. Watson Research Center, Yorktown Heights, N.Y. 10598 (2003). [7] Ariba, IBM, and Microsoft. Web services definition language (WSDL), March 2001. [8] IBM Corporation. WSLA language specification, version 1.0. http://www. research.ibm.com/wsla, 2003. [9] Sahai V. Machiraju M. Saya A. v. Moorsel, and F. Casati. Automated SLA monitoring for web services. In Proc. of 13th Int. Workshop on Distributed Systems, Montreal, Canada, 2002. [10] W3C. W3C XML Query (XQuery 1.0). http://www.w3.org/XML/Query/, January 2007. [11] W3C. Web Services Policy Framework 1.5. http://www.w3.org/2002/ws/policy/, July 2006.

288


[12] Global Grid Forum. Grid Resource Allocation Agreement Protocol. Web Services Specification. Available from http://www.ogf.org/Public_Comment_Docs/Documents /Oct-2006/WS-AgreementSpecificationDraftFi nal_sp_tn_jpver_v2.pdf, October 2006. [13] W3C. Universal Description, Discovery and Integration. http://www.uddi.org/. [14] Lamparter S., Ankolekar A., Grimm S., Studer S.: Preference-based Selection of Highly Configurable Web Services In Proc. of the 16th Int. World Wide Web Conference (WWW'07). Banff, Canada, May 2007. [15] ONCEServiceExpress. www.once.com.cn

Ontological Support in eGovernment Interoperability through Service Registries Yannis Charalabidis National Technical University of Athens, 9 Iroon Polytechniou, Athens, Greece [email protected]

Abstract. As electronic Government is increasing its momentum internationally, there is a growing need for the systematic management of the newly defined and constantly transforming services. eGovernment Interoperability Frameworks usually cater for the technical standards of eGovernment systems interconnection, but do not address service composition and use by citizens, businesses or other administrations. An Interoperability Registry is a system devoted to the formal description, composition and publishing of traditional or electronic services, together with the relevant document and process descriptions in an integrated schema. Through such a repository, the discovery of services by users or systems can be automated, resulting in an important tool for managing eGovernment transformation towards achieving interoperability. The paper goes beyond the methodology and tools used for developing such a system for the Greek Government, to population with services and documents, application and extraction of useful conclusions for electronic Government transformation at global level. Keywords: eGovernment Interoperability, Enterprise modeling for interoperability, Metaddata for interoperability, eGovernment Ontology

1 Introduction In the dawn of 21st century, where system complexity, multiplicity and diversity in the public sector is posing extreme challenges to common interoperability standards, eGovernment Interoperability Frameworks (eGIF’s) pose as a cornerstone for the provision of one-stop, fully electronic services to businesses and citizens [16]. Such interoperability frameworks aim at outlining the essential prerequisites for joined-up and web-enabled Pan-European e-Government Services (PEGS), covering their definition and deployment over thousands of front-office and backoffice systems in an ever extending set of public administration organizations.

290

Yannis Charalabidis

Embracing central, local and municipal government, eGovernment Interoperability assists Public Sector modernization at business, semantic and technology layers. As more and more complex information systems are put into operation everyday, the lack of interoperability appears as the most long lasting and challenging problem for governmental organizations which emerged from proprietary development of applications, unavailability of standards, or heterogeneous hardware and software platforms.

2 Background and Scope In order to effectively tackle the transformation of Public Administration, European Union has set key relevant priorities in its “i2010 eGovernment Action Plan” [15]. At national level, most European Union Member States have produced their own National Digital Strategies (e.g. the Greek Digital Strategy 2006-2013 [25], or the Estonian Digital Strategy [11]) which include measures and strategic priorities aimed at developing eGovernment. Within this context, most countries have tried to face the interoperability challenge with the adoption of national e-GIF’s covering areas such as data integration, metadata, security, confidentiality and delivery channels, which fall into the technical interoperability layer. Such frameworks have issued “sets of documents” guiding system design but have not developed to date appropriate infrastructures, such as repositories of XML schemas for the exchange of specificcontext information throughout the public sector – observed only partially in United Kingdom’s e-GIF Registry [6] and the Danish InfoStructureBase [8]. Furthermore, as shown in recent eGovernment Framework reviews [7, 14], there exists no infrastructure proposal for constructing, publishing, locating, understanding and using electronic services by systems or individual users. In order to take full advantage of the opportunities promised by e-Government, a second generation interoperability frameworks era, launching “systems talking about systems” and addressing issues related to unified governmental service and data models, needs to commence. As presented in the next sections of this paper, such an Interoperability Registry infrastructure, should consist of: x x x x

An eGovernment Ontology, able to capture the core elements and their relations, thus representing services, documents, providing organizations, service users, systems, web services and so on. A metadata schema, extending the eGovernment Ontology and providing various categorization facets for the core elements, so as to cover for information insertion, structuring and retrieval. Formal means for describing the flow of processes, either still manual or electronic, and the structure and semantics of various electronic documents exchanged among public administrations, citizens and businesses. An overall platform integrating data storage, ontology management, enterprise modelling and XML authoring, data input and querying mechanisms as well as access control and presentation means.

Ontological Support in eGovernment Interoperability through Service Registries

x

291

The population of the eGovernment Ontology database, with information about administrations, their systems, services and documents is an important step. Since this task usually involves gathering huge amounts of information, an initial set of data should be considered first: this way, population achieves a critical mass, while automatic knowledge acquisition tools are being developed.

3 Defining the eGovernment Ontology The representation means of the proposed system should first capture the core elements of the domain, together with their main relationships. Most existing approaches for eGovernment ontologies cover neighboring domains, such as Public Administration Knowledge [12,28], Argumentation in Service Provision [22], eGovernment projects [23], or types and actors in national governments [24]. As depicted in Figure 1, the proposed eGovernment Ontology provides for the representation of the following core elements: x x x x x x x x

Services, of various types, provided by Administrations towards citizens, businesses or other administrations. Documents, in electronic or paper forms, acting as inputs or outputs to services. Information Systems, being back-office, front-office or web portals providing the electronic services. Administrations, nested at infinite hierarchical levels, being ministries, regions, municipalities, organizations or their divisions and departments. Web Services, being electronically provided services, either final or intermediate ones (contributing to the provision of final services). XML (eXtensible Markup Language) Schema Definitions, for linking the formal representation of data elements and documents. BPMN (Business Process Modelling Notation) Models, for linking services with their workflow models. WSDL (Web Services Definition Language) Descriptions, linking Web Services with the respective systematic, machine readable description of their behaviour.

292

Yannis Charalabidis isControlledBy

Administration

isPartOf

operates

Information System

issues

isPartOf

provides

Document

isSupportedBy

isProvidedBy

relatesTo

Service

relatesTo

Web Service

isPartOf hasDescription

XML Schema

hasDescription

BPMN Model

hasDescription

WSDL Description

Fig. 1. Core Elements of the Ontology

Additional objects complementing the core ontology elements are Citizens (as various types of citizens requesting services), Enterprises (both as service recipients but also as contractors for government projects), Legal Framework Elements (that guide services provision), Life Events and Business Episodes that may trigger a service request, or Technical Standards affecting the provision of electronic services. 3.1 Metadata standards for multi-faceted classification The eGovernment Ontology is supported by numerous categorization facets and standardized lists of values for systematically structuring database contents during the population phase, including types of services and documents (according with the Government Category List – GCL categorization), All the core elements of the eGovernment ontology have predefined metadata, so that their description, search and retrieval can be assisted. The implemented metadata structure is based and extends on a number of existing metadata structures in literature and practice, namely: x

The Dublin Core metadata standard [10] which provides a generic set of attributes for any government resource, be it document or system, including various extensions [20].


x x

x

x

x

293

The European Interoperability Framework – EIF (Version 1.0) [16] published by the IDABC Programme. The United Kingdom e-Government Interoperability Framework [3] and its relevant specifications (e.g. the e-Government Metadata Standard [4], the e-Government Strategy Framework Policy and Guidelines [5], and the relevant Schema Library [6]). The German Standards and Architectures for e-Government Applications (SAGA) Version 3.0 (October 2006) [17], which identifies the necessary standards, formats and specifications, sets forth conformity rules and updates them in line with technological progress. The Danish Interoperability Framework (Version 1.2.14) [9] released in 2006, which includes recommendations and status assessments for selected standards, specifications and technologies used in e-government solutions while the collaboration tool InfoStructureBase [8] includes an international standards repository containing business process descriptions, data model descriptions, interface descriptions, complex XML schemas and schema fragments. The Belgian Interoperability Framework (BELGIF) [2] that is built on a wiki collaborative environment and has released recommendations on web accessibility and on the realization of XML Schemas, apart from a list of approved standards.

The resulting metadata definitions cover all the important facets for classifying and querying the elements of the ontology, so as to provide answers to important questions around the status of electronic provision of services, existence and structure of documents, relation of services with public administrations, characteristics of the various governmental information systems and so on. Table 1 shows the metadata definitions for the Service element, indicating which of them are represented as strings, numbers, list of values or structured elements themselves. Table 1. Services Metadata Field Code Title Providing Administration Engaged Administration Final Service Beneficiary Type Category Life Event Business Event

Description, Type The Service Code, Unique, String The Service Title, Unique, String The Administration (organization, department or office providing the service), Element Other Administrations, taking part in the service provision, Multi-Element Yes/No, if it is a final service, giving output to the citizens or businesses, List Citizens or Businesses or subtypes of them, Element The Service Type, (e.g. Registration, Benefit, Application, Payment, etc), List Service Category, according to GCL (e.g. social service, taxation, education), Element The associated Life Event, Element The associated Business Event, Multi-Element

294

Yannis Charalabidis

Field Legal Framework Ways of Provision Electronic Provision Level Multilingual Content Manual Authentication Type

Electronic Type

Authentication

Frequency Web Site International Policy National Policy Information Source Date of last Update

Description, Type The applying legal framework for the service, MultiElement Manual, Internet, SMS, I-TV, etc., Multi-List Level of electronic provision (1 to 4), according with the EC standardization Languages in which the content for the service exists, Multi-List Type of Authentication needed when the service is provided in a manual way (e.g. presence in person, idcard, proxy), List Type of Authentication needed when the service is provided electronically (e.g. username/passwd, token, digital signature), List Frequency the service is requested, by means of High-Medium-Low, List The URL of the portal providing the service, String Yes / No, if the service is included in the i2010 20 core-services set, List Yes / No, if the service is included in the National Digital Strategy core-services set, List The source(s) of information for the service, String The date of last sampling, Date

Relevant, extensive metadata description fields exist for Documents, Administrations, Information Systems and WebServices, providing an indication of the descriptive power of the Ontology.

4 Combining Processes and Data The description of Services and Documents cannot be complete without formal representation of the services flow and of the documents internal structure. The importance of formal, combined description of services and document schemas has been properly identified in current literature [22,13]. Business modeling and analysis of the processes and the public documents that take part in their execution, is done using the BPMN notation [18] and the ADONIS modeling tool, provided by BoC International [21]. On top of the ADONIS tool, integration with the eGovernment Ontology (Services, Documents, Administrations) has been implemented, ensuring a complete, interoperable data schema. As shown in Figure 2, eGovernment Processes are modeled using BPMN Notation, resulting in easy identification of documents to be exchanged, decisions taken during the service flow by citizens/businesses or administrations and specific activities or information systems that take part in the overall process execution – in this case the electronic VAT declaration from an enterprise towards the TAX Authority.


295

Fig. 2. VAT Declaration Model

Design of data schemas involved in the execution of the processes under consideration, has been performed with the use of the UN/CEFACT CCTS methodology [27], for the creation of common components among the various governmental documents that have been identified through process modeling. Then, following modeling and homogenization of data components, Altova XML authoring tools [1] have been used for defining the final XSD descriptions representing business documents of all types. Final XSD files have been linked with the respective governmental documents of the ontology, resulting in a comprehensive and easy to navigate semantic network structure.

296

Yannis Charalabidis

5 The Interoperability Registry Platform The architecture that implements the Interoperability Registry comprises three layers: (a) the Web-based and UDDI (Universal Description, Discovery and Integration) interfaces for various groups of users, (b) the tools layer including ontology management, process and data modeling and (c) the information repository for interconnected data elements, process models, XML schemas and Web Services descriptions. These three layers, as shown in Figure 3, are integrated through a Relational Database Management System and the Common Access Control and Application Engine.

Registry Intranet

Registry Web Site

(Limited Access: Public Administrations and Portal Builders)

(Public Access: Citizens and Businesses)

Registry UDDI Interface (Limited Access: Systems)

Common Access Control and Application Engine

Process Modeling Tools (incl. COTS software)

Ontology Management, Population & Reporting Tools

XML Management Tools (incl. COTS software)

Relational Database Management System

BPMN Process Models

Services, Documents, Systems & Organisations Metadata

XML Schemas & Core Components

Web Services

Fig. 3. Platform Architecture

The front-end platform components are the following: x x

The Registry Web Site found within the Greek eGIF Web Site [26], which publishes the various documents of the eGovernment Framework but also gives access to citizens and businesses for publicly available data. The Registry Intranet, accessible to pre-selected public administrations and portal builders that gives access to the Registry Tools (processes, ontology, XML).


x

297

The Registry UDDI interface, where administrations publish their Web Services or find existing, available Web services to use through their information systems, constructing truly interoperable, one-stop services.

The Tools layer consists of the process modelling facilities, based on ADONIS engine, the XML Management facilities, based on ALTOVA XML platform, and the custom-developed ontology management, data entry and reporting tools that integrate all representations and models. Finally, the Data Storage layer, incorporates connected database schemas for the ontology instances, the Web Service descriptions in WSDL, the process models and the XML schemas and Core Components. The development and integration of the whole platform has been performed with the use of Microsoft Visual Studio .net suite, using the ASP 2.0/AJAX development paradigm. A parallel installation has also been performed using Java/J2EE/MySQL components.

6 Population of the Repository Initial Population of the Interoperability Registry Repository was greatly assisted by the existence of data in electronic form, through the Greek Ministry of Public Administration. As shown in Table 2, even for a country close to the average European Union Member State population (11,000,000 citizens), the size of the domain is significant, involving thousands of governmental points, services and document types. Furthermore, a plethora of information systems are currently under development, during the new Greek Digital Strategy plan, aiming to achieve full electronic operation of the State by 2013. Table 2. Size of the Domain in Greece Organisational Aspect

18 ministries, 13 prefectures, 52 districts, 1,024 municipalities, 690 public sector organizations 2,500 Governmental “Points of Service” Services and Data Aspect

3,000 non-interoperable Service Types 4,500 Document Types exchanged 1,000 IT companies supporting IT systems

Systems Aspect

300 Central Government Internet Portals 1,000 Municipal Government Internet Portals 2,500 Systems

Public

Administration

Back

Office

Users Aspect

750,000 Enterprises (small, medium and large) 11,000,000 Citizens 18,000,000 Tourists per year

Population of the repository was achieved through the following automated and semi-automated activities:

298

Yannis Charalabidis

x x x x

Automated import of more than 1,797 administrations including ministries, prefectures, districts, municipalities and public sector organisations. Automated import of 1,009 public services definitions, with core metadata descriptions and frequency indications, stemming out of 3,000,000 service requests by citizens and businesses during the last year. Modelling of the core-100 governmental services (including all i2010 services and the services amounting to 85% of the yearly service requests), Modelling of the core XML schemas and WSDL for Web Services to be developed – an activity that is still going on.

The resulting platform is now being maintained and further populated with the assistance of engaged public administrations. The acceptance of the Interoperability Registry by the Public Administration is following a three-stage approach: (a) the core team, including the Ministry of Public Administration and the National eGIF team, (b) the main Public Sector stakeholders, including key ministries, organisations and local administrations and (c) eGovernment project managers and implementation teams, from the public and private sector. Currently, registry users, with various levels of access, exceed 100.

7 Conclusions The new Greek Interoperability Registry presented in this paper introduces a new system (not a paper-based specification) that will interact with e-Government portals and back-office applications, administration stakeholders, businesses and citizens, guiding eGovernment transformation and ensuring interoperability by design, rework or change. The initial application of the system, as well as the relevant evolutions from other European eGIF’s, are indicating that new perspectives should be taken into consideration in eGovernment Frameworks from now on, analysed as following: x x

x

x

Importance and adequate effort should be put in defining standard, formally described electronic services for businesses and citizens, thus providing clear examples to administrations and service portal developers. The paper-based specification should give way to system-based presentation of the framework, incorporating service descriptions, data definitions, unified domain representation ontologies and metadata in a common repository. Organisational interoperability issues should be supported by a more concrete methodology of how to transform traditional services to electronic flows, with the use of decision-making tools. In this direction, the Interoperability Registry infrastructure presented can be of great assistance as it contains all the necessary information in a comprehensive, welldefined and connected semantic network. The collaboration among European e-Government Interoperability Frameworks is particularly beneficial for the ongoing efforts of individual


299

countries, since it ensures that lessons from the pioneers’ experience are learnt and that the same mistakes will not be repeated. Future work along the Greek eGIF and the Interoperability Registry includes both organisational and technical tasks, since the proper maintenance and usage of the registry is now the crucial issue. So, efforts will be targeting the following objectives: x x x

Binding with the Central Governmental Portal for citizens and businesses, so that the registry can by used for locating and enrolling to electronic services. Completion and publication of additional XML Schemas based on Core Components methodology. Initial training of key staff within administrations for using and extending the registry.

Finally, is has been identified that no system can work without the engagement of the public servants: more effort is to be put towards encouraging stakeholders to interact with the registry and among themselves, building synergies across the public sector authorities in a truly interdisciplinary way – hopefully extending the eParticipation features of the registry.

References [1] [2]

Altova XML-Spy Authorware Tools, www.altova.com Belgian Interoperability Framework, Belgif, (2007), http://www.belgif.be/index.php/Main_Page [3] Cabinet Office – e-Government Unit: e-Government Interoperability Framework, Version 6.1, Retrieved February 5, 2007 from http://www.govtalk.gov.uk/documents/e-GIF%20v6_1(1).pdf [4] Cabinet Office – Office of the e-Envoy, e-Government Metadata Standard, Version 3.1, Retrieved February 5, 2007 from http://www.govtalk.gov.uk/documents/eGMS%20version%203_1.pdf [5] Cabinet Office – Office of the e-Envoy, Security - e-Government Strategy Framework Policy and Guidelines Version 4.0, Retrieved Feb. 2007 from http://www.govtalk.gov.uk/documents/security_v4.pdf [6] Cabinet Office, UK GovTalk Schema Library, http://www.govtalk.gov.uk/schemasstandards/schemalibrary.asp, (2007) [7] Charalabidis Y., Lampathaki F., Stassis A.: “A Second-Generation e-Government Interoperability Framework” 5th Eastern European e|Gov Days 2007 in Prague, Austrian Computer Society, April 2007 [8] Danish e-Government Project, InfostructureBase (2007), http://isb.oio.dk/info [9] Danish Interoperability Framework, Version 1.2.14, Retrieved February, 2007 from, http://standarder.oio.dk/English/Guidelines [10] Dublin Core Metadata Element Set, Version 1.1, Retrieved January 25, 2007 from http://dublincore.org/documents/dces/ [11] Estonian Information Society Strategy 2013, ec.europa.eu/idabc/en/document/6811/254, 30 November 2006 [12] Fraser J, Adams N, Macintosh A, McKay-Hubbard A, Lobo TP, Pardo PF, Martinez RC, Vallecillo JS: “Knowledge management applied to e-government services: The

300

[13]

[14]

[15] [16]

[17]

[18]

[19]

[20]

[21] [22] [23] [24]

[25] [26] [27]

[28]

Yannis Charalabidis

use of an ontology”, Knowledge Management In Electronic Government Lecture Notes In Artificial Intelligence 2645: 116-126, Springer-Verlag, 2003 Gong R., Li Q., Ning K., Chen Y., O'Sullivan D: “Business process collaboration using semantic interoperability: Review and framework”, Semantic Web - ASWC 2006 Proceedings, Lecture Notes In Computer Science, Springer-Verlag, 2006 Guijarro L.: “Interoperability frameworks and enterprise architectures in egovernment initiatives in Europe and the United States”, Government Information Quarterly 24 (1): 89-101, Elsevier Inc, Jan 2007 The i2010 eGovernment Action Plan, European Commission, http://ec.europa.eu/idabc/servlets /Doc? id =25286, 2007 IDABC, European Interoperability Framework for pan-European e-Government Services, Version 1.0, Retrieved February 5, 2007 from http://europa.eu.int/idabc/en/document/3761 KBSt unit at the Federal Ministry of the Interior, SAGA Standards and Architectures for e-Government Applications Version 3.0, Retrieved February 5, 2007 from http://www.kbst.bund.de/ OMG Business Process Modelling Notation (BPMN) Specification, Final Adopted Specification http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%2010%20Spec%2006-02-1.pdf Seng JL, Lin W: “An ontology-assisted analysis in aligning business process with ecommerce standards”, Industrial Management & Data Systems 107 (3-4): 415-437, Emerald Group Publishing, 2007 Tambouris E, Tarabanis K: “Overview of DC-based e- -driven eGovernment service architecture”, Electronic Government, Proceedings Lecture Notes In Computer Science 3591: 237-248, Springer-Verlag, 2005 The ADONIS Modeling Tool, BoC International, http://www.boc-group.com/ The DIP project eGovernment Ontology http://dip.semanticweb.org/documents/D9-3improved-eGovernment.pdf, 2004 The Government R&D Ontology, http://www.daml.org/projects/integration/projects20010811 The Government type Ontology, http://reliant.teknowledge.com/DAML/Government.owl, CIA World Fact Book, 2002 [12] The Greek Digital Strategy 2006-2013 (2007), http://www.infosoc.gr/infosoc/enUK/sthnellada/committee/default1/top.htm [2] The Greek eGIF Website, available at http://www.e-gif.gov.gr [28] UN/CEFACT Core Components Technical Specification, Part 8 of the ebXML Framework, Version 2.01, Retrieved January 25, 2007 from http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf Wimmer, M.: “Implementing a Knowledge Portal for e-Government Based on Semantic Modeling: The e-Government Intelligent Portal (eip.at)”, Proceedings of the 39th Annual Hawaii International Conference on System Sciences (HICSS'06) Track 4 p. 82b, 2006.

Towards Secured and Interoperable Business Services A. Esper, L. Sliman, Y. Badr, F. Biennier LIESP, INSA-Lyon, F-69621, Villeurbanne, France {alida.esper, layth.sliman, youakim.badr, frederique.biennier}@insa-lyon.fr

Abstract. Due to structural changes in the market, from mass customisation to increased interest in product-services management, an exponential growth of a service ecosystem will emerge in the coming years. This shift in the economy creates a need for instant and ondemand collaborative organisations which involve radical changes in the organizational structure of enterprises, increasing the need for business interoperability. Unfortunately, existing enterprise engineering approaches and information systems technologies lack the intrinsic agility and adaptability features required by these service-based collaborative organisations. To overcome these limits, we introduce a new approach called the Enterprise Urbanism Concept to reorganize enterprises into sets of interoperable industrial services. This new approach relies on the extension of the concept of information system urbanism in order to take into account industrial constraints while reorganising service business units. Nevertheless, despite this intrinsic partner reorganisation, instant and on-demand collaborative organisations can be limited due to a lack of trust between partners. To overcome these limits, we reinforce our approach by clearly assessing contextual security policies based on the patrimony of a company and technological security components. These components can be dynamically added in respect to the collaboration context when organising a consistent chain of industrial services. Keywords: Security issues in interoperability, Interoperable enterprise architecture, Service oriented Architectures for interoperability, Business Process Reengineering in interoperable scenarios, Enterprise modeling for interoperability

1 Introduction The need for increased customisation and service-oriented products has forced enterprises to adapt their organisational strategy. While focusing on their core business competencies, outsourcing and collaborative strategies must respond to market requirements, for example, being able to provide a high-quality service level to consumers. These organisational trends enhance the enterprise’s agility such as its ability to quickly respond to structural changes, client requests,

302

A. Esper, L. Sliman, Y. Badr, F. Biennier

technological or activity changes, supplier management [24, 30] and to reduce waste leading to a lean manufacturing organisation [42]. These organisations heavily use Information and Communication Technologies (ICT) [34] leading to increase the call for IT inter-operability. Their performance level is related to efficient information sharing systems so that deviation risks can be reduced [18]. Moreover, the increasing association between products and services creates a need to organize instant collaborations to fulfil a customer’s request. Consequently, an exponential growth of a ubiquitous ecosystem of services will emerge in the coming years. The ecosystem of services in the economy will rely on software services and support which span multiple organizations and service providers. The dynamic interaction between services creates chains of organizations that will provide agile support for business applications, governments, or, simply, the consumer. This global service vision leads us to identify two major statements: 2.

As such service ecosystems rely on a collaborative industrial organisation, service models must be designed to take into account industrial constraints. Furthermore, firms must be re-organised to provide consistent and interoperable industrial services. 3. Building a dynamic service chain depends on the capability to link services together in arbitrary ways in order to meet customer needs. Nevertheless, the potential lack of trust between partners can an obstacle to the global adoption of such distributed architectures. To overcome this limit, particular attention must be paid to both security requirements and management while specifying the context of the service and user preferences. The propagation of these constraints must be included in service compositions and orchestrations to respond to a particular service need. The paper is organized as follows: after defining the extended context of services in Section 2, we will introduce a new service model in Section 3 to specify business interoperability constraints. Lastly, in Section 4, we will define how services can be dynamically orchestrated through the combination of adapted technological components that fulfil context requirements.

2 Challenges in Ecosystem of Services The integration of services when selling a product increases the need for inter-firm collaborations and leads to the organization of industrial activities according to dynamic added-value networks instead of Michael Porter’s traditional value chain model [40]. Such a vision involves being able to dynamically define the way that global services can be linked together in industry. Yet, the definition of a global service is in contrast with the traditional enterprise organisation in terms of business sectors (i.e. sales and production) supported by underlying corporate information systems. This approach imposes an organization of the enterprise in respect to generic models of business sectors that can be customised. Unfortunately, this approach often leads to monolithic top-down engineering

Towards Secured and Interoperable Business Services

303

practices, gathering different engineering tools and methodologies in a common reference architecture [27]. In addition, it creates a vertical organisation of the enterprise in terms of customer relationship, supply management and production systems. The vertical organization, fully impacted when organising a dynamic collaboration, exhibits a poor agility level. 2.1 Interoperable Business and Production Processes Moreover, corporate information systems depend on a wide variety of technological-based support systems (i.e. DBMS and programming languages, etc.) and various business sectors. Examples include the Enterprise Resource Planning, Product Life Management, Manufacturing Execution Systems and Supply Chain Management Systems. Such corporate information systems exhibit a high level of technological complexity and lack system interoperability. They involve information redundancy which cause inconsistencies and decrease the flexibility and scalability of their architectures. Although leaner approaches such as workflow management systems can be fruitfully used to support both business and production processes [35], these on-demand tools may adversely increase Information System complexity and inconsistency. We attempt to solve these problems by recalling the Information System Urbanization approach [33] which organises the Information System into different levels. The urbanization approach separates activities from the Information System and technical infrastructure [12]. Inversely, the introduction of ServiceOriented Architecture (SOA) enables a flexible design and which produces a reactive environment of applications interconnected through an applicative bus that orchestrates processes [38]. Coupling the urbanization paradigm and the ServiceOriented Architecture in the design of Information Systems will improve the consistency and the agility of the firm to reorganize its activities. It is the first step towards the organisational business interoperability between collaborative firms. This coupling approach focuses on activities as fine-grained components of information and production systems in respect to the enterprise functional organisational chart and without taking into account the logic of production processes or organisational constraints. 2.2 Propagation of Security Requirements A lack of trust between partners can limit the emergence of collaborative organizations and weaken collaboration strategies in the way that partners share information. As information represents an important part of the enterprise patrimony [31, 15], security requirements must be taken into account while designing both business processes and the physical implementation [7]. The definition of security policy is often limited to the implementation of a secure infrastructure. For this purpose, methodologies and industrial standards have been defined since the 1980s to propose international level of certifications such as the DoD Rainbow series [19], ITSEC [21] and Common Criteria [16]. Nevertheless, this reduced point of view provides technical solutions to threats and vulnerabilities caused by the technology. Early risk analysis approaches, such as

304


EBIOS [17] and MEHARI [14], allow the design and implementation of safe architectures of consistent and reliable systems based solely on technological solutions as proposed in SNA [36] and OCTAVE [2]. Organisational vulnerability must also be considered in defining consistent security policy as proposed in the ISO 17799 standard [28]. Few approaches, such as UML-SEC [29] and web services deal with the integration of security requirements when designing processes. Security requirements in web services can be achieved at the technical level in respect to a reference architecture [25] that integrates different standards such as WS-Security [37] and WS-federation [26] for securing SOAP messages and federating different security realms. The security policies of infrastructures and processes suffer from being locally limited to corporate information systems [20]. Policy requirements and implementation are generally bounded by the boundary of each firm. The dominant logic of ecosystem of services implies global security roadmaps among chains of collaborative services. Security requirements and constraints should be propagated when orchestrating chains of distributed services. We attempt to deal with the problem of security propagation by examining Digital Rights Management architectures [23]. These architectures provide long life-cycle protection of audio and video contents based on cryptographic techniques and associated players. Adapting such an approach to a dynamic ecosystem of services involves the design of services to support contextual dynamic binding. The technology of Hippocratic databases [1] which respects the privacy of data it manages could ensure that disclosure concerns (i.e. privacy policy, security policy, legislation, etc.) are protected. Digital Rights Management architectures and Hippocratic Databases support security policies and access rights management [32] including user preferences in respect to the industrial standard of Platform for Privacy Policies (P3P) [13]. In conclusion, the ecosystem of services urges solutions to build on-demand and secured interoperable service systems. In the next section, we introduce an extended service model to embed both business interoperability and security constraints. We then pay special attention to define how contexts can be used to implement such service framework. We emphasize the contextual binding and orchestration monitoring functions.

3 Secure Interoperable Business Organisation To organise interoperable business organisations, our works rely on the Enterprise Urbanism concept [5] which splits the enterprise organisation into several “business areas” coupled with the production organisation. In this organisation the evolution of the corporate information system is guaranteed by the flexible and incremental design of processes [4]. In the enterprise urbanisation approach, the specification of business areas integrates industrial flows, competencies, decisions and information viewpoints. Because of the correlation between business areas and the production organisation, a given full process, including customer relationship management, production and purchase activities, belongs to the same autonomous


305

area [39]. This process can easily be integrated in dynamic collaborative organizations by binding and orchestrating industrial services. 3.1 Interoperability Constraints While traditional information systems focus on management and business aspects, we pay particular attention to the industrial aspect to efficiently support coproduction constraints and build interoperable business organisation. This leads to take into account several interoperability constraints: x

x x

Organisational Interoperability: means that enterprises must share the same goal and have compatible management strategies. This interoperability level is also related to the security policy and security context management so that a consistent end-to-end secured organisation can be built. Industrial Interoperability: means that enterprises must share information regarding products and production processes such as the process maturity level and the required real time of execution. Technical Interoperability: means that the different applications of the information system can exchange information.

3.2 Interoperable Business Services Based on different constraints, we propose to extend the service model that we have proposed in previous work [8] to design a multi-level architecture in order to build interoperable business services (Fig. 1): x x

x

x

The enterprise level: consists of the organisation of traditional business areas. The business service level: consists of sets of shared services that take into account both organisational and industrial interoperability constraints. These two levels are interconnected by means of urbanisation composition of services which gather different groups of technology tools and the routing system. Roughly speaking, the group of technology tools is used to identify consistent industrial units. The routing system connects each industrial business area to the traditional “vertical” business area. The collaborative level: defines different collaboration policies and trust rules in order to simplify both the contractual enactment phase and the dynamic building of adapted security policies. Policy requirements depend on partners engaged in the chain of services. The technological level: denotes shared and accessible interfaces to connect the industrial services to the implemented services. This level includes the contextual composition and orchestration engine, the Enterprise Service Bus (ESB) as well as connectors to components of the information system.

306


Supply

Customer

Accounting

Production

Design

Enterprise traditional organisation

Group technology tools

Business routing

Urbanisation

Industrial services

Service A Service A Industrial services

Service B Service B

Composition / orchestration

Service C Service C

Service D Service D

Service E Service E

Policies / preferences

Context manager

Composition / orchestration Security

B2B gateway

Mediation Entreprise

External Service provider

Soap service request

Transformation

Routing

Service Bus

Application Access service

Data access service

ERP

Web

Business service choregrapher

Service routing directory Business service directory

IT system SCM

Mainframe

CRM

Fig. 1. Multi-Level Architecture of Interoperable Industrial Services

3.3 The Service Extended Model The organisation of interoperable industrial services relies on a multi-interface extended service model (see figure 2): x

x

The industrial service: describes competencies of the service in terms of what the service can achieve (i.e. a “virtual” service product, a “real” manufactured product or a “product-service” offer connecting a manufactured product to the related value-added services). This conceptual service includes a global accessible interface defining exactly what the service will achieve (i.e. a stand alone product or a service-included product). The manufacturing interface: includes two views describing how the manufacturing service will be achieved: -

Product view: gathers information on material and products (i.e. bills of material, management policy, quality indicator, etc.) as well as production management strategies. As far as value-added services are concerned, the required resources including human


-

What will be achieved

Service Competencies

Pattern Indicator SLA Interface Acquisition

Manufacturing Interface

Exchange

Management Data

x

The control interface of the Service Level Agreement: Real-time constraints are used to describe global QoS constraints to be included in SLAs whereas safety constraints are used to define pre-emptive or non-preemptive services. This interface is coupled with a dynamic monitoring system to dynamically define adapted QoS monitoring features [9]. The security control interface: describes the global protection that should be applied to both data and processes depending on perceived risks and according to partner trust levels. In order to take into account threats related to the pervasive infrastructure of services, a particular facet devoted to the exchange protection is added. The implementation interface: indicates the semantic service to be executed by the implementation level. Adding this “virtual service layer” before composing and orchestrating “concrete services” allows us to remain independent from the IT system organisation and protect it as well by publishing only “embedded” service interface [10]. It consists of the conceptual service description and contextual policy information (i.e. security, QoS…) defined by WS-policy based ontologies [11]. Then, technological services, which are devoted to information access, monitoring and security are added before orchestrating industrial services.

Process

x

software and hardware resources are described in a bill of resources and management strategies which define the way resources will be scheduled. Process view: describes the routing specification, the process qualification according to the CMMI classification [41] and potential resource constraints used when allocating the manufacturing service to resources.

Process Material Management

How it will be achieved

Security interface Implementation interface Technical Abstraction Level

x

307

Conceptual service

Contextual policy patterns

Implementation …

How it is orchestrated

Fig. 2. Extended Service Model

308


3.4 The Binding Mechanism Binding industrial services is achieved according to the following steps: 1.

The service “semantic” selection first defines potential candidates. This service competencies description is associated to the public process interface without exactly specifying what will be processed or the returned information granularity level. 2. The industrial interoperability is then taken into account by refining the selection process according to process maturity and management rules so that a consistent service chain can be built. 3. The contextual information related to the service consumer is used to select the convenient “core process” associated with the private part of the process, adapting the returned information granularity level to the exact context. The duo of process and service description is only used to publish a visible part of the business service. 4. Lastly, Quality of Service (QoS) requirements are confronted with the current context to define which potential candidates can be selected and which monitoring services must be set to control the orchestration of services. After these industrial services composition phases, the “conceptual service” and the contextual information are transmitted to the implementation level so that technological services can be composed in order to support the technological interoperability.

Technical Abstraction Level

Business Abstraction Level

Conceptual service

Interface

« Published » unique Business instance

Implementations Collaboration Strategy based instances

Interface

Implementation

Interface

Implementation

Fig. 3. Embedded Conceptual Service and Core Process Relationships


309

4 Implementation Architecture To fit the technological interoperability requirement we propose an on-demand dynamic service binding process. Organised in a bottom-up way, the binding process consists of assembling “technological” sub-components so that the orchestrated services can be tuned to exactly fit environmental needs such as implementing a convenient security policy and supporting semantic and syntactic interoperability. Security policies are defined according to the following contexts: x

x

x

x

Provider Preferences: define different security requirements of the information system according to data and process patrimonial-values which describe the importance of the potentially shared element. Depending on the trust level of service customer and the underlying infrastructure, different security policies can be applied including authentication and authorisation processes and information cryptographic requirements [6]. Customer Preferences: are described in respect to the P3P specification and exactly define which customer information can be processed (i.e. authentication, logged accesses, etc) as well as mediation constraints (i.e. data interchange format). Collaborative Context: describes contractual relationships between the service provider and the service customer. These contractual relationships are used to specify what the service customer is allowed to directly process as well as Quality of Service requirements through industrial SLAs [9]. Infrastructure Context: in a pervasive environment, different threats are caused by the communication infrastructure. Particular security components must be added to protect the underlying infrastructure.

To provide dynamic contextual composition and orchestration features, we consider the orchestrated services as autonomous components. Each contextual view is associated with generic patterns implemented as classes, in a similar way as the PIM4SOA framework [3]. Then the dynamic binding process consists of providing a multi-model instantiation process conditioned by different contexts and standard components (i.e. pattern components). The instantiation process is used to select and bind the technological components patterns and generates the convenient BPEL script in respect to technological interoperability constraints. These autonomous services include: x x

x

Information System Access Services: these technological components implement connectors to the different software of the corporate information system. Mediation and Transformation Services: these technological components are used to support syntactic and semantic interoperability in translating information to understandable formats by applications. They are based on B2MML and FDML [22] in order to implement information interface services towards business service providers and manufacturing resources, respectively. Access Services: these technological components implement access controls, namely authentication, access filtering and reporting functions,

310


x

x

according to the partners’ collaboration scenario and based on the security policy and contextual information. Exchange Security Services: denote cryptographic components ensuring that soap message can be secured according to infrastructure contextual information. They provide encrypted content and its associated “playing” service which is invoked each time the message content is accessed. The exchange security service checks out whether the access request is defined in the “information licensing conditioned” base of the service provider. Monitoring Services: dynamically generate monitoring components based on QoS requirements and monitoring patterns.

5 Conclusion and Further Works In this paper, we propose extended an Industrial Service-Based Architecture to support secured interoperable businesses. This architecture is implemented in the Service-Oriented Enterprise Architecture. As trust and perceived risks are key points that are taken into account when defining a collaborative strategy, we pay particular attention to security policies and requirements when composing chains of services with regards to service consumer and infrastructure characteristics. The next steps will focus on the way a Lean Service Bus can be implemented in order to reduce IT structuring effects. Such a Lean Service Bus will adapt the orchestration process to a “pull flow” logic. Coupled with a trigger system, this service bus will improve the way the industrial service architecture fit the lean enterprise requirements.

Acknowledgements This work was supported by grants from the INSA BQR project “Enterprise urbanism” and the Rhône-Alpes Region Council through the GOSPI Cluster project INTERPROD.

References [1] [2]

[3]

[4]

Agrawal R., Kiernan J., Xu Y., Srikant R., 2002. Hippocratic Databases, 28th VLDB Conference, 10 pages, 2002. Alberts C., Dorofee A., 2001. An Introduction to the OCTAVESM Method. CERT White Paper. Available Online at http://www.cert.org/octave/methodintro.html, [Last Visited September 30 2007] Benguria G., Larruceat X., Elvesaeter B., Neple T., Beardsmore A., Friess M., 2007. A platform independent model for service oriented architecture. In Enterprise Interoperability: new challenges and approacghes. Doumeingts G., Müller J., Morel G., Vallespir B. Eds., Springer. pp. 23-32 Biennier F., Favrel J., 2003. Collaborative Engineering in Alliances of SMEs. Actes de PRO-VE’03. Lugano (Suisse), October 2003. In : Processes and foundations for


[5] [6] [7] [8]

[9]

[10]

[11]

[12] [13] [14]

[15]

[16]

[17]

[18] [19] [20]

[21] [22]

311

virtual organizations. Camarinha-Matos L., Afsarmanesh H. (Eds.). Kluwer academic publishers. pp. 441-448 Biennier F., Buckard S., 2005. Organising Dynamic Virtual Organisation: Towards Enterprise Urbanism, APMS 2005 Biennier F., Favrel J., 2005. Collaborative Business and Data Privacy: Toward a Cyber-Control Computers in Industry, V. 56, n° 4, pp. 361-370 (May 2005) Biennier F., Mathieu H., 2005. Security Management: Technical Solutions v.s Global BPR Investment. Schedae informatica vol. 14, pp. 13-34 Biennier F., Mathieu H., 2006: Organisational Inter-Operability: Towards Enterprise Urbanism. In Entreprise interoperability – New challenges and approaches, Eds.Doumeingts G., Müller J., Morel G., Vallespir B. Eds. Springer. pp. 377-386 Biennier F., Ali L., Legait A., 2007. Extended Service Integration: Towards Manufacturing SLA. IFIP International Federation for Information Processing, Volume 246, Advances in Production Management Systems, Olhager, J., Persson, F.. Eds., pp.87-94 Chaari S., Benamar C., Biennier F., Favrel J., 2006. Towards service oriented enterprise. In the IFIP International Conference on PROgraming LAnguages for MAchine Tools, PROLAMAT 2006, 15-17 June, Shanghai, China, pp 920-925. (ISBN: 978-0-387-34402-7) Chaari S., Badr Y., Biennier F., 2008. Enhancing Web Service Selection by QoSBased Ontology and WS-Policy. accepted in the 23rd ACM Symposium on Applied Computing, Ceará, Brazil, 16-20 March 2008 CIGREF 2003. Accroitre l’agilité du système d’information. Livre blanc du CIGREF, September 2003. Cranor Lorrie, Privacy with P3P, 239 pages, O’Reilly, 2001 CLUSIF, 2000. Mehari. Rapport Technique. 91pp, Available Online at https ://www.clusif.asso.fr/fr/production/ouvrages/pdf/MEHARI.pdf [Last Visited September 30, 2007] CLUSIF, 2005. Enquête sur les politiques de sécurité de l'information et la sinistralité informatique en France en 2005. online [Last Visited September 30, 2007] : http://www.clusif.asso.fr/fr/production/sinistralite/docs/etude2005.pdf Common Criteria Organisation, 1999. Common Criteria for Information Technology Security Evaluation – Part I: introduction and general model version 2.1 – CCIMB 99-031. Available Online at http://www.commoncriteria.org/docs/PDF/CCPART1V21.PDF, 61 p. [Last Visited, September 30, 2007] Direction Centrale de la Sécurité des Systèmes d’Information (DCSSI), 2004. Expression des Besoins et Identification des Objectifs de Sécurité : EBIOS, Rapport Technique. Available Online at http://www.ssi.gouv.fr/fr/confiance/ebios.html, [Last Visited, September 30, 2007] DeVor R., Graves R., Mills J.J., 1997. Agile Manufacturing Research: Accomplishments and Opportunities. IIE Transactions n° 29, pp. 813-823 Department Of Defence (DoD), 1985. Trusted Computer Security Evaluation Criteria - Orange Book. DOD 5200.28-STD report. Djodjevic I., Dimitrakos T., Romano N., Mac Randal D., Ritrovato P., 2007. Dynamic security Perimeters for Inter-enterprise Service Iintegration. Future generation of computer systems (23). pp. 633-657 EEC, 1991. Information Technology Security Evaluation Criteria. Available Online at http://www.cordis.lu/infosec/src/crit.htm, [Last Visited September 30, 2007] Emerson D., Brandl D., 2002. Business to Manufacturing Markup Language (B2MML) version 01. 60 p.

312


[23] Erickson J.S., 2003. Fair Use, DRM and Trusted Computing. Communications of the ACM, vol 46, n°4, , pp.34-39 [24] Goldman S. Nagel R., Preiss K., 1995. Agile Competitors and Virtual Organisations. New York: Van Nostrand Reinhold. [25] IBM and Microsoft Corp., 2002. Security in a Web Services World : A Proposed Architecture and Roadmap. 28pp white paper, Available Online at ftp://www6.software.ibm.com/software/developer/library/ws-secmap.pdf, [Last Visited, September 30, 2007] [26] IBM, Microsoft, BEA, Layer 7 technology, Verisign, Novell Inc., 2006. Web Services Federation Language. Version 1.1. Available Online at http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WSFederation-V1-1B.pdf. [Last Visited , September 30, 2007] [27] IFAC-IFIP, 1999, GERAM: Generalized Enterprise Reference Architecture and Methodology, Version 1.6.3, IFAC-IFIP Task Force on Architecture and Methodology. [28] ISO, 2000. ISO/IEC 17799:2000 standard - Information technology. Code of Practice for Information Security Management. [29] Jürjens J., 2002, UMLsec: Extending UML for Secure Systems Development. Lecture Notes in Computer Science 2460, UML 2002 Proceedings, pp. 412-425 [30] Lee H.L., 2004. The Triple A Supply Chain. Harvard Business Review, October 2004, pp. 102-112 [31] Levitin A.V., Redman T.C., 1998. Data as a Resource: Properties, Implications and Prescriptions. Sloan management review, fall 1998. pp. 89-101 [32] Lin A., Brown R., 2000, The Application of Security Policy to Role-based Access Control and the Common Data Security Architecture, Communication (23) pp. 15841593 [33] Longépé C, 2003. The Enterprise Architecture IT Project - The Urbanisation Paradigm, Elsevier. 320p. [34] Mahoué F., 2001. The E-World as an Enabler to Lean. MSc Thesis. MIT. [35] Martin J., 1992. Rapid Application Development, Prentice Hall, Englewood Cliffs. [36] Moore A. P.; Ellison, R. J., Architectural Refinement for the Design of Survivable Systems. Technical Note (CMU/SEI-2001-TN-008), Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, October 2001, Available Online at http://www.sei.cmu.edu/publications/documents/01.reports/01tn008.html [Last Visited, September 30, 2007] [37] OASIS, 2004. Web Services Security: SOAP Message Security 1.0 (WS-SECURITY 2004). 56 pages Available Online at http://www.oasisopen.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf [Last Visited, September 30, 2007] [38] Schmidt M.T., Hutchinson B., Lambros P., Phippen R., 2005. The Enterprise Service Bus. : Making Service Oriented Architecture Real. IBM System Journals, vol. 44, n° 4, pp.781-797. [39] Sliman L., Biennier F., Servigne S., 2006. Urbanisarion Conjointe de l’entreprise et de son Système d’Information. Colloque IPI 2006 proceedings : "Comprendre et piloter la mutation des systèmes de production", pp. 169-180 [40] Tekes, 2006. Sara - Value Networks in Construction 2003-2007. Sara technology programme, Available online at http://www.tekes.fi/english/programmes/sara [Last Visited, September 30, 2007] [41] Williams R., Wegerson P., 2002. MINI CMMI(SM), SE/SW/IPPD/SS Ver 1.1, Staged Representation. Cooliemon. [42] Womack J.P., Jones D.T., 2003. Lean Thinking, 2nd edition. Simon & Schuster, 404 p

Part IV

Ontologyies and Semantics for Interoperability

Semantic Web Services based Data Exchange for Distributed and Heterogeneous Systems Qingqing Wang1,2, Xiaoping Li1,2 and Qian Wang1,2 1

School of Computer Science and Engineering, Southeast University, Nanjing 210096, P.R.China 2 Key Laboratory of Computer Network and Information Integration(Southeast University), Ministry of Education, Nanjing 210096, P.R .China [email protected], [email protected], [email protected]

Abstract. Data exchange is the process of exchanging data between systems online, in which heterogeneity, distribution and different semantic descriptions are the main difficulties. In this paper, a data exchange framework constructed on the architecture of Web services is proposed, in which data provider deploys Web services for data exchange and publishes description of service function and exchange data on a register center, data requester searches for web services on the register center according to his requirements on function and data. To improve precision of data discovery, a semantic matching mechanism for matching the provided and requested Web services, based on OWL-S (Web Ontology Language for Services), is presented. The matching mechanism which takes both service function and exchange data into account calculates the semantic similarity of two Web services as matching result. A prototype system is implemented to verify the proposed framework and matching mechanism. Keywords: Interoperability for knowledge sharing, Ontologies and Semantic Web for interoperability, Interoperability for knowledge creation, transfer, and management, Design methodologies for interoperable systems, Enterprise application Integration for interoperability

1 Introduction Sharing information is difficult in systems with different operating systems, heterogeneous database management systems and distributed data sources based on various semantic description abilities and isolating levels. Data exchange, which is one of the ways to share information between such systems, is the process of exchanging data dynamically between systems [1] [2] and transforming data under a source schema to data under a target schema [3].

316

Qingqing Wang, Xiaoping Li and Qian Wang

Data exchange is a traditional problem, for which there are many different solutions according to different application scenes, user requirements and technical environments. Here we present a brief survey of some methods for data exchange: (I) EDI (Electronic Data Interchange). This is the electronic transfer between separated computer applications of commercial or administrative transactions, using an agreed standard to structure the transaction or message data. This kind of methods [4] focuses on the issues of data transfer and data format. However, other parts of data exchange process are not taken into account. (II) Traditional approaches of integrating heterogeneous data sources. This kind of methods [5] mostly uses wrapper components to shield the differences among data sources. They focus on transforming data formats. Other issues such as data discovery and data transferring are not referred to. These methods suit the scene that the data sources to exchange data are not many and changing frequently. (III) XML based method. This kind of methods uses XML as the medium of data exchange. XML files whose schemas can be matched and formats can be transformed is the common data format in the process. These methods [6] [7] focus on schema matching or format transforming. However, data discovery on internet are not emphasized. Moreover, some standards such as RosettaNet [8] and ebXML [9] also focus on data exchange and describe data with XML. But people in different industries define different XML tags according to their own customs, which causes that these standards become complex and separate with each other and lack of compatibility. Web services technology which defines how to interoperate between Web applications have three parts: service provider, service requester and service broker. Web services can solve the problem of distribution in data exchange and improve the efficiency and precision of data discovery, in which Web services matching is a key issue. Presently, existing Web services matching mechanism can be divided into two categories: (1) Syntax level. This kind of mechanisms usually publishes Web services according to industry classify standards, describes Web services interfaces by WSDL and matches Web services based on key words. These mechanisms can realize Web services discovery on Internet, but lack of function description for Web services as well as semantic information. Usually, these mechanisms are terse but with low discovery precision. Typical application are the UDDI systems developed by IBM, Microsoft, HP and so on [10]. (2) Semantic level. This kind of mechanisms usually describes Web services based on ontology theory, which can solve the semantic heterogeneity of syntax level mechanisms and add semantic description of Web services’ function. Service matching usually takes IOPE (Input, Output, Precondition and Effects) of Web services into account. Generally, discovery precision of semantic level is higher than the syntax level’s. Research on matching mechanism of semantic level and some related matching algorithms are introduced in [11] [12] [13]. Now, weaknesses of existing data exchange methods are: (1) exchange data is not easy to be discovered on Internet, (2) few methods are capable of completing the whole process of data exchange on Internet. To solve these shortcomings, a semantic Web services based data exchange method is proposed in this paper. Our focus is realizing the whole process of data exchange and easy data discovery on Internet. In the method, a data exchange framework is constructed on the

Semantic Web Services based Data Exchange

317

architecture of Web services, in which information of exchange data can be published and discovered, data discovery can be realized based on semantic information, data can be obtained and transferred remotely and data schema matching as well as data format transforming can be realized too. In order to improve the precision of data discovery, a Web services matching mechanism of semantic level for data exchange is also presented.

2 Terms and Definitions Data Exchange on Internet is the process of discovering needed data on Internet, exchanging data between information systems and transforming data under a source schema to data under a target schema. The process consists of data publishing, data discovery, data getting, data transferring, schema matching and format transforming. Data schema

Data publishing Data discovery Data getting Data transferring Schema matching

Format transforming

Service matching

Web services for data exchange

is the description for structures, compositions and properties of a data set. For database, it is the description for structures of tables, relations between tables as well as properties of fields. is the process of publishing information of exchange data on Internet for being requested. is the process of requesting needed data on Internet. is the process of extracting needed data from the database of data provider’s system. is the process of transferring exchange data from data provider’s system to data requester’s system. is the process of matching or mapping data schemas between data provider and data requester according to certain rules. is the process of transforming exchange data under provider’s schema to data under requester’s schema according to the result of schema matching. is the process of matching published Web services and requested Web services, the result of which should show the requester’s requirements at a certain extent. is a special kind of Web services which can provide exchange data.

318


3 Data Exchange Method 3.1 Architecture Figure 1 shows the architecture of the WSDE (Web Services based Data Exchange method) proposed in this paper, which is constructed on the architecture of Web services. There are three participants: DPRO (Data Provider), DREQ (Data Requester) and SUDDI (Semantic Universal Description Discovery and Integration) center. 68'', &HQWHU Preceding API Module

: HE 6 HU Y 3X EOLV K '352

Service Requesting API Result Displaying API Service Matching Module 6HUYLFH GDWD GHVFULSWLRQ 2:/ 6

6HUYLFH PDWFKLQJ HQJLQH

6HUYLFHRQWRORJ\ EDVH

8'', PDSSLQJ HQJLQH

V LFH HU Y 6 HE W : HV TX 5H

LFH V

Service Publishing API

'5(4

'RPDLQRQWRORJ\ EDVH

Service Requesting Module

Service Publishing Module 8'', %DVHG RQ 8'', Criterion

Data Encapsulating Module

Schema Matching Module 6FKHPD PDWFKLQJ HQJLQH

Service Deploying Module

,QYRNH :HE 6HUYLFHV Database

Service Invoking Module

Web Server

0DWFKLQJ UHVXOW HQJLQH ;6/7

'RPDLQ RQWRORJ\ EDVH

Format Transforming Module

Database

Application Software

Fig. 1. Architecture of WSDE

DPRO is the system who can provide exchange data on Internet. It deploys a local Web service and publishes service description as well as information of exchange data on the SUDDI center. When the service is invoked, DPRO extracts data from database dynamically, transforms it into a XML file and transfers the file to DREQ. DREQ is the system who needs exchange data. It requests Web services for data exchange on the SUDDI center. If a useful Web service has been requested successfully, DREQ invokes the service, gets exchange data from data provider, matches the data schema of provider and itself and transforms the exchange data under provider’s format to its own data format.


319

The SUDDI center accepts and matches the description of published services and requested services. It extends common UDDI systems found on UDDI 2.0 criterion, to which adds a semantic module. A semantic Web services matching mechanism for data exchange is presented in the semantic module, which is introduced in section 4. 3.2 DPRO (Data Provider) Modules of DPRO are described as follows: (1) Service Publishing Module This module is used to describe functions of published Web services and provided exchange data according to the service description model and the data description model respectively (introduced in Section 4), and publish function description as well as data description on the SUDDI center. (2) Service Deploying Module This module is used to deploy Web services that have been designed for data exchange to local web server. The WSDL file of these Web services will be uploaded on the web server too. When invoked, DPRO extracts requested data by data encapsulating module and transfer data to DREQ by SOAP. (3) Data Encapsulating Module This module is used to extract data schema of exchange data when the Web service is published and extract exchange data dynamically from provider’s database according to data requester’s needs when the Web service is invoked. 3.3 DREQ (Data Requester) Modules of DREQ are described as follows: (1) Service Requesting Module This module is used to describe DREQ’s requirements according to the service description model and the data description model, and request Web services that could provide needed exchange data on the SUDDI center. This module manages to realize data discovery by discovering Web services. (2) Service Invoking Module After discovering a Web service, service invoking module obtains the provider’s data schema, sets query condition for extracting needed exchange data, reads the WSDL file and invokes the chosen Web service. Then exchange data and its schema will be downloaded to local machine. This module manages to realize data getting and transferring by invoking Web services. (3) Schema Matching Module This module is used to match data schemas of DPRO’s and DREQ’s. Firstly, it extracts local data schema and transforms it to a XML Schema file, then matches the two schemas according to a schema matching algorithm. In this paper, a hybrid matching algorithm for XML Schemas introduced in [14] is adopted. Matching results are stored in a XSLT file. (4) Format Transforming Module

320


This module is used to transform the format of exchange data according to the schema matching result. So that data could be stored in local database or use it to participate in local applications. 3.4 SUDDI (Semantic Universal Description Discovery and Integration) Center Modules of SUDDI center are described as follows: (1) Preceding API Module This module consists of three kinds of APIs: x x x

Service Publishing API: These APIs accept description of published Web services functions as well as exchange data, and send them to the service matching module. Service Requesting API: These APIs accept description of requested Web services functions as well as demanded data, and send them to the service matching module. Result Displaying API: These APIs accept the Web services matching results from service matching module and display them on the preceding interface.

(2) Service Matching Module This module is used to match the published Web services and the requested service. Functions of this module are creating owl-s profile (namely service description) for Web services, parsing owl-s profile and domain ontology, and producing matching results according to the service matching mechanism introduced in Section 4. (3) UDDI Module This module founded on the UDDI 2.0 criterion is used to store WSDL file path and other common description of published Web services. It also produces mapping relations between owl-s profile base and UDDI module so that full information of a Web service could be published and requested. 3.5 Flow of Data Exchange Figure 2 illustrates the flow of data exchange in WSDE.


321

68'', &HQWHU '352 GHSOR\ :HE VHUYLFHV

'5(4 HE VK : SXEOL HU YLFHV V

PDWFK:HE VHUYLFHV

HE W: XHV V UHT HU YLFH V

U\ TXH X OW QJ UHV FKL PDW

VHW LQYRNLQJ FRQGLWLRQ

LQYRNH :HE VHUYLFHV ᧥WUDQVIHU H[FKDQJH GDWD DQG LWV VFKHPD PDWFK GDWD VFKHPDV WUDQVIHU GDWD IRUPDW VWRUH H[FKDQJH GDWD

Fig. 2. Flow of Data Exchange in WSDE

DPRO firstly deploys a Web service to local web server, publishes description of service function and exchange data on the SUDDI center and waits for the Web service being invoked. When DREQ needs data, it requests Web services and exchange data according to its own needs on the SUDDI center. The SUDDI center matches the requested service with all published services in the center, produces matching results according to the service matching mechanism, sorts the results and displays the match results. Then DREQ looks over these Web services for data exchange in the matching result list, chooses the most appropriate service, sets invoking condition for extracting needed exchange data, reads the WSDL file and invokes the chosen Web service. DPRO responses the invoking, executes the Web service and returns exchange data as well as its schema. After obtaining the exchange data and its schema, DREQ extracts local data schema, matches or maps the two data schemas and uses XSLT engine to transform data format according to the schema matching result. Finally, DREQ stores the exchange data that has been transformed in local database.

4 Web Services Matching Mechanism Precision of Web services discovery depends on the services matching mechanism. In the proposed data exchange method, data discovery is realized by Web services discovery, so the services matching mechanism adopted in WSDE determines precision of data discovery directly. Data discovery is the first and key step in the process of data exchange, whose result will affect the following steps. Therefore it is very important to choose an effective service matching mechanism for a data exchange method. The key task of Web services for data exchange, which have some differences with common Web services, is realizing data discovery. So services matching

322


between Web services for data exchange should cover not only IOPE that services matching between common Web services takes into account but also information of exchange data. As information of exchange data is so important to data discovery, the proposed method extends existing semantic matching mechanisms and presents a SWSM-DE (Semantic Web Services Matching mechanism for Data Exchange). SWSM-DE constructs both function description model and data description model, and integrates the result of function matching and data matching as final services matching result. Following will describe the SWSM-DE in detail. 4.1 Services Description Web services description is the base of services publishing, services discovery and services matching. SWSM-DE uses OWL-S which is published by W3C to describe semantic Web services to describe services. However, OWL-S profile only contains function items such as IOPE, so SWSM-DE extends the profile and adds description of exchange data to it. Definition 1. SDM (Service Description Model) is the semantic description of Web services function and exchange data in SWSM-DE, defined as SDM=. FM is function description model and DM is data description model. Definition 2. FM (Function Model) is the semantic description of name, text description, inputs and outputs of Web services, defined as FM᧹<Sn, Sd, Sin, Sout>. Sn is service name, Sd is text description of service, Sin is inputs of service and Sout is outputs of service. Definition 3. DM (Data Model) is the semantic description of domain, source, application scene and content of exchange data, defined as DM=. Dd is domain of exchange data, Ds is source of exchange data, As is application scene of exchange data and Dc is content of exchange data.Figure 3 shows the structure of SDM. 6'0 Service Description Model

)0 Function Model

Fig.3. Structure of SDM

'D

GDWD FRQWHQW

'V

DSSOLFDWLRQ VFHQH

'G

GDWD VRXUFH

6RXW

GDWD GRPDLQ

6LQ

VHUYLFH RXWSXWV

6G

VHUYLFH LQSXWV

WH[W GHVFULSWLRQ

VHUYLFH QDPH

6Q 6Q

'0 Data Model

'F


323

4.2 Matching Approach Different people or systems have different semantic description abilities, even to the same service or concept, so “completely same” for service matching is impossible and insignificant. We consider services matching is successful when the description of two services is “similar at a certain extent”. The key issue is how to judge “similar at a certain extent”. A matching mechanism introduced in [15] calculates the total similar degree of OWL-S service profile and other two parts of OWL-S profile which are OWL-S service model and OWL-S service grounding. The matching result is more precise, but more complex because it calculates similar degree of service model and service grounding additionally. A matching mechanism introduced in [16] matches services based on OWL-S service profile, and gets matching result by combining results of inputs matching, outputs matching, service category matching and user-defined matching. The mechanism is terser and easier to be realized, but the matching result is distinguished by only four ranks. So this mechanism is not flexible and the ability of distinguishing matching result is not perfect too. Besides, for data exchange Web services, the two mechanism are all lack of description and matching for exchange data. SWSM-DE which combines the merits of the above mechanisms describes services by OWL-S and measures similarity of Web services by a numerical value. Besides, it takes both service function and exchange data into account. SWSM-DE has two stages: the first stage is function matching and the second is data matching. Services that do not satisfy certain conditions will be filtered after each stage. The first stage calculates similarity of service function and set threshold value to filter useless services. Services that won’t be filtered in the first stage must be Web services for data exchange which have the ability of providing exchange data, and satisfy some conditions on inputs and outputs. The second stage calculates similarity of exchange data and set threshold value to filter services again. Services that will not be filtered in the second stage must satisfy some conditions on data domain, data source, application scene and data content. For each service that overpasses the two stages, SWSM-DE combines the similarity of services function and exchange data as final services matching result which is a numerical value. The two stages can use different matching algorithms. Figure 4 illustrates the matching process of SWSM-DE.

324


Fig. 4. Matching Process of SWSM-DE

According to SDM, the similarity of service Spro which represents the published Web service and service Sreq which represents requested Web service is defined as:

Sim( spro, sreq ) T 1 Simfunc ( Spro, Sreq ) T 2 Simdata ( Spro, Sreq ), T 1 T 2 1, 0 d T 1, T 2 d 1

(1)

Simfunc(Spro, Sreq) is the similarity of service function. Simdata(Spro, Sreq) is the similarity of exchange data. T1 is the weight value that function matching has in service matching. T2 is the weight value that data matching has. The two values can be adjusted according to actual situation. In SWSM-DE, they are initialized by 0.5 and 0.5 respectively. According to FM, the similarity of service function is defined as:

Sim ( S , S ) func

pro

req

O Sim ( S , S ) O Sim 1

name

O Sim 4

output

pro

req

2

description

( S , S ) O Sim ( S , S ) pro

( S , S ), O O O O pro

req

1

2

3

req

4

3

input

pro

req

1, 0 d O , O , O , O d 1 1

2

3

(2)

4

Simname(Spro, Sreq), Simdescription(Spro, Sreq), Siminput(Spro, Sreq) and Simoutput(Spro, Sreq) are the similarity of service name, service text description, service inputs and service outputs respectively. Simname(Spro, Sreq) and Simdescription(Spro, Sreq) can be calculated by MCMA (Multi-Concept Matching Algorithm) introduced in [14]. Siminput(Spro, Sreq) and Simoutput(Spro, Sreq) can be measured by MIMA (Multi-Input Matching Algorithm) and MOMA (Multi-Output Matching Algorithm) introduced in [10] respectively. O1, O2, O3 and O4 are the weight value of the above items in function matching, which can be adjusted according to actual situation. In SWSMDE, they are initialized by 0.25, 0.25, 0.25 and 0.25 respectively. According to DM, the similarity of exchange data is defined as:


Sim ( S , S ) data

pro

req

P Sim P Sim

( S , S ) P Sim ( S , S ) P Sim ( S , S ) ( S , S ), P P P P 1, 0 d P , P , P , P d 1

1

domain

4

content

pro

req

pro

req

2

1

source

2

pro

3

req

3

4

scene

1

2

pro

req

3

4

325

(3)

Simdomain(Spro, Sreq), Simsource(Spro, Sreq), Simscene(Spro, Sreq) and Simcontent(Spro, Sreq) are the similarity of data domain, data source, application scene and data content respectively, which can be measured by MCMA. P1, P2, P3, and P4 are the weight value of the above items in data matching, which can be adjusted according to actual situation. In SWSM-DE, they are initialized by 0.15, 0.15, 0.15 and 0.55 respectively. Let Cfunc represent the threshold value in the first stage and Cdata represent the threshold value in the second stage. According to the matching process of SWSMDE, if Simfunc(Spro, Sreq)=Cfunc, the second stage would be executed and Simdata(Spro, Sreq) would be calculated. In the same way, if Simdata(Spro, Sreq)=Cdata, the final matching result Sim(Spro, Sreq) would be calculated by formula (1). Namely, the more exact formula for calculating Sim(Spro, Sreq) is:

Sim( s , s ) pro

req

0, Sim ( S , S )< Cfunc or Sim ( S , S )< Cdata ® ¯(1) , Sim ( S , S ) t Cfunc and Sim ( S , S ) t Cdata func

func

pro

pro

req

req

data

data

pro

pro

req

(4)

req

5 Prototype System The prototype system which is developed by Borland JBuilder 9.0 uses three computers to simulate DPRO, DRQE and SUDDI respectively. DRPO which runs on Windows NT system uses SQL Server 2000 database and Tomcat 4.1 as local web server. DREQ which runs on Windows 2000 system uses Microsoft Access 2000 database. SUDDI which runs on Windows XP system uses OWL-S API to create and parse OWL-S profile, juddi0_9RC4 to realize UDDI 2.0 APIs, mysql 5.0 as database for registering, tomcat 5.0 as web server and JSP pages as user interfaces. The initial weight values in formula (1)(2)(3) are adopted. System is based on the following application scene: A machine factory in Beijing needs a special type of axletrees, while there are enterprises which can manufacture the very type in New York, London, Sydney, and Tokyo. However, the machine factory in Beijing doesn’t know which enterprises can manufacture them and doesn’t know how to inquire about them. If WSDE is adopted, a SUDDI center should be constructed: x

Enterprises that manufacture axletrees act as DPRO. They provide information of axletrees by Web services and publish the services information on the SUDDI center (Figure 5(a)).

326


x x x

The factory in Beijing which acts as DREQ requests Web services based on his requirements on services function and exchange data from the SUDDI center. The SUDDI center executes services matching and returns list of information of enterprises that can manufacture the very type of axletrees (Figure 5(b)). The factory in Beijing chooses a proper item associating with certain enterprise, invokes the Web services that the enterprise has deployed remotely and gets product information namely exchange data to local. Then data schema matching and format transforming will be executed. Finally, the exchange data after being transformed can be stored in local database or participate in application.

a

b

Fig. 5. a. Interface of publishing Web services; b. Interface of displaying matching results.

6 Conclusions In this paper, a semantic Web services based data exchange method is proposed, which can realize the whole process of data exchange on Internet. In the proposed method, data publishing, data discovery and data getting are realized by publishing Web services, discovering Web services and invoking Web services respectively. Data schema matching and format transforming are realized by XML technology. In order to improve the precision of data discovery, a Web services matching mechanism of semantic level for data exchange is presented, which takes both service function and exchange data into account and calculates the semantic similarity of published and requested Web services based on OWL-S. Compared to the existing data exchange methods, the proposed method can complete the whole process of data exchange, realize easy data discovery and provide or obtain exchange data dynamically on Internet. The prototype system takes an industry use case for example by which the presented framework and mechanism are verified. Also, the proposed data exchange method can be applied to various applications.


327

References [1]

[2]

[3] [4] [5]

[6] [7] [8] [9] [10] [11]

[12] [13]

[14] [15]

[16] [17]

ISO/TC184/SC5/WG4, (2002) ISO16100-1 Industrial automation systems and integration - Manufacturing software capability profiling for interoperability — Part 1: Framework ISO/TC184/SC5/WG4, (2005) ISO16100-3 Industrial automation systems and integration - manufacturing capability profiling for interoperability - Part 3: Interface services, Protocol and capability templates Fagin1 R, Kolaitis PG, Popa L, (2005) Data Exchange: Getting to the Core. ACM Transactions on Database Systems, 174–210 Meadors K, (2005) Secure Electronic Data Interchange over the Internet. Internet Computing, IEEE, 82–89 Wang N, Chen Y, Yu BQ, Wang NB, (1997) Versatile: A scaleable CORBA 2based system for integrating distributed data. In Proceedings of the 1997 IEEE International Conference on Intelligent Processing Systems, 1589–1593 Pendyala VS, Shim SSY, Gao JZ, (2003) An Xml Based Framework for Enterprise Application Integration. In IEEE International Conference on E-commerce, 128–135 Zhang M, Xu QS, Shen XC, (2006) Data exchange and sharing platform model based on XML. Journal of Tsinghua University (Science and Technology), 105–107, 119 ROSETTANET, (2007-10) About RosettaNet Standards. http://portal.rosettanet.org/ cms/site/RosettaNet/ EbXML Technical Architecture Project Team, (2001) EbXML Technical Architecture Specification v1.0.4. http://www.ebxml.org/specs/ebTA.pdf, 1-39. Hu JQ, Zou P, Wang HM, Zhou B, (2005) Research on Web Service Description Language QWSDL and Service Matching Model. Chinese Journal of Computers, 505–513 Gao S, Omer FR, Nick JA, Chen DF, (2007) Ontology-based semantic matchmaking approach. Advances in Engineering Software, 59–67 Paolucci M, Kawamura T, Payne TR, Sycara K, (2002) Semantic matching of web service capabilities. In Proceedings of 1st International Semantic Web Conference, Springer-Verlag, 333–347 Cui Y, (2005) Research on Service Matchmaking Model Based on Semantic Web. Master Dissertation, Dalian University of Technology, China Kajal TC, Vaishali H, Naiyana T, (2005) QMatch - A Hybrid Match Algorithm for XML Schemas. In Proceedings of the 21st International Conference on Data Engineering. IEEE Computer Society, 1281–1290 Hau J, Lee W, Darlington J, (2005) A Semantic Similarity Measure for Semantic Web Services. http:// www.ai.sri.com/WSS2005/final-versions/WSS2005-Hau-Final.pdf Jaeger MC, Rojec-GoldMann G, Liebetruth C, Muhl G, Geihs K, (2005) Ranked Matching for Service Descriptions using OWL-S. In: Proceedings of Communication in Distributed System, 91–102

Ontology-driven Semantic Mapping Domenico Beneventano1, Nikolai Dahlem2, Sabina El Haoum2, Axel Hahn2, Daniele Montanari1,3, Matthias Reinelt2 1

2

3

University of Modena and Reggio Emilia, Italy {domenico.beneventano, daniele.montanari}@unimore.it University of Oldenburg, Germany {dahlem, elhaoum, hahn, reinelt}@wi-ol.de Eni SpA, Italy [email protected]

Abstract. When facilitating interoperability at the data level one faces the problem that different data models are used as the basis for business formats. For example relational databases are based on the relational model, while XML Schema is basically a hierarchical model (with some extensions, like references). Our goal is to provide a syntax and a data model neutral format for the representation of business schemata. We have developed a unified description of data models which is called the Logical Data Model (LDM) Ontology. It is a superset of the relational, hierarchical, network, objectoriented data models, which is represented as a graph consisting of nodes with labeled edges. For the representation of different relationships between the nodes in the data-model we introduced different types of edges. For example: is_a for the representation of the subclass relationship, identifies for the representation of unique key values, contains for the containment relationship, etc. In this paper we discuss the mapping process as it is proposed by EU project STASIS (FP6-2005-IST-5-034980). Then we describe the Logical DataModel in detail and demonstrate its use by giving an example. Finally we discuss future research planned in this context in the STASIS project. Keywords: business schema representation, business interoperability, metamodel

1 Introduction Today’s enterprises, no matter how big or small, have to meet the challenge of bringing together disparate systems and making their mission-critical applications collaborate seamlessly. One of the most difficult problems in any integration effort is the missing interoperability at the data level. Frequently, the same concepts are embedded in different data models and represented differently. One difficulty is identifying and

330

D. Beneventano, N. Dahlem, S. El Haoum, A. Hahn, D. Montanari, M. Reinelt

mapping differences in naming conventions, whilst coping with the problems of polysemy (the existence of several meanings for a single word or phrase) and synonymy (the equivalence of meaning). A connected problem is identifying and mapping differences stemming from the use of different data models. For example information expressed in a relational schema is based on the relational data model, while XML Schema is basically a hierarchical model (with some extensions, like references). Therefore we propose an ontology to describe a unified data model which is called the Logical Data Model. The purpose of the Logical Data Model ontology is to provide a common representation able to encapsulate substantial information coming from different sources and various schema formats. Data models represented by such an ontology can be considered as a neutral specification which allows a common processing in an interoperability framework. In the remainder we first discuss the related work (section 2). Then we describe the mapping process to provide the context for this work in section 3. Section 4 presents the Logical Data Model Ontology and gives an example. Section 5 discusses ontology-driven semantic mapping and section 6 concludes with a discussion and an outlook to the future research.

2 Related Work The integration costs for enterprise applications cooperation are still extremely high, because of different business processes, data organization, application interfaces that need to be reconciled, typically with great manual (and therefore error prone) intervention. This problem has been addressed independently by MDA and ontology-based approaches. The Model Driven Architecture (MDA) proposed by the Object Management Group (OMG) uses platform-independent models (PIMs) [1] as the context for identifying relations between different applications. Transformation is a central concept in MDA to address how to convert one model into another model of the same system, and further into executable code. MDA provides technologies to handle meta models, constraints etc. which can be used for semantic enrichment and model transformation. In model-based approach, Unified Modelling Language [2] is used to express conceptual models. The meta language Meta Object Facility (MOF) is defined as part of the solution in order to capture relationships between data elements. Transformation languages are used to create executable rules, and transformation techniques can be used in the process of detailing the information needed, converting from abstract MOF compliant languages to more formal ones [3]. Today, ontology technologies have reached a good level of maturity and their applications to industrial relevant problems are proliferating. Ontologies are the key elements of the Semantic Web. The notion of the Semantic Web is led by W3C and defined to be a “common framework allowing data to be shared and reused across application, enterprise and community boundaries” [4]. Ontologies support semantic mapping by providing explicitly defined meaning of the information to be exchanged. The development of the LDM Ontology was

Ontology-driven Semantic Mapping

331

particularly inspired by related work on relational schema modeling and the general goal of establishing mappings among (fragments of) domain ontologies. The latter has been an active field of research in the last ten years, exploring a number of approaches. The basic expression of mapping for ontologies modeled with description logic formalisms and the associated languages (like OWL) involves the use of basic language constructs or evolved frameworks to express the existence and properties of similarities and then mappings [5] [6] [7]. One significant result in this area is the MAFRA framework [8]. Research in the area of database schema integration has been carried out since the beginning of the 1980s, and schema comparison techniques are often well suited for translation into mapping techniques. A survey of such techniques is offered in [9]. One system extensively using these techniques is MOMIS (Mediator Environment for Multiple Information Sources); MOMIS creates a global virtual view of information sources, independent of their location and heterogeneity [10]. The discovery of mappings has been studied by means of general methods often derived from other fields. One such approach is graph comparison, which comprises a class of techniques which represent the source and target ontologies (or schemas) as graph, and try to exploit graph structure properties to establish correspondences. Similarity flooding [11] and AnchorPrompt [12] are examples of such approaches. Machine learning techniques have also been used. One such example is GLUE [13], where multiple learners look for correspondences among the taxonomies of two given ontologies, based on the joint probability distribution of the concepts involved and a probabilistic model for combination of results by different learners. Another example is OMEN (Ontology Mapping Enhancer) [14] which is a probabilistic mapping tool using a bayesian net to enhance the quality of the mappings. Linguistic analysis is also quite relevant, as linguistic approaches exploit the names of the concepts and other natural language features to derive information about potential mates for a mapping definition. For example, in [15] a weighted combination of similarities of features in OWL concept definitions is used to define a metric between concepts. Other studies in this area include ONION [16] and Prompt [17], which use a combination of interactive specifications and heuristics to propose potential mappings. Similarly, [18] use a bayesian approach to find mappings between classes based on text documents classified as exemplars of these classes. In Athena (ST-507849), a large European IST project, two different technologies have been applied to support model mapping. Semantic mapping involves the application of an ontology. However, current literature does not provide detailed description regarding how this is to be done, as pointed out by [19] and [20]. In Athena, a solution has been proposed, based on semantic annotation (A* tool), reconciliation rules generation (Argos tool), and a reconciliation execution engine (Ares). Parallel, in Athena, also a model-based approach has been proposed, based on a graphic tool (Semaphore) aimed at supporting the user in specifying the mappings and XSLT based transformation rules.

332


Other European projects addressing mapping issues include the IST FP6 projects SWAP (IST-2001-34103) [21], SEKT (IST-2003-506826) [22], and DotKom (IST-2001-34038) [23].

3 Mapping of Business Schemata When analyzing semantic relations between business schemata, we follow the approach of A* [24] to obtain a neutral representation of the schemata first. In a subsequent step this neutral representation is processed to identify mappings. These steps are discussed in the following two sections. 3.1 Obtaining a Neutral Schema Representation

The proposed mapping process works on a neutral representation, which abstracts from the specific syntax and data model of a particular business schema definition. Therefore, all incoming business schemata first need to be expressed in this neutral format. Fig. 1 shows the steps of this acquisition process.

Fig. 1. Schema acquisition process

Firstly, the incoming schema is expressed in terms of a corresponding structural ontology. Several parseable and non-parseable schema formats are already analyzed and supported namely relational databases, XML schema, EDIFACT-like EDI environments, FlatFile representations. For each of these formats a specific structural ontology is defined [25]. Then, in a second step, the model specific structural ontology representation is transformed into a neutral representation which is based on the Logical Data Model. This transformation can be automated by applying a set of predefined rules.


333

3.2 Identification of Mappings

Once the schema information has been acquired and expressed in the unified model, further analysis and/or processing can be performed to identify a set of mappings between semantic entities being used in different business schemata. The goal is to provide such sets of mappings as input to translator tools to achieve interoperability between dispersed systems without modifying the involved schemata. The definition of the mappings is done through the acquisition of the crucial features in the schemata of the source and target, giving them a conceptual representation, enriching this representation with semantic annotations and then using the system functionalities to synthesize and refine the mappings. An overview of this process is given in Fig. 2.

Fig. 2. Mapping process

As shown in Fig. 2 the neutral representation of incoming schemata provides the basis for the identification of the relevant semantic entities being the basis of the mapping process. This step is labeled “extraction” and the resulting semantic entities are the a-box of the LDM Ontology. Apart from the element being identified as semantic entity, a semantic entity holds metadata such as annotations, example values, keywords, owner and access information, etc. The analysis of the information encapsulated in semantic entities can support the finding of mapping candidates. A more advanced way to identify mappings between semantic entities is to derive them through reasoning on aligned ontologies. For this purpose the semantic entities need to be annotated with respect to some ontology as proposed in A*. Based on the annotation made with respect to the ontologies and on the logic relations identified between these ontologies, reasoning can identify correspondences on the semantic entity level and support the mapping process. Beyond the capability of A* this reasoning can also benefit from the conceptual information derived from the LDM Ontology because all semantic entities carry this extra information by being instances of the concepts of the LDM Ontology.

334


4 Logical Data Model Ontology This section contains a general description of the Logical Data Model Ontology followed by an example to demonstrate its main characteristics. 4.1 General Description of the Model

The LDM Ontology contains generic concepts abstracting from syntactical aspects and different data models. As an intuitive example, in the relational model a foreign key expresses a reference between two tables; at a more abstract level we can consider the two tables as nodes of a graph and the foreign key as an edge from one table to another table; more precisely this is a directed (since a foreign key has a “direction”) and labeled (since we want to distinguish two foreign keys between the same pair of tables) edge. In this way, the LDM Ontology corresponds to a graph with directed labeled edges and it has the following types of concepts: 1.

The Nodes of the graph, which are partitioned in SimpleNodes and ComplexNodes. 2. The edges of the graph, which represent Relationships between Nodes. The following types of Relationships can exists: -

Reference: A Reference is a directed labeled edge between ComplexNodes. Identification: A ComplexNode can be identified by a SimpleNode or a set of SimpleNodes. Containment: A ComplexNode can contain other Nodes, SimpleNodes and/or ComplexNodes. Qualification: A Node can be qualified by a SimpleNode. Inheritance: Inheritance can exist between ComplexNodes.

The LDM Ontology has been represented as an OWL ontology. An overview of the concepts and their relations in the ontology is shown in Fig. 3. A detailed description of the LDM Ontology is provided by [25]

Fig. 3. Overview of the concepts in the LDM Ontology


335

4.2 Demonstration example

In this section an example is introduced to show how a relational data base schema is first represented in terms of a structural ontology and then transformed into a LDM Ontology representation by means of respective transformation rules. For the relational case the structural ontology has to provide concepts for the terms Database, Relation and Attribute and a property consistsOf to create a hierarchy involving them. For this purpose the structural ontology contains the concepts of Catalogue, Table and Column and the object property hasColumn. Consider the relational schema in Fig. 4. Expressed in terms of the structural ontology for the relational case (hereafter shortly referred as relational structural schema) there are two Tables: Table “Order” and Table “OrderLine” with their Columns “number”, “date”, “customerID” and “articleNumber”, “quantity”, “lineNumber”, “orderNumber” respectively. Additionally, the Column “number” is declared a PrimaryKey of the “Order” Table and the Column “lineNumber” the PrimaryKey of the Table “OrderLine”. Further, the “OrderLine” is connected to one specific “Order” using a ForeignKey reference “FK_OrderLine_Order”.

Fig. 4. Part of an exemplary relational data base schema

The next step to achieve an LDM Ontology representation is to apply transformation rules to the structural ontology representation. A brief overview of the transformation rules is presented in Table 1. Due to space limitation the table only gives an intuition of the rules; their detailed explanation is given in [25]. In general, in the LDM Ontology all Tables will be represented as ComplexNodes, Columns as SimpleNodes, and so on. Table 1. Transformation rules from the relational structural ontology into a LDM Ontology representation Entity in the relational Entity in the Comments structural ontology Logical Data Model Table ComplexNode All Tables are represented as ComplexNodes Column SimpleNode All Columns are represented as SimpleNodes KeyConstraint Identification All KeyConstraints (i.e. PrimaryKeys and AlternativeKeys) are represented as Identifications ForeignKey Reference All ForeignKeys are represented as References hasColumns Containment The relationship between a Table and its Columns is represented as a Containment relationship

336


The application of the transformation rules leads to an LDM Ontology based representation of the example as shown in Fig. 5. The notation used in this figure is described by [25].

Fig. 5. LDM Ontology representation of the exemplary schema

According to the graphical representation in Fig. 5 the example schema contains two ComplexNodes “Order” and “OrderLine”. For each Column a SimpleNode is introduced and connected with its Table/ComplexNode via the Containment relation. Identification relations are defined for the PrimaryKeys “number” and “lineNumber”. The ForeignKey “FK_OrderLine_Order” is transformed to a Reference “belongsTo”.

5 Ontology-driven Semantic Mapping As discussed in the section 3 mappings between Semantic Entities can be achieved based on annotations linking the semantic entities with some concepts being part of an ontology. The annotation of semantic entities with respect to external ontology means that additional machine processable knowledge is associated with them. As in A* the ontology-driven process of deriving correspondences between semantic entities belonging to different schemata will make use of this additional knowledge. Our approach also benefits from structural knowledge on the data model represented by linking the semantic entities to the concepts of the LDM Ontology. When the annotation of semantic entities belonging to different schemata is based on one common ontology and the LDM Ontology (see Fig. 6), the annotations can directly facilitate the discovery of semantic relations between the semantic entities. The definition of semantic link specification (SLS) is based on [26]. The following semantic relations between semantic entities of two business formats are defined: equivalence (EQUIV); more general (SUP); less general (SUB); disjointness (DISJ). As in [26], when none of the relations holds, the special IDK (I do not know) relation is returned; Notice IDK is an explicit statement that the system is unable to compute any of the declared (four) relations. This should be interpreted as either there is not enough background knowledge, and therefore, the system cannot


337

explicitly compute any of the declared relations or, indeed, none of those relations hold according to an application. The semantics of the above relations are the obvious set-theoretic semantics.

Fig. 6. Ontology-based schema mapping with a single common ontology

More formally, an SLS is a 4-tuple where ID is a unique identifier of the given mapping element; semantic_entity1 is an entity of the first format; R specifies the semantic relation which may hold between semantic_entity1 and semantic_entity2; semantic_entity2 is an entity of the second format. Our discussion is based on examples. To this end we consider the following two business formats: The graphical representation of semantic_entity1 from a business format 1 (bf1) shown in Fig. 7 and semantic_entity2 from another business format 2 (bf2) shown in Fig. 8. We consider the annotation of the above business format with respect to the Purchase_order Ontology (see Fig. 9).

Fig. 7. Business format specification (bf1) (derived from relational schema)

338


Fig. 8. Business format specification (bf2) (derived from an XML schema)

Fig. 9. The ontology of Purchase_order

The proposed “Ontology-based schema mapping with a single common ontology” is based on the annotation of a business format with respect to this single common ontology. Here we will use the following proposal. An annotation element is a 4-tuple where ID is a unique identifier of the given annotation element; SE is a semantic entity of the business format; concept is a concept of the ontology; R specifies the semantic relation which may hold between SE and concept. The proposal is to use the following semantic relations between semantic entities of the business format and the concepts of the ontology: equivalence (AR_EQUIV); more general (AR_SUP); less general (AR_SUB); disjointness (AR_DISJ). Let us give some examples of annotation. In the examples, the unique identifier ID is omitted. x

(bf2:Address, AR_EQUIV,O:Address) may be considered as the output of automatic annotation


x x

339

(bf2:Address, AR_SUB,O:Address) may be considered as the output of a ranked automatic annotation/search: the AR_SUB relation instead of AR_EQUIV is used since the rank is less than a given threshold (bf2:Address, AR_EQUIV, O:Address and Billing-1.Purchase_Order) may be considered as a refinement by the user of (bf2:Address, AR_EQUIV,O:Address) to state that the address in the BF is exactly the “address of the Billing in a Purchase_Order”

Let us also consider the following possible annotations of bf1 x x x x x

(bf1:Address, AR_EQUIV,O:Address) (bf1:Address, AR_SUB,O:Address) (bf1:Address, AR_EQUIV, O:Address and Shipping-1.Purchase_Order) (bf1:Address, AR_EQUIV, O:Address and Shipping-1.Purchase_Order) (bf1:Address, AR_DISJ, O:Address and Billing-1.Purchase_Order)

Now, some example of the SLS derived from annotation will be discussed. To this end, let us suppose that in the bf2 there is the following annotation for address (bf2:Address, AR_EQUIV,O:Address). We want to discuss what is the SLS derived between bf2:Address and bf1:Address, by considering the following cases for the Address annotation in bf1 Case 1) (bf1:Address, AR_EQUIV,O:Address) The following SLS can be derived (bf1:Address, EQUIV, bf2:Address) Case 2) (bf1:Address, AR_SUB,O:Address) and The following SLS can be derived (bf1:Address, SUB, bf2:Address) Case 3) (bf1:Address, AR_EQUIV, O:Address and InverseOf(Shipping).Purchase_Order) The following SLS can be derived (bf1:Address, SUB, bf2:Address) since Address and InverseOf(Shipping).Purchase_Order (the annotation of bf1:Address) is subsumed by Address (the annotation of bf2:Address). This shows how the semantic mapping can be derived from the semantic entity specification. The information of the linkage to the LDM Ontology is used in the same way. One topic is still open. A possible extension [to be evaluated] w.r.t. the [26] framework is the addition of the overlapping (OVERLAP) semantic relation. Formally, we need to evaluate if with OVERLAP we can decide IDK relations; moreover we need to proof that with OVERLAP “relations are ordered according to decreasing binding strength”

6 Discussion and Future Research We provide a joint approach to integrate the benefits of the MOF and ontology based semantic mapping methods. Model entities of business formats/standards are described by a generic meta model which is made explicit by an ontology, called the Logical Data Model Ontology. By annotating these semantic entities w.r.t. business ontologies an enriched knowledge base is available to reason on semantic links to align the entities of business formats. These technologies are going to be integrated in an interoperability framework to share the semantic information in

340


peer groups to enrich the semantic basis for cooperation. This enhances the common ontology to provide an even better basis for the mapping process. This is accompanied by further approaches to simplify the definition of ontologies, their linkage to semantic entities (annotation) and verification of the jointly generated semantic net.

Acknowledgments The STASIS IST project (FP6-2005-IST-5-034980) is sponsored under the EC 6th Framework Programme.

References [1] [2] [3]

[4] [5]

[6]

[7] [8]

[9] [10] [11]

[12]

[13]

[14]

Kleppe, A., Warmer, J., Bast, W.: MDA Explained: The Model Driven Architecture-Practice and Promise. Addison-Wesley, Boston (2003) Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling Language Reference Manual. Second Edition, Addison-Wesley, Boston (2005) Karagiannis, D., Kühn. H.: Metamodelling Plattforms. In Bauknecht K., Min Tjoa, A., Quirchmayr, G. (eds.): Thirst Int. Conference EC-Web 2002, p. 182. Springer, Berlin (2002) W3C Semantic Web Activity, http://www.w3.org/2001/sw/ last accessed 2007-10-24 Ehrig, M., Haase, P., Hefke, M., and Stojanovic, N.: Similarity for Ontologies – a Comprehensive Framework. In Workshop Enterprise Modelling and Ontology: Ingredients for Interoperability, PAKM 2004 (2004) Weinstein, P., Birmingham, W.P.: Comparing Concepts in Differentiated Ontologies. In 12th Workshop on Knowledge Acquisition, Modelling, and Management (KAW99), Banff, Alberta, Canada (1999). Choi, N., Song, I-Y., Han, H.: A Survey of Ontology Mapping. In SIGMOD Record 35, Nr. 3 (2006) Mädche, A., Motik, B., Silva, N., Volz, R: MAFRA - A Mapping Framework for Distributed Ontologies. In 13th Int. Conf. on Knowledge Engineering and Knowledge Management, vol. 2473 in LNCS, pp. 235--250 (2002) Rahm, E., Bernstein, P.: Survey of Approaches to Automatic Schema Matching. VLDB Journal 10 (2001) Beneventano, D., Bergamaschi, S., Guerra, F., Vincini, M.: Synthesizing an Integrated Ontology, IEEE Internet Computing, September-October (2003) Melnik, S., Garcia-Molina, H., Rahm, E.: Similarity Flooding: A Versatile Graph Matching Algorithm and its Applications to Schema Matching. In 18th International Conference on Data Engineering (ICDE-2002), San Jose, California, (2002) Noy, N.F., and Musen, M.A.: Anchor-PROMPT: Using non-local context for semantic matching. In Workshop on Ontologies and Information Sharing at the 17th International Joint Conference on Artificial Intelligence (IJCAI-2001), Seattle, WA, US (2001) Doan, A., Madhavan, J., Domingos, P., Halevy, A.: Learning to map between ontologies on the semantic web. In The 11th Int. WWW Conference, Hawaii, USA (2002) Mitra, P., Noy, N.F., Jawal, A.R.: OMEN: A Probabilistic Ontology Mapping Tool. LNCS, Vol. 3729/2005, Springer, Berlin (2005)


341

[15] Euzenat, J., Valtchev, P.: Similarity-based ontology alignment in OWL-Lite. In The 16th European Conference on Artificial Intelligence (ECAI-04), Valencia, Spain (2004) [16] Mitra, P., Wiederhold, G., Decker, S.: A scalable framework for interoperation of information sources. In SWWS01, Stanford University, Stanford, CA, US (2001) [17] Noy, N.F., Musen, M.A.: The PROMPT suite: Interactive tools for ontology merging and mapping. International Journal of Human-Computer Studies, 59, pp. 983--1024 (2003) [18] Prasad, S., Peng, Y., Finin, T.: A tool for mapping between two ontologies using explicit information. In AAMAS 2002 Ws on Ontologies and Agent Systems, Bologna, Italy (2002) [19] Wache, H, Vögele T., Visser, U., Stuckenschmidt, H., Schuster, G., Neumann H., Hübner, S.: Ontology-Based Integration of Information - A Survey of Existing Approaches. In: IJCAI-01 Workshop Ontologies and Information Sharing (IJCAI01), pp. 108-118 (2001) [20] Gómez-Pérez, A., Fernández-López M, Corcho, 0.: Ontological Engineering with examples from the areas of Knowledge Management, e-Commerce and the Semantic Web. Springer (2004) [21] SWAP Project Web Site, http://swap.semanticweb.org/ last accessed 2007-10-24 [22] SEKT Project Web Site, http://www.sekt-project.com/ last accessed 2007-10-24 [23] DotKom Project Web Site, http://nlp.shef.ac.uk/dot.kom/ last accessed 2007-10-24 [24] Callegari, G. Missikoff, M., Osimi, N., Taglino F.: Semantic Annotation language and tool for Information and Business Processes Appendix F: User Manual, ATHENA Project Deliverable D.A3.3 (2006) available at http://lekspub.iasi.cnr.it/Astar/AstarUserManual1.0 last accessed 2007-10-24 [25] STASIS Project Web Site, http://www.stasis-project.net/ last accessed 2007-10-24 [26] Giunchiglia, F., Yatskevich, M., Shvaiko. P.: Semantic Matching: Algorithms and Implementation. Journal on Data Semantics (JoDS), IX, LNCS 4601, pp. 1-38 (2007)

Self-Organising Service Networks for Semantic Interoperability Support in Virtual Enterprises Alexander Smirnov, Mikhail Pashkin, Nikolay Shilov, Tatiana Levashova St.Petersburg Institute for Informatics and Automation of the Russian Academy of Sciences, 39, 14 Line, 199178 St.Petersburg, Russia {smir, michael, nick, oleg}@iias.spb.su

Abstract. Virtual enterprises consist of a number of independent distributed members, which have to collaborate in order to succeed. The paper proposes an approach to creation of self-organising service networks to support semantic interoperability between virtual enterprise members. Since the centralized control is not always possible, presented approach proposes decentralized communication and ad-hoc decision making based on the current situation state and its possible future development. The presented approach proposes usage of self-organising networks of knowledge sources and problem solvers. The paper is devoted to questions of semantic interoperability in such kind of agent-based service networks. Ontologies are used for description of knowledge domains. Application of objectoriented constraint networks is proposed for ontology modelling. The approach uses such technologies as knowledge and ontology management, profiling, intelligent agents, Webservices, etc. Keywords: Self-organisation, semantic interoperability, agent, service, ontology, context

1 Introduction Nowadays, complex decision making faces problems of management and sharing of huge amount of information & knowledge from distributed and heterogeneous sources (experts, electronic documents, real-time sensors, etc.) belonging to virtual enterprise members, personalization, availability of up-to-date and accurate information provided by the dynamic environment. The problems include search of right sources, extraction of content, presentation of results in a personalized way, and other. As a rule, the content of several sources has to be extracted and processed (e.g., fused, converted, checked) to produce required information. Due to such factors as different data formats, interaction protocols and others this leads to a problem of semantic interoperability.

344

Alexander Smirnov, Mikhail Pashkin, Nikolay Shilov, Tatiana Levashova

Ontologies are widely used for problem domain description in the modern information systems to support semantic interoperability. An ontology is an explicit specification of a structure of a certain domain. It includes a vocabulary for referring to notions of the subject area, and a set of logical statements expressing the constraints existing in the domain and restricting the interpretation of the vocabulary [1]. Ontologies support integration of resources that were developed using different vocabularies and different perspectives of the data. To achieve semantic interoperability, systems must be able to exchange data so that the precise meaning of the data is readily accessible and the data itself can be translated by any system into the form that it understands [2]. Centralized control in complex distributed systems is not always possible: for example, virtual enterprises consist of independent companies and do not have a central decision making unit. Thus, decentralized self-organisation of distributed independent components is a promising architecture for such kind of systems [3], [4], [5]. However, in order for the self-organisation to operate it is necessary to solve a number of problems including: (i) registration and cancelling of registration of network elements, (ii) preparation of initial state, (iii) self-configuration: finding appropriate network elements [6], negotiation of conditions and assignment of links, and preparation of alternative configurations. Different research projects are devoted to self-management of such networks: self -contextualization, -optimization, -organization, -configuration, -adaptation, -healing, -protection [7]. The following major requirements to the approach to virtual enterprise interoperability support have been selected (some of the decision making processes in virtual enterprises have been identified in [8]): (i) intensive information exchange, (ii) distributed architecture, (iii) decentralised control, (iv) semanticbased information processing, (v) ad-hoc decision making support based on the current situation state and its possible future development. Self-configuration of heterogeneous sources providing knowledge and tools for this knowledge processing is a basic idea of the presented approach. The developed methodology proposes integration of environmental information in a certain context. The context is any information that can be used to characterize the situation of an entity where an entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves [9]. The context is purposed to represent only relevant information from the large amount of those. Relevance of information is evaluated on a basis how they are related to a modelling of an ad-hoc problem. A number of already solved problems and problems to be solved includes interoperability at both technological and semantic level, situation understanding by the members via information exchange, protocols of ad-hoc decision making for self-organization. Proposed technological framework incorporates such technologies as situation management, knowledge and ontology management, profiling, Web-services, decision support, negotiation protocols. The proposed methodology is based on the earlier developed concept of knowledge logistics [10] and includes such technologies as situation management, ontology management, profiling and intelligent agents [8]. Standards of information exchange (e.g., Web-service standards), negotiation protocols, decision making rules, etc. are used for information exchange and rapid

Self-Organising Service Networks for Semantic Interoperability Support

345

establishing of ad-hoc partnerships and agreements between the operation members. In the second section of the paper the developed methodology is presented. The technological framework is described in the third section. Some results are summarised in the Conclusion.

2 Proposed Approach The main idea of the approach is to represent virtual enterprise members by sets of services provided by them Fig. 1. This makes it possible to replace the interoperability between virtual enterprise members with that between their services.

Fig. 1. Representation of virtual enterprise members by sets of services.

At the first stage of the research the lifecycle phases of the self-configuring network and major requirements to them were defined (Table 1). Based on these requirements the main ideas the approach is based on were formulated: 1.

A common shared top-level ontology (application ontology) serves for terminology unification. Each service has a fragment of this ontology corresponding to its capabilities / responsibilities. This fragment is synchronized automatically when necessary (not during the operation). 2. Each service has a profile describing its capabilities, appropriate ontological model. 3. Each service is assigned an intelligent agent, representing it (together they will be called “agent-based service”). The agent collects information required for situational understanding by the service, negotiates with other agents to create ad-hoc action plans. The agent has predefined rules to be followed during negotiation processes. These rules depend on the role of the appropriate member.

346


4.

Web-service standards are used for interactions. External sources (e.g., medical databases, transport availability, weather forecasts) should also support these standards and the terminology defined by the application ontology. This is achieved by developing services for each particular source.

Table 1. Lifecycle phases for the self-configuring network, its needs and services to fulfil them Life cycle phase Community building (once, new members are added on a continuous basis)

Needs Common infrastructure

Services Modelling goals and objectives

Common communication standards and protocols

Identification, qualification, registration of members Common knowledge representation Common modelling for community members

Formation (continuous, initiated by the situation, or a task as a part of the situation) Operation (continuous)

Task definition model (context)

Task modelling Rules of partner selection

Partner selection Coordination and synchronization

Rules of re-negotiation and solution modification if necessary

Discontinuation Termination of the established Update of (continuous, initiated by agreements solution members)

the

current

The developed methodology proposes a two-level framework of context-driven information integration for decision making. The first level addresses activities over a pre-starting procedure of the system as creation of semantic models for its components (Fig. 2); accumulating domain knowledge; linking domain knowledge with the information sources; creation of an application ontology describing a macro-situation; indexing a set of available e-documents against the application ontology. This level is supported, if required, by the subject experts, knowledge and ontology engineers. The second level focuses on decision making supported by the system. This level addresses a problem recognition presented by a user request; context creation; identification of relevant knowledge sources; generation of a set of problem solutions; and making a decision by the user.


System Components

347

Model Domain ontology

Tasks&methods ontology

Domain knowledge Application ontology User (decision maker)

User profile

Environment

Information source models Formalism of OOCN

Fig. 2. Models for system components.

The internal knowledge representation is supported by the formalism of objectoriented constraint networks (OOCN) [11]. All the system components and contexts are represented by means of this formalism. According to the formalism, the application ontology is represented as sets of classes, class attributes, attribute domains, and constraints. The set of constrains comprises constraints describing “class, attribute, domain” relation; constraints representing structural relations as hierarchical relationships “part-of” and “is-a”, classes compatibility, associative relationships, class cardinality restrictions; and constraints describing functional dependencies. Below examples of some constraints are given: x x x x x x

“class, attribute, domain” relation: the attribute costs belongs to the class component and takes positive values; hierarchical relationship “is-a”: the body production facility is a resource; hierarchical relationships “part-of”: an instance of the class component can be a part of an instance of the class product; associative relationship: an instance of the class body can be connected to an instance of the class body production facility; classes compatibility: the class body is compatible with the class body production facility; functional dependence: the value of the attribute cost of an instance of the class body production facility depends on values of the attribute cost of instances of the class component connected to it and on the number of such instances.

Fig. 3 represents the macro-level taxonomy of the application ontology for a virtual enterprise built by domain experts. The represented classes are the main concepts for the production network configuration problem.

348


Fig. 3. Taxonomy of the application ontology for a virtual enterprise.

3 Technological Framework The generic scheme of a self-organizing service network is presented in Fig. 4. Each enterprise member is represented as an intelligent agent acting in the system. The architecture of the agent is presented in Fig. 5. Each agent has its own knowledge stored in its knowledge base and is described by a portion of the common shared application ontology. A part of this knowledge related to the current agent’s (and member’s) tasks and capabilities is called “context” and is stored separately to provide for faster task performance (only relevant information is processed). Capabilities, preferences and other information about the agent are stored in its profile that is available for viewing by other agents of the community. It facilitates communication, which is performed via the communication module responsible for meeting protocols and standards that are used within the community.


Alternative information sources

Common shared application ontology

Information source

349

Agent-based service

Agent-based service

Agent-based service

OWL-based information h SOAP-based

information h Fig. 4. Generic scheme of a self-organising network.

Communication module

Context

Core / engine

Profile

Personal knowledge base

Fig. 5. Agent architecture.

The agents communicate with other agents for two main purposes: (1) they establish links and exchange information for better situation awareness; and (2) they negotiate and make agreements for coordination of their activities during the operation. The agents may also get information from various information sources, for example, local road network for transportation can be acquired from a geographical information system (GIS). To make agent-based services independent a component Service Directory Facilitator (SDF) has been proposed. It could be hosted by independent or governmental organisations (for example, CLEPA [12] or regional associations existing in some European countries) SDF is responsible for service registration and update of autonomous services (Fig. 6). Initially an agent representing a service does not have any information about neighbouring services and its slice of the application ontology is empty. An automatic tool or an expert assigns it a set of the application ontology elements related to the service. For knowledge source services this could be classes which can be reified or attributes those values can be defined using content of knowledge sources. For problem solving services this could be tasks and methods existing in the problem domain.

350


Service Directory Facilitator

PSS

KSS

PSS

KSS

KSS PSS

PSS

PSS

KSS KSS PSS – Problem Solving Service KSS – Knowledge Source Service Fig. 6. Registration and update of services.

PSS

Agents inform SDF about their appearance, modifications, intention to leave the community and send scheduling messages to update the internal repository. The task of SDF is to build a slice of the application ontology for each service, update references to the neighbouring services, support list of services (type, location, schedule, and notification of services about changes in the network). Organization of references between services is a complex task and is out of scope of the paper. Well-organized references result in a list of services which are used as initiators of the self-organisation process. Knowledge source services are responsible for (i) representation of information provided by knowledge sources by means of the OOCN-formalism (ii) querying and extract content from knowledge sources, (iii) transfer of the information, (iv) information integration, and (v) data conversion. Two types of strategies for interaction with knowledge sources have been proposed: x

x

Pull – knowledge sources deliver content when it is requested. E.g., a temperature sensor can be mentioned as an example of such information source. It measures temperature and supplies this information needed (Fig. 7, left part). Push – knowledge sources send content to a certain Web-service. For example fire alarm sensor in case of fire can send this information to a special agent that would activate a corresponding scenario (Fig. 7, right part). request inform Pull IS

Push IS reply Fig. 7. Pull (left part) and push (right part) strategies.

When a situation that requires some action occurs, an appropriate context is built. The initiators of the self-organisation process receive a notification. Using references to neighbour services and developed rules / protocols an appropriate


351

network organization is build, to produce a solution. In Fig. 8 a simplified example of self-organizing network is presented. Initiators are agents representing services KSS1, KSS2, and PSS1. Agents of KSS2 and PSS1 delegate the task of participation in problem solving to agents of KSS3, and PSS2. Content of knowledge sources presented by services KSS1, and KSS3 is sufficient and solvers presented by services PSS1 and PSS2 process this content. When the configuration is finished, peer-to-peer interactions between members of the network take place.

4 Conclusion The paper represents an approach and its technological framework for semantic interoperability in virtual enterprises. It is proposed that self-organization can resolve problems arising from failures of centralized control.

PSS

KSS

PSS

KSS1

KSS PSS

PSS KSS3 PSS – Problem Solving Service KSS – Knowledge Source Service Discovery of neighbor services Self-organized network

PSS1 PSS2

KSS2

Context

Fig. 8. Self-organizing of service network.

Ontologies have been proposed for description of problem domain knowledge. In accordance with the selected model of interoperability, services directly connect and exchange information with one another, but service descriptions (in the paper this is description of the knowledge source content and tasks that can be solved) are mapped to the common shared application ontology. The further research activities will address refinement of algorithms (i) of neighbor services definition, (ii) selection of services that initialize selforganization of the network, (iii) traverse of network and (iv) generation and estimation of alternative network configurations. The authors believe that once completed the proposed architecture could efficiently work for a range of the real world problems.

Acknowledgments The paper is due to research projects supported by grants # 05-01-00151, # 06-0789242, and #07-01- 00334 of the Russian Foundation for Basic Research, projects

352


# 16.2.35 of the research program "Mathematical Modelling and Intelligent Systems", and # 1.9 of the research program “Fundamental Basics of Information Technologies and Computer Systems” of the Russian Academy of Sciences (RAS).

References [1]

Foundation for Intelligent Physical Agents (FIPA) Documentation, http://www.fipa.org. [2] Heflin, J., Hendler, J.: Semantic Interoperability on the Web. In: Proceedings of Extreme Markup Languages 2000, pp. 111--120. Graphic Communications Association, (2000). [3] Viana, A. C., Amorim, M. D., Fdida, S., Rezende, J. F.: Self-organization in spontaneous networks: the approach of DHT-based routing protocols. Ad Hoc Networks J., special issue on Data Communications and Topology Control in Ad Hoc Networks, vol. 3, no. 5, 589-606 (2005). [4] Hammer, B., Micheli, A., Sperduti, A., Strickert, M.: Recursive self-organizing network models. Neural Networks, vol. 17, no. 8-9, 1061--1085 (2004). [5] Nakano, T., Suda, T.: Self-Organizing Network Services with Evolutionary Adaptation. In: IEEE Transactions on Neural Networks, vol. 16, no. 5, 2005. [6] Chandran, R., Hexmoor, H.: Delegation Protocols Founded on Trust. In: KIMAS'07: Modeling, Exploration, and Engineering (proceedings of the 2007 International Conference on Integration of Knowledge Intensive Multi-Agent Systems), ISBN 14244-0945-4, pp. 328--335, IEEE (2007). [7] Baumgarten, M., Bicocchi, N., Curran, K., Mamei, M., Mulvenna, M., Nugent, C., Zambonelli, F.: Towards Self-Organizing Knowledge Networks for Smart World Infrastructures. In: Teanfield, H. (ed.) International Transactions on Systems Science and Applications, ISSN 1751-1461, vol. 2, no. 2., 123--133 (2006). [8] Smirnov, A., Shilov, N., Kashevnik, A.: Constraint-Driven Negotiation Based on Semantic Interoperability in BTO Production Networks. In: Panetto, H., Boudjlida, N., (eds.) Interoperability for Enterprise Software and Applications (proceedings of the Workshops and the Doctoral Symposium of the Second IFAC/IFIP I-ESA International Conference: EI2N, WSI, IS-TSPQ 2006), ISBN-13 978-1-905209-61-3, ISBN-10 1-905209-61-4, pp. 175-186, ISTE Ltd. (2006). [9] Dey, A. K., Salber, D., Abowd, G.D.: A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications, Context-Aware Computing. In: T.P. Moran, P. Dourish (eds.) A Special Triple Issue of HumanComputer Interaction, 16, Lawrence-Erlbaum (2001). [10] Smirnov, A., Pashkin, M., Levashova, T., Chilov, N.: Fusion-Based Knowledge Logistics for Intelligent Decision Support in Network-Centric Environment. In: George J. Klir (ed.) Int. J. of General Systems, ISSN: 0308-1079, vol. 34, no 6, pp. 673--690, Taylor & Francis (2005). [11] Smirnov, A., Sheremetov, L., Chilov, N., Sanchez-Sanchez, C.: Agent-Based Technological Framework for Dynamic Configuration of a Cooperative Supply Chain. Multiagent-based supply chain management. In: Chaib-draa, B., Müller, J. P. (eds.) Series on Studies in Computational Intelligence, vol. 28, ISBN: 3540338756, pp. 217--246, Springer (2006). [12] CLEPA: Comité de liaison de la construction d’équipements et de pièces automobiles (the European Association of Automotive Suppliers), http://www.clepa.be.

Semantic Service Matching in the Context of ODSOI Project S. Izza and L. Vincent Ecole des Mines de Saint-Étienne, Industrial Engineering and Computer Science Laboratory, OMSI Division, 158 cours Fauriel, 42023, Saint-Etienne, Cedex 2, France. {izza, vincent}@emse.fr

Abstract. Matching services still constitutes a big challenge for most of enterprises in general and notably for large and dynamic ones. This paper delineates a service similarity approach in the context of ODSOI (Ontology-Driven Service-Oriented Integration) project that concern the intra-enterprise integration issues in the field of manufacturing industry. Our approach is based on an extension of OWL-S service similarity. It proposes a rigorous quantitative ranking method based on some novel semantic similarity degrees. An implementation of this ranking method is provided in the form of a prototype coded on Java platform exploiting some existing APIs mainly Racer OWL API, and OWL-S-API. Keywords: Information System; Integration; Ontology; Semantics; Service; Similarity; Matching; OWL-S.

1 Introduction In the last few years, matching of services has been a very active research field in the context of semantic web in general and enterprise information systems in particular. Service matching is generally considered as the process by which similarities between service source (ideally candidate services) and service target (ideally the client's objectives presented in a form of a service template) are calculated. From an architectural point of view, the service matching involves three types of stakeholders: (i) service providers which have the goal of providing particular types of services and publish or advertise their services to enable potential requestors to discover and utilize them, (ii) service requestors which have the goal of finding services that can accomplish some internal objectives, (iii) matchmakers which are middle agents that can be used to find the service providers that match the stated requirements of a requestor [1].

354

S. Izza and L. Vincent

Today, the service matching is particularly challenging in the context of intraenterprise integration because of the large number of available web sources and services, and also of the different user profiles that may be involved. The use of efficient matching approach based on a pertinent ranking method becomes necessary in order to correctly facilitate and achieve some integration issues. This paper deals with these issues and precisely the service matching approach in support for intra-enterprise integration in the context of ODSOI (OntologyDriven Service-Oriented Integration) project [11]. It is organized as follows: Section 2 introduces some previous work in the domain of service similarity and matching. Section 3 presents the main principles of our service matching approach. Section 4 presents our semantic similarity approach. Section 5 presents some preliminary experimental results and lessons learned. Finally, Section 6 presents some conclusions and outlines some future work.

2 Related Work Semantic matching constitutes an important field that has been widely investigated in the last few years in several areas of research. We present a brief survey of some approaches to semantic matching that are related to the context of matching services. These works are presented following four categories of approaches: (i) concept similarity approaches, (ii) resource matching approaches, (iii) service matching approaches, and (iv) OWL-S service matching approaches. The first category of approaches concern the concept similarity metrics and the main representative ones with respect to our work are those proposed by [20], [19] and [7]. [20] proposed, in the context of semantic nets, a metric to measure conceptual distance between concepts in hierarchical semantic nets as a minimum number of edges separating the involved concepts. [19] proposed in the context of measuring information content of a concept a metric that associates probability with concepts in an hierarchy to denote the likelihood of encountering an instance of a concept. [7] proposed, in the context of similarity for ontology framework, a metric for measuring similarity for ontology concepts as an amalgamation function that combines the similarity measure of three complementary layers that are: (i) data layer that measures the similarity of entities by considering the data values of simple or complex data types such as integers and strings; (ii) ontology layer that considers and measures the semantic relations between the entities; and (iii) context layer that considers how entities of the ontology are used in some external context, most importantly, the application context. Although these approaches are pertinent, we exploit within ODSOI project a concept similarity approach based on OWL constructs. Another important work that is related to ours is [4] that proposed a taxonomy-based similarity measuring of ontology concepts. This latter, which does not provide an efficient asymptotic behaviour of the similarity measure, is improved by our similarity approach. The second category of approaches is closely related to resource matching such as: text document, schema, and software component matching. Text document matching constitutes a long-standing problem in information retrieval where most solutions are based on term frequency analysis. Schema matching is based on

Semantic Service Matching in the Context of ODSOI Project

355

methods that try to capture clues about the semantics of the schemas, and suggest matches based on them. Such methods include linguistic analysis, structural analysis, the use of domain knowledge and previous matching experience. Software component matching is an important activity for software reuse and is generally based on the examination of signature matching and specification matching. However, most of the approaches of this category are insufficient in the web service context because they present differences from the information structure, granularity and coverage point of view. The third category of works that are closed to ours concern those that exploit the notion of service similarity in general. [5], [10], [2], [3], [22], [15] and [24], constitute some important works that propose techniques that perform service matching exploiting the notion of service similarity. [5] proposed a metric for similarity search for web services in the context of Woogle search engine that exploits the structure of the web services and employ a novel clustering mechanism that groups parameter names into meaningful concepts. [10] proposed a metric for measuring the similarity of semantic services annotated with OWL ontology. Similarity is calculated by defining the intrinsic information value of a service description based on the inferencibility of each of OWL Lite constructs. [2] proposed, in the context of METEOR-S, a service similarity approach that is based on syntactic, operational and semantic information as a way to increase the precision of the match of web services. Syntactic similarity is based on the similarity of service names and service descriptions. Operational similarity is based on the functionality of services. Semantic similarity is based on the similarity of concepts and properties that defines the involved services. [2] proposed a matching algorithm that extended the work presented in [18] and precisely they mainly extended the subsumption based matching mechanism by adding information retrieval techniques to find similarity between the concepts when it is not explicitly stated in the ontologies. [22] uses, in the context of LARKS framework, five different types of matching: context matching, profile comparison, similarity matching, signature matching and constraint matching. [24] proposed an approach to rank services by their relative semantic order by defining three different degrees of matching, which are: (i) exact match (all requests in a demand are available in supply); (ii) potential match (where some requests in demand are not specified in supply); (iii) partial match (where some requests in demand are conflict with supply). Although these approaches present important principles, however, they do not concern OWL-S services. Finally, the fourth category of works that are the most closed to ours concern those discussed semantic discovery using OWL-S ontology such as [18] [3], [13] and [8], when the advertisement and request use terms from the same ontology. Most of these works proposed similar approaches for service discovery using a Semantic UDDI registry. They mainly enhanced the semantic search mechanism by enabling users to specify semantic inquiries based on web services capabilities. [18] propose, in the context of OWL-S services, a service similarity approach based on the use of Service Profile similarity, mainly the similarity of inputs and outputs. To achieve flexible matching, they define four degrees of service matches, which are: (i) exact, when there is an equivalence or a subsumption relationship between the two concepts, (ii) plug-in, when there is a subsumption relationship

356


between the two concepts, (iii) subsumes, when there is an inverse subsumption relationship between the two concepts, and (iv) fail, when no subsumption relation can be identified between the two concepts. [3] proposed, in the context of MAIS project, a service similarity approach that extends that proposed by [18] and that allow to calculate a similarity, between a published service and the user request, taking into account the semantics contained in the corresponding OWL-S ontologies. [13] refines the work by [18] and proposed a ranking method that concern OWL-S services. [8] introduced a complex semantic similarity measure for determining the similarity of OWL-S services as a linear combination of the functional similarity of services and their textual similarities. The functional similarity of services is determined by measuring semantic similarity which exists between their sets of inputs and outputs. In order to be able to measure the input/output similarity of services we introduced techniques for finding the similarity of OWL concepts which are used for annotating the inputs and outputs of services. Our work is very closed to this category of approaches and is aiming to propose more rigorous ranking method that may be used for matching of OWL-S services.

3 Main Principles of the Semantic Service Matching ODSOI (Ontology-Driven Service-Oriented Integration) project concerns the intraintegration issues in the context of large and dynamic enterprises with the aim to define agile integration architectures. Within this project, service matching constitutes an important point that allows to discovering pertinent services in order to compose them into more gross-grained services and/or useful processes. In our approach [11][12], services are mainly characterized by four elements that are defined using ontology concepts (OWL-DL constructs) and that are: context, signature, constraint, and non-functional attributes. Service context is defined using one or more of the following properties: service classification which is the service category where the considered service belongs to, service cluster which is the cluster, in terms of service area and domain, where the considered service belongs to, and the enterprise view which is the enterprise component that is exposed by the considered service. Service signature includes the inputs and the outputs of the service. Service constraint mainly includes constraints on service preconditions and postconditions of the service. Non functional service parameters include quality of service and service visibility. In our approach, the defined service matching method improves the traditional matching of services [18] which is mainly based on signature matching. Our matching approach is based on the matching of all the four above elements that describe enterprise services: x

Service context matching: the source service and the target service must share the same context (i.e.: contextsource contextt arg et where context source and contextsource are respectively the context of the source and the target service.


x

x

Service signature matching: the source service and the target service must present comparable signatures (ie.: ) where is the subsumption ( Int arg et In source ) (Out source Out t arg et ) operator, Insource and Outsource are respectively the inputs and the outputs of the source service, Inttarget and Outtarget are respectively the inputs and the outputs of the target service. Service constraint matching: the source service and the target service must have compatible constraints on their preconditions and postconditions. This means that we must make valid the following expression: ( precond source precond t arg et ) ( postcond t arg et postcond source ) where

precond source and postcond source are preconditions postconditions of precond

x

357

postcond

t arg et t arg et the source service, and and are preconditions and post-conditions of the target service. Non functional parameters: the source service and the target service must have comparable non functional parameters that are quality of service and service visibility. Precisely, the source and the target service must present comparable levels of quality (i.e.: QoS source QoS t arg et where QoS source and QoS t arg et are respectively the quality of the source service and of the target

service. Concerning the service visibility, we must also have compatible visibilities (i.e.: visibility source visibility t arg et where visibilitysource and visibility source are respectively the quality of the source and the target service.

4 Semantic Service Similarity Our approach is based on the calculation of a similarity degree that measures the degree of satisfaction evaluated using the similarity of ontology concepts. This similarity degree is based on some more elementary degrees that quantitatively refines the traditional inference between two concepts (equivalence, subsumption, inverse subsumption, intersection, and disjunction) such as those generally proposed in the literature [18].

5 Global Semantic Service Similarity Formally,

we

propose

to

calculate

the

global

similarity

degree

simglobal ( S , S ' ) between two given services (or a source service and a target service)

S and S' as a weighted product accordingly to the following formula:

358


sim global ( S , S ' )

sim xOx ( S , S ' ) (1)

xFilter

where x {context, signature, constraint, non-functional} and Ox is a positive real weight and where simcontext ( S , S ' ) denotes the similarity degree of service contexts,

sim signature ( S , S ' ) sim constra int ( S , S ' )

denotes

the

similarity

degree

of

service

signatures,

denotes

the

similarity

degree

of

service

constraints,

'

simnon functional ( S , S ) denotes the similarity degree of non-functional attributes. As it is shown, this formula may be interpreted as a probability of similarity of two services S and S'. The choice of the weighted product in the formula is not fortuitous and it can be justified by the fact that the global similarity must depend of the performance of all the elementary similarity degrees and not of the excellence of only certain degrees.

6 Elementary Semantic Service Similarity In a similar manner than the global similarity degree, all the above intermediary degrees are a combination of some more elementary degrees. For example, the similarity degree of service contexts simcontext ( S , S ' ) is calculated using the following formula: simcontext (S , S ' )

simO (S , S ) '

x

x x{type, cluster, view}

(2)

In a similar manner, the other intermediary similarity degrees are calculated accordingly to the following formulas:

simO (S , S )

simsignature (S , S ' )

'

x

(3)

x

x{input, output}

simconstra int (S , S ' )

simO (S , S )

(4)

simO (S , S )

(5)

x

'

x x{precondition, postcondition}

simnon functional ( S , S ' )

x

x x{QoS, visibility}

'

Therefore, we gradually define the global similarity degree as a combination of elementary degrees. We define an elementary degree as a degree that can not be divided in order to calculate it. For example, we consider in our approach that the two degrees siminput ( S , S ' ) and simoutput ( S , S ' ) as elementary because we consider them as not composite. The elementary degree is very important in the way that the problem of calculation of the global similarity degree is translated in the form of some simple problems of calculation of elementary degrees.


359

7 Semantic Ontology Concept Similarity For the calculation of the elementary similarity degrees, we exploit a variant that combines the structural topological dissimilarity [23] and the upward cotopic distance [16]. Based on these two measures, we define an appropriate measure that matches two ontology concepts of a same ontology and that takes into account the sensibility of the concepts depth. Given two concepts C and C' of the same ontology O with a depth Depth(O), the similarity degree between these two concepts is calculated accordingly to the following formula: 1 d d' D max( d , d ' ) 1 (1 min(d , d ' ) 1)( ) (6) sim (C , C ' ) (1 ( ) ) (1 ) 1 Depth(O) (min(d , d ' )) E d d' 1 Depth (O ) where D and E are parameters that control the flatness of the similarity function and that are defined as follows: D 1 max(d , d ' ), E log10 ( Depth(O)) (7) and where d and d' are respectively distances (augmented with one in order to avoid null denominators) between the concept C (resp. C') and the smallest common ancestor C0 :

d

dist (C , C0 ) 1, d ' dist (C ' , C0 ) 1

(8)

The common ancestor C0 of the two concepts C and C' is the solution of the optimization problem that allows to define the structural topological dissimilarity as introduced in [23] : (9) ?c: min[ dist (C , c ) dist (C ' , c )] c

Of course, the global concept similarity function (sim) is mathematically a function of similarity because it verifies the conditions of positivity, maximality and symmetry [14]. Furthermore, this function is normalized due to the fact that its values are in [0, 1].

360


(1-a)

(1-b)

Fig. 1. Curves of the concept similarity function

As it can be noted, the global similarity formula (formula 6) contains four factors. The first factor (1 ( d d ' )D ) represents the global behaviour of the d d'

similarity calculation. It allows a measure that is sensible to the depth of the two concepts. More the concepts are near from the common ancestor and more this quantity is important. In opposite, this quantity diminishes when the concepts are far away from the common ancestor. The disadvantage is that it favors the cases where the distances d et d' are equal even if one or more concepts are so far away from the common ancestor accordingly to the bisecting plan (d, d'). This disadvantage is corrected by the second factor (1 max(d , d ' ) 1) , that allows to 1 Depth(O )

diminish the curve when the distances d and d' increase in a same manner. This allows us to have a desired effect that is the effect of a bell. This effect is important because it allows to increase the similarity around the common ancestor and to decrease when the concepts move away from the common ancestor. Concerning 1 the last two factors (1 min(d , d ' ) 1) and ( ) , they allow to smooth the (min(d , d ' )) E 1 Depth(O) curve, notably along the contour of the curve where d = d'. Figure 1-a and figure 1b show the curves of this similarity function from two different angles of view. The calculation of some values of the similarity function, with Depth(O) equals to 100 is represented on table 1 that quantitatively illustrates the asymptotic behavior of this function. As shown, this latter conforms to the desired behavior which is to provide an efficient measure that takes into account the depth of the concepts in the ontology, their neighborhood, and also the asymptotic behavior of the measure when these concepts are far from the common ancestor.


361

Table 1. Some values of the concept similarity function d'

1

2

3

4

5

6

7

8

9

1.0000 0.9534 0.9189 0.8948 0.8761 0.8603 0.8464 0.8338 0.8219 0.8107

0.9534 0.2451 0.2422 0.2392 0.2362 0.2334 0.2307 0.2280 0.2254 0.2229

0.9189 0.2422 0.1068 0.1057 0.1046 0.1035 0.1024 0.1013 0.1002 0.0991

0.8948 0.2392 0.1057 0.0588 0.0582 0.0576 0.0570 0.0564 0.0558 0.0552

0.8761 0.2362 0.1046 0.0582 0.0369 0.0365 0.0361 0.0358 0.0354 0.0350

0.8603 0.2334 0.1035 0.0576 0.0365 0.0251 0.0248 0.0246 0.0243 0.0240

0.8464 0.2307 0.1024 0.0570 0.0361 0.0248 0.0181 0.0179 0.0177 0.0175

0.8338 0.2280 0.1013 0.0564 0.0358 0.0246 0.0179 0.0135 0.0134 0.0132

0.8219 0.2254 0.1002 0.0558 0.0354 0.0243 0.0177 0.0134 0.0105 0.0104

10

d 1 2 3 4 5 6 7 8 9 10

0.8107 0.2229 0.0991 0.0552 0.0350 0.0240 0.0175 0.0132 0.0104 0.0083

8 Preliminary Experimental Results and main Lessons Learned We conducted some preliminary evaluation analyzing the efficiency and comparing the performances of our service matching approach to show that exploiting such a method is pertinent and does not hinder the performance and scalability of the matching process. We implemented a matching prototype using Java under the Eclipse environment [6] and some APIs mainly OWL API [21] to extend and manage OWL ontologies, OWL-S API [17] to extend and manipulate OWL-S descriptions, and Racer [9] to perform OWL inferences. Figure 2 illustrates the developed prototype. As it is shown, the graphical user interface contains some graphical components that allow fulfilling the elements of the discovery request. In addition to this, we have the possibility to change the different weights and thresholds that are used for calculating the global similarity degree between the request and the published services.

362


n FunctionService MaintenanceArea

o

EquipementQualificationPredictio n

EquipementQualification

p

Fig. 2. Snapshots of the developed prototype

In order to facilitate the fulfilling of the request, the prototype allows visualizing some stored ontologies for selecting some desired concepts. Once the user finished its request, he can execute the discovery process by clicking on the button "Discover". Then the prototype restitutes the matched services that are ranked accordingly to the calculated similarity degrees. An example of simple discovery request that was experimented is to search for functional services within the cluster MaintenanceArea that produces Qualifications. The prototype executes the matching algorithm and restitutes ranked answers accordingly to the service similarity degree. But within the restituted answers, some services may present the same similarity degree (here we obtained in this case two services that have the same similarity degree 0,8684.). In order to differentiate them, we exploit other elements of the request. So we exploit the enterprise view (or other request elements) that allows to precise for example the type of the activity held by the service (planning, prediction, reporting, etc.). This is important in order to increase the performance (mainly precision and recall) of the prototype. By exploiting the Service View element, we can indicate precisely which kind of activity of qualification management we want to retrieve. For example, when we indicate in the Service View zone text the functional concept "QualificationQueryFunction" which is a concept from the Functional Ontology, then we can differentiate between the above services and we obtain two different


363

answers with two different degrees of similarity: 0,2921 and 0,8684. These similarity degrees may be more refined with the exploitation of the other elements, or by choosing more restricted service clusters. Based on our experimentation of Semantic Web services, and precisely of the semantic matching of enterprise services on a significant sample of enterprise services, we believe that the existing technologies (precisely the existing open OWL-S APIs and also on the existing OWL inference engines) are sufficiently mature to use them in industries even if they are sometimes very heavy in the sense that they need a consequent consuming time. The suggested matching method is very promoting in the way it proposes a pertinent quantitative ranking of enterprise services. We worked successfully with a sample of enterprise services and some evaluation of the performance was also made. And we are convinced by the importance of the implemented prototype. An additional notice concerns the graphical user interface. This latter seems to be important in order to correctly guide the process of discovery of enterprise services. With such an interface, a user may user-friendly make a request. By clicking on the browsing buttons, the prototype visualizes appropriate ontologies (in order to select ontology concepts), and the user gradually builds his request by only choosing desired concepts. Furthermore, the user can change the request weights (default values were set to one) in order to adapt them to the specific enterprise context. He can also change the different thresholds in order to better control the failure condition in the discovery process. Our experimentation shows that the values of the different weights and the different thresholds must be correctly determined. The experimentation also shows some limitations that need some amelioration in the future. Two notable ameliorations must at least be mentioned in order to enhance the prototype. The first one concerns the taking into account of the numerical values in the formulation of the discovery requests (for example to take into account a reliability of service higher than 0.9 which is not possible in the actual version of the prototype because we use the simple hypothesis that formalizes the quality as some discrete modalities) and also the possibility of visualizing the answers graphically using the principle of the cartography of the enterprise services that is more convivial.

9 Conclusions and Future Work We have presented in this paper an approach for service matching in the context of intra-enterprise integration, and precisely in the context of ODSOI project. This approach which extends the existing matching methods, may improve the service discovery approach in order to correctly search and rank services within and also outside the enterprise. Our service matching approach is based on the matching of all the four elements that describe enterprise services: context, signature, constraint and non-functional attributes. Furthermore, our approach proposes a rigorous ranking method that provides an efficient measure that takes into account the depth of the concepts in the ontology, their neighborhood, and also the asymptotic behavior of the measure when these concepts are far from the common ancestor concept. However, our approach presents some limitations and the main ones

364


concern its run-time-consuming in the sense that it needs a longer execution path than in a traditional matching approach. But the benefits are above all for long term because the matching method gives more refined results. We have implemented a matching prototype and we have performed several experiments within a large enterprise that gave good results. The future work will focus on improving the time consuming through reducing the loading and inference time by managing and manipulating small interrelated ontologies. It also focuses on testing the prototype in large realities in order to validate its scalability and also its importance in the context of large enterprises and the semantic Web services.

Disclaimer Certain commercial software products are mentioned in this paper. These products were used only for demonstration purposes. This use does not imply approval or endorsement by our institution, nor does it imply these products are necessarily the best available for the purpose.

References [1]

[2] [3]

[4]

[5]

[6] [7]

[8]

[9]

Burstein M. H., Bussler C., Zaremba M., Finin T. W., Huhns M. N., Paolucci M., Sheth A. P. and Williams S. K., "A Semantic Web Services Architecture". IEEE Internet Computing 9(5): 72-81 (2005). Cardoso A. J. S., "Quality of service and semantic composition of workflows". PhD Thesis, University of Georgia, Athens, Georgia, 2002. Corallo A., Elia G., Lorenzo G. and Solazzo G., "A Semantic Recommender Engine enabling an eTourism Scenario". ISWC2005 International Semantic Web Conference 2005, 6-10 November 2005, Galway, Ireland. Correla M. A. and Castels P., "A Heuristic Approach to Semantic Web Services Classification". 10th International Conference on Knowledge-Based & Intelligent Information & Engineering Systems (KES 2006), Invited Session on Engineered Applications of Semantic Web (SWEA). Bournemouth, UK, October 2006. Springer Verlag Lecture Notes in Computer Science, Vol. 4253, ISBN 978-3-540-46542-3, pp. 598-605. Dong X., Halevy A., Madhavan J., Nemes E. and Zhang J., "Similarity Search for Web Services". In proceedings of the 30th VLDB Conference, Toronto, Canada, http://www.vldb.org/conf/2004/RS10P1.PDF, 2004. Eclipse, "Eclipse - an open development platform". 2005, http://www.eclipse.org (accessed 3 March 2005). Ehrig M., Haase P., Hefke M. and Stojanovic N., "Similarity for ontology - a comprehensive framework". In Workshop Enterprise Modelling and Ontology: Ingredients for Interoperability, 2004. Ganjisaffar Y., Abolhassani H., Neshati M. and Jamali M., "A Similarity Measure for OWL-S Annotated Web Services". Web Intelligence (WI'06), IEEE/WIC/ACM pp. 621-624, 2006. Haarslev V. and Möller R., "RACER System Description". In Proceedings of the International Joint Conference on Automated Reasoning, June 18-23, 2001.


365

[10] Hau J., Lee W., and Darlington J., "A semantic Measure for Semantic Web Services". WWW2005, May 10–14, 2005, Chiba, Japan. [11] Izza S., Vincent L. and Burlat P., "A Framework for Semantic Enterprise Integration". In Proceedings of INTEROP-ESA'05, Geneva, Switzerland, pp-78-89, 2005. [12] Izza S., Vincent L., Burlat P., Lebrun P. and Solignac H., "Extending OWL-S to Solve Enterprise Application Integration Issues". Interoperability for Enterprise Software and Applications Conference (I-ESA'06), Bordeaux, France, 2006. [13] Jaeger M. C., Rojec-Goldmann G., Liebetruth C., Mühl G. and Geihs K., "Ranked Matching for Service Descriptions Using OWL-S". Springer Berlin Heidelberg, 2005. ISBN: 978-3-540-24473-8. [14] KnowledgeWeb, "Deliverables of KWEB Project". EU-IST-2004-507482, 2004, http://knowledgeweb.semanticweb.org/, accessed 10 June 2006. [15] Li L. and Horrocks I., "A software framework for matchmaking based on semantic web technology". In the International Journal of Electronic Commerce, 8(4):39-60, 2004. [16] Mädche A. and Zacharias V., "Clustering ontology-based metadata in the semantic web". In proceedings 13th ECML and 6th PKDD, Helsinki (FI), 2002. [17] Mindswap Group, "OWL-S API". 2005, http://www.mindswap.org/ 2004/ owl-s/api/ (accessed 24 March 2006). [18] Paolucci M., Kawamura T. and Payne T., "Sycara, K.: Semantic Matching of Web Service Capabilities". In proceedings of the First International Semantic Web Conference, 2002. [19] Resnik P. "Semantic similarity in a taxonomy: An information-based measure and its application to problems of ambiguity in natural language". In Journal of Artificial Intelligence Research, volume 11, pages, 95–130, July 1999. [20] Roda R., Mili H., Bicknell E. and Blettner M., "Development and application of a metric on semantic nets". In IEEE Transactions on Systems, Man, and Cybernetics, volume 19, Jan/Feb 1989. [21] Sourceforge, "OWL API". http://owlapi.sourceforge.net/, accessed April 2006. [22] Sycara K., Widoff S., Klusch M. and Lu J., "Larks: Dynamic Matchmaking Among Heterogeneous Software Agents in Cyberspace", ACM Portal, Source: Autonomous Agents and Multi-Agent Systems, v5, issue 2, pp. 173–203, June 2002. [23] Valtchev P. and Euzenat J., "Dissimilarity measure for collections of objects and values". In proceedings Coen X. Liu and M. Berthold, editors, Proc. 2nd Symposium on Intelligent Data Analysis., Vol. 1280, pp. 259–272, 1997. [24] Tommaso D. N., Di Sciascio E., Donini F. M. and Mongiello M., "A System for Principled Matchmaking in an Electronic Marketplace". In proceedings of the Twelfth International Conference on World Wide Web (WWW), 2003.

Ontology-based Service Component Model for Interoperability of Service Systems Zhongjie Wang and Xiaofei Xu Research Center of Intelligent Computing for Enterprises and Services (ICES), School of Computer Science and Technology, Harbin Institute of Technology P.O.Box 315, No.92, West Dazhi Street, Harbin, China 150001 {rainy, xiaofei}@hit.edu.cn

Abstract. Service system as the foundation for service providers and customers to create and capture value via co-production relationship, is a complex socio-technological system composed of people, techniques and shared information. One of the most significant characteristics of a service system is that there exist a mass of dynamic, stochastic and semantic interactions (i.e., interoperability) between heterogeneous service elements. For better considerations on interoperability during service system design, we import OWLbased service ontology to precisely express service semantics. Based on such ontology, heterogeneous service elements are elaborately classified and encapsulated into a unified form “Service Component” with a set of uniform interfaces to expose or acquire semanticsbased services to/from outside. In such way, right service components will be chosen out by ontology matching, and semantics conflicts between service elements will be easily discovered. Based on interface connections, selected service components are weaved together to form service system with good interoperability performance. Keywords: Ontology based methods and tools for interoperability, Design methodologies for interoperable systems, Model Driven Architectures for interoperability

1 Introduction Over the past three decades, services have become the largest part of most industrialized nations’ economies (Rouse and Baba 2006, Spohrer et al 2007) and researchers and practitioners have evolved more and more R&D on service related activities. In 2004, IBM firstly presented the concept “Services Sciences Management and Engineering (SSME)” (IBM, 2004) and promoted the creation of a new discipline “Services Sciences”, which tries to integrate across traditional disciplinary areas to obtain globally effective solutions in a service business

368

Zhongjie Wang and Xiaofei Xu

environment (Chesbrough and Spohrer, 2006) to better facilitate the development of service industry. Generally speaking, a service is a provider-to-client interaction that creates and captures value while sharing risks (Wikipedia, 2007). In order to support execution a service, there should be a well-designed service system for supporting. Consider education service system as an example, in which universities as service providers that aim to transform student knowledge through agreements, relationships, and other exchanges among students and university faculty, including courses offered and taken, tuition paid, and work-study arrangements (Spohrer et al, 2007). There has reached a consensus that, a service system is a value co-production configuration of people, technology, other internal and external service systems connected by value propositions, and shared information (such as language, processes, metrics, prices, policies, and laws) (Spohrer et al, 2007). It is a type of complex socio-technological system that combines features of natural system and manufacturing system (IBM, 2004). Easily to see that a service system is not just a pure software system but is additionally composed of various complex, heterogeneous and distributed service elements, e.g., people, techniques, resources, environments, etc. Besides, in order to fully accomplish service business, tight and continual collaborations between service elements provided by different participants cannot be thoroughly avoided. From above two points of view, service system is essentially considered as the interoperability between multiple sub-systems of different participants, or between multiple service elements. Formally speaking, we define service interoperability as the ability of people, resources, or behaviors to provide services to and accept services from other people, resources, or behaviors and to use the services so exchanged to enable them to operate effectively together. During service process, a smooth and effective interoperability channel between all service elements must be created and maintained to ensure coherent communications between participants, so as to realize the objective of “co-producing and share values”. Concerning state of the art about interoperability of service systems, current research mainly concentrates on the following two aspects, i.e., (1) Fundamental theories on service systems. Researchers try to borrow some universal theoretical methods from other similar complex systems (e.g., natural ecosystem, social networking system, ESA, etc) to analyze the interoperability mechanisms between service elements. Such methods include ecosystem based idesign method (Tung and Yuan 2007), small world network (Yuan and Zhang 2006), catastrophe theory (Liu et al 2006), etc. Unfortunately, at present these methods are merely resting in theoretical level and there still lack of concrete techniques to support the implementation of such theories in practical service systems. (2) Methodology for service engineering. This aspect usually emphasize on step-by-step mapping from customer requirements to service systems following model-driven approach to address interoperability issues (Tien and Berg 2003, Cai 2006). However, most of related literatures emphasize particularly on the interoperability between softwarized services (e.g., web services, SCA, etc) (Cox and Kreger 2005), in which ontology languages (e,g., OWL, RDF, DAML+OIL,

Ontology-based Service Component Model for Interoperability of Service Systems

369

etc) are adopted to eliminate semantics gap between services (Vetere and Lenzerini 2005), but those non-softwarized service elements are mostly ignored. In order to address limitations mentioned above, in this paper we present a new concept “Service Component (SC)” as basic and uniform building blocks to encapsulate heterogeneous service elements. Each SC has a set of unified interfaces to interact with others, and pre-defined domain-specific ontology is imported to formally express semantics of service elements encapsulated in SC. In this way, structural and semantic diversities will be thoroughly eliminated. During design and implementation of a service system, SCs could be precisely discovered, understood, invoked and composed together based on ontological information attached to them. This paper is organized as follows. In section 2 we analyze basic elements of a service system and possible interoperability scenarios between them. In section 3, we define the corresponding ontology for describing semantics of each type of service elements. In section 4 the concept of “Service Component” is put forward, including its classifications and unified interfaces. Section 5 discusses how to deal with interoperability issues by SC composition. Finally is the conclusion.

2 Service System and Typical Interoperability Requirements 2.1 Basic Constituents of a Service System

Service system is considered as a socio-technological system composed of multiple types of service elements. Generally speaking, such elements are classified into two types, i.e., technological and non-technological ones, either of which depends closely on each other to achieve global optimization of service performance (IBM 2004). Distinctive characteristics of a service system are specified as nine classes, i.e., customer, goals, input, output, process, human enabler, physical enabler, informatic enabler and environment (Karni and Kaner 2000). In our opinion, such classification is too fine-grained to be lack of clarity, therefore we re-classify typical service elements into the following four types based on IBM’s viewpoint (Spohrer et al 2007), i.e., x x x x

People, mainly referring to service customers and service providers, including their organizations, roles, human resources, professional skills and capabilities; Resource, including technological (virtual) and physical material resources, e.g., software, hardware and equipment, physical environments, etc, that could be utilized during service process; Shared information, including papery or electronic files, reports and documents which are created, processed by and exchanged between service customers and providers; Behavior, referring to the physical, mental and social behaviors that are provided by or as the responses of people or resources during services.

370


Organization

People 0..*

1..* Shared Information 0..*

1..*

Behavior 0..*

0..*

Capability 0..*

Software

Hardware

0..*

0..*

0..* Resource

0..*

1..* 1..*

0..*

0..*

Value

QoS/SLA Parameter Risk

Environment

Fig. 1. Service elements and their relationships

The reason that interoperability of service system is quite complex is that it contains not only a mass of non-technological elements (e.g., people, whose behaviors are difficult to model and simulate), but also because such interoperability is stochastic, nonlinear, difficult to forecast, and frequently changing along with requirements and resource providing. In Fig. 1, we present some typical service elements and relationships between them. 2.2 Typical Interoperability Issues in Service Systems

Considering different types of service elements, typical interoperability in service systems may possibly fall into one of the following situations: x x x x x

Interoperability between people, i.e., verbal communication or behavior interactions face-to-face or via collaborative web-based environment; Interoperability between people and software, i.e., people learn to use software, provide input information to it and receive returned information from it; Interoperability between people and information, i.e., people receive and try to understand information, then take specific actions or produce new information based on these information; Interoperability between people and hardware, i.e., service behaviors initiated by people requires the support by some specific hardware or equipments; Interoperability between people and environment, i.e., only when people locate in some specific environment, can they better provide proper services to others;


x x x

371

Interoperability between software, i.e., software belonging to different service participants should interoperate with each other via function calls or information sharing to automate accomplish some specific service tasks; Interoperability between resources, i.e., one resource may possibly use other resources for its own functions; Interoperability between resource and environments, i.e., a resource should be configured in a specific environment so as to be utilized by other service elements.

In real services, because service elements provided by different participants are quite heterogeneous, the interoperability scenarios mentioned above might not be easily realized. We summarize possible interoperability issues into the following three types, i.e., x

Function mismatch

-

-

-

Functions provided by a service element are rather larger or smaller than the required functions of other elements. For example, a service behavior “Business Consulting” include four packaged service activities (AS-IS modeling, component business analysis, business redesign, IT re-design), but a service customer might only require “ASIS modeling”; Functions provided by a service element require too much input information that other elements cannot fully provide. For example, a service “Switch a ERP system from simulative running to formal online running” requires that complete BOM (Bill of Materials) and BOP (Bill of Process) data have been fully prepared, but almost all customer enterprises usually cannot provide complete BOM/BOP at all; Output of a service element contains too much information that is not completely required by other service elements.

x

SLA mismatch Quality is a very important aspect of a service. When multiple service elements are composed together to form service system, quality of different service elements should be compliant with each other so that total service quality will reach an accepted level. Even two service elements are both in high-level quality, if they are not matching, the composite quality would be possibly bad. Typical SLA/QoS parameters include response time, cost, price, security, competence, etc, of service behaviors, resources and capabilities.

x

Semantics mismatch - Syntax format of service element representations/descriptions are inconsistent with others; - Semantics representations of service elements are inconsistent with other elements.

372


If such interoperability issues cannot be effectively eliminated, it is difficult for service providers and customers to establish favoring collaborations between respective service elements, therefore performance of the service system will keep in low level and some mandatory functional service requirements are difficult to cover indeed. Since interoperability in service systems is quite similar with interoperability between software systems, we prefer to find possible interoperability scenarios and solve them in service model level, then try to map them to the execution level of service systems. It is quite similar to the approach of Model-Driven Interoperability (MDI) in the domain of ESA interoperability (Elvesæter et al 2006).

3 Domain-specific Service Ontology A common approach to address interoperability is to import ontology by which the concepts are consolidated into a unified semantics space. In this paper we adopt similar approach, too, i.e., defining domain-specific service ontology, using which to express semantics of service components and support interoperability during service component composition. Table 1 lists some typical concepts and their property-based associations. Due to limited space, we will not explain each concept and property in details; however, readers could get to understand their meanings from the names. Table 1. Service ontology: concepts and properties Concept

Organization

People

Behavior

Property has contains provides provides has inStateOf has belongsTo provides provides has inStateOf has has has hasBehaviorType hasExecutionType in has isProvidedBy hasInput hasOutput

Associated Concepts OrganizationProfile People Resource Behavior Capability State PeopleProfile Organization Behavior Capability FeasibleDate State Profile PreCondition PostCondition BehaviorType ExecutionType GranularityLevel SLAParameter Organization or People Information Information


Concept

Property requires requires interactWith isComposedOf hasImpactOn

Capability

createValue followRisk has has requires inStateOf

CapabilityMetrics

enumerate

CapabilityRepresentation

enumerate

Resource

Information ServiceValue ServiceRisk State StateParameter

isRelatedTo has provides requires provides inStateOf Requires has fromState toState fromState toState contains hasName hasValue hasMetrics

373

Associated Concepts Resource Capability Behavior Behavior Resource or Organization or People or Behavior or Capability ServiceValue ServiceRisk CapabilityProfile CapabilityRepresentation Capability State {QualitativeMetrics, QuantitativeMetrics} {Advantage, Knowledge, Experience, ControllingResCapability} CapabiliytMetrics ResourceProfile Capability Capability Behavior State Resource InformationProfile State State State State StateParameter Name Value Metrics

SLAParameter

With flourish researches on Semantic Web, there have appeared so many ontology description techniques, e.g., RDF, DAML+OIL, OWL, KIF, etc, among which OWL (Web Ontology Language) (W3C 2004) now has been the most popular and de-festo standard of ontology description language for semantics on the Web. Although web-based services are just one of typical service elements in service system, it is easy to make use of OWL to describe other non-softwarized services; therefore we adopt OWL as the tool to describe our service ontology. Fig. 2 is a snapshot of service ontology defined in Protégé (Stanford 2007).

374


Fig. 2. A screen snapshot of service ontology definition by Protégé

Compared with other service elements, service behaviors are more emphasizing on interactive process. In Semantic Web, OWL is extended to OWL-S (OWL 2004) for defining interactive processes between web services, and here we also employ OWL-S as the tool for describing inner detailed processes of service behaviors, each of which is represented as an OWL-S process model according to pre-defined service behavior ontology. Fig. 3 shows an example of IT consulting behavior process composed of five fine-grained service behaviors, i.e., (1) CBM (Component Business Modeling) based AS-IS modeling and analysis, (2) business value analysis to specify the value of each business components on strategic goals of an enterprise, (3) business transformation design, (4) business re-deployment and (5) IT asset re-planning, each of which will be further decomposed as more fine-grained behaviors. Above listed ontology concepts are all universal to any service domains, but concrete semantics in various specific service domains are not included. When such ontology is applied to a given domain, it should be further refined and extended for more elaborated semantics.


375

Fig. 3. A screen snapshot of service behavior definition based on OWL-S

4 Interoperability-oriented Unified Service Component Model In this section we import the concept “Service Component (SC)” to facilitate encapsulation of heterogeneous service elements with uniform structure and semantics representations. Inner descriptions and functions are exposed by interfaces and their semantics are represented by the service ontology discussed in Section 3. 4.1 Classification of Service Components

A service component (SC) is defined as a reusable service element. Any service elements could be mapped to service components, which are correspondingly classified into the following types: x

x

People-ware SC (PSC): a people with some professional skills to provide behaviors to others during service execution, e.g., an IT consultant who has ten-year’s experience on cement manufacturing industry and could provide consulting services to such kinds of enterprises; Resource SC (RSC): a resource with specific capabilities to provide specific behaviors, including

376


-

-

-

x x

Software SC (SSC): a software entity with specific computation capabilities to provide specific services behaviors, e.g., a web services with WSDL-based interfaces, a SCA component, a database, an encapsulated legacy system, etc, to offer web-based service behaviors; Hardware SC (HSC): a hardware or physical equipment with specific capabilities, e.g., a machine for manufacturing, a computer server for residing software, an instrument for measuring and checking, a GPS for indicating directions, a telephone for communicating with customers, etc. Environment SC (ESC): a location with specific facilities as a container where service behaviors will take place, e.g., a meeting room with a council board, ten chairs, one projector and one whiteboard for Joint Application Design (JAD), a call center with 120 seats and 250line SPC telephones for providing help to customers, etc.

Behavior SC (BSC): processes, activities or actions that a person could behave to accomplish a service task, e.g., consulting, training, manipulating a machine, using a software system, reporting unanticipated problems, etc. Information SC (ISC): a physical or electronic information entity that is exchanged and shared among software systems, people, etc, e.g., a sales order, a log of call center, an ESA design document, a service manual for guidance, etc.

4.2 Architecture of Service Component

Similar to the architecture of a software component, service component is also designed as a black-box, i.e., interfaces are exclusive channels that service component communicates with external environment or other service components. There are two types of interfaces, i.e., Providing Interface and Required Interface, the former of which specifies the channel by which other components access its basic profiles and functions (behaviors, capabilities), and the latter specifies the functions/ information/resources/behaviors it requires from environment or other components, as shown in Fig. 4. Required Interface

Providing Interface Service Component

Fig. 4. Brief structure of a service component

For each type of service components, we’ve designed a set of specific interfaces listed in Table 2.


377

Table 2. Interfaces of service components SC type

PSC

Interface Type

Providing

Required Providing

BSC Required

Providing RSC

Required

ISC

Providing Required

Interface Name Profile ProvidingBehavior ProvidingCapability QueryFeasibleDate ReserveBehavior CancelReservation (None) Profile BehaviorDescription BehaviorInteraction RequiredResource RequiredCapability RequiredBehavior ImpactedResource ImpactedPeople InputInformation OutputInformation Profile ProvidingCapability ProvidingBehavior QuerySchedule ReserveResource CancelReservation RequiredResource RequiredBehavior RequiredCapability Profile CreateInfoEntity QueryInfoEntity (None)

Cardinality 1 n n 1 1 1 1 1 1 n n n n n 1 1 1 n n 1 1 1 n n n 1 1 1

5 SC Composition Based Service System Interoperability Solutions When specific service requirements are jointly confirmed by service providers and customers, service components will be selected from repository and composed together to get the corresponding service system. During service system development, the service component model presented in section 4 can effectively support interoperability in service system development, where x x x

Domain-specific service ontology is imported for solving semantics conflicts; Unified interfaces are designed for identifying function mismatch; SLA ontology is imported for solving SLA mismatch;

378


The process of interoperability-oriented service component composition includes the following steps: Step 1: Specify service requirements and SLA according to the negotiation results between service providers and customers; Step 2: Aiming at each service requirement, express it as the form of service ontology; Step 3: Find BSCs that match with the requirements by querying each BSC’s Profile interfaces; Step 4: For each selected BSC, query its RequiredResource, RequiredCapability, RequiredBehavior, InputInformation and OutputInformation interfaces to find what kinds of resources, capabilities, behaviors and information elements it requires; Step 5: For each service elements found in Step 4, query the responding SCs from repository by interface semantics matching; Step 6: Recursively query SCs from repository until there are no other SCs required; Step 7: For the function and semantics mismatch between SCs, design adaptors between them to eliminate the gaps; Step 8: Compose all selected SCs together.

PSC1

PSC2

ProvidingBehavior

ProvidingCapability

ProvidingBehavior

ProvidingCapability

Behavior Description

RequiredCapability

Behavior Description

RequiredCapability

Profile ISC1

BehaviorInteraction InputInformation

ISC2 Profile

BSC1

Required Resource

OutputInformation

InputInformation OutputInformation Profile Required Required Resource Capability

BSC2

ISC4 Profile Required Capability

ISC3 Profile

ProvidingCapability

Profile

SSC1

ProvidingCapability HSC1 RequiredResource

RequiredResource ESC1 Profile

Profile

Fig. 5. A simple example of service component composition

6 Conclusions Service system is the fundamental infrastructure that ensures service right and efficiently executed to co-produce and share values between service providers and customers by exerting individual competitive advantages. It is a kind of complex socio-technological system composed of various heterogeneous service elements, and whether the interoperability channels between them would keep smooth or not will impact service execution quality and efficiency to a large extent. In this paper, we carefully analyze basic service elements in service system and the possible


379

interoperability scenarios, and then construct typical service ontology defined by OWL and Protégé. To support interoperability, service elements are defined as service components with unified interfaces, where their semantics are represented by service ontology. Due to limited spaces, some technical details are not included in this paper. And concerning the key issue of how to find proper SCs by semantics matching during service component composition, it is a quite big topic and we will discuss in other papers.

Acknowledgement Research works in this paper are partial supported by the National Natural Science Foundation (NSF) of China (60673025), the National High-Tech Research and Development Plan of China (2006AA01Z167, 2006AA04Z165) and the Development Program for Outstanding Young Teachers in Harbin Institute of Technology (HITQNJS.2007.033)

References [1]

B. Elvesæter, A. Hahn, A.-J. Berre, and T. Neple. Towards an interoperability framework for model-driven development of software systems. The 2nd International Conference on Interoperability of Enterprise Software and Applications. Springer London, 2006, 409-420. [2] D.E. Cox and H. Kreger. Management of the service-oriented architecture life cycle. IBM Systems Journal, 2005, 44(4): 709-726. [3] G. Vetere and M. Lenzerini. Models for semantic interoperability in service-oriented architectures. IBM Systems Journal, 2005, 44(4): 887-903. [4] H. Cai. A two steps method for analyzing dependency of business services on it services within a Service Life Cycle. ICWS'06. 877-884. [5] H. Chesbrough and J. Spohrer. A research manifesto for services science. Communications of the ACM, 2006, 49(7): 35-39. Service Sciences, Management and Engineering (SSME). [6] IBM. http://www.research.ibm. com/SSME [7] J. Spohrer, P. Maglio, J. Bailey, and D. Gruhl. Steps towards a Science of Service Systems. IEEE Computer, 2007, 40(1):71-77. [8] J.M. Tien and D. Berg. Towards Service Systems Engineering. IEEE International Conference on Systems, Man and Cybernetics, 2003, 5(5): 4890-4895. [9] Q.G. Liu, J. Zhou, and J.Y. Li. Catastrophe modeling for service system in the networked environment. 2006 Asia Pacific Symposium on Service Science, Management and Engineering. Nov. 30-Dec. 1, 2006, Beijing, China. [10] R. Karni and M. Kaner. An engineering tool for the conceptual design of service systems. Springer Berlin Heidelberg. Advances in Services Innovations. 2000, 65-83. [11] R.D. Mascio. Service process control: a method to compare dynamic robustness of alternative service processes. Journal of Process Control. 2003, 13(7): 645-653. [12] R.X. Yuan and X. Zhang. Spatial characteristics of agent behavior in small world networks. 2006 Asia Pacific Symposium on Service Science, Management and Engineering. Nov. 30-Dec. 1, 2006, Beijing, China.

380


[13] Stanford Medical Informatics. The Protégé ontology editor and knowledge acquisition system. http://protege.stanford.edu/ [14] The OWL Services Coalition. OWL-S: Semantic Markup for Web Services. http://www.daml. org/services/owl-s/1.0/owl-s.html [15] W.B. Rouse and M.L. Baba. Enterprise transformation. Communications of the ACM, 2006, 49(7): 66-72. [16] W.-F. Tung and S.-T. Yuan. iDesign: an intelligent design framework for service innovation. Proceedings of 40th Hawaii International Conference on System Sciences (HICSS 40), Hawaii, USA. January 3-6, 2007. 64-73. [17] W3C. OWL Web Ontology Language Overview. http://www.w3.org/TR/owlfeatures/ [18] Wikipedia. http://www.wikipedia.org/wiki/services

Supporting Adaptive Enterprise Collaboration through Semantic Knowledge Services Keith Popplewell1, Nenad Stojanovic2, Andreas Abecker2, Dimitris Apostolou3, Gregoris Mentzas3, Jenny Harding4 1

2

3

4

Coventry University, Priory Street, Coventry CV1 5FB, United Kingdom [email protected] Forschungszentrum Informatik, Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe, Germany {nstojano, abecker}@fzi.de Institute of Communication and Computer Systems, 157 80 Athens, Greece {gmentzas, dapost}@mail.ntua.gr Loughborough University, Loughborough, Leicestershire, LE11 3TU, United Kingdom [email protected]

Abstract. The next phase of enterprise interoperability will address the sharing of knowledge within a Virtual Organisation (VO) to the mutual benefit of all VO partners. Such knowledge will be a driver for new enhanced collaborative enterprises, able to achieve the global visions of enterprise interoperability. This paper outlines the approach to be followed in the SYNERGY research project which envisages the delivery of Collaboration Knowledge services through interoperability service utilities (ISUs): trusted third parties offering web-based, pay-on-use services. The aim of SYNERGY is to enhance support of the networked enterprise in the successful, timely creation of, and participation in, collaborative VOs by providing an infrastructure and services to discover, capture, deliver and apply knowledge relevant to collaboration creation and operation. The proposed approach aims to (a) provide semantic ontology-based modelling of knowledge structures on collaborative working; (b) develop a service-oriented self-adaptive solution for knowledgebased collaboration services; and (c) facilitate the testing and evaluation of the efficiency and effectiveness of the solution in concrete case studies. Keywords: enterprise interoperability, semantic web, knowledge services, knowledge management, trust, virtual organisation.

1 Introduction In a recent roadmap of the European Commission (Enterprise Interoperability Research Roadmap – EIRR hereafter, [5]) four challenges were identified as

382

K. Popplewell, N. Stojanovic, A. Abecker, D. Apostolou, G. Mentzas, J. Harding

strategic directions of research in the area of Enterprise Interoperability: (i) interoperability service utility; (ii) web technologies for enterprise interoperability; (iii) knowledge-oriented collaboration; and (iv) a science base for enterprise interoperability. Here, we discuss the development of the necessary technological infrastructure for supporting the third grand challenge, i.e. the next phase of development of deeper functionality of enterprise interoperability that will allow the sharing of knowledge within virtual organizations (VOs) to the mutual benefit of the VO partners. Such research will help mitigate two primary needs of enterprises in successfully forming and exploiting VOs: rapid and reliable formation of collaborative consortia to exploit product opportunities; and application of enterprise and VO knowledge in operational and strategic decisionmaking, thereby leading to enhanced competitiveness and profitability. In this paper, we claim that research on semantic web services [12] [19] has the potential to facilitate the satisfaction of these needs and provide the underlying technological infrastructure for supporting adaptive enterprise collaboration through semantic knowledge services [14]. Specifically, we outline the major objectives and architectural directions of a multi-national research project (SYNERGY), which aims to enhance support for the successful and timely creation of, and participation in, collaborative virtual organizations by providing an infrastructure and services to discover, capture, deliver and apply knowledge relevant to collaboration creation and operation. Section 2 outlines the motivation of this research, while section 3 gives the overall objectives and conceptual architecture of the SYNERGY infrastructure – it focuses on three categories of knowledge services to be developed: moderator services; collaboration pattern services; and knowledge evolution services. Section 4 discusses related work, while the final section 5 presents the main conclusions and further work.

2 Motivation The last decades show a clear trend in business – away from big, comprehensive trusts which can cover all stages of a value creation chain, and away from long standing, well-established and stable supply chains; instead, companies increasingly focus on their core business competencies and often enter into flexible alliances for value creation and production. For example, in the automotive industry the market speed demands flexible configuration and re-configuration of supply-chains, in typical “knowledge-oriented businesses” (like management consulting and software engineering) more and more freelancers and small specialized companies form project-specific coalitions for customer-specific products or services, while in life sciences and biotech technological progress comes from research-based companies in co-opetitive relationships which require flexible and ad-hoc co-operations. This growing demand for flexibly interactive and efficiently integrated businesses and services has already led to a huge amount of scientific and technological research in enterprise interoperability. Although such research has achieved already promising results and partially led to first commercial products

Supporting Adaptive Enterprise Collaboration through Semantic Knowledge Services

383

and service offerings, as well as operational, deployed applications, these remain nevertheless at the level of data interoperability and information exchange; they hardly reach the level of knowledge integration, and certainly fall short of knowledge-based collaboration. Seen from the business-process perspective, today’s approaches to business interoperability mainly address support processes (for instance, how to manage ordering and buying a given product), but they hardly support the companies’ core processes (e.g., finding a decision about what product to buy) with the companies’ core knowledge assets in the centre of value creation and competitive advantage. If we rely on typical definitions of the term “knowledge” as widely accepted in the Knowledge Management area [13], some of the key characteristics of knowledge are that it is highly context-dependent, interlinked with other pieces of knowledge, action-oriented, and often either bound to people or expressed in complex, often logic-based, knowledge representation formalisms. This shows that today’s business interoperability approaches usually address the level of information and application data, but clearly fail to achieve the “knowledge level”. This situation is sketched in Figure 1. Knowledge subject to uncontrolled sharing

Enterprise N Enterprise 3

Knowledge which SHOULD be shared but rarely is • Organisation knowledge assets • Policy • Strategy

Enterprise 2

Enterprise 1

Legacy Systems

Data Interoperability

Legacy Systems

(eg. ERP, CAD, etc)

Process Interoperability

(eg. ERP, CAD, etc)

• Etc.

Knowledge which MUST NOT be shared but often is

Isolated, ad hoc, interpersonal communications

Misunderstanding; Core IPR confidentiality lost

• Core IPR • Competing projects • etc.

Lost opportunities to learn and adapt from past collaborations

Missed Collaboration Opportunities

The Collaborating Partner The Virtual Organisation

Fig. 1. Current Forms of Knowledge-Oriented Collaboration

Some of the identified shortcomings of the current situation are as follows: Existing solutions for automated business interoperability address data interoperability for (more or less hard-coded) support of business processes as implemented, e.g., in ERP systems. All forms of “higher-level” interoperation in

384


knowledge-intensive processes ([1], [18]) usually take place in the form of isolated, selective, informal person-to-person contacts, such as e-mails, meetings, telephone conversations, etc. If the business partners do not know each other already and do not have deep insights in the other company’s internal affairs, they can not be aware of their partner’s internal rules, regulations, experiences, core knowledge assets, etc. which easily lead to misunderstandings, wrong estimations, etc. Even worse, “uncontrolled” and unsystematic collaboration about complex issues may not only be subject to inefficiencies, misunderstandings, or wrong decisions because of missing knowledge about the business partner; it is also exposed to the risk of unaware, accidental disclosure of corporate secrets and all kinds of confidential information. Furthermore, unmanaged knowledge exchange can not only cause direct problems such as inefficiency, mistakes, or confidentiality problems; there are also indirect problems which stem from the fact that a systematic assessment of new opportunities, a continuous collaboration-process improvement, etc. can only happen if there is some level of formality and documentation as its basis. Modular, Ontology Based Knowledge Knowledge shared with controls & understood risks • Organisation knowledge assets • Policy • Strategy • Etc.

ISU Services

Enterprise 3 Enterprise 2

Information and Process Interoperability Services Enhanced VO Collaboration

Collaboration Patterns

Common Understanding

VO Opportunity & Decision Conflict Identification & Resolution

Moderator Services The Learning VO

Learning Services

New Knowledge The Learning Enterprise

Collaboration structured for enhanced support of VO

Partner KM Services

Knowledge Sharing and Security

Protected knowledge • Core IPR • Competing projects • etc.

Enterprise N

Enterprise 1

Learning Loop

Collaboration Registry Services

Publishing Capabilities Searching for Contributions

The Collaborating Partner The Virtual Organisation

Fig. 2. SYNERGY Vision of Knowledge-Oriented Collaboration

Figure 2 illustrates the overall idea of the SYNERGY project in terms of the TO-BE situation which will be enabled by the SYNERGY project results. In this TO-BE situation, a Web-based and service oriented software infrastructure will help all kinds of companies which need to engage in collaborative businesses, to


385

discover, capture, deliver and apply knowledge relevant to collaboration creation and operation thus helping them to effectively and efficiently participate in Virtual Organizations (VOs) whilst avoiding the above mentioned shortcomings and problems. The next section outlines in more detail the objectives and conceptual architecture of our approach.

3 The SYNERGY Approach 3.1 Objectives

Following the vision and approach of the IST Enterprise Interoperability Research Roadmap (EIRR, [5]), the SYNERGY architecture takes up and refines the challenge of the Interoperability Service Utility (ISU), i.e. of an open, serviceoriented platform which allows companies to use an independently offered, intelligent infrastructure support to help planning, setting-up, and running complex knowledge-based collaboration. The ISU services to be investigated, designed, prototypically implemented and tested in the SYNERGY project can be organized in three groups: x

x

x

basic collaboration support, including: collaboration registry services that allow publication of and search for capabilities; and information and process interoperability services that may include, e.g., data mediation at the message level, protocol mediation at the service orchestration level, process mediation at the business level, etc. [19]: enhanced collaboration support, including: partner-knowledge management services: services helping a company that wants to enter the collaboration space, to efficiently build up and manage a knowledge base of collaboration-oriented internal knowledge, together with sharing and exchange services which guarantee adequate treatment of confidentiality concerns etc.; collaboration pattern services: as a means to use and reuse proven, useful, experience-based ways of doing and organizing communication and collaboration activities in specific collaborative tasks; and moderator services: which implement the role of a trusted third party helping to establish and run a specific collaborative engagement, to employ collaboration patterns, to mediate conflicts and communication problems, to implement intelligent services at partner site such as opportunity detection, etc; collaboration evolution support, i.e. learning services which continuously accompany and evaluate ongoing activities in order to realize a continuous improvement of knowledge residing both in the central services (such as the collaboration patterns) and at the partner sites (partner-specific collaboration knowledge).

The overall aim of SYNERGY is to enhance support of the networked enterprise in the successful, timely creation of and participation in collaborative

386


VOs by providing an infrastructure and services to discover, capture, deliver and apply knowledge relevant to collaboration creation and operation. The infrastructure must facilitate the sharing of knowledge within an enterprise, between potential and actual VO partner enterprises, and across industrial sectors, whilst allowing, and indeed actively promoting, the protection of individual and shared commercial interests in operating knowledge and expertise and intellectual property rights (IPR). Note that whilst the results of this research are aimed at providing services which could be integrated into the offerings of an ISU, it is not the intention to duplicate research, carried out elsewhere, into the policy, strategy, delivery and operation of ISUs in general. Rather our research effort aims to define the way in which ISUs in general can provide the essential infrastructure for knowledgeoriented collaboration.

3.2 Conceptual Architecture SYNERGY supports collection and preservation of individual enterprise knowledge about inter-organizational collaboration and its secure integration and harmonization within the existing knowledge landscape of a networked enterprise, stored globally in the ISU or locally at the enterprise level. Through collaboration-knowledge services, SYNERGY provides an active platform for efficient maintenance of and access to shared and individual knowledge, and moderation of inter-organizational collaboration, including the ability to continually learn from experience. In this section, we present in detail how we plan to realize this idea. Figure 3 presents an overview of the SYNERGY conceptual architecture. ISU Services

Partner KM Services

Moderator Services Learning Services Collaboration Registry Services

Access to ALL Knowledge Repositories through ISU Services

Collaboration Patterns

Application

Enterprise IPR Collaboration Experience etc..

ISU Knowledge Registry Moderator Knowledge Industry Knowledge Collaboration Capabilities Collaboration Patterns etc..

Distributed Knowledge Repositories

ISU Service Information and Process Interoperability Services

Networked Enterprise

Local Repositories

Repositories at ISU

Fig. 3. Overview of SYNERGY Conceptual Architecture: distributed knowledge repositories, residing locally in an enterprise or globally in the ISU (right-hand side), which


387

can both be maintained and accessed through collaboration-knowledge ISU services (lefthand side)

Each network will develop, through its lifetime, project-specific knowledge. This is in part knowledge specific to the network’s product or service, and to the processes and technologies involved, but it is also related to the current state of the network in its life-cycle. In most cases, such knowledge needs to be maintained only for the network and its partners because it is of no use, and possibly even very confusing, outside that context. Nevertheless, there may be a need to analyse such knowledge and its evolution to provide improved patterns for the future, thus forming a basis for organisational learning. Such collaboration patterns may then enter the public domain to support future collaborations across, say, an industrial sector, but there will be (perhaps most) cases where it is precisely this knowledge which represents competitive advantage to the network or partners concerned, so there is a need to identify where this is the case, and how services might deliver new learning to a specified and appropriate audience of future users – perhaps only partners in the network generating this new knowledge. Within SYNERGY we aim to deliver a Collaboration Knowledge Services Framework (CKSF), a structural framework for knowledge repositories and collaboration services defining mechanisms to manage correct sharing and protection of knowledge. In order to effectively share information and knowledge, it is essential to know when sharing is advantageous: the CKSF will embody knowledge to provide this capability. The maintenance of a library of appropriate collaboration patterns, available as process and service templates to be specialised as necessary and applied to network enterprises either as they form or as they subsequently evolve, is central to the support of partner collaboration in a VO. The CKSF will therefore embody structures and services to define collaboration pattern templates and to select (according to the nature of a developing or existing/changing network), specialise and apply such templates. It is envisaged that the distribution of repository knowledge will reflect its commercial sensitivity, so that at one extreme the most sensitive, perhaps enterprise core competence, would reside within the enterprise’s own systems, whilst at the other extreme a set of collaboration patterns applicable to different scenarios common across an industrial sector would reside in the service provider’s repository. Between these extremes, services may deposit or access knowledge from the service provider or from other partners, but the significant issues relate to the control of access regardless of the location of knowledge. Enterprise knowledge relevant to the formation and operation of collaborative ventures will include, though not necessarily be limited to, (i) Enterprise Core Competence, (ii) Process knowledge for VO Formation, (iii) Process knowledge for partner selection, (iv) VO Operations Management Knowledge. The architecture will be mainly based on the development of a number of ISU services for collaboration: moderator services, pattern services and knowledge evolution services. They are examined in more detail in the following sections.

388


3.2.2 Collaboration Moderator Services A critical aspect of effective knowledge sharing within VOs is the identification of the most appropriate knowledge for reuse or exploitation in a particular context combined with the most efficient tools and mechanisms for its identification, sharing or transfer. Knowledge has a life-cycle and therefore, to maintain its value it must evolve through ongoing maintenance and update. These issues are addressed through the identification of appropriate knowledge sources and the concept of a Collaboration Knowledge Model to support knowledge-sharing activities. However, these elements on their own are insufficient to actively support knowledge sharing and interactions between collaborating partners in the VO. Partners also need to be aware of when knowledge needs to be shared, the implications of doing so and when their decisions are likely to affect other partners within the collaboration. Therefore tools and methods are needed to support identification, acquisition, maintenance and evolution of knowledge and to support knowledge sharing through the raising of awareness of possible consequences of actions and other partner's needs during collaboration. SYNERGY addresses these issues, by exploiting the identified sources of collaboration knowledge in the design of a Collaboration Moderator to raise awareness of needs, possible consequences and likely outcomes in collaboration activities between the partners of the VO. Collaboration Moderation Services comprise the process of identifying key knowledge objects and processes as well as understanding their relevance in context and their relationships. We will exploit previous research work [8] [11[11]] and will also identify innovative knowledge acquisition approaches to extend existing moderator functionalities to enable improved collaboration support through ongoing knowledge updating and maintenance. 3.2.3 Collaboration Pattern Services The collaboration-computing experience is currently dominated by tools (e.g. groupware) and the boundaries they introduce to collaboration processes. As new integration methods (e.g. Web Services) enable users to work more seamlessly across tool boundaries and to mix and match services opportunistically as collaboration progresses, a new organisational model becomes desirable. The challenge is not simply to make integration easier, but also to support the users deal with a multiple of collaboration-related information, tools and services. By adopting collaboration patterns as the organizational model of collaboration, users will work in a more complete context for their actions and be burdened by fewer manual integration tasks. At the same time, by dividing collaborative work into distinct collaboration activities, users can focus more readily on a particular activity and deal more easily with interruptions by suspending and resuming activities as needed. Collaboration patterns augment rather than replace collaboration services and tools. Through reference-based integration methods, collaboration patterns introduce new views and organizational schemes that cut across service and tool boundaries, thereby increasing the integrity of the representation of work and mitigating scatter.


389

SYNERGY will assess the appropriate level of pattern granularity (abstraction) and represent collaboration patterns using ontologies. We will then develop the Collaboration Patterns Editor, a software component for defining collaboration patterns. The editor will represent collaboration patterns as a collection of relationships that emerge between people, the resources they use, and the artefacts they work on, as well as the communication, coordination, and business processes that are used to complete their work. Collaboration patterns will link to services that are already exposed by collaborative tools, such as workflow tools, word processing, wikis, etc. We envisage three ways for generating collaboration patterns: manually, from best practice data; semi-automatically, by detecting prominent usage patterns using folksonomy techniques (e.g. users typically tend to send an email to all other users asking their feedback when a meeting agenda is sent out); and by community members themselves, either from scratch or as refinements of existing patters. A collaboration pattern created with the editor can be used as a template that guides the informal collaborative process without constraining it. We will also develop a simulator that takes as input information about on-going collaborations taking place and being recorded in a collaboration-pattern knowledge base. The simulator will focus on visualizing collaborative networks as well as transactions inside them. 3.2.5 Knowledge Evolution Services One of the unique features of the SYNERGY approach is based on the idea that an explicit management of knowledge-based collaborative work opens up completely new possibilities regarding (semi-) automatic verifying, evolving, and continuously improving the collaboration-knowledge bases. We aim at a comprehensive management of all dynamic aspects in the proposed knowledge bases, including: (i) automated searching for inconsistencies and problems; (ii) automated recommendation of possible new collaboration opportunities; (iii) propagation of evolutionary changes in the collaboration environment toward dependent artefacts in the codified information space; or (iv) implementing means for self-adaptive collaboration that will enable learning from experience and continuously adapt collaboration patterns and their usage preconditions. Altogether, this will lead to a further development of the concept of the learning organization toward a “learning virtual organization” or, better, a “learning business ecosystem”. Methodologically, we intend to extend ideas and approaches of the Learning Software Organization [9].

4 Related Work The European Commission’s EIRR [5] identifies the state of the art of a number of research areas relevant to enterprise interoperability in general and to SYNERGY in particular. For example, the EIRR recognises ontology definition as necessary to the sharing of knowledge, almost by definition – Gruber [7] defines a domain ontology as “a formal, explicit specification of a shared conceptualisation”.

390


Similarly, the EIRR anticipates that delivery of enterprise interoperability capabilities will be achieved through Interoperability Service Utilities (ISUs) providing services to clients, possibly on a pay-per-use business model making them affordable to SMEs. SYNERGY aims to define collaboration knowledge services [14] explicitly to be delivered as services in this way. Specifically, two of the main innovations of SYNERGY include: (i) a reference architecture for an interorganisational knowledge-sharing system, based on knowledge services; and (ii) the formal representation of meta-knowledge for network enterprise collaboration, as well as for risk assessment, propagation and evaluation in networked enterprise collaborations. Concerning moderator services, a lot of research has been reported since the early work of Gaines et al. [6]. Although recent efforts promote the research agenda in this field (e.g. [10], [20], [23]), none of them have addressed interoperability and semantic heterogeneity issues. In SYNERGY, we will provide reference ontologies and example knowledge bases for Collaboration Moderator Services and design and develop a prototype implementation of semantic Collaboration Moderator Services. Collaboration between partners in a VO from a wide variety of domains will result in the need to share knowledge from varied sources, with different data types, file formats and software tools. To cope with this, [16] proposed an ontology-based approach to enable semantic interoperability. The case study proves the effectiveness of ontologies in collaborative product development to support the product-data exchange and information sharing. However, for interoperability to be achieved effectively, it is essential that the semantic definitions of the knowledge objects, processes, contexts and relationships are defined based on mathematically rigorous ontological foundations [11]. Much current work utilises the Web Ontology Language (OWL) for the representation of semantic objects, but this has a very limited capability in terms of process definition. Similarly, the Process Specification language (PSL) has a strong process representation capability, but is weak in its representation of objects. Researchers are therefore increasingly identifying the need for heavyweight ontologies and improved knowledge formalisms [3, 22]. Within SYNERGY, we will develop a blueprint (requirements, language, system architecture, runtime experience) for a knowledge representation and reasoning solution dedicated to knowledge-based collaboration support, as well as a prototype implementation dedicated to knowledge-based collaboration-support requirements. Patterns and pattern languages are becoming increasingly important in various areas such as community informatics [2], activity management [15] and workflow management [21]. A pattern formalizes the structure and content of an activity and the integration methods it depends on, thereby making it reusable as a template in future activities. Collaboration patterns can be regarded as abstractions of classes of similar cases and thus describes a kind of best practices for the execution of specific collaboration activities. Collaboration patterns are useful because they may be used to suggest possible tasks to the users, they can provide information about dependencies between tasks, provide insight about the roles that are required, the resources needed, etc. By sharing collaboration patterns, users can ‘‘socialize’’ best practices and reusable processes. Recently, [4] provided a categorization of


391

collaboration patterns, while [17] presents a first collaboration-patterns ontology. However, to our knowledge there exist no software tools that exploit collaboration patterns as a means to support collaboration in real-time. In SYNERGY, we intend to develop a collaboration pattern-based system that gathers and manipulates many types of content without relying on their native applications. Specifically, we will develop: (i) a reference ontology for collaboration-pattern representation; (ii) methods and service-based tools for collaboration-pattern management and use; and (iii) novel methods of collaborative work and knowledge-task management based on collaboration-patterns support and awareness mechanisms. The ATHENA European FP6 integrated research project considered aspects of enterprise models for interoperability and model driven interoperability. ATHENA focused on application interoperability and on the necessary ontological and semantic requirements to support interoperability of enterprise information. Reports of results and pilot implementations can be accessed through the ATHENA web site [24].

5 Conclusions In this paper we outlined the major objectives of the SYNERGY project, which aims to enhance support for the successful and timely creation of, and participation in, collaborative virtual organisations. Moreover, we presented the architectural directions for a software infrastructure and services supporting collaborative virtual organisations to discover, capture, deliver and apply knowledge relevant to collaboration creation and operation. SYNERGY is expected to benefit collaborating organisations in many ways. As a "learning organisation" a collaborating partner is better able to exploit past experience in responding to future opportunities and in particular to opportunities for participation in collaborative networks. Improved risk assessment may enable collaborating partners to participate in more networks than previously seemed safe, whilst minimising exposure to survival-critical risk. Enhanced sharing of knowledge, with dynamic access control and security accelerates and improves network decision making, shortens time to market and reduces network operating costs, whilst improved capture and especially re-use of enterprise and network knowledge reduces the cost of repeating work of earlier projects, and of repeating past errors. Improved, risk-aware decision making reduces the costs of wrong decisions, and failed collaborations. The SYNERGY software infrastructure will be extensively evaluated against the sophisticated collaborations which arise in the pharmaceutical industry and the engineering domain. The participation in the project of collaborating organisations from more than one industrial sector will enable the evaluation of different aspects of collaboration and, at the same time, will ensure that SYNERGY is generic and not sector-specific.

392



[4]

[5] [6]

[7] [8]

[9] [10] [11]

[12] [13]

[14] [15]

[16]

[17] [18]

[19]

Abecker A.: Business Process Oriented Knowledge Management – Concepts, Methods and Tools. Phd Thesis, University of Karlsruhe (2003) Chai, C.S., Khine, M.S.:. An Analysis of Interaction and Participation Patterns in Online Community. Education Technology & Society, 9(1):250-261 (2006) Cutting-Decelle, A.-F., Young, B.I., Das, B.P., Case K., et al: A Review of Approaches to Supply Chain Communications: From Manufacturing to Construction. Itcon, vol. 12, pp 73-102 (2007) den Hengst, M., Adkins, M.: Which Collaboration Patterns are Most Challenging: A Global Survey of Facilitators. In: Proc. 40th Hawaii Int. Conf. on System Sciences (2007) European Commission: Enterprise Interoperability: A Concerted Research Roadmap for Shaping Business Networking in the Knowledge-based Economy (2006) Gaines, B.R., Norrie, D.H., Lapsley, A.Z.: Mediator: An Intelligent Information System Supporting the Virtual Manufacturing Enterprise. In: Proc. 1995 IEEE Int. Conf. on Systems, Man and Cybernetics, pp. 964-969 (1995) Gruber, T.R.: Towards Principles for the Design of Ontologies used for Knowledge Sharing. Int. J. of Human-Computer Studies, vol. 43, pp.907-928 (1993) Harding, J.A., Popplewell, K.: Driving Concurrency in a Distributed Concurrent Engineering Project Team: A Specification for an Engineering Moderator. Int. J. of Production Research, 34(3):841-861 (1996) Henninger, S. Maurer, F.: Advances in Learning Software Organizations: 4th Int. Workshop (LSO 2002). Springer, Heidelberg, 2002. Huang, G. Q.: Web Based Support For Collaborative Product Design Review. Int. J. of Computers in Industry, 48(1):71-88 (2002) Lin, H.K., Harding, J.A.: A Manufacturing System Engineering Web Ontology Model on the Semantic Web for Inter-Enterprise Collaboration. Int. J. of Computers in Industry, 58(5):428-437 (2007) Martin, D., Domingue, J.: Semantic Web Services, Part 1. IEEE Intelligent Systems, September/October, pp. 12-17 (2007) Mentzas, G., Apostolou. D., Abecker, A., Young, R.: Knowledge Asset Networking: A Holistic Approach for Leveraging Corporate Knowledge”, Springer, Heidelberg (2002) Mentzas G., Kafentzis, K., Georgolios, G.: Knowledge Services on the Semantic Web. Comm. of the ACM, 50(10):53-58 (2007) Moody, P., Gruen, D., Muller, M.J., Tang, J., Moran T.P.: Business Activity Patterns: A New Model for Collaborative Business Applications. IBM Systems Journal 45(4):683–694 (2006) Mostefai, S., Bouras, A., Batouche, M.: Effective Collaboration in Product Development via a Common Sharable Ontology. Int. J. of Computational Intelligence, 2(4):206-216 (2005) Pattberg, J., Fluegge, M.: Towards an Ontology of Collaboration Patterns. In: Proceedings of Challenges in Collaborative Engineering 07 (2007) Remus, U.: Integrierte Prozess- und Kommunikationsmodellierung zur Verbesserung von wissensintensiven Geschäftsprozessen. In: Abecker, A., Hinkelmann, K., Maus, H., Müller, H.-J. (eds): Geschäftsprozessorientiertes Wissensmanagement, pp. 91-122. Springer, Heidelberg (2002). In German. Studer, R., Grimm, S., Abecker, A.: Semantic Web Services. Concepts, Technologies, and Applications. Springer, Heidelberg (2007)


[20]

[21] [22]

[23]

[24]

393

Ulieru, M., Norrie, D., Kremer, R., Shen, W.,: A Multi-Resolution Collaborative Architecture for Web-Centric Global Manufacturing. Information Sciences 127, 3-21 (2000) van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.P.: Workflow Patterns. Distributed and Parallel Databases, 14(3):5-51 (2003) Young, R.I.M., Gunendran, A.G., Cutting-Decelle, A.-F., Gruninger, M.: Manufacturing Knowledge Sharing in PLM: A Progression Towards the Use of Heavy Weight Ontologies. Int. J. of Production Research, 45(7):1506-1619 (2007) Zhou, L., Nagi, R.: Design of Distributed Information Systems for Agile Manufacturing Virtual Enterprises Using CORBA and STEP Standards. J. of Manufacturing Systems, 2(1):14-31 (2002) ATHENA Project Public Website: http://www.athena-ip.org/

Part V

Interoperability in Systems Engineering

Semantic Web Framework for Rule-Based Generation of Knowledge and Simulation of Manufacturing Systems Markus Rabe, Pavel Gocev Fraunhofer Institut Produktionsanlagen und Konstruktionstechnik (IPK) Pascalstrasse 8-9, 10587 Berlin, Germany {markus.rabe, pavel.gocev}@ipk.fraunhofer.de

Abstract. The development of new products and manufacturing systems is usually performed in the form of projects. Frequently, the conduction of the project takes more time than planned due to inconsistency, incompleteness, and redundancy of data, which delays other project activities influencing the start of production (SOP). This paper proposes a semantic Web framework for cooperation and interoperability within product design and manufacturing engineering projects. Data and knowledge within the manufacturing domain are modelled within ontologies applying rule-based mapping. The framework facilitates the generation of new knowledge through rule based inference that enriches the ontology. This enables a high-level model completeness in the early phase of product design and manufacturing system development, which is a basic prerequisite for the realisation of a proper simulation study and analysis. The simulation results can be integrated into the ontologies as a knowledge that additionally extends the ontology. Keywords: Semantic Web, Product Design, Manufacturing, Ontology, Knowledge Base, Rules, Inference, Modelling and Simulation.

1 Introduction The design and development of new products and manufacturing systems is usually considered as a project that involves numerous project members, who cooperate and exchange data and information. The design and development activities result in new findings and conclusions, which are knowledge applied to a particular situation. Usually, at the beginning of the project there are strategic decisions of the management about the new products that are documented as plain text or simple tables, describing the features of the products. Product designers deliver the first

398

Markus Rabe, Pavel Gocev

design and “look and feel” models of the new products. Simultaneously, technologists and production experts are involved in order to determine the required technologies for the production, to develop the manufacturing system and to estimate the product cost. Various concepts of the product and the manufacturing system are usually verified through discrete event simulation of the production and the logistics. The process of data and information exchange has a very important aspect of understanding of the meaning. In [27] the authors (Studer at al.) give an overview of the understanding process supported by the Meaning-Triangle, which describes the relations between symbols or words, thoughts and real objects. As the meaning of the words highly depends on the context, the environment and the personal view of the project partner, the authors conclude that the missing of a common understanding leads to misunderstandings, wrong communication, inadequate interoperability and limited reuse of data and information within various software systems. Most of the required data and information in the early project phase are informal and based on the experience from already existing products and manufacturing systems. Generally, the data and the information are taken from existing IT applications for Business Process Modelling (BPM), Enterprise Resource Planning (ERP), Product Data Management (PDM), Product Life Cycle Management (PLM), Computer Aided Process Planning (CAPP), Manufacturing Execution System (MES), and others. Usually, for the project purposes data are extracted as office applications in format of text, spreadsheet, project plans, presentation slides, etc. The authors’ experience proved the practice of using of different files in multiple IT applications with distinct structures and terminology, which causes inconsistency, redundancy, and incompleteness. Regular meetings of the project members govern the share and exchange of information, as well as the presentation of the achievements. The attendees of those meetings analyse, debate, reason and conclude in order to take decisions for their further project work. The different skills and abilities of the project members for knowledge perception, conclusion and context presentation are an additional reason for a possible extension of the project work, very often influencing the critical milestones of the project. The complexity grows when supply networks have to be analysed, developed and simulated where the data and project members belong to several enterprises with different cultures and procedures for data management. The complexity of cooperative project work can be reduced if project data and information are free of ambiguity and redundancy and presented in a format and structure that enables easy use by the project members. The explicit description and defined data structures facilitate the integration of various sources (data and information) and therewith the interoperability within the project. The necessary level of domain description can be achieved through classes which are organised as taxonomies with assigned individuals (instances) and defined relations between them in one model. These models are called ontologies and defined by Gruber [7] as an explicit, formal specification of a shared conceptualisation. Ontologies can be used to develop a knowledge base for one particular domain under consensus of the involved partners as a means to collect and structure the existing knowledge as well as the generation of new knowledge through reasoning.

Semantic Web Framework for Rule-Based Generation of Knowledge and Simulation

399

This paper gives an overview of existing technologies and approaches for ontology development to describe manufacturing systems. The focus is set on solutions that utilise the emerging semantic Web technologies (section 2.1), existing and emerging standards, and open standards for modelling of manufacturing systems (section 2.2). Section 3 summarises the challenges for development. Section 4 gives an overview of the framework proposed, that is based on semantic Web technologies and is utilised for the modelling of the manufacturing domain as well as for the generation of new knowledge.

2 Related Enabling Technologies and Developments 2.1 Semantic Web Technologies

Under the leadership of the World Wide Web Consortium (W3C) [12] new developments of technologies that are suitable for data modelling and management have been achieved. With the definition of the Extended Markup Language (XML) [13] a widely accepted base for the syntax of structured data was given. The modelling of the semantics was realised with the Resource Description Framework (RDF) [14] and Resource Description Framework Schema (RDFS) [15] which enable the description of the relations among the data objects as statements in the form of subject-predicate-object (triples). The statements described with RDF can be processed by computers, but RDF does not offer a concept to model similarities, distinctions, cardinalities, restrictions, intersections, unions, characteristics of properties and other functionalities that are needed for the explicit description of a domain. These features are offered by the Web Ontology Language (OWL) [16]. But, OWL does not support the modelling of logical rules in form of “If-Then”rules that are essential for reasoning and inference. The requirements for logical reasoning could be satisfied with the Semantic Web Rule Language (SWRL) [17] that is still in the proposal stage by the W3C. The rules can be expressed as OWL concepts (classes, properties and instances) which enable easy integration with OWL ontologies. The rules in terms of OWL syntax are axioms that comprise of an antecedent part (body) and consequent part (head) of the rule. Both consist of atoms built with variables, classes, properties, individuals or built-ins. If all antecedent atoms are true, then all consequent atoms will be true, too. Example: IF car has wheels AND ModelX isA car THEN ModelX has wheels.

The example shows how to extend the knowledge about the individual ModelX. The result of inference upon the rules is a new statement as a triple (ModelX-haswheels), which enriches the ontology and represents the newly generated knowledge.

400


2.2 Standards and Initiatives for Modelling of Manufacturing Systems

An essential prerequisite for the integration of information and knowledge from different project members is the deployment of a common data structure. Since the processes and operations of manufacturing companies are supported by various IT applications, very often there are data redundancies, structural differences and semantic distinctions. Most of the companies are striving to an integration of the business domain activities with production planning, scheduling, performance reporting, and other related processes. As a result of these attempts numerous standards, open standards and industrial initiatives have emerged or still are appearing. All objects and phases of the life cycle of manufacturing systems are considered by standards, but there is no complete one that covers all aspects. The list of most frequently applied standards for modelling and description of manufacturing systems entails ISA 95 (ISO 62264) [18], OAGIS [19], ISO 10303 (STEP) [20], MIMOSA [21], RosettaNet [22], PIDX [23], ISO 15926 [24], and ISO 18629 [25]. For the design, development and analysis of manufacturing systems, standards or open standards can be used. Very suitable are the models and data structures for manufacturing systems which are defined with the standard for vertical business to manufacturing integration ISA-95 Enterprise Control System Integration and with the open standard OAGIS. Main elements that are defined with the both standards are: x x x x

Hierarchy, functional and physical object models of manufacturing systems. Activity models for manufacturing operations management. Object Models and attributes for information exchange. Transactions between applications performing business and manufacturing activities.

The latest developments within the Object Management Group (OMG) [28] for systems engineering emerged in a Systems Modeling Language (SysML) [29]. Seven diagrams from Unified Modeling Language 2.0 (UML 2.0) [30] have been adapted and two new have been developed in order to support specification, design, analysis and testing of complex systems and system-of-systems. Still the applicability for an explicit domain description and inference seems to be limited, due to the fragmentation of the diagrams and the complexity of the language, especially for non-software engineers. As the metadata interchange standard XML Metadata Interchange (XMI) [31] for SysML is based on XML, it could be applied for data and information exchange with RDF/OWL-based files. 2.3 Ontologies for Manufacturing Systems

A comprehensive state-of-the-art of ontologies for modelling and simulation of manufacturing systems is given in [2]. Several scientific communities conduct research on the development of ontologies for discrete event simulation. Most of the work is focused on the architecture of the simulation model and on its parts like entities, clock, resources, activities, queues, etc.


401

The most recent developments at the University of the Georgia Athens are moving towards ontology-based model generation for simulation purposes [3], where the authors develop an ontology-driven Simulation (ODS) Architecture based on a discrete event modeling ontology [4]. The suggested architecture generates simulation models for the healthcare domain. Different ontologies have been developed that are used for manufacturing domain descriptions. However, these ontologies are used for various other purposes than for simulation. The project PABADIS PROMISE [5] develops a manufacturing ontology [6] based on ISA-95, ISO 10303 and ISO 61499 [26]. The ontology has to provide a formal and unambiguous description of manufacturing systems that will support the new control architecture for manufacturing enterprises. A manufacturing system engineering (MSE) ontology [8] is developed to provide a common understanding of manufacturing-related terms within globally extended manufacturing teams. The goal of ontologies for Supply Chain Management (Onto-SCM) [9] is to provide terms within the SCM domain and to model general concepts and relationships. Therewith it presents a neutral basis for an effective cooperation by different partners. A core manufacturing ontology [10] has been developed as an object-oriented UML model to be used in the communication between agents within an adaptive holonic control architecture for distributed manufacturing systems (ADACOR) [11]. The attempts and solutions mentioned are a significant step of deploying ontologies for a description of the manufacturing domain. However, a solution to support the cooperation within the projects between different members and considering the multiple information structures and semantics is not suggested. The solutions found consider specific parts of the manufacturing domain and are still not sufficient for the evaluation of manufacturing systems through simulation. The key performance indicators for manufacturing systems, which are essential for analysis and evaluation of manufacturing systems, have not been considered, too.

3 Functionalities Required for the Generation of Knowledge In order to support the collaborative work within the development projects and to reduce the development time, there is a need for assistance of definition, structuring and generation of the knowledge. Instead of having one or more glossaries as text documents, which are usually not related with distributed data carriers, explicit definition of objects and terms within the manufacturing system and the relations between them is required. This will enable an unambiguous manipulation with the concepts, and will facilitate the consideration of only related data and information within the collaboration activities in design, modelling and simulation of manufacturing systems as a part of the digital factory. Thus, the following functionalities emerge for a framework for generation of knowledge, modeling and simulation of manufacturing systems: x x

Embedding of domain knowledge within a single knowledge base. Inclusion of results from the daily work of project members involved in the design and development of new products and manufacturing systems.

402


x x x x x

Discovery of relationships between the entities of the knowledge base. Generation of new knowledge through inference. Integration of generated knowledge into the knowledge base and therewith enrichment of the knowledge base. Facilitating simulation and evaluation of a manufacturing system and integration of simulation results back into the knowledge base. Extraction of data and information from the knowledge base for the users and project members in a format needed for daily project work (e.g. spreadsheets, process models, documents, drawings, etc.).

4 Framework for the Generation of Knowledge within the Manufacturing Domain The framework for knowledge generation has to enable a knowledge base that describes products, materials, resources, technologies and processes. Their models have to hold information and knowledge needed for flawless project activities of the users. Figure 1 presents the main components of the framework: x x x x x

Standard-based core ontology of the manufacturing domain. Rule-based interface for the integration of dispersed information about the products, processes, resources, technologies and organization of a particular manufacturing system. Manufacturing Knowledge Base (MKB) as an entirety of information and knowledge for the particular manufacturing systems. Rules for inference and generation of new knowledge and enrichment of the MKB. Interface for modelling and simulation of the manufacturing system and integration of the simulation results into the knowledge base.

Manufacturing Manufacturing Manufacturing Manufacturing Domain Domain Domain Ontologies with Domain Ontologieswith with Ontologies Ontologies with Different Different Different Structures Different Structures Structures Structures

Simulationgenerated Knowledge Generated Knowledge

Simulation

Inference Engine

Mapping Rules Core Manufacturing Ontology (OWL-M)

Manufacturing Knowledge Base (MKB) Rules

Standard based Structures (ISA-95/OAGIS)

Manufacturing Knowledge Base (MKB)

Manufacturing Knowledge Base (MKB)

Rules

Rules

Continuously Enriched and Growing MKB

Fig. 1. Semantic Web Framework for Manufacturing Systems.


403

4.1 Core Manufacturing Ontology

The Core Manufacturing Ontology (OWL-M) is under development on Fraunhofer IPK and is built using the RDF/OWL syntax upon the object models and structures defined within the ISA-95 standard series and the open standard OAGIS. OWL-M is the further development of the data model for simulation explained in [1], structured according to the classes of ISA-95: x x x x

Process segments as a business view of the production, Product definition with bill of materials and production plans, Resources and their subclasses (personnel, equipment and material), Work description of production, maintenance, quality tests and inventory as: -

Capabilities as the highest sustainable output rate that could be achieved for a given product mix, raw materials, and resources, Schedules for production, maintenance, quality tests and inventory, Performance as a report of the production responses.

Since the ISA-95 and OAGIS are developed for the execution of manufacturing systems, OWL-M comprises additional classes and properties that describe shiftpatterns, spatial elements for the layout, manufacturing engineering project phases (installation, qualification and ramp-up), resource status, queues, transporters, performance indicators, etc. The OWL-M gives a core structure that can be used for the development of an extensive MKB for a particular manufacturing system comprising the individuals. 4.2 Rule-based Mediation of Source Ontologies The Manufacturing Knowledge Base (MKB) comprises several interfaced ontologies around the OWL-M. The input information from different IT applications is imported as an XML file. These XML files can be transformed as OWL files with a weak semantic, since they still have the original structure as in the XML file using the OWL syntax. The integration of the elements within these input OWL files into the structure of OWL-M can be realised through rule-based mediation. The mapping procedure yields the correspondences between the source OWL files and OWL-M. The alignment and matching of the ontologies are specifications of similarities. Those specifications are the base for rule development by the engineer. The rules govern the merging and creation of the MKB on the skeleton of OWL-M. An inference engine (software) applies the rules, reasons over the OWL-M structure, populates the existing classes, properties and instances in form of statements, and generates new ones. 4.3 Inference and Enrichment of the Manufacturing Knowledge Base

Due to the variety of information sources upon which the MKB is generated, there is “hidden” knowledge within the MKB that it is still not “visible” for the user (person or IT application). For example, the bill of material given by the product

404


designer frequently does not contain additional materials like consumables in production. The list of fixtures and tools needed for a particular product is not given by the product designer and not available in the product description. The production plan does not exist, too. To produce all theses information in a structure needed for further processing (e.g. bill of resources, production plan), usually discussions and information exchange between project members is needed. This goal can be achieved through rules and reasoning performed again by an inference engine. The antecedent part of the rules consists of existing axioms and facts about the individuals (triples) from different classes or ontologies. The consequent part includes the facts and statements that have to be generated through inference. An overview of the whole process is given below through an example. A product SiP_07 and the corresponding manufacturing system have to be designed. A product designer determines the list of the components that the new product has to conclude (Figure 2). Some of the product features are given, too. These are the result of the customer requirements and the experience knowledge of the designer. Facts: SiP_07 has following materials: RS_1, D_3, C_7 and T_5. The product SiP_07 has to be processed on a pick-and-place with speed of 300. The printing has to be performed according to the Jig principle and SiP_07 has to have a value of 5 for the feature distance. hasPlacingSpeed SiP_07

hasPrintingType RS_1

300

JigPrinting

hasDistance hasMaterial

D_3

5

T_5 C_7

Fig. 2. Description of the Instance SiP_07 by the Product Designer

The technologist has the knowledge about the materials, components, and their features as a result from his or her experience, using own terminology (Figure 3). Facts: RS_1 needs following technologies: Modules_Test, Reflow, Pick_and_Place, Jig_Printing, Sieve_Printing and Stacking. RS_1 needs either SB_21 with a length of 5, or SB_22 with length of 7.


405

Modules_Test Reflow Pick_and_Place needsTechnology

RS_1

Jig_Printing Sieve_Printing

needsMaterial

SB_21 SB_22

hasLength hasLength

5

Stacking

7

Fig. 3. Description of the Instance RS_1 by the Technologist.

The modeler is the designer of the OWL-M and is responsible for the semantic within the ontology (Figure 4), as well as for the rules, which enable reasoning and inference. Rules can be modelled as a set of atoms. hasLength owl:equvalentProperty hasDistance

Fig. 4. Equivalency of two Properties.

A rule example is given in table 1. Table 1. Example of a Rule for Extension of the Bill of Material

Rule Atom

Example

IF

IF

(?P :hasMaterial ?C)

SiP_07 hasMaterial RS_1

Product Designer

(?C :needsMaterial ?M)

RS_1 needs SB_21

Technologist

(?P, ?PP, ?PPV)

SiP_07 hasDistance 5

Product Designer

(?M, ?MP, ?MPV)

SB_21 hasLength 5

Technologist

(?PP owl:equivalentProperty ?MP)

Distance and Length are equal

Modeler

5=5

Modeler

equal(?PPV, ?MPV) THEN

Source

THEN SiP_07 hasMaterial SB_21

Inference Engine

(?P :hasMaterial ?M)

The first rule atom (?P :hasMaterial ?C) considers all products P and the instances C that are related with P through the property hasMaterial. The following atoms of the rule’s body are additional premises of the rule. The head of the rule contains just one atom (triple) that has to be generated by the inference engine that

406


reasons upon the ontology. The rule governs if all premises given in the antecedent are satisfied for a set of particular individuals. Then, the list of the materials that are in relation with the SiP_07 with the property hasMaterial will be extended. All values for M that satisfy the conditions will be added to the list and therewith the MKB will be augmented. In this example the technologist defined that RS_01 needs either SB_21 with value for the feature hasLength of 5 or SB_22 with value for the same feature of 7. As per the last rule’s premise the values of hasDistance and hasLength have to be equal, only SB_21 comes as a result of inference. A new statement (SiP_07 :hasMaterial SB_21) enriches the bill of material of the individual SiP_07 and therewith new knowledge is generated (Figure 5). hasPlacingSpeed SiP_07

hasPrintingType RS_1

300

JigPrinting

hasDistance hasMaterial

D_3

5

T_5 C_7 SB_21 Fig. 5. Augmented Description of the Instance SiP_07 after the Inference.

The same procedure can be applied considering other axioms and facts within the MKB through the deployment of additional rules that are specified to reach a particular goal. Deploying the knowledge of the production engineer, a production plan for the SiP_07 can be generated, too. The results are to be seen after the inference as triples (subject-predicate-object). Only those triples that are selected by the user build the generated knowledge and can be asserted into the MKB. 4.4 Connecting the MKB with the Simulation Model

The enrichment of the MKB can yield a completion of information needed for simulation of the manufacturing system (bill of materials, production plans, available resources, production orders and shift plans). The more data about the manufacturing system are available, the more accurate and closer to reality the simulation can be performed. The triples from the MKB through transformation can be used as an input for the simulation model. After the end of the simulation, the results (e.g. throughput-time, resource utilisation, buffer time and needed capacities) can be imported into the MKB through XML-to-OWL transformation. Therewith the information and knowledge


407

gained from the simulation can be used for further inference and enrichment of the MKB.

5 Conclusions and Future Developments An ontology for the manufacturing domain is needed as a skeleton for the modelling of the knowledge about a particular manufacturing system. The basis for the core manufacturing ontology (OWL-M) that is presented in this paper is taken from the structures and the object models defined within the ISA-95 series and open standard OAGIS. The distributed information about one particular manufacturing system can be transferred from the source files into several ontologies. The objects of those ontologies can be integrated into the OWL-M skeleton through rule-based ontology mediation, yielding the Manufacturing Knowledge Base (MKB) for a particular manufacturing system. Rules can generate new knowledge and through assertion of inference statements the MKB can be augmented. Since this paper describes a method and first applications, further developments are necessary in order to provide the users with a more friendly interface for ontology modeling, as project members can not be expected to be familiar with ontology modeling software. The MKB as a repository of knowledge about the particular manufacturing system can be used for further analysis and developments like simulation. The practice is that the logical decisions at branching points of the material flow are embedded into the simulation models. Examples are scheduling decisions, batching, matching, lot splitting, etc. The logic models could be a part of the MKB and therewith free the simulation models from complex constructs of modules and logical elements. This approach would enable rapid building of simulation models for complex manufacturing systems. The results obtained from the simulation could be integrated into the MKB as an additional enrichment. The inclusion of the scenarios into the MKB could give a basis for manufacturing system advisor through querying a knowledge base, where expert knowledge is stored and can be used later by other users or applications. Further developments could enable the connection of the MKB with existing Manufacturing Execution Systems. Similar to the results from simulation, the real information from daily operation of the manufacturing system could augment the MKB. The described semantic Web framework can substitute a part of the project activities usually in form of data and information exchange, understanding, agreeing, reasoning and knowledge generation. The modelling of the manufacturing domain with ontologies facilitates and accelerates the cooperation and collaboration processes within the projects of product design and development of manufacturing systems.

408


References [1]

[2]

[3]

[4] [5] [6] [7] [8]

[9]

[10]

[11]

[12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

[25]

[26]

Gocev, P., Rabe, M.: Simulation Models for Factory Planning through Connection of ERP and MES Systems. Tagungsband 12. ASIM-Fachtagung Simulation in Produktion und Logistik, pp. 223-232. Kassel (2006) Gocev, P.: Semantic Web Technologies for Simulation in Production and Logistic - a Survey. Simulation und Visualisierung 2007 – Doktorandenforum Diskrete Simulation, pp. 1-10. Magdeburg (2007) Silver, G., Hassan, O., Miller, J.: From Domain Ontologies to Modeling Ontologies to Executable Simulation Models. Proceedings of the 2007 Winter Simulation Conference, pp 1108-1117. (2007) Miller, J., Fischwick, P.: Investigating Ontologies for Simulation Modelling. Proceedings of the 37th Annual Simulation Symposium (ANSS’04). pp 55-63. (2004) Project Pabadis‘Promise. www.pabadis-promise.org Development of Product and Production Process Description Language (PPPDL). www.uni-magdeburg.de/iaf/cvs/pabadispromise/dokumente/Del_3_1_Final.pdf Gruber, T.: A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition 5(2), pp. 199-220, (1993) Lin, H. -K., Harding, J. A., Shahbaz, M. Manufacturing System Engineering Ontology for Semantic Interoperability across Extended Project Teams. International Journal of Production Research, Vol.42, No.24, pp 5099-5118. Tylor & Francis (2004). Ye, Y., Yang, D., Jiang, Z., Tong, T.: Ontology-based Semantic Models for Supply Chain Management. The International Journal of Advanced Manufacturing Technology. Springer, London (2007) Borgo, S., Leitao, P.: Foundations for a Core Ontology of Manufacturing. Ontologies – A Handbook of Principles, Concepts and Applications in Information Systems, Vol.14, Part 4, pp 751-775. Springer (2007) Leitão, P., Colombo, A., Restivo, F.: ADACOR – A Collaborative Production Automation and Control Architecture. IEEE Intelligent Systems, Vol.20, No.1, pp 5866. (2005) World Wide Web Consortium. www.w3.org Extensible Markup Language. http://www.w3.org/XML Resource Description Framework. www.w3.org/RDF Resource Description Framework Schema. www.w3.org/TR/rdf-schema Web Ontology Language - www.w3.org/2004/OWL Semantic Web Rule Language. www.w3.org/Submission/SWRL Instrumentation, Systems, and Automation Society, Enterprise-Control System Integration. Parts 1,2,3. Published 2000-2005. www.isa.org Open Applications Group Integration Specification. www.oagi.org Standard for the Exchange of Product Model Data. www.tc184-sc4.org/SC4_Open Machinery Information Management Information Open Systems Alliance. www.mimosa.org RosettaNet Standards. www.rosettanet.org Petroleum Industry Data Exchange (PIDX). www.pidx.org Industrial Automation Systems and Integration – Integration of Life-Cycle Data for Process Plants Including Oil and Gas Production Facilities. www.iso.org; http://15926.org Industrial Automation Systems and Integration – Diagnostics, Capability Assessment, and Maintenance Applications Integration Part 1. (Under Development), 2006. www.iso.org Function Blocks for Industrial-Process Measurement and Control Systems. www.iec.ch


409

[27] Studer R. et al.: Arbeitsgerechte Bereitstellung von Wissen – Ontologien für das Wissensmanagement. Technical Report, Institut AIFB, Universität Karlsruhe. 2001. www.aifb.uni-karlsruhe.de/WBS/ysu/publications/2001_wiif.pdf [28] Object Management Group (OMG). www.omg.org [29] Systems Modeling Language (SysML). www.sysml.org [30] Unified Modeling Language (UML). www.uml.org [31] XML Metadat Interchange (XMI). www.omg.org/technology/documents/formal/xmi.htm

Semantic Interoperability Requirements for Manufacturing Knowledge Sharing 1

N. Chungoora and R.I.M. Young1 1

2

Wolfson School of Mechanical and Manufacturing Engineering, Loughborough University, Loughborough, LE11 3TU, UK [email protected] Wolfson School of Mechanical and Manufacturing Engineering, Loughborough University, Loughborough, LE11 3TU, UK [email protected]

Abstract. Nowadays, sophisticated Computer Aided Engineering applications are used to support concurrent and cross-enterprise product design and manufacture. However, at present, problems are still encountered whenever manufacturing information and knowledge have to be communicated and shared in computational form. One of the most prominent of these problems is concerned with semantic mismatches, which impinge onto achieving seamless manufacturing interoperability. In this paper, the possible configuration of frameworks to capture semantically enriched manufacturing knowledge for manufacturing interoperability is being discussed. Ontology-driven semantic frameworks, based on explicit definitions of manufacturing terminology and knowledge relationships, offer an attractive approach to solving manufacturing interoperability issues. The work described in this paper defines Hole Feature ontological models in order to identify and capture preliminary semantic requirements by considering different contexts in which hole features can be described. Keywords: interoperability, semantics, manufacturing knowledge sharing

1 Introduction Information and Communications Technology (ICT) infrastructures, coupled with appropriate manufacturing strategies and practices can bring considerable benefits towards the survival and integration of manufacturing enterprises. According to Ray and Jones [1], interoperability is “the ability to share technical and business data, information and knowledge seamlessly across two or more software tools or application systems in an error free manner with minimal manual interventions”. Seamless interoperability, although being one fundamental requirement for ICT

412

N. Chungoora and R.I.M. Young

infrastructures, so as to support efficient collaborative product development, is still not completely achievable. This lack of interoperability is costly to many globally distributed industries [2] where significant amounts of money are spent into overcoming interoperability problems [3]. Several problems are responsible for the lack of interoperability of manufacturing systems, the most common reason being due to incompatibility between the syntaxes of the languages and the semantics of the terms used by the languages of software application systems [4]. It has been asserted that the problems of interoperability are acute for manufacturing applications, as applications using process specifications do not necessarily share syntax and definitions of concepts [5]. Moreover, clear emphasis has been laid to the fact that either common terms are used to mean different things or different terms are used to mean the same thing which leads to potentially substantial interoperability problems [1]. Several authors such as Prawel [6], Liu [7] and Cutting-Decelle et al. [8] have recognised the importance of product data exchange and information modelling as a means of obtaining a certain level of systems integration. Systems and process integration and interoperability work hand in hand, for example, at manufacturing level, the integration of mechanical analysis into the design process is one of the most obvious and crucial requirements, particularly during the early stages of design [9]. In modern PLM systems, manufacturing knowledge handled by decision support systems has to be communicated across the entire lifecycle effectively. In the design and manufacture domain, this knowledge is developed in activities such as Design for Function, Design for Assembly and Disassembly, Design for Manufacture and Manufacturing Planning. Current limitations of semantic interoperability, therefore, inevitably affect manufacturing knowledge sharing capability. Effort pursued through ontological approaches provide attractive potential solutions to the problem of semantic interoperability. However, the greatest difference of significance between ontological approaches is the basis upon which the sharing of meaning is made in relation to the level of rigour with which terms are defined [10]. Furthermore, it has been specified that interoperability between manufacturing activities is influenced by the context dependency of information [11]. Hence, an all-embracing framework to solve semantic manufacturing interoperability issues is likely to cut across rigorous ontological engineering which captures the contextual representations of information and knowledge. This paper provides an understanding of the potentials that ontology-driven frameworks possess in order to solve semantic interoperability problems in the manufacturing domain. A hole feature ontology example has been devised to illustrate some of the requirements for capturing semantic as well as to identify key areas which need to be focused towards solving semantic manufacturing interoperability and manufacturing knowledge sharing issues.

Semantic Interoperability Requirements for Manufacturing Knowledge Sharing

413

2 Manufacturing Information and Knowledge Support Systems The quest towards PLM decision support systems with increasing decisionhandling capabilities has driven the progression from information support systems to knowledge-based systems. Relevant information support to product design and manufacturing has been pursued through the use of Product and Manufacturing Models [12]. A Product Model may be defined as an information model, which stores information related to a specific product [13]. The Product Model paradigm has slowly been extended with time, for instance, through the inclusion of additional dimensions such as product family evolution [14]. On the other hand, a Manufacturing Model is said to be a common repository of manufacturing capability information, whose use is justified in the way the relationships between all manufacturing capability elements are strictly defined [15]. Nowadays, new product development in large companies, operating for instance in automotive and aerospace sectors, is supported by Knowledge-Based Engineering (KBE). KBE in industry is mostly used to automate design processes and to integrate knowledge and experience from different departments [16], for example, in the design and manufacture domain the generative technology of knowledge-based tools enables companies to create product definitions which incorporate the intuitive knowledge (experience) of designers and engineers about design and manufacturing processes [17]. The main claimed benefit of KBE lies in its ability to aid rapid product development in a collaborative way for increased productivity. 2.1 Integrating Product and Manufacturing Knowledge

The concept of acquiring manufacturing knowledge is partly based on having the appropriate system infrastructure to aid the integration of product and manufacturing information repositories. It has been mentioned that Manufacturing Information Models have not been shown fully integrated with each other or with a Product Information Model [18]. Manufacturing knowledge dissemination can be more specifically targeted to the useful interoperability of both product and manufacturing information repositories in such as way that clear contexts, relationships, constraints and rules are defined. Previously, multi-view modelling has attracted attention as a framework for gathering manufacturing systems knowledge. However, multi-view modelling to acquire manufacturing knowledge has been developed into solutions based on the use of UML, and therefore uses a lightweight ontological approach which is inappropriate for intersystem interoperability [10]. Therefore, more stringent approaches need to be devised in order to capture and share manufacturing knowledge. 2.2 Ontology-Driven Frameworks for Knowledge Support Systems

The area of ontological representation of knowledge is a subset of technologies for information and knowledge support [19], which implies that in one way or the

414


other, ontological approaches can be sought in order to set up platforms for knowledge-driven integration of Product and Manufacturing Models. In recent years, ontological engineering has been witnessed in the manufacturing domain, for instance, a Manufacturing System Engineering (MSE) ontology model that has the capability to enable communication and information exchange in interenterprise, multi-disciplinary engineering design teams, has been proposed [20]. In another instance, a product ontology concerned with the development and refinement of the ISO10303-AP236 standard to support information exchange for the furniture industry has been developed [21]. One fundamental observation made is that only a progression towards the use of heavyweight ontologies can provide greater confidence that the real meaning behind terms coming from different systems is the same [10]. Hence, heavyweight ontologies offer the potential of supporting semantic manufacturing interoperability.

3 Understanding Semantic Requirements for Knowledge Sharing As an attempt to understand the need for semantic support in knowledge sharing between functional domains, Figure 1 has been proposed. A functional domain may be regarded as being any group or community in which a particular knowledge is fully accepted, understood and shared for the realisation of a specific function. In a concurrent engineering environment, a functional domain could be synonymous to, for example, a team of people working in Design for Assembly or another group working in Design for Function. Having a communal acceptance of knowledge within a group implies that a specific ontology is being adopted within a functional domain. Therefore, it can be deduced that the common understanding of concepts, communication and sharing of these concepts, and subsequent decision-making, all depend on the semantics defined and used in a functional domain. Assuming that a functional domain has a semantically well-defined ontology as a basis for sharing knowledge and the meaning behind the knowledge, it becomes feasible to suggest that different domains are likely to develop their own ontologies. Hence, two functional domains, regardless of whether they operate within similar areas or not, may not necessarily achieve consensus, whenever knowledge is to be shared among the two groups. This is because, although the ontologies can be well-formed, accepted and semantically correct in both individual groups, the semantics from both functional domains do not match when both groups have to communicate with each other. In concurrent engineering design and manufacture premises, semantic mismatches are primarily due to multiple manufacturing and product-related terminologies defined to mean similar things or to mean disparate concepts. As a consequence of this, a software system developed to suit the purpose of one functional domain, needing to communicate with another software system suited for another domain, does not always readily do so. These semantic problems can be carried downstream in the product lifecycle. At present, there still exist problems related to ambiguous semantics ([5], [10]) which prevent manufacturing knowledge to be captured and shared seamlessly. In Figure 1, the central ellipse


415

denotes the ongoing misfits in semantics, which lead to the problem of knowledge sharing. Knowledge Sharing

Functional Domain

X

Concept Understanding Concept Communication Decision Making

Functional Domain

Concept Understanding

Semantics Semantics

Concept Communication Decision Making

Fig. 1. Knowledge Sharing and Semantics between Functional Domains

3.1 Hole Feature Ontology Model to Identify Semantic Requirements

To illustrate the issue identified previously, an example has been put forward where aspects of two different but related domains (namely a design domain and a manufacture domain) have been captured. An ontological approach using the Protégé 3.3 tool has been exploited to model the two domains. The scope of the task is to identify a set of semantic requirements, which can be used as specifications to the design of frameworks to promote semantic interoperability of knowledge resources within disparate contextual representations of features. It has been acknowledged that feature-based engineering bridges the gap between CAD and knowledge-based engineering systems [22]. Features play a key role in providing integration links between design and manufacture [23]. For these reasons, it was considered appropriate to build an onthology around a feature so as to incorporate some level of manufacturing knowledge. The feature ontology proposed has been developed to identify semantic requirements related specifically to holes as features. This is partly because hole feature manufacture is problematic and sometimes costly to industries, as a result of the diverse contexts, manufacturing processes and poorly established best practice methods associated to whole features. An example to illustrate the prominence of the contextual definitions for the designation of whole features is illustrated in Figure 2. In the design functional domain, a counterbored hole accommodating a particular size of bolt may be

416


regarded as a bolt hole. In the manufacture functional domain, the functionality (of the whole acting as a bolt hole) can be of little importance and instead, the same hole in a manufacture functional domain may be designated as a counterbored hole. In the latter case, this could further imply that the counterbored hole needs to consist of an optional centre-drilling operation, a required drilling operation and a required counterboring operation. A whole feature may be considered from various contexts and the semantics need to be defined for contexts such as functional, geometry, manufacturing, machining process and assembly [11]. Drilling Counterboring Bolt Hole Design Functional Domain

Manufacture Functional Domain

has functional context

has machining context

Counterbored hole Fig. 2. Considering a Counterbored Hole from Two Different Contexts

3.1.1 Design Hole Feature Ontology

A lightweight ontology for hole feature representation from a purely functional and geometry context, reflecting the design functional domain, was developed. Figure 3 depicts the class hierarchy from the Design Hole Feature ontology. This ontology may be regarded as one possible context in which hole features can be represented. The superclass “Design Hole Feature” has two subclasses namely “Circular CrossSection Hole” and “Shaped Hole”, implying shape and geometric property variations from these two parent classes.


417

Fig. 3. Class Hierarchy for the Design Hole Feature Ontology

Protégé allows the user to define classes and specify the properties or slots of these classes. These properties, also known as attributes in the OO environment, describe the information elements which are the building blocks of a class. The necessity for having parent to child class property inheritance (i.e. is-a relationship) is significant. For example, the “depth” property of the class “Design Hole Feature” is inherited by the subclass “Circular Cross-Section Hole” and subsequent child classes. It is also possible to define additional slots for specific classes, for example, the “Circular Cross-Section Hole” class has a “primary diameter” property. It would not be reasonable for the class “Shaped Hole” to possess the property “primary diameter” since a shaped hole consists of two or more geometries which define its cross-section. In the proposed Design Hole Feature ontology a few instances have been defined. 3.1.2 Machining Hole Feature Ontology

A similar approach to the ontology development of the Design Hole Feature ontology has been adopted to devise a Machining Hole Feature ontology. The latter captures other contexts in which hole features can be represented namely from a machining and manufacturing process context, thus reflecting the manufacture functional domain. Provision for the geometric context has also been made since it is impossible to describe a “Machining Hole Feature” without referring to the basic dimensions of the feature. Several classes and subclasses have been defined. Two main superclasses are present namely “Machining Hole Feature” and “Hole Machining Operation”. The “Machining Hole Feature” class holds knowledge about particular classes of holes which can be encountered during production, while the “Hole Machining Operation” class holds knowledge about the capability of a particular process to machine a given hole feature. Figure 4 illustrates some of the relationships that can be made through slots. One type of relationship is called an inverse relationship whose semantics is well defined (in

418


the current ontology the “produced by” and “produces” slots pertaining to the classes “Machining Hole Feature” and “Hole Machining Operation” respectively are inverse slots) and Protégé allows the user to input this information through an “inverse-slot” option made available.

Knowledge Fig. 4. Class Hierarchy and Knowledge Relationships in the Machining Hole Feature Ontology

The property defined as “requires machining sequence” is a requirement for the “Hole Machining Operation” class. This is because for selected processes, a processing sequence may be required before a complete machined hole feature can be obtained. As previously seen, attributes or properties can be defined so that they represent relationships which state the behaviour of information elements between classes, slots and instances, thereby acquiring some knowledge within the domain ontology. In order to understand occurrence and process-dependency aspects in hole manufacturing operations, a reaming operation required to produce a reamed hole, has been taken into account. A “Reamed Hole” may be described as being “produced by” a certain reaming operation which “produces” the hole feature and achieves the necessary dimensional target. The reaming operation involves the use of an available manufacturing resource “Machine Chucking 10.02mm”. Also, it is possible to define that a reaming operation “requires machining sequence” and use this property to identify other manufacturing operations and resources pertinent to a reaming operation. The instances diagram in Figure 5 gives a clear idea of the level of semantic linking that needs to be defined through relationships.

Reamed Hole 10.02mm diameter = 10.02 produced by = Machine Chucking 10.02mm diameter tolerance = +/-0.008 depth = 35.0 quantity = 6

produces

produced by

Machine Chucking 10.02mm HIGH-SPEED_STEEL Centre Drill 2.00mm requires machining sequence = Stub Length 9.50mm Machine Chucking 10.02mm tool diameter = 10.02 produces = Reamed Hole 10.02 tool diameter tolerance = +0.005, -0.000 tool type = FLUTED_REAMER

requires machining sequence Centre Drill 2.00mm overall length = 40.0 body diameter = 5.0 pilot length = 2.5-3.3 tool material = HIGH_SPEED_STEEL tool diameter = 2.0 produces = Centre Drilled Hole 2.05mm tool diameter tolerance = +0.013 tool type = 60_DEGS_INCLUDED_ANGLE

produces

produced by

Centre Drilled Hole 2.05mm diameter = 2.05 produced by = Centre Drilling 2.00mm diameter tolerance = +/-0.03 depth = 3.0

requires machining sequence

tool material =

419

requires machining sequence


requires machining sequence Stub Length 9.50mm tool material = SOLID-CARBIDE requires machining sequence = Stub Length 9.50mm tool diameter = 9.5 produces = Drilled Hole 10.02 tool diameter tolerance = +0.000, -0.015 tool type = HELICAL_POINT

produces

produced by

Drilled Hole 9.52mm diameter = 9.52mm produced by = Stub Length 9.50mm diameter tolerance = +/-0.02 depth = 35.0

Fig. 5. Implications of Producing a Reamed Hole from Knowledge Contained in Instances

4 Discussions and Conclusions The feature-oriented ontologies developed with well-defined semantic relationships reflect a potential way forward to the integration and sharing of product and manufacturing knowledge. It is clear that the functional and geometry contexts from the Design Hole Feature ontology capture some relevant aspects of the Product Model perspective. On the other hand, the machining process context

420


based on manufacturing methods, witnessed in the Machining Hole Feature ontology, reflects the Manufacturing Model perspective. In Design for Manufacture, having context-specific hole feature representations is important but these representations should not be used individually from each other. Thus, a basis needs to be defined so as to enable the successful management and matching of feature-oriented ontologies constructed from different contextual views for knowledge sharing. So as to meet the purpose of manufacturing interoperability, unambiguous semantic relationships need to be set up among these context-specific ontologies so that multi-context manufacturing knowledge becomes interoperable and subsequently shareable. In the experiment, the “requires machining sequence” property gives the relationship between multiple hole machining operations and introduces a knowledge element to the system. Although existent, the basis over which the “requires machining sequence” property has been defined is still not explicit enough and it would be an advantage to create a more rigorous statement. Some of the questions which could be asked concerning this issue are: is the sequence an ordered sequence? Is the machining sequence in an ascending order of dimensional targets? Is the sequence in descending order of importance? One highly promising direction to solve this and other similar issues is to include meta-modelling of the classes and slots in such a manner that the semantics behind classes and properties are fully captured, thus removing the ambiguities present in semantic linking through property definitions. Given that the manufacturing knowledge in question is captured using different methods employed by different groups and cutting across varying contexts, two important questions need to be reviewed in the quest for an ontology-driven semantic interoperable framework for manufacturing knowledge sharing. These main questions have been identified below: x x

How can methods of manufacturing knowledge capture be refined in such a way that a level of semantic enrichment of the knowledge is achieved to enable comprehensive knowledge sharing? To what extent can a semantic framework verify what segments of manufacturing knowledge are appropriate for sharing? Conversely, what segments of manufacturing knowledge prove to be semantically dissimilar so that they cannot be shared?

At this stage, it is possible to list a number of distinct semantic requirements to be satisfied with the intention of promoting semantic interoperability for manufacturing knowledge sharing. These requirements are as follows: x x x

It is necessary to provide an adequate basis for sharing design and manufacture related meaning through comprehensive ontological frameworks (e.g. through the construction of domain ontologies). These frameworks should entail sufficient complexity in the way information and knowledge are structured (e.g. through meta-modelling). Semantic definitions need to cut across several contexts so as to provide a basis for matching semantics from different functional domains (e.g. geometric, assembly and machining contexts).


x x

421

Semantic linking should be made through well-defined knowledge relationships thereby bridging the semantic gaps between contexts. It is essential to provide an underlying mathematical rigorousness to formalise semantic statements (e.g. where dependencies on options, sequences, activities and event-based parameters are present).

Future work to be based on RDF(S)/OWL ontology markup languages, using the software Protégé OWL and Altova SemanticWorks, shall provide a further insight into answering the above questions. Furthermore, the subsequent exploration of heavyweight feature-oriented ontologies using the Process Specification Language (PSL) shall provide additional support into overcoming the problem of semantic interoperability for manufacturing knowledge sharing.

References [1]

Ray SR, Jones AT, (2003) Manufacturing interoperability. Concurrent Engineering, Enhanced Interoperable Systems. Proceedings of the 10th ISPE International Conference, Madeira Island, Portugal: 535–540 [2] National Institute of Standards and Technology, (1999) Interoperability cost analysis of the U.S. automotive supply chain. http://www.nist.gov/director/prog-ofc/report991.pdf [3] Brunnermeier SB, Martin SA, (2002) Interoperability costs in U.S. automotive supply chain. Supply Chain Management: an International Journal 7(2): 71–82 [4] Das B, Cutting-Decelle AF, Young RIM, Case K, Rahimifard S, Anumba CJ, Bouchlaghem N, (2007) Towards the understanding of the requirements of a communication language to support process interoperation in cross-disciplinary supply chains. International Journal of Computer Integrated Manufacturing 20(4): 396–410 [5] Pouchard L, Ivezic N, Schlenoff C, (2000) Ontology engineering for distributed collaboration in manufacturing. AIS2000 Conference. http://www.acmis.arizona.edu/CONFERENCES/ais2000/Papers.back/Papers/PDF/a0 26pouchardlc.pdf [6] Prawel D, (2003) Interoperability best practices: advice from the real world. TCT 2003 Conference organised by Rapid News and Time Compression Technologies, NEC, UK [7] Liu S, (2004) Manufacturing information and knowledge models to support global manufacturing coordination. PhD Thesis, Loughborough University, Loughborough, UK [8] Cutting-Decelle AF, Das BP, Young RIM, Case K, Rahimifard S, Anumba CJ, Bouchlaghem NM, (2006) Building supply chain communication systems: a review of methods and techniques. Data Science Journal 5: 26–51 [9] Aifaoui N, Deneux D, Soenen R, (2006) Feature-based interoperability between design and analysis processes. Journal of Intelligent Manufacturing 17: 13–27 [10] Young RIM, Gunendran AG, Cutting-Decelle AF, Gruninger M, (2007) Manufacturing knowledge sharing in PLM: a progression towards the use of heavy weight ontologies. International Journal of Production Research 45(7): 1505–1519 [11] Gunendran AG, Young RIM, Cutting-Decelle AF, Bourey JP, (2007) Organising manufacturing information for engineering interoperability. Interoperability for Enterprise Software and Applications Conference, Madeira Island, Portugal

422


[12] Costa CA, Young RIM, (2001) Product range models supporting design knowledge reuse. IMechE Part B Journal of Engineering Manufacture 215(3): 323–337 [13] Molina A, Ellis TIA, Young RIM, Bell R, (1995) Modelling manufacturing capability to support concurrent engineering. Concurrent Engineering Research and Applications 3(1): 29–42 [14] Sudarsan R, Fenves SJ, Sriram RD, Wang F, (2005) A product information modelling framework for product lifecycle management. Computer Aided Design 37: 1399– 1411 [15] Liu S, Young RIM, (2004) Utilizing information and knowledge models to support global manufacturing co-ordination decisions. International Journal of Computer Integrated Manufacturing 17(4): 479–492 [16] Liening A, Blount GN, (1998) Influences of KBE on the aircraft brake industry. Aircraft Engineering and Aerospace Technology 70(6): 439–444 [17] Kochan A, (1999) Jaguar uses knowledge-based tools to reduce model development times. Assembly Automation 19(2): 114–117 [18] Feng SC, Song EY, (2003) A manufacturing process information model for design and process planning integration. Journal of Manufacturing Systems 22(1): 1–16 [19] Chandra C, Kamrani AK, (2003) Knowledge management for consumer-focused product design. Journal of Intelligent Manufacturing 14: 557–580 [20] Lin HK, Harding JA, (2007) A manufacturing engineering ontology model on the semantic web for inter-enterprise collaboration. Computers in Industry 58(5): 428– 437 [21] Costa CA, Salvador VL, Meira LM, Rechden GF, Koliver C, (2007) Product ontology supporting information exchanging in global furniture industry: 278–280. In: Goncalves RJ et al. (eds.) Enterprise interoperability II: new challenges and approaches, Springer-Verlag London Limited, London, UK [22] Otto HE, (2001) From concepts to consistent object specifications: translation of a domain-oriented feature framework into practice. Journal of Computer Science and Technology 16(3): 208–230 [23] Brimson J, Downey PJ, (1986) Feature technology: a key to manufacturing integration. Computer Integrated Manufacture review

Collaborative Product Development: EADS Pilot Based on ATHENA Nicolas Figay, Parisa Ghodous 1

2

EADS IW 12, rue Pasteur – 92152 Paris Cedex – France [email protected] Bâtiment Nautibus, Université Claude Bernard Lyon 1, 43 bd du 11 novembre 1918, 69622 Villeurbanne cedex - France [email protected] URL: http://liris.cnrs.fr/ 2

Abstract. When willing to support collaboration within enterprise or between enterprises, it is required to support fast establishment of communication and interactions between numerous organizations, disciplines and actors. More and more, it implies to be able to interconnect enterprise applications that support involved partners and their communication, authoring and management processes. This paper presents an innovative federation framework and associated usage, which composes an effective way already existing enterprise, knowledge and application interoperability frameworks that are themselves standardized. The framework is defined according ATHENA vision, addressing interoperability at Enterprise, knowledge and Information/Communication technologies and establishing links at semantic level by means of ontologies for information, service and processes. The framework aims to address governance, organizational and technological brakes identified in industrial context when willing to establish fast and effective eCollaboration, providing modeling and execution platforms able to produce executable collaboration models and supporting round-trip development, that is a pre-requisite when willing to federate legacy solutions of partners involved within the collaboration. It proposes policies for choice, composition and usage of de jure and de facto standards that will remove these brakes. It will be validated within the particular domain of collaborative Product Development within Aerospace sector. Keywords: Interoperability of Enterprise Application, Federation, Model Driven Interoperability, Semantic Preservation

424

Nicolas Figay, Parisa Ghodous

1 Introduction: Interoperability Needs and Issues for Emerging Networked Organization In order to face a more and more competitive environment, enterprises rely more and more on usage of enterprise applications, which are supporting the main functions and processes of the enterprise: Enterprise Resources Planning applications, Human Resources management applications… Characteristic of these applications is to support, enact, monitor, control and some time execute business processes of the enterprise for numerous activities and categories of users, which are geographically distributed. In addition, they are managing informational resources of the enterprise that are becoming more and more electronic: databases, documents, models, knowledge… and that are produced by authoring tools such as document authoring tools (e.g. Microsoft word…), relational database systems, Computer Aided Design tools (e.g. Dassault Systems Catia). As functions of the enterprise need to be interconnected in order to support transversal processes, in particular those related to the clients and attached to the creation of values and benefits, integration of enterprise information system became a key issue the last years, with as means integration frameworks, integration systems (e.g. Enterprise Application Integration Systems), middleware (e.g. Common Object Request Broker Architecture [3]), data/documents exchange facilities (e.g. XML) and Service Oriented Architectures and Systems. In order to govern evolution of the whole enterprise information system and to align the information system with strategic objectives of the enterprise, new approaches have been created such as controlled urbanism of the Enterprise Information System with associated Enterprise Modelling capabilities (e.g. Business Process Modelling or decision modelling). Nevertheless, integration of enterprise applications remains difficult due to heterogeneity of legacy applications and due to the fact the used software were not initially designed to be interoperable (c.f. Interoperability anti-patterns defined in ATHENA[13]). In addition, integration solutions provided by the market are most of the time not interoperable between them and led to add technological or software products silos to functional silos Because of globalization of the economy and necessity to focus on core high value business activities, enterprises had also to establish partnerships with other companies specialized in other domains, which are required to support their activities but that are out of their core activities. For example in-house software development was replaced by selection of commercial of the shelves (COTS) software products. Other example is Aerospace activity where the amount of subcontracted activity is today targeted to 60%, including design activity. It lead to the creation of what is called Virtual Enterprise, where integrators have to coordinate activities of all the partners and to import them on the information and communication system supporting product development (what is called Extended Enterprise). Challenge of Extended Enterprise is very often seen as to be able to integrate information systems of several enterprises. But as establishment of each enterprise information system was done independently, integration of enterprise information systems is a very difficult challenge. Due to the new relationships established between enterprises, it is also most of the time neither wished nor possible, in particular because partners and members of the supply chain are

Collaborative Product Development: EADS Pilot Based on ATHENA

425

working with several partners, clients and programs that are independent, and also because internal informational systems are based on heterogeneous core domains and activities. How can then an integrator constraint a partner to work with the tools that are related to a domain they are not expert in and that is out of their core activity? In such a situation, collaboration is to be established between partners having heterogeneous core domain activity, processes, applications, and information/communication technologies, without targeting integration but fast and limited in time interconnection of applications supporting the collaboration within a collaboration space. For such a challenge, existence and usage of accurate set of ‘de jure’ and ‘de facto’ standards addressing interoperability at enterprise level, knowledge domain level and Information and Communication technologies level are critical. Competition of numerous standardization bodies and solutions providers, pushing valuable but incompatible and overlapping solutions, does not facilitate the task. ATHENA research program on interoperability of enterprise applications highlighted difficulties to use simultaneously solutions coming from these different communities when trying to integrate them within piloting activities. For example, semantic mediation prototypes were based on Resource Description Framework schemas, while Service Oriented Execution components were based on message structured according XML schema [8]. So it required to work on mapping of schema definition languages. Similar issues exists for model interchange format (XML Model Interchange, XML Process Definition Language, etc).From enterprise piloting activities point of view, it was particularly important because the different models had to be coherent and projected on robust Service Oriented execution platform. Finally business domain communities (such as Manufacturing, Health, etc) are creating their own standardization communities collaborating with several Information and Technology Interoperability initiatives. Some try to formalize their need a way that is Information and Communication technology independent, developing their own specification framework (e.g. ISO STEP community) that includes binding to important interoperability technologies (e.g. for ISO STEP community bindings with XML, UML[12], Java, etc) but also contributing to vertical specification definition concerning their domain in liaison with different other communities (e.g. PDM enablers and PLM services [4] within the Mantis [5] group of OMG, or PLCS consortium at OASIS defining PLCS PLM services or Reference Data Libraries). An important difficulty is related to incompatibilities between the used paradigms and solutions developed for each technological framework. It was highlighted for example within the SAVE project trying to use simultaneously STEP AP214 and PDM Enablers. Another difficulty is related to incompatible implementations of the standards, due to insufficient conformance testing frameworks and certification process establishment. Consequently, there is a strong need today to find new interoperability solutions enabling enterprises to collaborate a federate way, and to interconnect their legacy integrated information systems using together the different accurate technological interoperability frameworks a coherent way in order to avoid technological silos.

426


2 State of the Art Concerning Standard Based Technological Interoperability Frameworks to Reuse ATHENA research programs provided foundation to establish interoperability of enterprise application, but also highlight a set of important issues that are still not solved. Existing Interoperability frameworks can be assessed according the different viewpoints defined by ATHENA. 2.1 ATHENA

The ATHENA Integrated project proposed a vision for interoperability of enterprise applications, that should be addressed a holistic way at Enterprise, knowledge and ICT (Information and Communication Technologies) levels, with semantic models as glue between levels and enterprise applications. It is a basis for the establishment of federation framework and identification of relevant standards to use within this framework.

Fig. 1. Interoperability supported at all the layers of the enterprise by ATHENA

Within ATHENA, several sectors (Aerospace, Telecom, Automotive, and Furniture) and domains (Enterprise modelling, Executable service oriented platform) were implied. But it is important to point that open federative platform for several organizations was not really addressed by researchers, targeting more one to one connection as reflected in the model of reference. Neither federation issues related to data (e.g. multiple identification, naming, and typing rules) nor usage of different used legacy formalisms within a single modelling environment were addressed. It was an issue when willing to integrate ATHENA produced innovative solutions within an open collaborative framework. 2.2 Standard Based Technological Interoperability Frameworks to Reuse

Numerous solutions and approaches have been developed the last decade in order to address interoperability. State of the art was done in order to cover the different layers to be considered for enterprise applications interoperability (enterprise, knowledge, ICT with semantic mediation), with coverage of information, service and process aspect, and with as prerequisite openness, standardization and existence of implementations as commodities on the WEB (i.e. free, open source


427

and robust implementations). According ATHENA, the different viewpoints to consider are domain knowledge, enterprise, and ICT (Information and Communication Technologies). Domain knowledge related standards have been defined to address some interoperability issues, with specific technological frameworks and bindings to other technologies. It is the case for manufacturing domain that is used for validation of the federation framework through collaborative design business scenarios. This community is being producing, through ISO 10303 STEP standard, a set of applications protocols (formal and computational information models in EXPRESS[7]) in order to address exchange, sharing and long term retention of data describing a product (e.g. an aircraft or an automotive) between several organizations and software products. Bindings to existing technologies of interest are provided. This community is also producing set of standardized object oriented interfaces (Product Data Management Enablers) and web services (Product Lifecycle Customer Support – PLCS[24]- and Mantis Product Lifecycle Management or PLM services) based respectively on Common Object Request Broker Architecture and Web Services Definition Language [6]. In order to use these standards together, several initiatives addressed the issue of federation of different domain models, such as PLCS. PLCS produced STEP AP239 standard, PLCS PLM services and Reference Data Libraries standards and specifications, that attempts mixed usage of several technologies and provide ways to interrelate different domains ontologies to product data model provided by AP239. Enterprise modelling related standards is just emerging, and it is difficult to really identify those that should be use. Some are addressing modelling of an enterprise as a system, providing modelling construct for an enterprise, such as Unified Enterprise Modelling Language. But such standard is mainly used by consultant and function of the enterprise dealing with organization and not for Application Engineering. Application specifications are often formalized by means of UML use cases, in combination with Business Process Modelling. Usage of different modelling language for application specifications, combined to projects boundaries, lead to “islandization” of applications, i.e. creation of independent and not interoperable applications within the enterprise. Finally emerging approaches related to executable Business Process Models and related standardized modelling language should be considered, as part of the Enterprise Modelling construct, or as component of the enterprise models to be considered. Without a real consensus today for usage of a single enterprise modelling “de-jure” standard, it is difficult today to select one. A more pragmatic approach should be to establish, for a given community, a set of collaboration processes, shared services and information models of reference for collaboration, within a federated environment. More and more communities are dealing with federation issues: federated authentication (Liberty Alliance project), web services federation (OASIS’ SAML), Federated Enterprise reference architecture (or FERA, by Collaborative Product Development Associates, LCC or CPDA). FERA proposes a framework for loosely coupled business process integration as part of its product value management and product lifecycle management infrastructure research services, with implementation on ebXML platform. It is consequently within a technological silo and it creates new overlapping model of reference in

428


PLM domains, which is not related to other PLM standards such as PLCS, PDM Enablers or STEP Application protocols. FERA approach is nevertheless important, as related to Product value management that is not necessarily considered by other PLM standardization communities. At Information and Technological level, it is important to distinguish the modelling platforms, the development platforms and the execution platforms. The most promising execution platforms are the service oriented platforms encompassing standardized application servers, integration framework, process enactment and execution platforms, presentation integration (portals), federated authentication and single sign-on components. Such an execution platform was already described by the author [1] [2] within ATHENA Networked Collaborative Product Development Platform within Aerospace pilot. The federation platform will be an extension of this platform. For the development platform, the used standard should be based on mature enough open “de-jure” and “de-facto” standards for application modelling, programming and model transformation. An extension of EUROPA[25] Eclipse platform was identified as an excellent candidate, the Papyrus UML platform, that support most of the last versions of OMG standards for UML modelling, interchange (diagrams and models) and transformation language (Model to Model). In addition, it should be extended by Model to Text and Text to Model capabilities to be able to import and export views of enterprise modelling platforms and operational execution platforms. For modelling platforms, the more appropriate technologies and standards are those related to MDA[16] in one hand, and to the semantic WEB in the other hand, in conjunction with usage of relevant models for a community (e.g. emerging enterprise/application modelling language and models). Papyrus platform, in conjunction with appropriate profiles and transformations, is a good candidate as MDA platform. Some of these transformations are being developed by the author within the scope of the OpenDevFactory project[20], as components of the federation framework described later on. For ontological models, the modelling platform is Protégé ontology editor, coupled with standards based querying (sparQL[11] based tool such as Virtuoso) and reasoning (DL[14] based tools such as Pellet[18]) tools. It is required to find way to federate heterogeneous models (different modelling language and different viewpoints) within each environment and to interchange federated models between the two modelling environment. This issue is addressed within the proposed federation frameworks through definition of extended multi-ground hyper models.

3 Proposed Federation Framework The proposed federation framework is addressing the different interoperability needs and issues identified within the previous sections. It is first aimed to be able to establish federation of applications on a collaborative space that will allow collaboration between enterprise having heterogeneous internal private and specific processes, information, organizations, modelling platforms and execution platforms. The challenge is to identify eligible legacy solutions based on open


429

standards, which could be combined to provide organizations modelling, knowledge modelling and application modelling platform that can be combined to support model driven approach collaboration and roundtrip transformation between service oriented execution platforms and modelling platforms. The proposed federation framework encompasses a federated organization reference model, enabling collaborative and B2B standard based platforms specifications and principles and finally innovative enabling concepts to break the technological silos, roundtrip transformation and heterogeneous model aggregation. 3.1 The Federated Organisational Model

The federated organization is a network for which each member is an organization or a company with its own objectives, private business processes and specific business objects. Each information process is supported by applications that are providing services to human end users or to other applications. Relationships between business processes and application is done through business use cases, that define interactions between application and users a specific context, constrained by business rules coming from disciplines methods, application usage guidelines and software product usage. User interfaces are sequenced in order to give access or to basic information Creation, Remove, Update or Delete (CRUD) operations, or providing service invocation templates and result consultation templates. Internally, an application is a business information container (data, documents) and a service provider, which implement some business logic. Interfaces with other application is done by publication of set of services that can be composed by means of executable business process, defined by means of programs, batches, composition or workflows. In order to be integrated at the outside, the application can support business data/documents exchange and sharing, business services access to application and business service access to human users (by means for example of portlets). Most of the time, members of the network don’t have a model oriented approach and no enterprise models or application models exist, only documents. The internal applications are also not structured this way. It is a prerequisite to consider that front-office applications of the enterprise is structured this way, and can publish what is described. It represents state of the practice, through usage of application servers, portals and process enactment systems.

430


Fig. 2. Front Office Application of a Network Member

A federated organization is a network where collaboration processes and business rules are not those of one member of the network, but those of the network, and where each member of the network has its own specific internal private organization, process and set of business objects. A Collaborative platform for federated organization is a place where collaboration processes can interconnect legacy application systems, through different means such as service publication and consumption or service composition. In addition, it should allow business information exchange and sharing a secured way, on the basis of a common business language. It is important to point that such a platform does not correspond to the model of Extended Enterprise, which is just an extension of the enterprise boundary to enterprise external actors.

Fig. 3. Collaborative Platform for federated organization


431

3.2 Collaborative Platform Specifications

The network collaboration platform for federated organization is providing collaboration execution platform, with business logic containers including heterogeneous sets of shared and private heterogeneous and aggregated business data and metadata, which can be used and accessed through application server, process enactment systems and user application interaction enactment. In addition, it provides a shared governance platform based on enterprise business computer independent models. It also provides collaboration modelling platform for executable business models, shared business services and information business models. It provides a development platform that allows to make the link between the business models and the application models, but also to implement when required the business logic. Two other components are a resource repository (services, models, processes) and a communication and transformation platform. All these platforms are interconnected in order to support roundtrip transformations between enterprise models, application models and execution platforms. They are each providing set of services such as governance services, modelling time related services, business runtime services, and finally transversal enactment services. Complementary services that are not domain specific, such as security, authentication, transactions, etc… are also addressed through services that are plugged on business containers (CCM/EJB models for application servers).

Fig. 4. Platform architecture requires semantic preservation and aggregation

First principle is the business logic alignment between enterprise models of the governance, the modelling, the development and the business logic container of the execution platform, and the semantic preservation between formal representations on each of these platforms. Second principle is the simultaneous existence within

432


the collaboration system of aggregated heterogeneous business logic, data and schemas. 3.3 Enabling Concepts: Extended Multi-ground Hyper Models for Heterogeneous Grounds

The modelling platform to provide is not a simple application modelling platform as it should be able produce annotated CIM, PIM and PSM models, with capability to import and export models using different modelling languages. The roundtrip transformation should be possible in order to maintain coherency between models, code and binaries. Finally, some semantic mediation and transformation should be possible to exchange information between the different members of the network, but still again being able to perform reverse transformation and reconciliation of models and data. As part of the federation framework, concepts were defined for a metamodelling workshop to respond to all these needs. First the concept of modelling “ground” was defined. A modelling ground is a concrete modelling environment, based on a modelling paradigm with associated standardized language. Some activities, services and tools are associated to this modelling “ground” aiming to implement a vision of the community that defined this paradigm and associated standards. It is for example the object paradigm, with as associated standards UML that is dedicated to software engineering with representation of several aspects of an application (usage with use cases, object with class diagrams, sequence with dynamic diagrams, and deployment with deployment diagrams). A concrete ground could consequently be Eclipse environment with UML2 plug-in, based on UML 2.1, XMI 1.4 [9] and EMF 2.0. Another modelling “ground” is for example Protégé 3.3, based on the semantic web paradigm and OWL 1.0[10], RDF schema, SparQL and OWL-S standards. Second concept is the semantic preservation of the business concept. For users of an application, the way a business object was logically defined in order to be interpreted by a computer is not important. For example a “person” concept remains the same being modelled as a UML class, a OWL class, an EXPRESS entity or an XSD entity. So when a conceptual business model is moved between different “grounds”, a risk exist to loose semantic due to “impedance” mismatch, i.e. to the lost of information when translating from one language to an other, as they are not equivalent. The idea to avoid semantic lost is to extend the idea developed by hypermodel, in order to support preservation of the semantic of the business models when moving the model from one ground (e.g. meta-workshop UML2) to an another ground (e.g. meta-workshop OWL). The idea is also to be able to import business models formalized on other grounds (e.g. Product Data Exchange based on EXPRESS models) but being able to keep track of the original modelling concepts. For example, if reusing an application protocol express schema containing an entity “Person”, the resulting UML class person should keep track of the fact it can be considered as a STEP entity within the model. Of course, it is true for class concept, but also for all the other modelling concepts and their relationships.


433

Fig. 5. Semantic Preservation of Business Concept Person within different grounds

So in a collaboration space federating numerous and heterogeneous systems, with important information flow and roundtrip generation, it is very important not to loose information in order to have a coherent system. It is about impossible with business model translation from one language to another, except if keeping track of the original language constructs with additional information concerning details that are lost during the transformation and allowing to make the reverse transformation So a concrete federation framework is considered as a set of “grounds” for modelling, coding or execution that have to be robust in term of standards compliance, in order to allow usage of several paradigms and associated modelling language within the collaboration space. Such an approach should resolve some issues related to technology silos and to be able to mix usage of different technological framework.

4 Application to a Product Lifecycle Management Collaborative Platform These principle have been applied for establishment of a Collaborative PLM federated organization, with as business information models of reference STEP application protocols, with ass business service of reference PLM services and collaborative process of reference some collaborative processes such as Engineering Data Package, Change and Configuration Management or co-revue of a product. It is currently evaluated through an industrial research called SEINE[22]. A Networked Collaborative Product Development Platform for collaboration is being defined and developed, extending the one defined in Aerospace ATHENA pilot, with in particular an application server based on EJB3 for execution platform

434


and a Model Based development platform based on AndroMDA and UML2 profiled modelling for enterprise application on the WEB. Finally STEP application protocols semantic preservation between modelling and execution platform is currently being addressed. EXPRESS UML2 profile was defined, allowing transforming application protocol as UML models, stereotyped as EXPRESS model in one hand (CIM provenance) and as EJB entities and Value Objects in the other hand (PSM targets). A similar way to annotate the model with a OWL UML2 profile, derived from OMG ODM, is under development in order to be able to easily export the extended hypermodel on Protégé 3.3 ground.

5 Conclusion and Perspectives Numerous component solutions exist for establishment of open and standards based collaboration platform aiming to respond to emerging needs for fast establishment of collaboration for federated organization allowing interconnection of involved enterprise information system. The federation framework currently proposes ways to address it, including federated organization model of reference, standards based platforms specification, principles and finally innovative concepts for extended hyper-models allowing semantic preservation on heterogeneous grounds. This framework, that is being developed iteratively, needs to be extended in order to take into consideration not only information models, but also service and process models. Some investigation should be done on data themselves (as managed individuals or object instance). These extensions will be described in future papers. Once robustness demonstrated, methodological approaches will be defined for the different actors involved on establishment and usage of the collaboration space.

References [1]

[2]

[3] [4] [5] [6] [7]

[8] [9]

Figay, N, “Technical Enterprise Applications interoperability to support collaboration within the Virtual Enterprise all along lifecycle of the product”, I’ESA2006 Doctoral Symposium Figay, N, « Collaborative Product Development :EADS Pilot Based on ATHENA results », 2006, within “Leading the web in concurrent engineering – Next Generation Concurrent Engineering”, IOS Press, ISBN I-58603-651-3 CORBA - http://www.omg.org/gettingstarted/history_of_corba.htm PLM services - http://www.prostep.org/en/standards/plmservices/ ManTIs - http://mantis.omg.org/index.htm WSDL http://www.w3.org/TR/wsdl ISO 10303-11:1994 Industrial automation systems and integration -- Product data representation and exchange -- Part 11: Description methods: The EXPRESS language reference manual XML Schema, http://www.w3.org/TR/xmlschema-0/ XML Metadata Interchange, http://www.omg.org/technology/documents/modeling_spec_catalog.htm#XMI 2

2

3

2


435

[10] OWL Web Ontology Language Overview, http://www.w3.org/TR/owl-features/, in June, 2006. Web Ontology Language – Description Logic, http://www.w3.org/2004/OWL/ [11] SparQL - http://www.w3.org/TR/rdf-sparql-query/ [12] UML Unified Modeling Language http://www.omg.org/technology/documents/formal/uml.htm [13] ATHENA - http://www.athena-ip.org [14] F. Baader, D. Calvanese, D. McGuinness, D. Nardi, & P. Patel-Schneider (eds) The Description Logic Handbook, Theory, Implementation and Applications, Cambridge University Press, United Kingdom, (2003) 555 pp. [15] ATHENA Aerospace piloting Web Site : http://nfig.hd.free.fr [16] MDA: Model Driven Architecture Official web site: http://www.omg.org/mda/ [17] Virtuoso web site: http://virtuoso.openlinksw.com/wiki/main/Main/VOSSPARQL [18] Pellet web site: http://pellet.owldl.com/ [19] Object Management Group at http://www.omg.org [20] OpenDevFactory as part of the Usine Logicielle project at http://www.usinelogicielle.org [21] Papyrus UML at http:// http://www.papyrusuml.org/ [22] S.E.I.N.E. at http:// http://seine-plm.org/ [23] Enterprise Java Beans specification at http://java.sun.com/products/ejb/docs.html [24] PLCS web site at http://www.plcs-resources.org/ [25] Eclipse Europa at http://www.eclipse.org/ 3

3

3

3

4

4

4

4

4

5

5

5

5

5

6

6

Contribution to Knowledge-based Methodology for Collaborative Process Definition: Knowledge Extraction from 6napse Platform V. Rajsiri1, A-M. Barthe1, F. Bénaben2, J-P. Lorré1 and H. Pingaud2 1

2

EBM WebSourcing, 10 Avenue de l’Europe, 31520 Ramonville St-Agne, France {netty.rajsiri, anne-marie.barthe, jean-pierre.lorre} @ebmwebsourcing.com Centre de Génie Industriel, Ecole des Mines d’Albi-Carmaux, 81000 Albi, France {benaben, pingaud}@enstimac.fr

Abstract. This paper presents a knowledge-based methodology dedicated to automate the specification of virtual organization collaborative processes. Our approach takes as input knowledge about collaboration coming from a collaborative platform called 6napse developed by EBM WebSourcing, and produces as output a BPMN (Business Process Modeling Notation) compliant process. The 6napse platform provides knowledge to instantiate the ontology to contribute to the collaborative process definition. The ontology is in the collaborative network domain, consisting in (i) collaboration attributes, (ii) description of participants and (iii) collaborative processes inspired from the enterprise Process Handbook (MIT). Keywords: Ontology based methods and tools for interoperability, Tools for interoperability, Open and interoperable platforms supporting collaborative businesses

1 Introduction Nowadays companies tend to open themselves to their partners and enter in one or more networks in order to have access to a broader range of market opportunities. The heterogeneities of partners (e.g. location, language, information system), the long-term relationships and establishing mutual trust between its partners are the ideal context for the creation of collaborative networks. The interoperability is a possible way toward the facilitation of integrating networks [6] [18]. General issue of each company in collaboration is to establish connections with their partners. Partners have no idea about what their collaboration will exactly be but they know what they are waiting for from the collaboration. This means that

438

V. Rajsiri, A-M. Barthe, F. Bénaben, J-P. Lorré and H. Pingaud

partners can express informally and partially their collaboration requirements (knowledge). But, how to make these requirements more formalized and completed? In principle, partners collaborate through their information system. The concept of collaborative information system (CIS) has been evolved to deal with the interoperability issues. According to [16], this concept focuses on combining the information systems of different partners into a unique system. Developing such a CIS concerns the transformation of a BPMN collaborative process model into a SOA (Service Oriented Architecture) model of the CIS. This is comparable to the Model Driven Architecture (MDA) approach [9], as discussed in [17]. The BPMN supports the Computation Independent Model (CIM) of the MDA, while the SOA-based CIS supports the Platform Independent Model (PIM) of the MDA. Consequently, our research interest concerns the CIM model. The main focus is to formalize the informal and partial knowledge expressed from the partners in form of BPMN relevant process. But, how do we obtain the BPMN? The answer is shown as follows:

Fig. 1. Our approach for defining a BPMN collaborative process

The schema above shows our approach composing of (i) two gathering methods: interview and knowledge extraction, (ii) two repositories: collaboration characteristics (participant and collaboration) and collaborative processes, and (iii) a transformation. The approach starts at gathering knowledge by interviewing or extracting from a platform called 6napse. This knowledge will be classified and kept in corresponding repositories. Main difference between these two gathering methods is that the interview provides knowledge about the participants (e.g., name, role, business, service) and their collaborations (e.g., relationship, common objective) for the characteristic repository, while the extraction from 6napse provides not only the same knowledge as interview, but also the collaborative process (e.g., CIS, CIS services). Both repositories allow to analyze, keep and construct knowledge in form of collaborative process. Defining these two repositories requires implementing a knowledge-based methodology. This methodology uses ontology and reasoning to automate the specification of collaborative processes. The ontology covers the collaborative network domain which maintains the repositories of collaboration characteristics and collaborative processes, as shown in Fig. 1. The reasoning methodology

Contribution to Knowledge-based Methodology for Collaborative Process Definition

439

establishes the interactions between the repositories in order to fulfill the building of collaborative processes. The paper is focused firstly on introducing 6napse platform. Secondly, the ontology describing the collaborative network domain will be presented. Finally, the knowledge extraction from the platform and an application scenario will be discussed.

2 6napse Collaborative Platform The global evolution makes the enterprises to open themselves to their partners. The necessity of creating network depends on various elements, for example, competition, communication, complexity of products. The collaboration is set up around business tools corresponding to a collaborative process between the enterprises (e.g., group buying services, supplier-customer services). The actual market offers many collaboration tools addressing various functionalities, for example, communication (i.e. e-mail, instance massager), sharing document (i.e. blogs), knowledge management (i.e. wiki, e-yellow pages) and project management (i.e. calendar sharing). However, one of the most required functionality from users is to be able to integrate directly their functionalities emerged from their proper activity domain to the platform as mentioned in [7]. EBM WebSourcing, an open source software provider, has been found in late 2004. Their business focuses on editing and developing the solutions dedicated to SME clusters. EBM WebSourcing is now developing a collaborative platform called “6napse”. 6Napse is a collaborative platform intended to enterprises that would like to work together. The main idea is to provide a trustable space for members to establish (or not) commercial relations among them. The platform will play the role of mediator between the information systems of the enterprises. It is different from the other actual products in the market because it is integrated the business services. The development of this platform is on a basis of the social network paradigm. It aims at (i) creating a dynamic ecosystem of enterprises which communicate by using the services provided by the platform (i.e. send/receive documents, send mails, share documents), (ii) creating a network by viral propagation in the same way as Viadeo, LinkedIn and (iii) being the first step which drive to integrate information systems of the partners and to define more complicated collaborative processes (i.e. supply chain, group buying, co-design). The third development aim led to the concept of CIS and the collaborative process definition by using the knowledge-based methodology (Fig. 1). The followings are some examples of functionalities that the platform offers to their members: x x x x

Registering the enterprise, the user. Login or logout of the user to the platform. Creating or consulting the profile of enterprise and user. Inviting partners to join network, creating a partnership and a collaboration.

440


x

Searching enterprises, services via keywords (i.e. service, localization, tag)

Through these offered functionalities, the members can create their partnerships and collaborate. The user of the 6napse platform will be an individual relevant to an enterprise. It means that an enterprise is considered as a frame grouping their individuals (employees). An enterprise can be also a reference for the external individuals because normally we need to recognize the enterprise before being able to identify their belonging personnel. The collaboration occurred on the platform is established at the individual level.

3 Collaborative Network Ontology (CNO) In Artificial Intelligence, according to [3], knowledge representation and reasoning aim at designing computer systems that reason about a machine-interpretable representation of the world, similar to human reasoning. A knowledge-based system maintains a knowledge base which stores the symbols of the computational model in form of statements about the domain, and it performs reasoning by manipulating these symbols. Our knowledge-based methodology lies on the above approach in order to deal with the collaborative process design. Fundamentally, the methodology of collaborative process design in our case starts at analyzing the input knowledge regarding collaborative behaviors of the participants and ends at providing a related BPMN collaborative process. The input knowledge we require for manipulating the methodology concerns the collaborative characteristics or behaviors of all involved partners of the network. This kind of knowledge is, for example, business sectors, services (competencies) and roles. This knowledge is extractable from the 6napse platform. We have already discussed about the platform in the previous section. The knowledge extraction will be presented in Section 4. After manipulating the methodology, what we are waiting for at the output are network participants, exchanged data, business services and coordination services. These elements are essential for designing a BPMN collaborative process. Thus, to make the methodology able to produce these elements, we need (i) to define ontology and rules describing the collaborative network domain and (ii) to use an inference engine to deduce these modeling elements from the input knowledge. According to [4], ontology is a specification of a conceptualization. It contains a set of concepts relevant in a given domain, their definitions and interrelationships. To define domain and scope of ontology, [8] suggested starting by answering several basic questions which concerns for example, the domain of interest, user and expected result of the ontology. Often developing ontology is akin to defining a set of data and their structure for programs to use. Problem-solving methods and domain-independent applications use ontologies and knowledge bases built from them as data. The domain of interest for developing an ontology that we focus is on the collaborative network domain especially for designing collaborative process. The


441

knowledge base built from this ontology will cover the two repositories shown in Fig. 1. It will be used in some applications by the consultants of EBM WebSourcing to suggest their clients a collaborative process relevant in given collaboration behaviors. There are three key concepts underlying the collaborative network ontology (CNO) which are (i) the participant concept, (ii) the collaboration concept and (iii) the collaborative process concept. What we need to define in an ontology is not only the concepts, relations and properties, but we need also to define rules that reflect the notion of consequence. The followings are some examples of rules in the collaboration domain: If decision-making power is equal and duration is discontinuous then topology is peer-to-peer or if role is seller then participant provides delivering goods. The following paragraphs describe these three concepts with their relations, properties and rules. The participant concept, see Fig. 2, concerns the descriptions about participant, which are the characterization criteria of collaboration [13]. A participant provides several services at high level (discussed in the collaborative process concept) and resources (e.g., machine, container, technology), plays proper roles (e.g., seller, buyer, producer) and has business sectors (e.g., construction, industry, logistic).

Fig. 2. RDF graph representing the participant concept

From the above figure, reasoning by deduction can be occurred for example between role and service. Role and service are not compelled to have both but at least one of them is required because they can be completed by each other by deduction. It means that related services will be derived from a given role and viceversa. For example, if role is computer maker then its services are making screen, making keyboard… The collaboration concept, see Fig. 3, concerns the characterization criteria of collaboration [13] and the collaborative process meta-model [17]. Common objective, resource, relationship and topology are the characterization criteria, while CIS and CIS services are a part of the collaborative process meta-model.

442


Fig. 3. RDF graph representing the collaboration attributes

A collaborative network has a common objective (e.g., group same products to buy together) and a CIS. A CIS has its own CIS services which can be generic (e.g., send documents/mails) or specific (e.g., select supplier service). A network can have several topologies which can be star, peer-to-peer, chain or combination of these three structures. Topology has duration and decision-making power characteristics. Central, equal or hierarchic power is a decision-making power. Duration can be continuous or discontinuous. A topology contains relationships which can be group of interest, supplier/customer or competition. Reasoning topology by deduction is for example, if decision-making power is equal and duration is discontinuous then topology is peer-to-peer, if decisionmaking power is hierarchic for whatever duration be then topology is chain. The collaborative process concept, see Fig.4, is an extension of the concepts developed by the MIT Process Handbook project [8] and also the value chain of [12]. The value concept provides a list of services describing competencies at very high level and generic (e.g., vehicle manufacturing, software development), while the Process Handbook provides business services (i.e. assemble components of computer) at functional level. A service can be divided into business service and coordination service. Business service explains task at functional level. Service can derive the business services that correspond to it. For example, if service is making keyboard then business services are assembling circuit board, testing board…

Fig. 4. RDF graph representing the service

The concept of dependencies (flows) of resources is also included. To deduce a dependency, according to [2], we consider possible combinations of services using resources. Each dependency can be associated a coordination service (i.e. manage flow of material from a business service to another). The concepts of dependency and coordination are related because coordination is seen as a response to problems


443

caused by dependencies. This means a coordination service is in charge of managing a dependency. For example, if the placing order service of a buyer produces a purchase order as output and the obtaining order service of a seller uses a purchase order as input then there is a dependency of resource between these two services and we can use the forwarding document coordination service to manage this dependency. Collaborative networks usually have several participants, resources, relationships and a common objective. Common objective achieves services which use resources and are performed mostly by proper roles of the participants. A relationship gets two participants together which its type is depended on the roles of the participants (e.g. if two participants play seller and buyer roles, the relationship will be supplier/customer). The following figure shows these expressions which unite the three above concepts together:

Fig. 5. Union of the participant, collaboration and collaborative process concepts.

Once the CNO has been informally defined, we need to formalize it with rigorous syntax and semantic language. OWL (Web Ontology Language), a W3C recommendation, is the most recent development in standard ontology languages. There are three OWL versions but the most appropriate one in our case is OWLDL (Description Logics) because it adapts to automated reasoning. It guarantees the completeness of reasoning (all the inferences are calculable) and logics. For using this language, we need an editor to create ontology’s elements (classes, relations, individuals and rules). We use the Protege which is an opensource OWL editor developed by Stanford University [11]. To reason the ontology, we use the inference engine Pellet which is an open source OWL-DL inference engine in Java, developed at the University of Maryland’s Mindswap Lab [15].

4 Knowledge Extraction from 6napse Platform The two previous sections have been described about the CNO and the 6napse platform. This section interests in using 6napse platform with the CNO as discussed in [1]. We focus on extracting knowledge from the platform, which will be used to instantiate the CNO. The beginning idea of using 6napse came from when partners have no perspective about what their collaboration is supposed to be or they would like to see it clearer, they can try to collaborate through 6napse. In principle, we try to extract knowledge and to find patterns behind the collaborations occurred on the 6napse. The extracted knowledge and patterns will

444


be used to improve existing collaborations and to define more complicated collaborative processes. In this section, we will discuss about the knowledge extraction from 6napse platform. Then, an application scenario will be presented by using a suppliercustomer use case. 4.1 2-level Knowledge Extraction

Extracting knowledge from 6napse can be occurred at two levels corresponding to the life cycle of the enterprise on the platform: individual registration and collaboration. The first level occurs when the enterprises register on the platform. The second level is when the enterprises collaborate or start exchanging data between their partners. The second one can occur once the first one has been done. We will detail the extractable knowledge at each level of the platform in comparison to the requirements of the ontology defined in Section 3. The individual registration level provides knowledge about the description of the participants concerning the enterprise itself which is seen as an organization. This knowledge is available immediately since the participants have individually registered themselves on the platform and will not be varied depending on the collaboration. We can find this knowledge on the “my company” and “my profile” pages of the platform. The table 1 compares the information that the ontology requires as input to what we can extract from the 6napse. Table 1. Requirements of the ontology vs. Extractable knowledge from 6napse Requirements of the ontology Name of participants Business sector Services Business services Relationships

Extractable knowledge from 6Napse Name of the enterprise Activity sector List of the services List of the business services (or function of the individual belonging to the enterprise) List of the partners

Following is an example of the information on the “service” tab of the “my company” page. The service tab shows the list of services which explain the competencies of the enterprise.


445

Fig. 6. Printed screen of a service tab of an enterprise

The collaboration level provides the source of knowledge concerning the enterprise which is considered as a member of the network. To enter the collaboration level, they need to declare their partnerships and create their collaborations (network) on the platform. This can occur once the individual registration of each enterprise has been done. After the individual registration, the enterprises can invite other 6napse’s members to be their partners in the network. Then, they can create their collaborations on the collaborative space of the platform. During the partners are collaborating (e.g., transferring documents) via the platform, we will extract their collaboration knowledge. Through this knowledge, we can understand what is happening in the real collaboration. This knowledge is available on the collaborative space which includes the “share service”. The knowledge we expect to extract in this level are, for example, number of participants in the network, CIS services they are using and documents transferred from one to others, see the table below. Table 2. Requirements of the ontology vs. Extractable knowledge from 6napse Requirements of the ontology Number of participants CIS services Transferred resources Business service Common objective Duration of the collaboration (continuous, discontinuous)

Extractable knowledge from 6Napse Number of members in a collaboration CIS generic services of the platform Documents shared on the platform Shared by (individual who shares the document) Description of why creating the collaboration Measurement of the duration of the collaboration

Following is an example of the knowledge on the “share” tab of a collaboration occurred on the platform. The share tab shows the documents transferring between partners of this collaboration.

446


Fig. 7. Printed screen of a collaboration occurred on the 6napse platform.

The knowledge extracted in this level is, for example, an individual named Laura shares the test case documents as same as Pascal who shares the how-to text to their partners. Comments can be written for each shared documents. However, some working environments force the users to reroute several times before finding the right information, for example, B needs to see the document shared by A before transferring to C. We cannot study the exchange flows of documents on the platform without taking the network topology and the type of relationship into account. This is significant for improving or defining more complicated collaborative processes afterwards. 4.2 Supplier-customer Scenario

To illustrate principles of knowledge extraction in this section, we introduce a customer-supplier use case. The input knowledge is extracted from the 6napse platform. Some reasoning examples will be shortly explained. The output result will be shown at the end. The tables 3 and 4 show the knowledge extracted from 6napse while registering and collaborating respectively. Table 3. Description of each participant in the network Participants

Business sector

M

Manufacturing

S

Part Manufacturing

W

Logistics

Services Making computers Sales Supplying the parts of computer Stocking materials and transporting to customers

Relationships S, W (supplier-customer) M (supplier-customer) M (supplier-customer)

Table 4. The extracted knowledge from 6napse while collaborating

Knowledge Nb of participants CIS services used Resources transferred

Extracted knowledge 3 Sharing documents, Mailing… Purchase order, bill, delivering detail, receipt, messages...


Business services Common objective Duration of collaboration

447

Identifying needs, transferring materials, paying… Fulfill the supply chain for manufacturing products to stock Continuous

The knowledge in the tables 3 and 4 is required as input of the ontology. It will be used to instantiate the ontology defined in the section 3. Once we have the input knowledge (instances in the ontology), we can derive first of all the topology and the characteristics of the network. This network has two chain topologies because, from the deduction, the decision-making power is hierarchic and the duration is continuous. We continue the collaboration definition by deducing the roles and business services. If there is any missing information at this level, this information will be completed by the ontology. In this case, for example, since M provides making computer and sales then M plays manufacturer role which performs identifying needs, receiving materials, paying and producing business services. Once the business services provided by the participants have been reasoned, what we need to do next is to derive all possible dependencies between business services belonging to different participants. This dependency brings to the deduction of the coordination and the CIS services in the collaborative process. After that, we can find if there are any services required in the collaboration that no any participant can be in charge of. If this is the case, we need to create the CIS services to perform these services. For example, the control and evaluation service cannot be done by any participant, so it will belong to the CIS. At the end, we have to deduce once again the dependency between the CIS services and the coordination services. The result is shown in the following figure:

Fig. 8. A solution of collaborative process of the network.

448


We have to remark that the collaborative process obtained at the end is just a solution for the given use case. It is always possible to have other solutions that meet to collaborative behaviors of the participants more than the proposed one.

5 Conclusion The 6napse collaborative platform is still on the development phase. It allows to extract knowledge before setting up collaborations. The contribution of the 6napse is dedicated to partners who have no idea about what their collaboration is supposed to be or would like to see it clearer. The partners can capitalize on their collaboration knowledge for better collaborating in the future. Also, it plays an important role for enriching the knowledge (instances) in the CNO in order to improve existing collaborations of the partners and define more complicated collaborative processes. The collaborative process obtained from the ontology (Fig. 8) is really near the BPMN compliant process but still not complete. There are some missing elements such as gateways and events. These elements are needed to be added in actual collaborative processes because they can make process more dynamic. Our current work is focused on firstly extracting knowledge from real collaborations occurred on the 6napse. Secondly, we address adding the dynamic aspect to the actual reasoning methodology by taking into account event and gateway elements. Also, the actual knowledge-based methodology, including its concepts, rules and reasoning steps is needed to be finalized and validated.

References [1]

[2]

[3] [4] [5] [6] [7] [8]

[9]

Barthe, A-M. : La plateforme 6napse – présentation et perspectives d’intégration de cet outil et du recueil d’informations qu’il autorise, Mémoire de Master Recherche, Génie Industriel de l’Ecole des Mines d’Albi-Carmaux (2007). Crowston, K.: A Taxonomy of Organizational Dependencies and Coordination Mechanisms (Working paper No. 3718-94): Massachusetts Institute of Technology, Sloan School of Management (1994). Grimm S., Hitzler P. and Abecker A.: Knowledge Representation and Ontologies: Logic, Ontologies and Semantic Web Language, Semantic Web Services. (2007). Gruber, T. R.: A translation approach to portable ontologies, Knowledge Acquisition, 5(2), pp.199-220 (1993). Katzy B., Hermann L.: Virtual Entreprise Research: State of the art and ways forward, pp.1-20 (2003). Konstantas D, Bourrières JP, Léonard M and Boudjlida N.: Interoperability of enterprise software and applications, INTEROP-ESA’05, Springer-Verlag (2005). Lorré, J-P.: Etat de l’art, EBM WebSourcing (2007) Malone, T.W., Crowston K., Lee J., Pentland B.: Tools for inventing organizations: Toward a Handbook of Organizational Processes, Management Science/Vol. 45, N° 3. (1999). Process Handbook Online : http://ccs.mit.edu/ph/ Millet J. and Mukerji J.: MDA Guide Version 1.0.1 (2003)., available on http://www.omg.org


449

[10] Natalya F.N. and Deborah L.M.: Ontology Development 101: A Guide to Creating Your First Ontology. Stanford University, Stanford, CA, USA. (2001) [11] Protege http://protege.stanford.edu (2000) [12] Porter M. : L’avantage concurrentiel, InterEdition, Paris, pp. 52 (1986). [13] Rajsiri V, Lorré JP, Bénaben F and Pingaud H.: Cartography for designing collaborative processes. Interoperability of Enterprise Software and Applications (2007) [14] Rajsiri V, Lorré JP, Bénaben F and Pingaud H.: Cartography based methodology for collaborative process definition, Establishing the Foundation of Collaborative Networks, Springer, pp. 479-486. (2007) [15] Sirin E., Parsia B., Grau B.C., Kalyanpur A. and Katz Y.: Pellet: A practical OWLDL reasoner, Journal of Web Semantics, 5(2). (2007) [16] Touzi J, Lorré JP, Bénaben F and Pingaud H.: Interoperability through model based generation: the case of the Collaborative IS. Enterprise Interoperability. (2006). [17] Touzi J, Bénaben F, Lorré JP and Pingaud H.: A Service Oriented Architecture approach for collaborative information system design, IESM’07. (2007). [18] Vernadat FB.: Interoperable enterprise systems: architectures and methods, INCOM’06 Conference. (2006).

SQFD: QFD-based Service Quality Assurance for the Lifecycle of Services Shu Liu, Xiaofei Xu and Zhongjie Wang Research Centre of Intelligent Computing for Enterprises and Services (ICES), School of Computer Science and Technology, Harbin Institute of Technology, 150001, Harbin, China {sliu, xiaofei, rainy}@hit.edu.cn

Abstract. Based on a service system, service providers offer services to customers. Quality of a service system has great influence on customer. Therefore in order to provide better services to customer, it is necessary to assure quality for the lifecycle of services. With the experiences accumulated in developing and implementing some typical IT systems in manufacturing enterprises from past decade, we have proposed a new service engineering methodology named SMDA, to assist service providers to build better service system. As part of the SMDA, the Service Quality Function Deployment (SQFD) has been proposed to consider quality aspects of a service system. SQFD, which is adopted from QFD, focuses on designing, evaluating and optimization of service quality in lifecycle of services. The three phases of SQFD, i.e., build-time QFD-oriented service quality design, run-time service performance evaluation and service performance optimization, are illustrated in this paper. Keywords: Quality and performance management of interoperable business processes, Service oriented Architectures for interoperability, Model Driven Architectures for interoperability

1 Introduction In the past decade the world economy has changed rapidly, especially in the advanced countries, a modern service centered economy is emerging with the growing GDP of service sector and advanced development of information technology. In order to gain advantages in the competition of the new economy attention has focused on service quality. While there have been efforts to study service quality, there have been no general agreement on the effective way to measure and improve service quality. One service quality measurement model that has been extensively applied is the SERVQUAL model developed by Parasuraman A, Zeithaml V, and Berry L L. The SERVQUAL instrument has been the predominant method use to measure

452

Shu Liu, Xiaofei Xu and Zhongjie Wang

consumers’ perceptions of service quality. The SERVPERF model is another service quality measurement instrument, was developed later by Cronin and Tayor, which inherited from SERVQUAL and expanded SERVQUAL. Both models have been focusing on service quality measurement lack of attention on service quality design and service quality assurance for the lifecycle of services. Under this atmosphere research center on Intelligent Computing for Enterprises and Services (ICES) of School of Computer Science and Technology in Harbin Institute of Technology (HIT) is one of the pioneers. With the rich experiences accumulated in developing and implementing some typical IT systems (e.g., ERP, SCM, CRM, etc.) in manufacturing enterprises from past decade, ICES proposed a new service engineering methodology named Service Model Driven Architecture (SMDA), to assist service providers to build their service systems in an MDA style, e.g., modeling customer requirements and gradually transforming models into a executable service system [1][2]. As part of the SMDA the Service Quality Function Deployment (SQFD) has been proposed to consider quality aspects of a service system. The SQFD was originated from Quality Function Deployment (QFD) which was developed at the Kobe Shipyard of Mitsubishi Heavy Industries, Ltd. as a way to expand and implement the view of quality. QFD has been widely applied in many industries worldwide, such as automobile, electronics, food processing, computer hardware and software ever since. SQFD focuses on service quality assurance for lifecycle of services includes service quality design, service system evaluation and optimization. The purpose of this paper is to illustrate the approaches of SQFD which is organized as following. The 2nd section explains service quality and SQFD in detail. In the 3rd section the build-time QFD-oriented service quality design was discussed. The run-time service quality evaluation and service lifecycle optimization are introduced in section 4 and 5 respectively. Finally is the conclusion.

2 Service Quality and SQFD 2.1 Service Model Driven Architecture

In order to understand the mechanism of SQFD it is necessary to explain the architecture of SMDA first. SMDA, a new service engineering methodology, contains three-layer service models and a service system, as showing in figure 1.

SQFD: QFD-based Service Quality Assurance for the Lifecycle of Services

Services Demand Acquirement

USML: Unified Services Modeling Language

Service Requirements Model

SRM: Service Requirement Model

Service Process Model Capability Model

Services Design

SBCM: Service Behavior/Capability Model Service Modeling Process

Service Execution Model

Selecting Services Components

(Build time)

Services Component Sets

SEM: Service Execution Model

Evaluation On-Demand Services

Mapping Services Quality Evaluation

453

Service Performance

Implementation and Execution of Services Systems (Run time)

Instances of Services Components SES: Service Execution Systems

Fig. 1. The architecture of SMDA

The first layer of SMDA is Service Requirement Model (SRM), which captures Voice of Customer (VOC). The second layer, Service Behavior and Capability Model (SBCM) are used to design service behaviors and capabilities by transforming VOC defined in SRM. The Service Execution Model (SEM), the third layer of SMDA, further transforms service behaviors and capabilities from SBCM into executable service component sets by selecting appropriate service components. Then SEM is mapped to a Service Execution System (SES) of a specific service. There is a top-down transformation between models in SMDA by three mappings: SRM to SBCM, SBCM to SEM, and SEM to SES. The first two mappings are service modeling process, belong to build-time. And the third mapping is implementation and execution of services systems; belong to run-time [2]. 2.2 Service Quality in SMDA

Service quality is a concept that has aroused considerable interest and debate in the research literature because of the difficulties in both defining it and measuring it with no overall consensus emerging on either [3]. Among a number of definitions for service quality, one that is widely accepted defines service quality as the difference between customer expectation of service and perceived service. Analyzing and measuring the gap between customer expectation of service and perceived service is the starting point in designing and improving traditional service quality. Figure 2 is a conceptual model of service quality with 5 major gaps, which was proposed by Parasurman, Zeithaml and Berry. As shown in the figure gap 5 is the discrepancy between customer expectations and their perceptions of the service delivered, which is the sum of other 4 gaps. In order to improve service quality in traditional service, the efforts have to be focused on reducing the gap 5, which is necessary to be able to measure gap 1~ 4 and reduce each of them.

454


Fig. 2. Gaps in Service Quality in Traditional Service

With similar approach the conceptual model of the service quality of SMDA is proposed with 5 major gaps, as shown in figure 3.

Fig. 3. Gaps in Service Quality of SMDA

x x x

Gap1: the difference between customers expected quality of service and quality characteristics captured in SRM. Gap2: the difference between quality characteristics captured in SRM and quality characteristics transformed in SBCM. Gap3: the difference between quality of SBCM and transformed in SEM.


x x

455

Gap4: the difference between quality of SEM and external communications to customers. Gap5: the difference between customers expected service quality and customer perceived service quality of service systems.

As seeing in figure 3, to improve service quality of SMDA the key is reducing gap5. Since the gap5 is the sum of other 4 gaps, to reduce each gap become the ultimate goal. As part of SMDA the SQFD was proposed to capture VOC and transform through SRM to SBCM to SEM, finally to service execution system (SES). 2.3 SQFD

Traditional quality evaluation systems aim at minimizing negative quality such as eliminating defects or reducing operational errors. QFD is quite different in that it seeks out customer requirements and maximizes "positive" quality by designing and transforming quality factors through product development process [4]. QFD facilitates translation of a prioritized set of subjective customer requirements into a set of system-level requirements during system conceptual design [5]. Then further translate system-level requirements into more detailed set of requirements at each stage of the design and development process [6]. SQFD is proposed with a similar approach, it translates a set of customer requirements of a service into an executable service system through the service modeling process. SQFD consist of three phases: x x x

Build-time QFD-oriented service quality design Run-time service quality/performance evaluation Service quality/performance optimization

As shown in Figure 4, the service quality design process is depicted along black arrows. VOC is captured in Service Level Agreement (SLA) through negotiation between customers and service providers. As input to SRM, the Quality aspect of VOC is transformed though SBCM and SEM into service system by QFD approach. Through the performance monitoring, data collection, and evaluation the red arrows depict the service optimization process of the service system.

456


Fig. 4. Structure of SQFD

3 Build-time QFD-oriented Service Quality Design As core of QFD, the House of Quality (HoQ) can be used to incorporate VOC into every manufacturing activity. There are four levels of quality house were proposed in typical manufacturing case as shown in Figure 5. It helps to trace what design engineers and manufacturers do for what customers want [7].

Fig. 5. The Four Houses of QFD

With the similar approach the three levels of quality house have been designed with each level corresponding to one of the model in SMDA, as shown in figure 6.


457

Fig. 6. The three levels of SHoQs

The three-level service house of quality (SHoQ) incorporates customer’s voice into every modeling activity of SMDA. It helps to make customer an integral part of early design synthesis and evaluation activities. In building each level of the quality house of SQFD, four dimension views of SMDA should be considered, as shown in table 1. Table 1. Modeling Views in SMDA Models SRM

SBCM

SEM

Service Provider Customer (S-PC View) Service Behavior View (SB View) Service Action View (SA View)

Four dimension views SMDA Service Service Resource Organization View View (SR View) (SO View) Service Role Service Capability View View (SL View) (SC View) Capability Service Configuration Participation View View (CC View) (SP View)

Service Information View (SI View) Service Information View ((SI View)) Service Information View ((SI View))

HoQ of SQFD Level-1 SHoQ

Level-2 SHoQ

Level-3 SHoQ

The level-1 SHoQs is used to capture “Voice of the Customer” for specific service and transform them into SRM with top-down approach. Identification and extraction of customer’s essential needs are the first step in building house of quality. In the customer requirement acquisition, methods such as interviews, surveys, market investigation, and trend analysis are often used, it is important to ensure that complete, consistent, nonredundant, and true customer requirements are identified and specified [8][9]. When building the Level-1 SHoQ. the four dimensions of SRM should be considered include Service-Provider-Customer View, Service Organization View, Service Resource View, and Service Information View. Figure 6 (a) depicts the level-1 SHoQ, it takes the values and risks extracted from requirements of customers as the inputs of the SHoQ, and outputs the quality targets for each task of specific service.

458


The level-2 SHoQs take the outputs from the level-1 as its inputs and transform them into SBCM with top-down approach. Figure 6 (b) depicts the level-2 SHoQ of the four View, it takes output of target values for each task from level-1 as input and outputs target values for each behavior of specific task. Level-3 SHoQ takes target values of each behavior from the level-2 as its inputs and transforms to target values for each action of specific behavior by topdown approach, as shown in figure 6 (c). Meanwhile, the bottom-up approach is also used to select available service components with different granularity to meet the target values of task/behavior/action.

4 Run-time Quality/Performance Evaluation Figure 7 depicts the Run-time quality/performance monitoring mechanism. Service system in run-time, the monitoring software automatically sends queries and receives reports from different service component environments periodically. The system run-time Key Performance Indicators (KPIs) will be evaluated based on collected data. The service system quality/performance can be evaluated from three aspects with different granularity as shown in figure 8. KPIs of service components are collected and evaluated; KPIs of service orchestration are collected and evaluated; KPIs of service choreography are collected and evaluated. The results from runtime quality/performance evaluation are analyzed for further service system optimization.

Fig. 7. Run-time quality/performance monitoring


459

Fig. 8. Aspects of service quality/performance evaluation

5 Service Quality/Performance Optimization Service quality/performance optimization is the third phase of SQFD, it is a reversed process compare to service quality design as shown in figure 9. Blue arrows represent the quality design process and the red arrows with opposite direction represent the optimization process. The gaps between customer expected service quality from SRM and customer perceived service quality from service system are identified, analyzed, and traced backward to early phase for reasoning the causes. In order to improve the quality of service system efforts are made to optimization by considering re-design, re-configuration, and or re-negotiation. This closes the loop of quality assurance for lifecycle of services. SRM Performance

SRM (System)

SBCM Performance

SBCM (System)

Expected Service Quality Gap

SEM Performance

SEM (System)

SQFD based quality design

Service System Performance

Service System

Reversed SQFD based quality optimization

Fig. 9. Service quality/performance optimization of SMDA

Perceived Service Quality

460


6 Conclusion In this paper, based on SMDA a SQFD method is proposed to ensure service quality for the lifecycle of services. There are three phases in SQFD which includes service quality design, service quality evaluation, and service quality optimization. The QFD method is adopted and applied to design service quality by building three levels of quality houses. Run-time based service quality evaluation and optimization is also depicted briefly. Further research work include: refining of SQFD based on real case study; defining quality parameter sets for specific typical service sectors etc.

Acknowledgement Research works in this paper are partial supported by the National High-Tech Research and Development Plan of China (2006AA01Z167, 2006AA04Z165) and the National Natural Science Foundation (NSF) of China (60673025).

References [1]

[2]

[3] [4] [5]

[6]

[7]

[8]

[9]

Xiaofei Xu, Zhongjie Wang, Tong Mo. SMDA: a New Methodology of Service Engineering. 2006 Asia Pacific Symposium on Service Science, Management and Engineering. Nov. 30-Dec. 1, 2006, Beijing, China Xiaofei Xu, Tong Mo, Zhongjie Wang. SMDA: A Service Model Driven Architecture. the 3rd International Conference on Interoperability for Enterprise Software and Applications. Mar. 28-30, 2007, Madeira Island, Portugal Parasuraman A., Zeithaml V.A., Berry L.L.. A conceptual model of service quality and its implication. Journal of Marketing. 1985 Vol. 49 Fall, pp. 41~50 Xiaoqing Frank Liu. Software Quality Function Deployment. IEEE POTENTIALS Jong-Seok Shin, Kwang-jae Kim, M. Jeya Chandra. Consistency check of a house of quality chart. International Journal of Quality & Reliability Management. Vol. 19 No. 4, 2002, pp. 471~484 Kwai-Sang Chin, Kit-Fai Pun, W.M. Leung, Henry Lau. A quality function deployment approach for improving technical library and information services: a case study. Library Management. Jun 2001 Volume: 22 Issue: 4/5 Page: 195~204 A. Ghobadian, A.J. Terry. How Alitalia improves service quality through quality function deployment. Managing Service Quality. 1995 Volume: 5 Issue: 5 Page: 31~35 Anne M. Smith, Moira Fischbacher, Francis A. Wilson. New Service Development: From Panoramas to Precision. European Management Journal. October 2007 Vol. 25 No. 5, pp. 370~383 Eleonora Bottani, Antonio Rizzi. Strategic Management of Logistics Service: A Fuzzy QFD Approach. Int. J. Production Economics 103 (2006) 585~599

Coevolutionary Computation Based Iterative MultiAttribute Auctions Lanshun Nie, Xiaofei Xu, Dechen Zhan Harbin Institute of Technology, Harbin 150001, P.R. China {nls, xiaofei, dechen}@hit.edu.cn

Abstract. Multi-attribute auctions extend traditional auction settings. In addition to price, multi-attribute auctions allow negotiation over non-price attributes such as quality,terms-ofdelivery, and promise to improve market efficiency. Multi-attribute auctions are central to B2B markets, enterprise procurement activity and negotiation in multi-agent system. A novel iterative multi-attribute auction mechanism for reverse auction settings with one buyer and many sellers is proposed based on competitive equilibrium. The auctions support incremental preference elicitation and revelation for both the buyer and the sellers. Coevolutionary computation method is incorporated into the mechanism to support economic learning and strategies for the sellers. The myopic best-response strategy provided by it is in equilibrium for sellers assuming a truthful buyer strategy. Moreover, the auction are nearly efficient. Experimental results show that the coevolutionary computation based iterative multi-attribute auction is a practical and nearly efficient mechanism. The proposed mechanism and framework can be realized as a multi-agent based software system to support supplier selection decision and/or deal decision for both the buyer and the suppliers in B2B markets and supply chain. Keywords: Socio-technical impact of interoperability, Decentralized and evolutionary approaches to interoperability, Enterprise application Integration for interoperability

1 Introduction Auctions are important mechanisms for allocating resources and services among agent[1]. It has found widespread use as a technique for supporting and automating negotiations in business-to-business online markets, industrial procurement and Multi-Agent System. Multi-attribute auctions [2, 3] extend the traditional auction setting to allow negotiation over price and non-price attributes such as quality and terms-of-delivery, and promise to improve market efficiency in markets with configurable goods. Traditional auction mechanisms, such as the English, Dutch, First(or Second) price Sealed-Bid auction, can’t be extended straightforwardly to

462

Lanshun Nie, Xiaofei Xu, Dechen Zhan

the multi-attribute settings, because there is private information in both sides of the auction. Several researchers have considered attributes other than price in the procurement setting from a purely theoretical perspective. Most of them adopt mechanism design theory and focus on the agent’s best-response strategy. Che [2] first studies the optimal auction when there are only two attributes, price and quality. He proposes a buyer payoff-maximizing one-shot sealed-bid auction protocol with a first price and a second price payoff function. Branco [4] extends this protocol to the case where the seller cost functions are correlated. Milgrom [5] has shown that efficiency can be achieved if the auctioneer announces his true utility function as the scoring rule, and conducts a Vickrey (second-price sealedbid) auction based on the resulting scores. Beil and Wein [6] propose an iterative payoff-maximizing auction procedure for a class of parameterized utility function (with K parameter) with known functional forms and naive suppliers. The buyer uses K rounds to estimate the seller cost functions deterministically. For the final round they design a scoring function so as to maximize buyer payoff. Although theoretical progress has been made, there are some limitations:(1) Agents are required to have complete information about their preference. However, preference elicitation is often costly and bidders would prefer not to determine an exact value tradeoff across all different combinations of attribute levels. (2) Agents are required to reveal a great deal of private information. However, they would prefer to reveal as little information as possible about costs and preferences. (3) Agents are often required to have complete rationality. Another approach to auction problem is competitive equilibrium theory. In this model an agent plays a best-response to the current price and allocation in the market without either the strategies of other agents or the effect of its own actions on the future state of the market. Iterative auction mechanisms based on it, which allow agents to provide incremental information about their preference, are especially important in application of multi-attribute auctions. Research about this is just beginning. As far as we know, only Parkes and Kalagnanam [3] propose a iterative primal-dual based multi-attribute auction mechanism for reverse auction settings. The auctions are price-directed. A myopic best-response strategy is in equilibrium for sellers assuming a class of consistent buyer strategies. The auctions are efficient with a truthful buyer. In this study, we propose an iterative multi-attribute auction mechanism based on competitive equilibrium theory. Coevolutionary computation method [7] is incorporated into the mechanism to support economic learning and strategy for the sellers. Section 2 formulates general multi-attribute auction problem. Section 3 introduces an iterative auction mechanism for it. Coevolutionary computation based multi-attribute auction method is presented in Section 4. A computation result is reported in Section 5. We discuss some characteristics of the proposed mechanism in Section 6.

Coevolutionary Computation Based Iterative Multi-Attribute Auctions

463

2 Multi-attribute Auction Problem In the multi-attribute auction problem there are N sellers, one buyer, and M attributes. Let I denote the set of sellers, and J denote the set of attributes. Each attribute, jJ, has a domain of possible attribute values, denoted with 4j. The joint domain across all attributes is denoted 4=41u42u}u4M. For an attribute bundle, T4, each seller, iI, has a cost function, ci(T)t0, and the buyer has a value function, v(T)t0. We restrict our attention to the problems in which a single buyer negotiates with multiple sellers in a reverse auction, and will eventually select a single seller. Also, we assume that agents have quasilinear utility functions. The utility to seller i for selling an item with attribute bundle T at price p is the difference between the price and its cost, i.e. u i (T , p ) p ci (T ) . Similarly, the utility to the buyer for buying an item with attribute bundle T at price p is the difference between its value and the price, i.e. u B (T , p ) v(T ) p . We believe that efficiency is a more appropriate goal for multi-attribute auction since it is usually applied in business to business market and procurement activity[3]. In addition to efficiency, individual-rationality, budget-balance, low rationality requirement to agents are all desirable properties of a multi-attribute auction mechanism.

3 Iterative Multi-attribute Auction Mechanism We propose the following iterative mechanism(IMA) for the multi-attribute auction problem. Step 1 The buyer announces minimal constraints to bids, maximal round MAX_R, the number of bids OPT in each round, the number of rounds for quit QUIT_R. The current round CUR_R=0. Each seller submits an initial bid. Step 2 The buyer determines the best bid for this round BestbidCUR_R and announces it to the sellers. Step 3 CUR_R++. Each seller (i), except the one providing BestbidCUR_R-1, proposes at most OPT new bids to the buyer and the buyer returns the result whether these bids are better than BestbidCUR_R-1. If some proposed bids are better than BestbidCUR_R-1, seller i selects one of them as the bid of this round. Else, i.e. no bids are better than BestbidCUR_R-1, count the number of consecutive rounds seller i failed, if it is larger than QUIT_R, seller i loses. Step 4 If there is only one active seller, this seller win. The deal result is BestbidCUR_R-1. And the whole auction terminates in success. Step 5 If CUR_R<MAX_R, goto Step 2; else, the whole auction terminates in failure. In mechanism IMA agents don’t have to know complete information about their preference. Preference elicitation is only on demand when a new bid is proposed. They can simply compare the bids without knowing and determining their exact utility values. Little information is revealed in IMA. The sellers learn the

464


preference of the buyer through interaction and information exchange, and improve the bids in order to find the deal with high efficiency. At the same time, since the buyer selects only one seller, the relationship between sellers are completely competitive and no collusion will happen[8]. So, every seller struggles to propose bid which the buyer prefer in order to win and maximizes his utility. We assume that the buyer is truthful, i.e. the buyer’s utility is achieved through natural competition between the sellers rather than cheat. This is reasonable for the long-term market design and cooperation between enterprises. As concerned as the sellers, preparing a bid that matches the auctioneer’s requirement, which is better than the bids of other seller agents and also maximizes the seller agent’s utility is a sophisticated task when it does not completely know the buyer’s preference and other sellers’ cost. So learning capability and strategy capability is critical to the seller agent.

4 Coevolutionary Computation Based Multi-attribute Auction Agent-based computation economics (ACE) [9] is the computational study of economies modeled as evolving systems of autonomous interacting agents. In recent years, ACE has become a powerful tools for mechanism design. Coevolutionary computation is a dominant approach of ACE. In this study, we incorporate ACE tools into multi-attribute auction problem and propose a coevolutionary computation based multi-attribute auction model for the first time. In doing so, two important goal can be achieve. First, the auction mechanism IMA is simulated appropriately and the performance of it is evaluated. Second, we provide a powerful tool for supporting the strategy of the seller agents in the mechanism IMA. Coevolutionary computation is developed from traditional evolutionary algorithms, which simulates the coevolutionary mechanism of the species in nature and adopts the notion of ecosystem. Multiple species coevolve and interact with each other and result in the continuous evolution of the ecosystem. The species are genetically isolated–individuals only mate with other members of their species[7, 10]. Coevoluationary computation model for iterative multi-attribute auction mechanism IMA is shown in Fig. 1. Each seller in the auction is represented by a species in the ecosystem. Each species evolves a bundle of individuals, which represent the bidding strategies of the corresponding seller. Each species is evolved through the repeated application of a conventional evolutionary algorithm. The buyer is represented by the buyer agent. Fig. 1 shows the fitness evaluation phase of the evolutionary algorithm from the perspective of species 1. To evaluate an individual (bidding strategy) from species 1, collaboration is formed with representatives (representative bidding strategy) from each of the other species. Buyer agent determines whether this individual is better than other representatives and returns the result to species 1. Then species 1 can use the result to evaluate the fitness of its individual. Here the fitness is the utility to the corresponding seller provided by this individual if it wins. There are many possible methods for


465

choosing representatives, for example, the current best individual, or a random individual[10].

Fig. 1. Coevoluationary Computation Framework for IMA mechanism

The coevolutionary computation procedure, entitled IMA-CGA, for the iterative multi-attribute auction mechanism IMA is as follows, in which the evolution of each species is handled by a standard Genetic Algorithm. Pseduo-code of IMA-CGA k=0 for each species i do begin initialize the parameters of the species' GA initialize the species' population

Pop 0i

evaluate fitness of each individual Ind 0i , n in Pop 0i end while termination condition=false do begin for each species i do begin choose a representative Re pki from Popki reproduction from

Popki to get Mateki

crossover and mutation from

Mateki to get Popki 1

evaluate fitness of each individual Ind ki ,n1 end k=k + 1 end output the winner and the bid

in

Popki 1

Here the details of the species’ fitness evaluation procedure and the buyer agent’s winner determination procedure are omitted since they are straightforward. The key variables, data structure and procedure of IMA-CGA are defined as follows: k is the generation counter of the evolutionary process, and it corresponds to CUR_R. n is sequence number of individuals in a species. Every individual corresponds to a bidding strategy, which is composed of the value of price and

466


non-price attributes. Every attribute is encoded in a chromosome. Simple roulette wheel selection strategy is used for reproduction. Uniform strategy is used for crossover. Swap strategy is used for mutation. The current best individual is selected as the representative of each species. This is consistent with the selfinterested nature of the sellers and also accelerates the speed of evolution. If the fitness of all the individuals of a species are zero for the last QUIT_R consecutive generations, the corresponding seller loses and is thrown out from the auction. When the last competitor quits, the seller left is the winner, and the winning bid is the representative proposed by it in the last generation. Of course, if k is large than MAX_R of IMA, the auction terminates in failure. The coevoluationary computation model completely simulates the iterative multi-attribute auction mechanism IMA, including the buyer, the sellers, the competition between the sellers, the interaction between the buyer and the sellers, and the iterative auction procedure. At the same time, the coevolution of the species provides the corresponding seller with economic learning capability and strategy capability, so the strategy of the sellers in IMA can be supported by this tool.

5 Computational Results The problem in Beil [6] is adopted here to illustrate our mechanism because the buyer value function and the seller cost functions are all complex and nonliear. This problem has N=2 sellers and one nonprice attribute, quality. The cost function of seller 1 is q3+4q15, the cost function of seller 2 is 2q+q3, and the value function of the buyer is 5q0.9. The IMA-CGA is implemented in C++ based on GALib[11]. The price and quality attribute are encoded in real. The size of population is 50. The crossover probability is set to 0.9, and the mutation probability is 0.1. QUIT_R is set to 3. When a bid provides the buyer with a 0.1 higher utility than the other, the bid wins. The problem is solved by IMA-CGA and the procedure is shown in Fig. 2. In Fig. 2, S1U and S1toB represent the utility to the seller 1 and the buyer, respectively, provided by the best individual of this generation. S2U and S2toB represent the utility to the seller 2 and the buyer, respectively, provided by the best individual of this generation. The competition and interaction between the two sellers are mainly reflected in the trend of S1toB and S2toB. As a whole, competition from the opponent compels seller agent to provide better and better bid for the buyer in order to defeat the opponent, with the utility for itself decreasing. The utility to the buyer provided by seller 2, S2toB=1.8717, can not defeat that provided by seller 1, S1toB=1.9787, from the 6th generation. This does not change after 4 generation. So seller 2 quits and seller 1 wins. The outcome is that price p is 2.2096, quality q is 0.8213, and the utility of seller 1 is 1.4466.


467

Fig. 2. Coevolutionary computation procedure for the multi-attribute auction problem

Let’s analyze whether the outcome reached by the coevolutionary computation procedure is an equilibrium. First, assuming there is complete information, constrained by individual-rationality, the maximal utility to the buyer provided by seller 2 is 2.0198. Since 2.0198 is less than 1.9787+0.1, there exists no strategy better than the outcome, i.e. lost, for seller 2. As concerned as seller 1, the maximal utility to itself is 1.4588, constrained by winning seller 2. It deviates merely 0.8% from the utility in the outcome by IMA, i.e. 1.4466. So, for seller 1, there are nearly no strategy better than the outcome. In a word, the strategy provided by the coevolutionary computation procedure IMA-CGA is ex post Nash equilibrium for the sellers, assuming the buyer is truthful. Now let’s go to the efficiency of mechanism IMA. The Vickrey auction mechanism proposed by Milgrom [5] is efficient assuming the buyer announce his truthful utility function as scoring rules. We use it as the benchmark for evaluating IMA. The outcome of Vickrey mechanism is that, seller 1 win, the utility of the buyer is 2.0198, and the utility of seller 1 is 1.4177. The utility of the buyer in the outcome of mechanism IMA is 2% less than that of Vickrey. The utility of seller 1 in the outcome of mechanism IMA is 2% more than that of Vickrey. The total utility of the market in mechanism IMA is 3.4253, which deviate only 0.3% from that of Vickrey(3.4375). Hence, iterative multi-attribute auction mechanism IMA, with coevolutionary computation procedure IMA-CGA, is nearly efficient for the multi-attribute auction market.

6 Discussion Some characteristics of the proposed mechanism IMA, with procedure IMA-CGA, for multi-attribute auction problem are as follows: (1) The multi-attribute auction model in this study has no limitation on attributes and utility functions, hence it has

468


wide applicability. (2) Mechanism IMA supports incremental preference elicitation on demand. Moreover, agents can simply compare the bids without having to determine the exact utility value of them. (3) Agent do not have to reveal complete utility function or scoring function. Information revelation is little and private information is well preserved. (4) Not only coevolutionary computation procedure IMA-CGA supports myopic best-response strategies for the sellers, but also these strategies are ex post Nash equilibrium. (5) Mechanism IMA is nearly efficient for multi-attribute auction market and has a quick auction speed.

7 Conclusions Multi-attribute auctions are central to negotiation in business to business markets, procurement activity and multi-agent system. A novel iterative multi-attribute auction mechanism IMA for reverse auction settings with one buyer and many sellers is proposed based on competitive equilibrium theory. The auctions support incremental preference elicitation and revelation for both the buyer and the sellers. Coevoluationary computation method is incorporated into the mechanism to support economic learning and strategy making for the sellers. Experimental results show that the myopic best-response strategy provided by it is ex post Nash equilibrium for sellers assuming a truthful buyer strategies and the auction are nearly efficient, i.e. the total utility of IMA deviates mere 0.3% from that of multiattribute Vickrey auction mechanism. Efficient outcome can be quickly reached by the practical mechanism IMA in the setting where agents don’t have complete information about their preference, or they would not reveal much private information, or they don’t have complete rationality. Also, the proposed mechanism and framework may be extended to the multiattribute, multi-unit auction problem[12], which is so complex that, as far as we know, there are nearly no theoretical or practical approaches for it to this day. A Multi-agent based system, in which the proposed mechanism and framework are realized, has been developed for supporting the reverse multi-attribute auction in B2B markets and supply chain procurement activity. Supplier selection decision and/or deal decision are supported by the system for both the buyer and the suppliers. The software will be applied and verified in a supply chain composed of an automobile company and its main suppliers.

References [1] [2] [3] [4]

McAfee R.P., McMillan J.: Auctions and bidding. Journal of Economic Literature. 25(2) (1987) 699–738 Che Y. K.: Design competition through multidimensional auctions. RAND Journal of Economics. 24 (1993) 668–680 Parkes D.C., Kalagnanam J.: Models for Iterative Multiattribute Procurement Auctions. Management Science.51(3) (2005) 435–451 Branco F.: The design of multidimensional auctions. RAND Journal of Economics. 28(1) (1997) 63–81


469

Milgrom P.: An economist’s vision of the B-to-B marketplace. Executive white paper, http://www.perfect.com. [6] Beil D.R., Wein L.M.: An inverse-optimization-based auction mechanism to support a multiattribute RFQ process. Management Science. 49(11) (2003) 1529–1545 [7] Potter M.A., De Jong K.A.: Cooperative coevolution: An architecture for evolving coadapted subcomponents. Evolutionary Computation. 8(1) (2000) 1–29 [8] Klemperer P.D.: Auction theory: a guide to the literature. Journal of Economic Surverys. 13 (1999) 227–286 [9] Tesfatsion L.: Agent-based computational economics: Growing economics from the bottom up. Artificial Life. 8(1) (2002) 55–82 [10] Wiegand R.P.: An analysis of cooperative coevolutionary algorithms. Ph. D. dissertation, George Mason Univ., 2003. [11] Matthew W.: GAlib: a C++ Library of Genetic Algorithm Components, version 2.4, MIT,1996. [12] Bichler M., Kalagnanam J.: Configurable offers and winner determination in multiattribute auctions. European Journal of Operational Research. 160(2) (2005):380–394 [5]

Knowledge Integration in Global Engineering Prof. Reiner Anderl, Diana Völz, Thomas Rollmann Petersenstraße 30, 64287 Darmstadt, Germany {anderl, voelz, [email protected]}

Abstract. In the globalised economy, organisational structures and methods used in product development have changed. Companies and organisations have responded by reengineering involved processes, increasing the use of information and communication technologies. Although not new, innovative concepts are required to fully support the resulting distributed virtual product development process. Modern information systems provide the access to information as well as communication, but actual software tools do not integrate the changing circumstances, arising from working in an intercultural field. Global Engineering can create problems of misunderstandings in the product development process leading to a possible lack of information as well as knowledge circulation. Knowledge Integration in collaboration supports successful communication and cooperation. It also supports finding common grounds, processes, and project language. The aim of this paper is to advance knowledge integration in product development to tackle the new challenges in Global Engineering. Keywords: Global Engineering, Knowledge Integration, cultural diversity in collaborated team work, different organisational structures, product development

1 Introduction Due to intensified processes of globalisation organisations have reengineered product development: Engineers working together in global teams embedded in virtual environments. The new circumstances in intercultural global team work offer new possibilities to create innovative products. However, the consequential virtual team environments also require new strategies to overcome the challenges of global product development. Team collaboration in product development is vital for developing successful products. This study presents an empirical survey in Global Engineering including interviews that identify the actual reengineering of working processes in global organisational structures. An overview is given about the important aspects impacting global team work which should be taken under consideration to improve global product development. The focus of this paper is

472

Prof. Reiner Anderl, Diana Völz, Thomas Rollmann

the issue of Knowledge Integration as a key for improved virtual team collaboration in intercultural fields. It will be argued that Knowledge Integration is the basis for mutual understanding in Global Engineering.

2 Global Engineering 2.1 Why has Engineering gone global?

World-wide networked engineers and modern information as well as communication technologies offer new forms of collaboration in product development. An engineer can better understand costumers’ needs and feelings when located in the local sales market. Therefore customers’ requirements can be integrated earlier in the product development process. This reduces time-consuming and costintensive developments. Today it is necessary for companies to be represented in the global market to be competitive. From another point of view, Global Engineering makes it possible to combine dispersed worldwide expertise on one project. Special knowledge support is sometimes needed in engineering, e.g., the application of special software simulation tools. In Global Engineering the expert is able to work on several projects at the same time without leaving his location. Furthermore, product development in a multicultural field can evoke synergy effects. “Such teams have the potential to provide companies with a more practiced and economical way to develop new products and services.” [1] 2.2 Global Teams

Global teams are both geographically dispersed and culturally diverse. They work together in virtual environments and are mostly embedded in different organisational structures. Research suggests, however, that companies are struggling to deal with the myriad problems arising from the use of such global teams [1]. Much of this struggle seems to stem from the nature of global teams.

3 Challenges in Global Engineering 3.1 An Investigation in Global Engineering

This research aims to investigate the support of Global Engineering by the use of Computer Supported Cooperative Work (CSCW) - Technologies. An empirical survey addressing the shortcomings in communication, coordination and cooperation as well as the application of (CSCW) - Technologies in practical Global Engineering was developed to tackle the challenges in global team work.

Knowledge Integration in Global Engineering

473

The survey was started at the Global Annual PACE-Forum [17] and additional distributed via e-mail to engineers working in the global field. The first part of the survey entailed questioning the respondents about the most important factors affecting the Global Engineering process. The second part of the survey was meant to understand the benefit of team building process. The number of international respondents was forty-six. Effects in Global Engineering were measured by asking the respondents to indicate the extent to which seven factors were influencing the global team work and the project’s results. A five item scale was used to evaluate each factor. The mean of each factor which represents is overall importance is pointed out in Figure 1a). The respondents estimated that “different organisational cultures” was the most influential factor in global team work.

Fig. 1. Factors impacting Global Engineering team work and project results

The organisational culture was the most vital factor influencing Global Engineering regardless of the different roles in the global team (team member, project leader, and process leader). However, the second and third factors varied depending on the position in the team (Fig. 1b). The findings are influenced by the different areas of responsibility depending on the role of the engineer in the team. Figure 2 presents the responses about the teambuilding’s benefits in the Global Engineering project. A four item scale was used to evaluate each factor. The mean of each factor is presented in Figure 2 based all of the responses. Due to most respondent’s attitude, teambuilding arrangements can lead to a better understanding of common project goals, and Knowledge Integration between the project members was found to the second most important factor affecting the team cooperation. It is striking in the findings of the questionnaire that the number of 24 hour developments has increased in product development.

474


In addition, five interviews with representatives of engineering companies working in a global field showed the global re-engineering of product development processes and its consequences. After having merged, companies reorganised their departments, thus new competence centres were established. Work processes directly integrate suppliers in the product development. The standardisation of those processes makes it possible for testing procedures, virtual modelling, and assembling to be processed anywhere and anytime from every engineer.

Fig. 2. Desired benefits of teambuilding methods

The global management regulates the different engineering competence departments worldwide. Members of global teams are confronted with a global supervisor that is usually not working at the same location, thus they do not necessarily know supervisors personally. The globalisation of both organisational structures and standardised processes enable the distribution of tasks depending on free resources and available competences in all cross-locations. Product data management systems permit access to worldwide distributed development data, and CSCW-technologies enable communication, coordination, and cooperation in team collaboration. The misunderstandings and lack of trust are crucial issues which every organisation solves in their own way. Some organisations arrange “face-to-face” meetings or a “coming together” to build cohesion in global teams, whereas other organisations include cultural trainers in collaborative team work to coach the team members in cultural issues. To support cooperation, as well as to overcome language difficulties in communication, engineers use visualisations of the product. 3D-CAD-models or digital mock-ups represent the real form of the product to evaluate and the engineers discuss development questions over wide distances and across cultural boundaries. According to statements of the interviewed persons, visualisations can help to build a common project goal and improve mutual understanding. Visualisation tools, like shared desktop or viewer, offer the possibility of working together in globally dispersed teams. 3.2 An Outline in Global Engineering

Due to the geographical extent of collaboration, product development processes are affected by new challenges.


475

The challenges for personal interaction, including different language skills as well as a different set of cultural beliefs, can lead to misunderstandings and more room for interpretation in global team work. Different countries have a different focus on skills, mirrored by education and working attitudes, and different companies have various approaches to work which have to be combined in cooperation. The challenges for managing global teams stem from the nature of global teams. In Global Engineering the team members are geographically dispersed and often live in different time zones. Communication only takes place virtually. The team members working in networks seldom know each other personally. This can lead to a lack of trust and cooperation between team members. Finally, these aspects make it complicated for project managers to build a common goal and a task strategy as well as cohesion between the team members. Sometimes “face-toface meetings” or a “coming together” are arranged to overcome this problem in Global Engineering. In addition to cooperation between companies there is often non-uniform technical support. This implies that the software systems are not compatible. Therefore, it is difficult for an engineer to get the right information when it is needed. The transparency of information and knowledge is vital in product development. The challenges can be summarized as challenges in communication, coordination, and cooperation of global teams that are embedded in virtual team environments.

4 Global Virtual Team Environments 4.1 Global Virtual Team Rooms

A comparison of Real Team Rooms (the room where co-workers meet face-toface) and Virtual Team Rooms (communication network linking global teams) shows the differences of both working environments. Today’s Real Team Rooms offer an all encompassing working environment where team members personally interact which leads to team cohesion share environment. In contrast to Real Team Rooms, the team members of Virtual Team Rooms are networked by information and communication applications. The utilised tools depend on organisational structures. The product visualisation is the connecting factor of Virtual Team Work and the product visualisation fosters mutual understanding in such teams. 4.2 Communication, Coordination and Cooperation in Global Teamwork

Empirical studies about team work in product development deal with the key points of successful team collaboration: communication and coordination as referenced in [2], [3], and [4]. In his “3C-Model”, Teufel [5] added the key point coordination.

476


The “3C-Model” consists of Communication, Coordination, and Cooperation are terms that must be kept in mind in interdisciplinary team collaboration which can be extended to Global Engineering. Communication means the exchange of development data as well as management project information in verbal, textual, or graphical form. Coordination is needed to structure distributed and interdisciplinary team work in the planning of time schedules, work processes, milestones as well as in networking knowledge, expertise, information, and data. Cooperation in team work means to be responsible for one’s own field of duty and to be aware of the interfaces to one’s team colleagues. Cooperation is driven by the open-minded behaviour of the team members to transfer information, expertise, and results to his colleagues. 4.3 CSCW-Technologies

“Computer Supported Cooperative Work (CSCW) is a generic term which combines the way people work in groups with the enabling technologies of computer networking and associated hardware, software, services, and techniques” as outlined by Wilson in [16]. CSCW-technologies resolve the limitation of time and space in collaboration, thus team meetings can take place anywhere and anytime. Groupware enables the synchronous communication of many team colleagues over a great distance. Communication is more focused on the project tasks because important project feedback can be given when needed. The disadvantages of CSCW-technology use is that team members are confronted by a flow of redundant information and the lack of social contact. A classification of CSCW-technologies regarding time and space in the CSCWMatrix was developed by Johansen in 1988 [19]. This model was extended by distinguishing between synchronous and asynchronous CSCW-technologies. Burger [6] integrated the classification of CSCW-technologies in the 3C-Model of Teufel (Fig. 3).

Fig. 3. CSCW-Triangle-Matrix according to [5]


477

The support of communication is vital for verbal, textual or graphical information exchange in collaboration. Tools providing the possibility to communicate can be subdivided into tools enabling asynchronous communication, e.g., e-mail exchange. Examples of synchronous communication technology include chats or video conferencing systems. Communication tools can be used individually or can be connected with further Groupware systems. Coordination tools should enable an unhindered and efficient flow of work in collaboration. Coordination can be processed by the project members themselves by using the aforementioned communication tools or by special workflow management systems. Workflows should advance the project’s progress in coordinating activities and resources of team members. Systems for coordination also enable access to development data and allow for easier administration of the project information. Cooperation is driven by the interaction and open-minded behaviour of the team members. Cooperation tools should fulfil different requirements depending on the project phase. Therefore a number of systems are needed with various applications, such as permitting synchronous as well as asynchronous working on common documents. In summary, there exists a lot of CSCW-Technology to support team collaboration in the global field. According to [7] and the survey, the most technology is intuitively applied in the correct way depending on the richness of communication and information transfer by the users. Facial expression and body language are important nuances that are lost in asynchronous communication. Only the video conference system is less convenient to use because of the needed preparation time. Steinheider and Legrady [8] introduced the cooperation model based on the 3CModel [5]. In this model cooperation is replaced by Knowledge Integration as the basis of communication (Fig. 4) and is defined as the partial exchange of knowledge between participants [8].

Fig. 4. Extended CSCW-Triangle-Matrix according to [6]

478


Due to this research the IT-support of Knowledge Integration needs further attention.

5 Knowledge Integration a Key in Global Engineering? 5.1 Knowledge Integration

Knowledge Integration means the application of tacit knowledge into a specific situation. Team members pool their tacit knowledge in solving a collective task, e.g., during the Product Development Process when developing innovative products. Effective teamwork requires joint problem solving to integrate and apply knowledge to the task at hand. This process requires an environment of easy, frequent, content- and context-rich interpersonal interactions. Knowledge Integration is developed over time and primarily through direct interaction between the team colleagues. Interaction takes place through rich and iterative communication and information transfer in team work. In Virtual Team Environment the dispersion of team members, their different cultural background, working attitudes, expertises as well as languages constrain the development of Knowledge Integration in Global Engineering. In these settings Knowledge Integration can suffer, thus tacit knowledge is not integrated and is not brought to bear on Product Development Process. [9] Based on Knowledge Integration cooperation can take place to define a common project goal and project content as well as a common project language. Therefore information and knowledge have to become productive. The gained Knowledge Integration should be the background for further communication. To support the communication process leading to Knowledge Integration in team collaboration further research has to be done. [8] According to Clark and his colleagues, “common ground” is a key ingredient of effective communication and collaboration in team settings [10], [11], [12]. To gain Knowledge Integration flexibility is needed. Using IT support, strong rules are necessary but can lead to unevenly shared knowledge across the virtual environment. A prerequisite for effective Knowledge Integration in teams is, knowing who has the required knowledge and expertise, where the knowledge and expertise are located, and where and when they are needed. Knowledge exists in firms, networks and is bounded in employees. Knowledge Integration enables the ability of organisations to sense, interpret, and respond to new business opportunities, e.g., re-engineering of Product Development Processes. [9] The investigation of [8] points out that common Knowledge Integration is easier gained by the use of visualisation of the project item in collaboration. Especially in product development, where engineers work together, visualisation plays an important role, realising the idea in a digital model, helping to ensure the level of Knowledge Integration. Documentation and visualisation plays an important role for Knowledge Integration in the Product Development Process. This can be realized in a graphical supported communication. Especially engineers are used to communicate by visualisation. Current research in linguistic science


479

investigates the interplay of texts and drawings in communicating the knowledge in the field of engineering [13] .The connecting factor for all cross-locations in product development is the product which can be visualised by the 3D-geometry. The digital model can be helpful to ensure a fixed level of Knowledge Integration in team work. Several studies revealed that enhanced 3D-representations are immediately understood by about 90% of the engineers compared to only 10-30% regarding plain texts or 2D mechanical drawings. Current research dealing with the establishment of Knowledge Management Systems (KMS) doesn’t take under consideration that Knowledge Integration is the first step to do before developing a KMS. 5.2 The Concept of a Computer Supported Knowledge Integration System

The results of the survey showed a lack of Knowledge Integration in Global Engineering team work. According to the last section special beneficial technology does not exist that supports Knowledge Integration in Global Engineering. To build Knowledge Integration within a Virtual Team Environment, a number of requirements have to be taken into account. Some of the important requirements of Computer Supported Knowledge Integration Systems (CSKIS) are listed in Table 1 and described afterwards: Table 1. Requirements of Computer Supported Knowledge Integration Systems. Requirements of CSKIS flexible socio-technical accessible context based social well arranged data representation generally understandable digital model based compatible adaptable storable network structured common ground based

Description adaptable to different teams, different tasks in product development, different organisation structures allow direct interaction between team members, simple but well structured dispersed team members should have access to the system as well as to information regardless of their location allow communication on a common project task facilitate virtual team building representing ongoing actual project information and development data in the user’s view facilitate mutual understanding regardless of culture, language, expertise and working attitude as the language of engineers and product oriented data representation to heterogeneous software systems compatible to existing software systems for further knowledge management systems and lessons learned as well as technical product documentation guideline to stored knowledge (who knows and where it is) basic information about the own and other cultures, working attitudes, expertise – competence matrix, yellow pages

Knowledge Integration significantly depends on the interaction in teams. The behaviour of a team member is relevant in building Knowledge Integration such as diligence, openness, acceptance, and the readiness to change the perspective to a

480


better understanding for a colleague. These factors can hardly be managed by software tools, but a socio-technical management system that includes team members interactively working together based on a common context [14]. A CSKIS can foster strong ties within weakly coupled subnet works of individuals to build trust and cohesion by facilitating Knowledge Integration, according to [9] “Acquiring knowledge” by communication [15] assimilates external knowledge in projects. CSKIS should offer a collaboration platform to build common grounds in global teams. Common grounds about other professional disciplines, culture, and organisational structures are key points for Knowledge Integration. “Identify knowledge” is the task to analyse internal and external organisation knowledge to gain an overview of the available organisation competences. This means that data, information and competence available in data banks, internet or literature have to be identified. In this process teams should become aware of the involved project competence. In Global Engineering it is a part of teambuilding. The formation of teams is a key point for the involved project knowledge. Only knowledge involved in teams can circulate through networked projects. Distribution of knowledge plays an important role in global teamwork because communicated knowledge is mostly distributed by communication technologies or in form of texts and graphics. In intercultural team work it is vital to document and visualise the development results and experiences to gain common grounds. Visualisation is mentioned by the respondents as an important tool to advance mutual understanding in global team work. The best way is the use of interactive documents including visualisation because Knowledge Integration is a dynamic process where the activity of all team members is needed. Further requirement of CSKIS is to represent information in the users view to guarantee the distribution of knowledge. The integrated knowledge should be stored, for example, in content management systems to enable access to knowledge anywhere at anytime for global team members. 5.3 Further steps

Knowledge Integration has to be classified in the Product Development Process to focus the knowledge based interaction between team members in Global Engineering. Current research doesn’t take into account the special knowledge based task during the Product Development Process. The ongoing phases of the Product Development Process change from technical to social based accommodation with different deepness of team interaction. Further steps are to investigate applied Collaboration Platforms and to integrate dynamic visualisation technology in them, e.g., the Portable Document Format Technology linked with Product Data Management Systems. The advantage is that existing platform software is interlinked with actual 3D-geometry, independent of expensive 3D-CAD-software tools. 3D-PDF represents compressed but exact 3Ddata, which reduce time-consuming upload processes. Therefore the system is portable and applicable in every kind of team collaboration. In early 2005 PDF received numerous new functionalities regarding the visualisation of 3D-geometries. The functions cover the possibility of including


481

user interactions to alter the current state of the graphical representation. Users viewing the document can easily rotate, pan, tilt, and zoom the 3D-object as well as trigger pre-loaded animations of the 3D-object. Measurements are also possible. Aside from the well-known functions for the representation of textual information, PDF was enhanced for a combination of both, graphical and textual information in one document. Communication processes with the ability of transferring information also via 3D-representations enable collaborative engineering to work more efficiently, as technical issues and problems can be demonstrated more vividly. They are also more easily understood without the need for special terminologies if 3D-models are used as interactive contents. Further advantages of the PDF-Technology are listed in Table 2. [18] Table 2. Advantages of the PDF-Technology Advantages

- Tools and plug-ins can be inserted into PDF-based applications. - High degree of awareness and diffusion rate - Data integrity: PDF-documents integrate textual information, fonts, images and figures, graphs, audio, video and 3D-objects - Protection of data privacy: PDF-documents can be signed with digital keys, or they can be cryptographically secured

Also, the system can integrate additional functions and information like establishing project wikis, “yellow pages”, containing profiles of team members specifying their area of specialisation, and searchable libraries as well as electronic bulletin boards where team members can post questions and seek other team members’ assistance and knowledge. One further step should be an investigation of already implemented functions in collaboration platforms helping to gain Knowledge Integration, e.g., videoconferencing, groupware, e-mail and shared whiteboards and the testing of possible integration of new technologies, e.g. hypervideo functions.

6 Conclusion The purpose of this paper is to show the challenges in Global Engineering and the re-engineering of organisational structures as well as product development processes. This leads to new requirements for CSCW-Technologies. The existing communication and collaboration tools are applied intuitively in the correct way. But these tools are not able to store the gained Knowledge Integration when communicating. Therefore new functions have to be implemented in collaboration platforms enabling flexible, interactive, and context based global team work. In engineering, communication by using the evolving 3D-geometry of the product is sensible in bridging the language difficulties in Global Engineering. The communication data should be stored to guarantee Knowledge Integration in the actual team project for “lessons learned” in further global projects as well as for the use in the technical product documentation. Further research is needed to enhance

482


Knowledge Integration during the product development phases and to test the integration of 3D-PDF in collaboration platforms.

References [1]

[2]

[3]

[4]

[5] [6] [7] [8]

[9] [10] [11] [12]

[13] [14]

[15]

[16] [17] [18]

[19]

Donough (Mc), E.F., Kahn, Kenneth B., Barczak, G.: "An investigation of the use of global, virtual and collocated new product development teams", in The Journal of Product Innovation Management, pp. 110-120; (2001) Wehner, T.; Raeithel, A.; Clases, C.; Endres, E: „Von der Mühe und den Wegen der Zusammenarbeit.“ In Endres, E.; Wehner, T. (Hrsg.): Zwischenbetriebliche Kooperation - Die Gestaltung von Lieferbeziehungen. Weinheim: Psychologie Verlags-Union (1996) Badke-Schaub, P.; Frankenberger, E.: „Analysing Teams by Critical Situations: Empirical Investigations of Teamwork in Engineering Design Practice“. Vortrag auf dem Fifth European Congress of Psychology, Dublin, Ireland (1997) Frankenberger, E.: „Arbeitsteilige Produktentwicklung – Empirische Untersuchung und Empfehlungen zur Gruppenarbeit in der Konstruktion“. Düsseldorf VDI-Verlag (1997) Teufel, S.; Sauter, C.; Mühlherr, T.; Bauknecht, K.: „Computerunterstützung für die Gruppenarbeit“. Bonn: Addison-Wesley (1995) Burger, C.: „Groupware: Kooperationsunterstützung für verteilte Anwendungen“. Dpunkt-Verlag (1997) Hertel, G.; Konradt, U.: „Telekooperation und virtuelle Teamarbeit – Interaktive Medien“, Oldenbourg, München, 2007 Steinheider, B., Legrady, G.: „Kooperation in interdisziplinären Teams in Forschung, Produktentwicklung und Kunst“, Fraunhofer Institut für Arbeitswirtschaft und Organisation, Stuttgart, (2001) Alavi, M.; Tiwana, A.: “Knowledge Integration in Virtual Teams”, Journal of the American Society For Information Science And Technology, October 2002 Clark, H.: “Using language”, New York: Cambridge University Press, (1996) Clark, H.; Carson, T.: “Speech acts and hearer`s beliefs”, In N.Smith (Ed.), Mutual knowledge (pp. 1-36), New York: Academic Press Clark, H., Marshall, C.:”Definite references and mutual knowledge”, in A. Joshi, I. Sag, & B. Webber (Eds.), Elements of discourse understanding (pp. 10–63). New York: Cambridge University Press. (1981) Teich, E.: http://www.linglit.tu-darmstadt.-de/index.php?id=1169#c2272 (2007) Troxler P., Lauche L.: “Knowledge Management and learning culture in Distributed Engineering”, ICED International Conference on Engineering Design, Stockholm, August 2003 Gausemeier, J., Hahn, A., Kespohl H.D., Seifert, L.: “Vernetzte Produktentwicklung. Der erfolgreiche Weg zum Global Engineering Networking“, pp. 311-313 Carl Hanser Verlag München Wien (2006) Anderl, R.: „Skript Produktdatentechnologie B – Produktdatenmanagement SS2007“. Technische Universität Darmstadt (2007) PACE-Forum: http://www.pace-digiman.de/ (2007) Lee, K: „Einsatzmöglichkeiten der 3D-PDF-Technologie in der Technischen Produktdokumentation“, Master Thesis at Technische University Darmstadt, Institute Datenverarbeitung in der Konstruktion, 2007 Johansen R: “GroupWare: Computer Support for Business Teams”, The Free Press, New York, NY, 1988

Part VI

Modelling and Meta-modelling Methods and Tools for Interoperability

A Framework for Executable Enterprise Application Integration Patterns Thorsten Scheibler and Frank Leymann Universität Stuttgart, Institute of Architecture of Application Systems (IAAS) Universitätsstrasse 38, 70569 Stuttgart, Germany {leymann, scheibler}@iaas.uni-stuttgart.de

Abstract. A great challenge for enterprises is the improvement of the utilization of their landscape of heterogeneous applications in complex EAI (Enterprise Application Integration) scenarios. Enterprise Application Integration Patterns help to address this challenge by describing recurring EAI problems and proposing possible solutions at an abstract level. However, EAI patterns are documentation only used by systems architects and developers to decide how to implement an integration solution. Thus, patterns do not specify how to produce the code that will actually implement the solution described by the pattern on a specific middleware. In this paper we introduce a framework that provides configuration capabilities for EAI patterns. The framework also allows to generate executable integration code from EAI patterns using a model-driven architecture approach. Furthermore, we present a tool providing this framework. Keywords: Enterprise application Integration for interoperability, Service oriented Architectures for interoperability, Model Driven Architectures for interoperability

1 Introduction Enterprise Application Integration (EAI) means integration of huge application systems landscapes comprising different kinds of heterogeneous artifacts (e.g. data, services, applications, processes). EAI applications function by coordinating standalone, independent applications, that can run by themselves, in the enterprise landscape in a loosely coupled manner. EAI therefore does not mean creating a single application that is distributed across several systems. A common way of integrating applications is by using messaging[15]. This technology eases integration by enabling multiple applications to exchange data using a “send-and-forget” paradigm together with providing a certain level of Quality of Service (QoS) because of the “store-and-forward” approach. Often, business processes (i.e. workflows) are used to describe and execute the integration

486

Thorsten Scheibler and Frank Leymann

of multiple services in a message-oriented system[14]. Workflows invoke the distributed services in a coordinated manner, using e.g. coordination protocols, and compensation logic. While designing EAI scenarios, one recognizes that the same solutions are used multiple times to address recurring problems. Those problems and their solutions are generally described in terms of Patterns [2]. Besides the well-established patterns in the field of object-oriented software design [11], there is an emerging area for creating patterns for software and enterprise architecture [5, 9]. For instance, [12] defines a set of patterns, covering prominent examples of situations encountered in message-based EAI solutions. Basically, the development of EAI scenarios comprises three layers: modeling, integration, and implementation. Figure 1 depicts exactly this approach: (i) on the top level, architects are drawing system landscapes in an abstract way to describe the system architecture without specifying technologies used in the system. This level eases the communication between architects not knowing all technical details, and technical personnel. (ii) The middle layer, also known as integration layer, enables the gluing of various services. The code produced represents business logic developed to achieve the business goals. (iii) At the lowest level reside the implementations of enterprise applications (legacy systems, databases,…) providing different services that eventually help to achieve business goals.

Fig. 1. Three levels of Enterprise Application Integration

Having the architecture of the desired systems landscape for a particular EAI scenario on the one hand and the implemented services on the other, no continuous method currently exists explaining how to get from the top level down to the lower level. This reveals the so-called Architecture-and-IT-gap- a vacuum between the persons who are familiar with the overall architecture (including business processes) and the staff with expertise in technological issues independent of the business goals targeted by a particular scenario. In this paper we present an approach to fill this gap. We introduce a framework that allows to generate executable integration code from EAI patterns using a model-driven architecture (MDA) [10] approach. The framework also provides configuration capabilities for EAI patterns in a platform independent manner which serve as basis for the generation logic. The paper is structured as follows: in Section 2 we discuss the connection of EAI patterns and MDA, including a short

A Framework for Executable Enterprise Application Integration Patterns

487

comparison of the Pipes-and-Filter (PaF) architecture and workflows, that are two basic alternatives available at the integration level. In Section 3 we introduce the general approach of configuring EAI patterns and present concrete properties of selected patterns. In Section 4 we show an example how an integration solution designed with those EAI patterns can be translated into a specific implementation technology including the presentation of a tool enabling the framework. The paper is concluded by the outlook in Section 5.

2 EAI Patterns and MDA Regarding the three levels of EAI (see Figure 1) no standard exists to model and design EAI scenarios. EAI patterns [12] are a way of documenting an architecture of enterprise application systems on a higher abstraction level. Those patterns are intended for use by analysts or systems architects to draw IT landscapes in a standardized way. These patterns are pieces of advice for integrating various systems, and a documentation explaining the underlying architecture leaving out specific technical details. On this level nothing is mentioned about how the visual representations of the patterns can be implemented. Currently, the realization is being done solely manually, which underlines the lack of methodology or tool. This situation was neglected in research and has not been studied yet. Nevertheless, there exists comparable work in several other areas. In the area of Workflow Patterns [19] it has been shown that such patterns can be mapped to BPEL [13, 16, 17]. In Service Interaction Patterns [4], the authors suggest how to represent the patterns with the help of WS-*[20] and BPEL[1] technology [3]. With respect to EAI patterns first implementation suggestions are presented to provide pattern support in an Enterprise Service Bus (ESB) [6] in a non-systematic manner. Right now there are two proposals: (i) within the open source ESB Mule 3, and (ii) within the routing engine Apache Camel 4 on top of Apache Active MQ. However, none of those approaches offer a coherent method for getting from the design down to the technical details. Actually, the (automatic) generation of executable code from EAI patterns has not been addressed at all. Also, there is no existing work on representation of patterns and their configuration, as well as no existing tool to support such a methodology. Considering the illustration of EAI patterns in Figure 1, by default based on the PaF architecture, one can recognize that the structure is comparable to graphs in which nodes are connected via edges. In EAI patterns, there are filters as working units representing nodes and channels as data links between two filters representing edges. Such a graph-oriented notation is comparable to workflow graphs with nodes standing for activities and control links connecting the nodes. Based on this similarity a PaF architecture can be viewed as a workflow where data flow and control flow is identical. Nevertheless, both architectural styles have fundamental differences [18]. The main distinction was found to be in the support of instances. In workflow based systems an incoming request message starts a new 3 http://mule.codehaus.org/ 4 http://activemq.apache.org/camel/

488


instance of a business process. Hence, messages are associated with a particular workflow instance in contrast to PaF where messages traverse the filters independent of an notion of an instance: when a filter receives a message it processes it, forwards it, and processes the next upcoming message immediately. Therefore a message is not connected to an instance of a filter an vice versa. But the concept of an instance is very important in production environments enabling monitoring, auditing, repair etc. [14]. In an EAI scenario the implementations layer is realized by legacy applications, standard applications, or roll-your-own applications available at an enterprise. Often, the interfaces of those applications are described using some Interface Definition Language (IDL) allowing the integration layer to integrate the systems in an architected manner (e.g based on J2EE Connector Architecture 5). Nowadays those interfaces are described using Web Service technology (WS-*) [20] which is the latest integration technology. The IDL in the WS-* stack is the Web Service Description Language (WSDL [7]). In a Web Service environment BPEL (Business Process Execution Language [1]) is the standard for describing and executing business processes. BPEL processes reference the WSDL descriptions of the enterprise applications to integrate.

Fig. 2. EAI patterns transformed into executable workflows

In MDA the so-called Platform Independent Model (PIM) describes a solution to a problem in a technology independent manner. At PIM level a system, thus, is described platform neutral. The PIM can be translated into a Platform Specific Model (PSM) with a transformation logic based on a Platform Model (PM) as well as on Marks which configures the generation of particular code. In case of the three levels modelling EAI solutions (see Figure 1) the analogy to MDA is obvious: EAI patterns are at the level of a PIM, BPEL as orchestration language and Web Services as application interfaces reflect the level of a PSM (see Figure 2), and the gap between those levels can be filled if an appropriate generation algorithm can be developed which automatically maps from the non-executable PIM into an 5http://java.sun.com/j2ee/connector/


489

executable PSM. The transformation algorithm needs configuration guiding the generation of appropriate code. Especially in the case of EAI patterns as PIM we need further information how the utilized patterns are intended to be used. Therefore, we introduce parameters for each pattern as well as for the whole system to support the transformation algorithm and to enhance the PIM with some information about the (technical) execution environment. Moreover, these parameters enable reusability when developing different algorithms for various target technologies.

3 Parameterization of EAI Patterns Current approaches (see Section 2) lack a configurability of patterns. With configured EAI patterns we introduce a new way to develop a common basis for various transformation algorithms targetting different technologies: This configuration is used by the transformation algorithm to generate platform specific code. We call configuration properties of individual types of patterns parameters. Evaluating EAI patterns we identified four categories of properties which form the parameters and describe the patterns in a more specific way. The categories are as follows (see Figure 3): x x x

x

Input: This categories describe the amount of incoming (request) messages. Output: This categories describe the amount of outgoing (request) messages. Characteristics: This is the main kind of the category. The paramaters of this category describe the detailed behavior of each type of EAI pattern, i.e. different choices and settings lead to different characteristics of the platform specific code. Control: This category describes the format of control messages which dynamically lead to a new behavior of a pattern in terms of manageability of the pattern implementation.

We choose a simple graphical notation to visualize those categories of parameters. The category characteristics has the main impact on the transformation algorithm. Different settings of parameters may lead to different results of the transformation because the algorithm generates different code depending on the settings. This will be discussed in Section 4.

Fig. 3. Generic visual representation of EAI patterns parameters

490


Next, we describe the parameters of some patterns. As an example we show one pattern from each category of EAI patterns described in [12], namely Message Construction, Messaging Endpoints, Messaging Channels, Message Routing and Message Transformation. We describe in detail how each of the selected patterns can be expressed in a parameterized form. The parameterized representation of other patterns can be found in [8]. 3.1 Message Construction

Message Construction patterns suggest ways how applications (i.e. filters) that use Message Channels can actually exchange a piece of information. The Message pattern, the most prominent pattern, describes how to structure information in form of a message consisting of a header and a body part. The header contains information relevant for message delivery (e.g. destination address) or processing (e.g. security tokens) and is intended to be interpreted by the communication infrastructure. The body of a message contains the actual payload that is to be delivered to a receiver. Since the header part is used by the transmitting middleware and is typically set by the sending application- or the middleware itself-, we do not reflect that part in our parameters: parameters only describe the representation of the payload. A message in the system is not a processing, thus, it has no input, no output, and no control parameters. The message is only characterized by the format representing the content of the message, which is therefore the only parameter describing this pattern. 3.2 Messaging Endpoints

Messaging Endpoints describe how applications are connected to messaging systems and thus, how applications send and consume messages. Message reception through message endpoints can be further detailed by the way messages are received: in case of a Polling Consumer, the recipient actively polls the communication infrastructure for data items to consume. In contrast to this, an Event-driven Consumer is notified by the communication infrastructure as soon as a new data item becomes available. In case of a Selective Consumer, the pattern can be described by the kind of message which the consumer will receive through the connected filter. The consumer can further be parameterized by the selection criteria which selects messages based on their content and, thus, filters messages transmitted to the consumer. Those criteria can be simple key/value pairs, ranges of values or even complex selection logic (e.g. sophisticated XPath queries in case of an XML-based message content). 3.3 Messaging Channels

Messaging Channels are used to establish connections between applications and therefore transfer aspects of a messaging-based application. As mentioned earlier each channel is associated with an assumption about the particular “sort of messages” communicated over that channel. Applications choose a channel to


491

communicate messages based on the expectation of the type of messages that run over that channel. There are a lot of parameters describing all kinds of message channels independent from the real occurrence of the pattern (e.g. Data Type Channel). Similar to all channel patterns is that only one message is put into the channel, same does not hold for the output of a channel- e.g. in case of a Publish-Subscribe Channel there are possibly more than one message leaving the channel. A channel can furthermore be characterized by the Quality of Service the channel has to provide: (i) reliable (yes/no), (ii) secure (kind of security, security token, security algorithm used), and (iii) persistent delivery (yes/no). Moreover it could be important to annotate the logical address of the channel, the maximum size of a single message, and the buffer size for messages to be temporarily saved. Also we have to define if a Dead Letter Channel is associated with the channel and under which circumstances (e.g. time out, buffer size exceeded,…) messages are forwarded to this channel. Parameters used by the data type channel are all of those mentioned. Additionally the pattern is characterized by one input and one output messages as well as the kind of message which can be transmitted through the channel. 3.4 Message Routing

In order to decouple a message source from its ultimate destination, messageoriented middleware employs Routers to guide messages through a network of channels. Furthermore routers not only direct messages through the system but they split, aggregate, or rearrange messages while traversing the middleware. Routers are messaging clients that forward messages between channels and decide e.g. based on content or application context to which channel a message or parts of it should be forwarded to.

Fig. 4. Parameters of a Message Translator

Fig. 5. Parameters of a Message Translator

The Content-based Router pattern (see Figure 4) is described by one message received by the pattern and one message (the same) as output of the pattern. In contrast to most of the patterns a content-based router has more than one exit (channel), however, only one exit is activated while utilizing the router. Furthermore a parameter describes the routing logic which specifies the outgoing channel depending on the content of the incoming message. The definition includes optionally an “else” channel if no matching channel can be found within the

492


routing logic. A possible alternative in specifying the routing rules is to utilize an external service. In this case we have to define the address of the external service. The result of the service shows the channel to which the message has to be transmitted. The Message Transformation patterns help to reduce coupling between applications introduced by the message format when messaging technology is used to integrate different applications which do not share a common data format. Thus, it is typically required to transform messages during their transmission from one application to another. This can be accomplished by using e.g. the Message Translator pattern (see Figure 5). This pattern is characterized by one input and one output message, and the type of messages going in and respectively out. Moreover, the transformation logic has to be defined. This may be a simple mapping of one part of the incoming message to one part of the outgoing message to the point of a complex transformation algorithm (e.g. a complicated XSLT stylesheet in case of a XML message). If the capability of the transformation logic do not suffice the requirements, an external service can be used to achieve the desired transformation.

4 Model Transformation In this section we discuss the mapping of configured EAI patterns to BPEL processes. Consider the following example (see Figure 6) where we transform an parameterized EAI solution. Patterns used in the scenario are those discussed in Section 3. We take this model as a basis and fill the parameters with appropriate values to enable the transformation algorithm to generate platform specific code. In our case we generate a BPEL process and corresponding WSDL file which can be deployed onto an appropriate workflow engine (e.g. “Active BPEL” 6).

Fig. 6. Scenario of the example mapping

The example to illustrate the functionality of our framework is a simple order scenario where a customer sends an order of either a pair of shoes or jewels to a system. The system sends a delivery instruction to a shoe store or a jeweler’s shop depending on the content of the customer order. This decision is accomplished by a routing node. As the incoming message formats differs from the delivery request

6http://www.active-endpoints.com/active-bpel-engine-overview.htm


493

message format we need a transformation between both formats (i.e. a message translator). All channels in the scenario are data type channels, each with one input and one output, and the characteristic “message type”. No more parameters are set. Channels A, B, and C have the customer request message as data type, channel D has the shoe store message, and channel E the jeweler’s shop message type. The customer request message consists of four parts: (i) the kind of article (shoe or jewel), (ii) the customer address, (iii) the name of the article, and (iv) the price of the article. The message types of shoe and jeweler requests differ only as the part “kind” is left out. All message types are described using XML Schema. The content-based routers offer two exit channels, no “otherwise” channel is set. The outgoing channel is determined based on the content “kind” of the incoming message. The message path ending at the show store is selected if the value is “shoe”, if the value is equal to “jewel” the other exit is chosen. Both message translators use an XSL stylesheet to describe the transformation logic which is a simple mapping of values from one type to another. The integration scenario ends in sending the shoe request message to the shoe store and the jeweler request message to the jeweler’s shop service respectively. To finish the parameterization the endpoints of each used service (jeweler’s shop and show store) have to be defined. Now, the parameterized EAI patterns are ready to be used for generating BPEL. 4.1 Mapping to BPEL

Each entity of the EAI patterns diagram will be transformed to a BPEL snippet. Each snippet will be connected according to the message flow, resulting in one BPEL process representing the integration scenario. The incoming request sent out by a message endpoint is received via a Receive activity. The content-based router corresponds to an If activity in BPEL. The routing rules are evaluated using XPath expressions (e.g. “sendOrderRequest/kind = shoe”) as conditions. Each message translator is represented by an Assign activity using a “doXslTransform” operation wherein a XSL style sheet is applied to transform the messages. The message endpoints “shoe store” and “jewelers shop” are mapped to Invoke activities. All messages are represented by variables. The message type is described with XML schema. The single BPEL snippets are glued together via Links to form a complete process. Hence, those links represent the channels in the integration scenario. Beside the BPEL process all needed additional artifacts are generated automatically by the transformation algorithm (e.g. a WSDL file describing the interface of the process, Partner Links used by the process, namespace definitions, imports, …).

494


Fig. 7. The Parameterization Tool

A tool was developed to provide the parameterization of EAI patterns in a comfortable, visual manner including a transformation algorithm generating platform specific code. The tool is available as an Plug-In for the Eclipse IDE7. Figure 7) presents a screen shot of this tool. It provides a toolbar on the right including all available patterns and a parameter configuration facility for each pattern (in the “Properties” tab), and the overall system. It automatically checks if the connected patterns fit together by controlling for instance the message type transmitted over a channel and the message type received by a filter. Moreover, it verifies that all needed artifacts for generating BPEL (e.g. XSD and WSDL files) are imported into the system. Thus, the tool only generates BPEL code if all properties are properly set. Figure 8 shows the generated BPEL of the presented scenario. To ease the error detection of the user, the tool uses the problems view of Eclipse. The actual implementation for generating BPEL code from EAI patterns supports only a subset of all EAI patterns. All basic patterns are currently represented in our implementation of the framework whereas composed patterns (e.g. Message Processor) are not yet fully supported. Some EAI patterns and their corresponding parameterizations are very complex and cannot be transformed into BPEL in a manner that produces acceptable BPEL code. Therefore, we have to provide special kind of services hiding this complexity. Until now, the framework dependends on those services. That means the special, external services are not generated automatically within the framework.

7http://www.eclipse.org


495

Fig. 8. Generated BPEL file (in Active BPEL Designer notation)

5 Conclusions and Outlook In this paper, we presented a compact framework offering a configuration facility for EAI patterns and a transformation algorithm to generate platform specific code (in this case BPEL). We described a tool implementing our framework supporting a subset of EAI patterns and generating a valid BPEL file with additional WSDL description. The architect still needs knowledge of the underlying system (like WSDL messages, port types, and operations), however with the framework we reduce the gap between the architect’s view on a system and the technology used. In our future work we will target improvements in the development of EAI pattern parameters with the help of decision trees[21]. In order to support the whole catalogue of EAI patterns the implementation of System Management patterns and composed patterns (like Message Broker) has to be completed. Until now our MDA approach offers only generating BPEL as platform specific code. Investigations of other targets apart from workflow-based

496


systems are needed, for instance a mapping of EAI patterns onto a generic Enterprise Service Bus (ESB). We have shown that a model-driven architecture approach can be used to automatically generate executable code from EAI patterns. Parameterization of patterns facilitates the reusability of code representing the patterns. We demonstrated a method for transforming the non-executable documentation of EAI solutions into executable artifacts that can be deployed on a BPEL workflow engine.


[4]

[5] [6] [7] [8] [9] [10] [11]

[12] [13] [14] [15] [16] [17] [18]

Web Services Business Process Execution Language Version 2.0 - Committee Specification. Technical report, OASIS, Jan 2007. C. Alexander. The Timeless Way of Building. Oxford University Press, 1979. A. Barros, M. Dumas, and A. ter Hofstede. Service Interaction Patterns. Proceedings of the 3rd International Conference on Business Process Management, pages pp. 302318, September 2005. A. Barros, M. Dumas, and A. ter Hofstede. Service Interaction Patterns: Towards a Reference Framework for Service-based Business Process Interconnection. Technical Report FIT-TR-2005-02, Faculty of Information Technology, Queensland University of Technology, Brisbane, Australia, March 2005. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture. Wiley, 1996. D. Chappell. Enterprise Service Bus. Theory in Practice. O'Reilly Media, January 2004. E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) 1.1. Technical report, Mar 2001. B. Druckenmüller. Parametrisierung von EAI Patterns. Master's thesis, Universität Stuttgart, 2007. M. Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002. D. Frankel. Model-Driven Architecture: Applying MDA to Enterprise Computing. Wiley, January 2003. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 1995. G. Hohpe, B. Woolf, and K. Brown. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, 2003. V. Kramberg. Pattern-based Evaluation of IBM WebSphere BPEL. Master's thesis, Universität Stuttgart, 2006. F. Leymann and D. Roller. Production Workflow: Concepts and Techniques. Prentice Hall PTR, September 1999. R. Monson-Haefel and D. Chappell. Java Message Service. O'Reilly, 2000. N. Mulyar. Pattern-based Evaluation of Oracle-BPEL (v.10.1.2). Technical report, Department of Technology Management, Eindhoven University of Technology, 2005. T. Scheibler and F. Leymann. Realizing Enterprise Integration Patterns in WebSphere. Technical Report 2005/09, Universität Stuttgart, October 2005. J. Trautvetter. Analyse der 'Pipes and Filter' Architektur gegenüber instanzbasierten Ansätzen bei Workflows. Master's thesis, Universität Stuttgart, 2006.


497

[19] W. M. P. van der Aalst, Ter, B. Kiepuszewski, and A. P. Barros. Workflow patterns. Distributed and Parallel Databases, 14(1):5-51, July 2003. [20] S. Weerawarana, F. Curbera, F. Leymann, T. Storey, and D. Ferguson. Web Services Platform Architecture. Prentice Hall, 2005. [21] O. Zimmermann, J. Grundler, S. Tai, and F. Leymann. Architectural Decisions and Patterns for Transactional Workflows in SOA. Proceedings of 5th International Conference of Service-Oriented Computing (ICSOC 2007), September 2007.

Experiences of Tool Integration: Development and Validation J-P. Pesola1, J. Eskeli1, P. Parviainen1, R. Kommeren2 and M. Gramza2 1

2

VTT Technical Research Centre of Finland, P.O. Box 1100, FIN-90571 Oulu, Finland [email protected], [email protected], [email protected] Philips Applied Technologies, High Tech Campus 5, 5656AE Eindhoven, The Netherlands [email protected], [email protected]

Abstract. Generally in software development, there is a need to link the development work products with each other i.e., requirements with the corresponding design artefacts, to the resulting software and associated test cases. This enables, for instance, the efficient change impact analysis and reporting facilities during the different phases of the software development life cycle. Establishing and maintaining these links manually is a laborious and error prone task, so tool support is needed. This paper describes a configurable tool integration solution (the Merlin ToolChain) that integrates project management, requirements management, configuration management and testing tools. The paper introduces the architecture of the ToolChain as well as describes the development and validation activities carried out. Experiences from real life industrial case showed that the ToolChain works and is useful in collaborative software development. Keywords: Industrial case studies and demonstrators of interoperability, Tools for interoperability, Engineering interoperable systems

1 Introduction The software size in embedded systems grows exponentially. For instance, in consumer electronics it doubles every one to two years. In the perspective of growing size and complexity of embedded systems, companies are not able to develop all the required functionality by themselves. As a result, suppliers specialize in specific functionality or specific skills which they can sell to others. This is clearly visible in the largely growing numbers of the outsourcing constructions in the past years. Collaborative engineering of embedded systems has become fact of life, and currently there is no way back anymore; companies have

500

J-P. Pesola, J. Eskeli, P. Parviainen, R. Kommeren and M. Gramza

already outsourced large parts of their developments to other companies, resulting in that the related skills are no longer available in their own organisations. Instead, the companies need to manage a complex situation of many partners, subcontractors, suppliers, software platforms and so on. Poor interoperability of development tools is one of the major problems in embedded systems development today. Currently there are many product development tools, often with dedicated, specific strengths. These tools need to be connected and these connections managed in order to enable traceability between development phases as well as between collaboration partners, ensure consistency of the work products as the development progresses, and provide visibility beyond partner borders. However, the existing tools are hardly integrated and poorly interoperable. At worst, manual work is required to transfer data between tools. Industrial experiences indicate that development performance can be increased by tens of percentages, if development is optimally supported by well-integrated tools. This is true for product development within one company, but even more for multicompany development, where many different tools are used. Currently the main available tool integration solutions are the integrated tool sets offered by the large tool vendors. These bundled tool-chains solve the problems only partly and create dependency on the particular tool vendor. For instance, introduction of a new, good tool from another vendor impedes the total development process dramatically, due to poor integrability of single tools. This paper describes the further development of the tool integration environment called the ‘Merlin ToolChain’ to support collaborative software development. The first version was introduced in I-ESA 2007 [1]. The development of this tool integration has been carried out in the Merlin 8 project, which is a three-year research project within the ITEA 9 framework. The paper is composed as follows. Chapter 2 describes related work about existing tool integration approaches. This is followed by Chapter 3 where the general concepts for the tool integration in the ToolChain and the first prototype of the ToolChain are introduced. Then the further development and generalisation of the tool chain is discussed in the Chapter 4. Chapter 5 presents the results and findings of the ToolChain validation in an industrial project. Finally, the conclusions and thoughts for future research are discussed in the Chapter 6.

2 Background: Existing Tool Integration Solutions In this chapter we list existing approaches to tool integrations, what is meant by application lifecycle management (ALM), discuss briefly about existing ALM solutions and finally about the general weaknesses of existing tool integrations.

8 Merlin project home page: http://www.merlinproject.org 9 ITEA home page: http://www.itea-office.org

Experiences of Tool Integration: Development and Validation

501

2.1 Tool Integration Approaches

The current approaches to tool integration are described in the following table (Table 1). The descriptions are based on [2, 3, 4, 5].

Table 1. Current approaches to tool integration Approach

Description

Piecemeal

Tools are applied to achieve improvements in specific life cycle phases and migration between the development phases is done manually. This approach focuses on specific phases and lacks the view to the overall improvement between the phases

Singlevendor

This approach attempts to improve all life cycle phases with a fulllifecycle-product from a single vendor. The approach requires selecting a vendor with the technical expertise required to effectively support all life cycle phases, creating a risk of locking the organization into a costly, proprietary solution.

Best-inclass

This approach attempts to integrate the best tools of regarded domains, typically from different vendors, for specific life cycle phases. Best-in-class has two variations: point-to-point integrations and framework based integrations:

x

x

Point-to-point integrations, or one-to-one integrations, provide integration built between two defined tools specifically. Point-topoint integrations are adequate only for small numbers of integration endpoints and typically create more complexity in developing and managing tools than they solve. This is the most common type of interface between systems engineering tools. [6]. Framework-based integrations attempt to classify tools and provide integration between tool classes based on vendor-neutral interfaces and mechanisms. Framework-based approach provides integration environment and common look and feel without limiting the choice of tools.

Another relevant topic regarding tool integration is application lifecycle management (ALM), meaning the coordination of development life-cycle activities, including requirements, modelling, development, build, and testing, through enforcement of processes that span these activities, management of relationships between development artefacts used or produced by these activities; and reporting on progress of the development effort as a whole [7]. ALM operates with the artefacts produced and used during the lifecycle of SW products by providing visibility into the status of the evolving SW product. A variety of solutions provide mechanisms to represent different types of traceability links between developmental artefacts. However, the interpretation of the meanings of such linkages is often left to the user.

502


2.2 Existing Implementations

The existing implementations of tool integration include company specific tool integrations (piece-meal or point-to-point) that are not publicly available (and thus not discussed in this chapter), various frameworks, and single vendor solutions for ALM. Also, development environments offering complete product development environment including integrated development tools have also appeared. Examples of these implementations are presented in Table 2.

Table 2. Examples of tool integration implementations Name

Type

Description

Borland Open ALM

ALM solution

Several Borland tools (e.g., CaliberRM and Caliber DefineIT, Together, SilkTest, StarTeam) are integrated with each other. CaliberRM integrates also with MS VSTS and Eclipse.

IBM ALM solutions

ALM solution

IBM tool portfolio covers all development lifecycle stages integrating several IBM Rational tools, (e.g., RequisitePro, Rational Rose, Rational Software Architect, Rational Functional Tester, Rational Performance Tester and ClearCase CM).

Microsoft Visual Studio Team System (VSTS)

ALM solution

A development platform that support various phases of SW development lifecycle. The backbone is the Team Foundation Server, the central point of contact for project and process management. Also, process guidance is provided via Microsoft Solutions Framework (MSF).

Eclipse

Framework

The Eclipse provides mechanisms to use, and rules to follow to integrate tools. Eclipse Platform offers good support to extend its functionality by plug-ins. Eclipse simplifies tool integration by allowing tools to integrate with the platform instead of each other [4, 8].

MODELBUS

Framework

MODELBUS 10 offers a tool API independent layer of abstraction for exchanging models using Eclipse EMF metamodeling technology. The aim is to simplify access to tool data in a distributed environment based on SOAP middleware. MODELBUS doesn’t offer support for, e.g., management of traceability links across tools.

ALF

Framework

Application Integration Framework (ALF) 11 is part of Eclipse foundation. The project aims to provide the logical definition of the overall interoperability business process. This technology handles the exchange of information, the business logic governing the sequencing of tools in support of the application lifecycle process,

10 http://www.eclipse.org/mddi/ 11 Alf project, (2007) www.eclipseproject.org/alf


503

and the routing of significant events as tools interact. IBM Jazz

Framework

IBM Jazz attempts to build a scalable, extensible teamcollaboration platform for seamlessly integrating tasks across the software lifecycle. Jazz is based on Eclipse, and is a kind of middleware layer for linking development assets.

Model-based tool management and integration platform

Framework

The platform supports model integration, where models defined in different tools for different aspects of the same system are related such that they may share and exchange data. The integration platform also enables model management functionalities on a fine-grained level. The approach is based on Matrix PDM tool and stores a copy of the data in the tool, which then creates consistency problems. [9]

Fujaba

Framework

Mechanism to integrate different tools on the metamodel level. A consistency management system is included, especially for the integration of different or enhanced meta-models. The Meta-Model Extension and MetaModel Integration patterns enable the integration of data in different scenarios on the meta-model level. [6]

CollabNet

Devel. environment

CollabNet is a collaborative development environment where the developers and IT projects managers collaborate on-line through CollabNet.

As it can be seen from the table above (Table 2), already many tool integration frameworks and solutions exist. However, these solutions do not solve the integration problem optimally. For example, the existing ALM solutions are single vendor specific tool integrations creating dependency on the vendor, regarding for example version support and future developments of the tools. Single vendor solutions also limit the choice of tools; companies cannot choose the individual tools that would fit to the situation and specific purpose the best, but have to consider the development tools as a whole. This results in having to use a set of onaverage best tools available for the situation, whereas free selection of individual tools would provide better support when well integrated. The same is true for the development environments. Regarding tool integration frameworks, they are often generic, providing flexibility for the integration, but on the other hand causing that the integration has to be planned and built from scratch each time, resulting in large amount of effort needed. The Merlin ToolChain uses existing knowledge and solutions (e.g., Eclipse) of tool chain integrations and tries to come up with new ways to solve the problems like: replicating data, manual transfer of data between tools etc. These aspects are discussed in more detail in the following chapters.

504


3 Tool Integration Concepts This chapter describes the concepts of the Merlin ToolChain, including the data model and the architecture of the ToolChain. 3.1 Merlin ToolChain Data Model

The data model of the ToolChain presents how the development artefacts from the different tools map to each other. As stated before, the ToolChain integrates four different type of tools: project management (PM), configuration management (CM), test management (TM), and requirements management (RM). The following figure (Fig. 1) shows simplified models of example tools and how they are traced to each other via unique identifiers in the ToolChain.

Fig. 1. Data model of Merlin ToolChain

The data model is divided into four parts according to the tools integrated in the ToolChain. For each tool the entities that are connected to another entity in certain relationship in the ToolChain are presented in the model. This linking of the connections is based on the entities’ unique identifiers, which can be for example id strings. Based on these unique identifiers traceability links are created and stored in to the traceability database. 3.2 Merlin ToolChain Architecture

The basic idea is to have several Eclipse plug-ins making it possible to connect the different tools into the same environment. The Merlin plug-in is a kind of “master plug-in” and it is composed of a set of extension points in which the tool plug-ins connect. The Merlin plug-in communicates with tool specific plug-ins through


505

tree- and table interfaces. Each tool integrated into the ToolChain is implemented using the defined interface providing the Merlin plug-in the data from the tools. The Merlin plug-in then delivers the data to Traceability View plug-in, which visualizes the information and status to the end user. The links between the data from the different tools are stored into a traceability database that is also operated by the Merlin Plug-in. The following figure (Fig. 2) introduces the conceptual architecture of the Merlin ToolChain.

Fig. 2. Merlin ToolChain conceptual architecture

This architecture enables that the Merlin plug-in does not need to know how the particular plug-in gets the data it needs, so there are no restrictions or definitions while designing and implementing tool specific plug-ins. This means that the plugin developer can create a plug-in for a new tool as he wishes and after that integrate the new plug-in into Merlin ToolChain by implementing the supplied interfaces. The main idea of the Merlin ToolChain is to integrate different tools together and bring only the most essential information from every tool to the shared view. This essential information was defined in co-operation with the Merlin industrial partners. Also, for ease of use, a similar look and feel was used for the views. 3.3 The First Prototype

This chapter describes the first prototype of the Merlin ToolChain briefly. This work was done in close co-operation within the Merlin project consortium, including valuable input from the industrial partners (e.g., Philips) on the requirements and potential use for the ToolChain. The development and the resulting first prototype itself are described in detail in [1]. The tools integrated in the first prototype of the Merlin ToolChain were, for requirements management IBM Rational RequisitePro, for project management

506


Philips Project Assist Tool (PAT), for configuration management Telelogic Sunergy/CM and for test management Philips SoftFab. The development of the Merlin ToolChain started from learning how to create and implement Eclipse plug-ins. The first tool integrated into Eclipse environment was IBM Rational RequisitePro and later on the ToolChain was expanded to be a set of separate tool specific plug-ins for the other above mentioned tools. After the tool specific plug-ins were ready, the integration between these tools was created. The goal was to increase the traceability during the project life cycle. Items from the requirements management tool (RequisitePro) were selected to be “the integration point” where the other tool’s traceability links should be created. This creation of links was handled differently and separately for each tool. This means that creating a link for example between project tasks (from PAT) and requirements (from RequisitePro) was made in the plug-in made especially for linking these items, while on the other hand, code files (from Synergy/CM) were linked with these requirements in another plug-in. Thus the first prototype was not according the architecture described in Fig. 2. The first prototype of the ToolChain appeared to be quite promising one. We had several demonstrations and try outs with the ToolChain and we got encouraging comments and experiences on it. However, the ToolChain still needed some improvements to make it more valuable and useful in a real life projects, and during the Merlin project, it has been further developed as will be described in the following chapters.

4 Generalisation of ToolChain The first prototype proved the concept of tool integration via Eclipse plug-ins, next goal for the ToolChain development was to make a more generic tool integration solution. The generalisation work continued to be done in close co-operation with the Merlin project consortium; in bi-monthly workshops the status of the development was presented and future development directions agreed. This work started by developing integrations to alternative tools of the project management (PM), configuration management (CM), requirements management (RM) and test management (TM) tool types. This was done in order to study the differences in plug-ins for different tools and thus to find out the generalisation possibilities for the integration. Another aim was to prove that the ToolChain concept was robust with respect to changing tools: interoperability of tools should be maintained when plugging out a tool and replacing it by another. The following tools were integrated to the tool chain using the same point-to-point method as in the first prototype solution: Telelogic DOORS, OSRMT (Open Source Requirements Management Tool), Open Workbench, Subversion and TestLink. These tools were chosen based both on industrial partners’ input and on decision of using open source tools. Based on doing these integrations, the generic interfaces for PM, TM, CM and RM tools to the ToolChain could be specified. This enables the changeability of the tools and also easy integration of other similar tool(s) into the ToolChain.


507

Currently the ToolChain supports two PM tools (Open Workbench, PAT), three RM tools (DOORS, OSRMT, RequisitePro), two CM tools (Subversion, Synergy/CM) and two TM tools (Testlink and Softfab). Adding other PM, RM, CM or TM tools to the ToolChain is also easy using the defined API. Using the tool selector feature of the ToolChain any combination of these tools can be taken into use, however if the tools are changed later on, the traceability database must be reset and therefore all the traceability data will be lost. Creating a purely open source tool set from the existing integrations in ToolChain is also possible. However, the ToolChain itself is not yet available as open source, but will share it in the near future. The Traceability view (see Fig. 3) gathers all the information from the selected tools. Users can create dependencies between different development artefacts in this view by drag & dropping. When new dependencies are created, the data is immediately available to the other ToolChain users, who then can inspect the existing relations and create new ones if necessary.

Requirements

Source code related to task Task status Test cases related to requirements

Fig. 3. ToolChain’s requirement traceability perspective

The traceability links are created using drag & drop mechanism, e.g., tracing a code file to requirement is done by selecting a requirement and then dragging code files from the CM tool view and dropping them to the code files window in the Traceability View. The dragged items come from tools’ own plug-ins. The same mechanism works for all the existing and new tools. This mechanism enables easy adding of new tools to the ToolChain significantly; in the first prototype changing tools and defining relationships between their artefacts had to be done by modifying the source code and the traceability database structure. At the moment, all the plug-ins handle their own user interface themselves but the Merlin-plug-in synchronizes the views. Thus, all views are always up to date for all ToolChain users, regardless if they have the underlying tool installed in their computer, or where they are located.

508


5 Experiences of Implementation: Validation of Tool Chain In this chapter we discuss about ToolChain validation case. The case was carried out in cooperation between Philips and VTT. The trial was performed in the OSIB project, realized by Philips Applied Technologies and its purpose is to provide the Integrated Ambient Experience™ 12 for a new hotel chain 13. The software is designed and developed for several hardware subsystems interconnected through well defined software interfaces. The subsystems of the OSIB solution are as follows: x

x x

Moodpad: advanced remote control with a touch screen and hardware buttons. Moodpad is used to enable the user interface to the hotel room (controlling the light, TV, Venetian blinds, sunscreen curtain, room climate). Room Controller: Implements the hotel room logic and interacts with the Moodpad, room TV, climate control system, RFID door lock. Ambient Experience server: subsystem functioning as a gateway between hotel rooms and the external components: Property Management System of the hotel chain and the remote hotel diagnostics centre.

All the devices communicate either via Ethernet or wireless (Wi-Fi) connections with each other. The project uses agile way of working, where development is done in increments of two weeks and requirements are selected for each increment, together with the customer. The goals for the case from the ToolChain development viewpoint were to evaluate the usability and usefulness of the ToolChain in real-life product development. The aim was to get experiences from setting up the tool chain to the industrial situation, from its’ use in practice as well as from the adaptability of the selected concepts to the needs appearing during the use of the ToolChain. From the case project viewpoint, the goals for using the tool chain were to improve traceability and visibility to the project progress while not interrupting the product development work. 5.1 Preparation and Setup

The case was the first time that the ToolChain was tried out in a real life setting, so the technical improvements of ToolChain during the case were significant. First the ToolChain was adapted to Philips environment by integrating the tools they had in use to the ToolChain. The toolset used in the case was Project Assist Tool (PAT), DOORS, Subversion and Softfab. In practice, this meant developing new plug-in for DOORS, adopting the available Subversion plug-in and updating the PAT and

12 See http://www.medical.philips.com/main/company/ambient_exp/ for the description of the Ambient Experience for Medical Environment. Concepts mentioned there can be applied in different domains as well, for example in the hospitality. 13 More information about the hotel itself and the room technology can be found at http://www.citizenm.com/new-hotel-room-technology.php.


509

Softfab plug-ins as the versions used by the project were not the same as were used in the development of the ToolChain. The installation of ToolChain to the case project environment was done in a week when the ToolChain developers from VTT visited Philips to set up the ToolChain. Some compatibility problems were encountered at first, but they could be handled quite easily as they were mainly configuration problems. Also, some features considered essential by the case project were added to the ToolChain during the installation. The trial showed that the ToolChain could be adopted and set up for the industrial project environment relatively quickly, only a week for setup was needed. Considering that the ToolChain integration is only a research prototype, the setup period can be further shortened in the future. 5.2 Experiences from using the ToolChain

Next the OSIB project members would use the ToolChain in everyday development work. During this period the OSIB project members wrote down all the encountered problems and ideas for improvement. This feedback was given to the ToolChain developers bi-weekly and urgent problems were handled immediately. The feedback was also analysed and prioritized in the bi-monthly workshops with the Merlin partners. Examples of the improvements made for the ToolChain based on the feedback include: development of the Tool Selector that enables selecting the tools that are in use, improving usage of available space in the user interface, and showing more information for the user. Also, the database was changed to an open source alternative during this development period. The new version of the ToolChain was sent to the industrial partner after it was finalized. In conclusion, during the evaluation period many new features were added in the ToolChain and it became more robust and durable in the practical use. The case also proved that the ToolChain works in daily operations in a natural way without complicating things, but rather making things easier by providing traceability between development artefacts like requirements and code files.

6 Conclusions and further research In this paper, further developments of a tool integration solution called Merlin ToolChain were discussed. The Merlin ToolChain provides customizable tool integration for requirements management, configuration management, project management and test management tools. The ToolChain has been evaluated in a real industrial product development project, proving to improve the traceability of product data and visibility of the project progress without disturbing the product development. The ToolChain also proved to be relatively easy to install and to take into use. As a result we conclude that the current version of ToolChain works and can be useful in collaborative software development, but it should be noted that it is just a research prototype; it has not been extensively tested or used in different situations.

510


Future improvements of the ToolChain include, for example, developing a robust user right management / security model, and extending the current traceability model to support direct tracing between any types of artefacts. Also, adding new types of tools, e.g., for change management, design, etc and developing means to control the integrated tools from the Merlin ToolChain would improve the usefulness of the tool.

Acknowledgements The authors would like to thank all Merlin 14 research partners for their assistance and cooperation. Especially the authors would like to thank the industrial partners’ investment of time and support for the study, especially Philips representatives and the OSIB project members.

References [1]

[2] [3] [4] [5] [6]

[7] [8] [9]

Kääriäinen, J., Heinonen, S, & Takalo, J., 2007, Challenges in collaboration: tool chain enables transparency beyond partner borders, Proceedings of 3rd International Conference on Interoperability for Enterprise Software and Applications I-ESA 2007, March 28th – 30th, 2007. Kanwalinder, S., Tool Integration Frameworks -- Facts and Fiction, IEEE Proceedings of the National Aerospace and Electronics Conference 2 pp. 750-756, 1993 Nghiem, A., 2002 Web Services Part 6: Models of Integration http://www.awprofessional.com/articles/article.asp?p=28713&seqNum=2 Eclipse http://www.eclipse.org/proposals/eclipse-almiff/main.html Digital, Framework-Based Environment Design Center, Version 2.0, SPD 56.03.00, http://h18000.www1.hp.com/info/SP5603/SP5603PF.PDF Burmester, H. Giese, et al., “Tool integration at the meta-model level: the Fujaba approach”, International journal on software tools for technology transfer, Springer, vol. 6, no. 3, pp. 203-218, 2004. Schwaber, C., The Changing Face of Application Life-Cycle Management, Forrester Research Inc., August 18, 2006. Amsden, J., Levels Of Integration, Five ways you can integrate with the Eclipse Platform, 2001, OTI. http://www.eclipse.org/articles/index.html El-khoury, J., Redell, O., Torngren, M., A tool integration platform for multidisciplinary development, 31st EUROMICRO Conference on Software Engineering and Advanced Applications, 30 Aug.-3 Sept. 2005 Page(s):442 – 449

14 Merlin is an European co-operation project carried out in ITEA framework. Merlin web pages: http://www.merlinproject.org, ITEA web pages: http://www.itea-office.org

Interoperability – Network Systems for SMEs Kai Mertins, Thomas Knothe, Frank-Walter Jäkel Fraunhofer Institute Production Systems and Design Technology Pascalstr. 8-9, D-10587 Berlin {kai.mertins, thomas.knothe, Frank-Walter.Jaekel} @ipk.fraunhofer.de

Abstract. Small and Medium Sized Enterprises suffers more than others from interoperability challenges. On the one hand these companies are often dependent from different larger enterprises that are dictating methods standards and technologies for collaboration. On the other hand they have to form cooperation and networks in order to fulfill customer requirements – e.g. to provide complete components as known in the car industry. The paper gives an overview about SME situation regarding Enterprise Interoperability and related research activities. In the second part a framework and integrated methodological and software service solutions will be introduced for tackling SME challenges for cooperation establishment and operations starting and ending from a business perspective. A certain part of this portfolio the extended MO²GO software based process assistant will be explained in more detail. At the end a research and technological outlook will be provided Keywords: Interoperability in SME, Enterprise Modelling in the Context of Interoperability, Frameworks

1 Introduction Short-term and flexible usage of market opportunities requires close cooperation between different core competencies and their bundling in common value-added chains. This is often limited by the lack of compatibility between IT solutions, but also by organizational and cultural differences between the companies. In this situation large companies tends to react with the establishment of subsidiaries to better manage specific conditions in different regions around the world such as laws, rules, mentality etc.. An example could be the laws in some countries such as China that only products could be soled if a production exists in these countries. But also environmental costs and logistic costs are considered. Especially the large companies can benefit from fewer restrictions in terms of environmental and social

512

Kai Mertins, Thomas Knothe, Frank-Walter Jäkel

responsibility which reduce their production costs and increase their compositeness on the European market. In contrast, small and medium-sized enterprises (SMEs) have to rely much more on cooperation and networking. Unlike large companies, small and medium-sized companies cannot rely on company-wide standards and require far more flexible solutions and interoperability [1] to act in different networks with different partners. Applications for network building and operation of networks such as M + E Network [2], [3] VIENTO, Supply Chain Mapping (www.supply-chain-mapping.de) consider both the short-term benefits as well as the long-term ability of SMEs to operate in different collaborations. This increases the need for coordination and interoperation of IT-systems and processes. „Interoperability” is needed to facilitate the technological and organizational requirements for simple and flexible networking with different companies. Some problems linked with the word "interoperability" are: x x x x x x x x

Format differences in the processing of orders or supplier data and thus costs for manual activities Requirement of transparency by customers Many different supplier portals, market places and custom specific software Support of joint product development processes Mastery of a menagerie of different IT systems Data quality at the interface with customers and suppliers Low IT accessibility, sometimes only a web browser could be expected Different certification requirements of the customers

The list can be further expanded and illustrates the variety of aspects which can be summarized under "Enterprise interoperability". "Enterprise Interoperability" defines as a field of activity with the aim to improve the manner in which enterprises, by means of Information and Communication Technologies (ICT), interoperate with other enterprises, organisations, or with other business units in the same enterprise, in order to conduct their business [4].

2 Situation in Research and Industry Potential solutions to the interoperability of companies are provided by the results from European projects like INTEROP-NoE and ATHENA-IP [1]. These projects addressed also the handling of the influence of mutual trust with cooperation partners (e.g. Can I call my cooperation partners clients or not?) and possible cultural aspects (e.g. different contact initiations in different countries or different decision-making structures). The cultural aspects of companies and their collaborations have been a major issue in the project IKOPA (innovation capability through cooperation and participation) [2]. With IKOPA, among others, the influence of corporate culture and cooperation on the innovativeness of the company was analyzed and optimize. On the EU level projects such as DBE-IP (Digital Business Ecosystem) has tackled the cultural issues and it is also addressed within the roadmap of the enterprise interoperability cluster.

514


3 Solutions Provided to Industry The Corporate Management (CM) division at Fraunhofer IPK-Berlin has developed new concepts and tools for the establishment of interoperability in enterprises in two of the largest EU projects for interoperability as well as in the context of industrial projects. Key points of CM work are the issues of synchronization and interoperability of companies with specific emphasis on SMEs [6, 9, 10]. With further results from projects for enterprise networks and cooperation of enterprises in the following a framework of the IPK to support the interoperability of companies is outlined, and a solution component is closer presented. 3.1 Framework for the Improvement of SME Interoperability

A flexible but secure, and above all, inexpensive network of partners allows for a significantly higher agility. To implement such networking means a high investment risk for many companies which have to adjust their business processes and software to different partners without knowing how many common business activities will be held. This requires a continuous support of cooperation in the development stages. In Fig. 2 the general phases of cooperation based on [10] are shown. Phase 1 Identify Demand

Phase 2 Search Partners

Phase 3 Establish Network

Phase 4 Operate Collaboration

Phase 5 Optimise Collaboration

Fig. 2. Cooperation phases based on [12]

At first, in phase 1 the own need for external cooperation is to be identified. This requires the transparency of the own profile, as well as competency and skill profiles of potential partners. Finding partners and the partner selection in Phase 2 are characterized by matching the desired profile with those of potential partners [12]. This results in the compilation of a joint cooperation profile with which the business for both partners can be assured. Legal aspects play a not insignificant role. To establish the networking is required to examine technical specifications for the business and production process integration (for example for data exchange or for packing ¬ conventions) as well as organizational schemes (accountability for quality audits and Returns). The operational phase is characterized by monitoring the performance and the identification of optimization opportunities, which are to be implemented in the ongoing operation during Phase 5. The different phases are not strictly separated. Supporting methods and models should be applied during the phases.

Interoperability – Network Systems for SMEs

515

3.2 Solution Modules

For all of the partners simple methods to cooperate along the stages are necessary, but they must be able to integrate case wise. The integration is based on the Integrated Enterprise Modelling (IEM). The appropriate models and approaches serve as a "backbone" for all methods and tools of cooperation. A uniform transparency is offered by the network model, which is gradually built up along the cooperation phases (Fig. 2). The model includes descriptions of the connected network products, processes, systems and organizations. In Fig. 3, the solution components of the enterprise management division of IPK are aligned along the phases to improve the interoperability of cooperation’s. Essential is the model integration of the solutions, so that the components can be integrated application-oriented. Analyse

Interoperability Maturity Models

Integrated Enterprise Modelling MO²GO

Benchmarking Index

Intellectual Capital Statement Integrated Cooperation Reference Models

Design

VIENTO Platform, Supply Chain Mapping Model Data Exchange

Operation

Implementation Assistant Process Assistant SPIDER-WIN Order Data Management Phase 1 Identify Demand

Phase 2 Search Partners

Phase 3 Establish Network

Phase 4 Operate Collaboration

Phase 5 Optimise Collaboration

Fig. 3. IPK portfolio for continuous support of networked enterprises

Linked with the model of the network the solution components of IPK are: x

x

x

The "Intellectual Capital Statement" identifies the need for structural, relational and human capital of a company. Based on the analysis of the relationship capital, optimization potential in existing collaborations as well as new needed skills can be unlocked. [14, 15] Often, particularly in the phase of finding partners, the abilities to cooperate are not transparent. The "EIMM maturity model" for interoperability enables rapid identification of the capabilities of a company to cooperate without giving internals to the outside [16]. A transparent description of the processes and structures of the company allows for easy definition of "external" views for fast linking of process

516


x

x

x

x

x

x

chains. The IPK deploys its MO²GO-System [8] which implements the integrated enterprise modeling and enables a very fast and easy to understand modeling. The "VIENTO platform" helps to define the necessary operational skills, the development of joint production process and the relevant legal aspects of a cooperation of partners facing the end customer [5]. The software AMERIGO visualizes all supplier relationships (supply chain mapping) and clarifies delivery risks, so that alternative strategies for reorganizing the supply network can be chosen. Many companies already have enterprise and process models. With the help of developments from INTEROP and ATHENA individual companies can exchange models and synchronize content to design together processes and principles of the cooperation [9, 15]. With the help of an implementation assistant operational processes of the cooperation can be developed and adapted in such a way that the necessary specifications for IT implementation respectively adaptation of the software systems is directly available. [18]. The process assistant is the extension of the implementation assistant with all management and support processes of the cooperation and serves as an integral foundation for an integrated and above all complete digital management system based on the cooperation model [19]. With the help of the "SPIDER-WIN order data management system" it is possible to automatically distribute order data over several stages (tiers) of the Supply Chain, monitor processing status in the supply chain and react to disturbances. Orders are automatically fractioned in their subcontracts and given to the suppliers and subcontractors. In addition, the modelconfigured system offers overall visibility of the "stocks" in the entire supply chain [7]. With the help of the benchmark index [20] the performance of the cooperation can be easily compared with best practices from more than 15 countries around the world. The benchmark index is updated annually with benchmarking data for over 100,000 businesses. With this instrument improvement potentials can be identified quickly, which can be linked for example with the results of the knowledge balance.

In addition to the syntactic and semantic backbone, the underlying business model leads to a common description and communications base. In the next section as an example the implementation assistant is presented to support phase 3 and phase 4 of the reference procedure. In the next subchapter the module Process Assistant will be explained to a wider extent to support a use case in the real estate business. 3.3 Use Case - Process Assistant in Distributed Work Environments

The real estate business in Berlin is radically changing from public to private owned. In this context more efficiency in managing complete living environments as well as new tasks for becoming a full service provider are demanding. In our


517

case several small sized real estate management companies had to merge. In order to realize efficiency effects harmonised work environments including common usage of software systems are required. As first step a preliminary enterprise model based on the IEM methodology were developed by the entire corporate management team. This model played only the frame which the refined definitions have to follow. These activities were performed by knowledge workers in the operative business coming from the distributed subsidiaries of the company under coaching support by the modelling experts. This participative approach ensures elaboration of real enterprise representations highly acceptance of modelling activities. By the way the procedures of work use of software were harmonised by take into account best process and structure practices. By using of the MO²GO capabilities of automated import and export of document linking information and new developed services for connecting IBM LOTUS Notes content more operative information can be linked to the model. From this point the Process Assistant were generated in order to give the entire company employees access to the model based information (see Fig. 4). Lotus Notes Environment

Process Assistant Model based linking to content

Tr C a n on sf te or n m t at io n

MO²GO Enterprise Modelling t n en io nt at Co form s an Tr

Fig. 4. Operationalized Enterprise Architecture to support day to day business

The process assistant provides reflecting views as html report with an integrated graphical model viewer. The representation of the reflecting views is independent from the modelling language and so easy to use for employees which are not familiar with enterprise modelling but need support to fulfil their duties. On the other hand more operational data and documents (responsibility lists, actual figures) were decentralised elaborated without recognising the model behind. By applying this approach not any more conceptual modelling elements, work instructions and checklists are integrated into the process assistant as well as day to day changing information. The beauty is, whilst knowledge worker do not recognising the model behind their work but a lot of colleagues receives the benefits through the process assistant. In order to integrate the process assistant, the MO²GO tool and IBM Lotus Notes some services for automatic linking of

518


documents to the model and transformation of document data through the modeling tool to the process assistant. This solution extent the Active Knowledge Modelling approach by Karlsen and Lillehagen (compare [21]) functionality to integrate non modelled Content into a joint enterprise architecture without explicit modelling by users. It is a complementary approach between static model representation and operation and the concept of model generated workplaces (MGWP).

4 Conclusion and Outlook The medium and long-term goal is a dramatic change of the current situation there SME are react mostly direct on the pressure coming from large companies both customers and suppliers. Today the result is the elaboration of partial solutions just for one challenge related to one customer or supplier. Consequently, European SME might not be on a good technological edge for the competition on the market places around the world. In contrast in the future SME should have the capability to provide their interoperability services to their collaboration partners (customers, suppliers and cluster/network partners). This requires: x x x x

Transparency of the processes out of the company and the possibility to create different interconnected (external) views of these processes on demand, Prepared to operate in a multicultural environment as well as for the management of different degrees of confidence (Trust-Levels), Implementation of a strategic cooperation management and training of the employees (management and operative staff) to act in global networks Clear definitions of the terminology used in the daily business (might be by the application of reference ontology technologies and enterprise modelling).

To be sustainable, solutions towards interoperability require a development in the direction to become standards. Two aspects are in the focus: x

x

Interoperability to enable efficient collaboration and cooperation within SME networks dynamically according to market demands to ensure that SMEs as a network creates a market positioning, so that they become equal partners for large international companies. Interoperability as a precondition for cooperation on global markets, especially between different businesses of different sizes. Towards the capability of an organisation to simultaneous participate in various collaborations and networks without adapting the internal systems and process architecture and without providing specific proprietary systems for each partner.

Sustainability of enterprise interoperability requires the capability of SME to participate in collaborations and enterprise networks on demand without high additional investments in IT or process support. The vision is the accessibility of


519

easy to use and open services supporting collaborations. Organisations such as the INTEROP-Vlab on the European level with its localised poles such as the DFI in Germany are established to coordinate the work on such vision. The introduced use case of a distributed midsized intents, these kind of companies have still to overcome own interoperability gaps. The introduced interoperability framework solutions can help companies on the way to better business. Especially the extended process assistant and its interfaces to the internal operational content enables on the one hand more structured and efficient business process by reducing unnecessary conceptual work and delays. On the other hand employees can stay at their environment but be “hidden” model based connected to the entire company. One of the next steps for solution improvement is the introduction of semantic services to extract content from business operations semi automatically into the enterprise model. The experiences from the real use case are very encouraging.

References [1] [2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

Müller, J. P.; Mertins, K.; Zelm, M. Enterprise Interoperability II. New Challenges and Approaches. Springer-Verlag London 2007. Schallock, B.; Nojarov, S: Mit Wirksystem und Prozessmodellierung zur leistungsorientierten Innovationskultur. In: Doleschal, R. et al. (Hrsg.) Innovationen systematisch gestalten. Beiträge zum Innovationskongress 2006, Schriftenreihe des KOM, Fh Lippe und Höxter, Lemgo 2007, S. 107 ff. Enterprise Interoperability Research Roadmap, Final Version (V4.0), 31 July 2006, published by the European Commission, http://cordis.europa.eu.ist.ict-ent-net/eiroadmap_en.htm Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990. Schallock, B.; Yalniz, Z.: Network management tools supporting market access and product innovation – cases from VIENTO, cDIE and InnoRegio. Proceedings Sevilla 13.-16. June 2004; Internatioanl Concurrent Engineering conference ICE 2004 BIBA Bremen Press, S. 248- 256 Paganelli, P.; Peterson, S. A.; Schallock, B.: Feature-based analysis framework for Interoperability in networked organisations. in: Camarinha-Matos, L.M.; Afsarmanesh, H.; Ortiz, A. (Hrsg.): Collaborative networks and their breeding environments. New York: Springer 2005, S. 467-474. Rabe, M., Weinaug, H., Unterstützung von KMU bei Prozessgestaltung und Supply Chain Execution. In: Uhlmann, E. (Editor) 3D-Erfahrungsforum - Innovation Werkzeug- und Formenbau. Tagungsband 3D Erfahrungsforum, IPK Berlin 17-18. Mai 2006, S. 53-63. Mertins, K.; Jaekel, F-W: MO²GO: User Oriented Enterprise Models for Organizational and IT Solutions. In Bernus, P., Mertins, K., Schmidt, G.(ed.). Handbook on Architectures of Information Systems. Second Edition. Springer-Verlag, Berlin Heidelberg New York 2006, S. 649-663. Jaekel, F.-W.; Rabe, M.; Zelm, M.:’Praxisnahe Interoperabilität von Unternehmenssoftware in KMU-Netzwerken’, Industrie-Management 21 (2005) 4 Gito Verlag, Berlin, 2005, S. 49-52.

520


[10] Jaekel, F.-W.; Perry, N.; Campos, C.; Mertins, K. and Chalmeta, R. (2005) Interoperability Supported by Enterprise Modelling; On the Move to Meaningful Internet Systems 2005: OTM Workshops: OTM Confederated: International Workshops and Posters, AWeSOMe, CAMS, GADA, MIOS+INTEROP, ORM, PhDS, SeBGIS, SWWS, and WOSE 2005, Agia Napa, Cyprus, October 31 November 4, 2005. Proceedings Editors: Robert Meersman, Zahir Tari, Pilar Herrero ISBN: 3-540-29739-1 Chapter: p. 552; Lecture Notes in Computer Science, Publisher: Springer-Verlag GmbH , ISSN: 0302-9743 Subject: Computer Science Volume 3762. [11] Greiner, U.; Lippe, S.; Kahl, T.; Ziemann, J.; Jäkel, F.-W. (2006) A multi-level modeling framework for designing and implementing cross-organizational business processes. Proc. of TCoB Workshop, Cyprus, 2006. [12] http://www.ec-net.de/ECNet/Navigation/Kooperationen/kooperationsschritte,did=101812.html [13] Schallock, B; Bading, N.: Kundenintegrierende Innovation. In: Doleschal, R. et al. (Hrsg.) Innovationen systematisch gestalten. Beiträge zum Innovationskongress 2006, Schriftenreihe des KOM, Fh Lippe und Höxter, Lemgo 2007, S. 145 ff. [14] Alwert, K. Wissensbilanzen für mittelständische Organisationen. Entwicklung und prototypische Anwendung einer geeigneten Implementierungsmethode. Herausgeber: Mertins, K. Erschienen Stuttgart: Fraunhofer IRB Verlag, 2006, X, 181 S. Zugl.: Berlin, TU, Diss., 2005, Berichte aus dem Produktionstechnischen Zentrum Berlin ISBN: 3-8167-7033-9 [15] Mertins, K.; Will, M. Intellectual capital statement: The basis for knowledge management. Quelle Warsaw University of Technology, Faculty of Production Engineering ; International Institution for Production Engineering Research -CIRP-, Paris: APE 2007, International Conference on Advances in Production Engineering : 14 - 16 June 2007 Warsaw, Poland, Warschau, 2007, S.43-51. Konferenz International Conference on Advandes in Producion Engineering (APE) . [16] Knothe, T.; Kahl; T., Schneider, K.; Böll, D.: Framework for Establishing Enterprise Modeling in the Context of Collaborative Enterprises, Proceedings HICCS Hawaii International Conference on System Sciences 2007 [17] Ziemann, J.; Ohren, O.; Jäkel, F.-W.; Kahl, T.; Knothe, T.: Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel. In: Doumeingts, G.; Müller, J.; Morel, G.; Vallespir, B. (Ed.): Enterprise Interoperability - New Challenges and Approaches. Springer-Verlag London Limited 2007. S.199 – 208. [18] Jankovic, M.; Ivecic, N.; Knothe, T.; Mrjanovic, Z.; Snack, P.: "A Case Study in Enterprise Modelling for Interoperable Cross-enterprise Data Exchange" In: Müller, J. P.; Mertins, K.; Zelm, M. Enterprise Interoperability II. New Challenges and Approaches. Springer-Verlag London Limited 2007 S. 541 – 552. [19] Knothe, T.: Synchronization of Service Engineering and Operational Process. In Proceedings of COMA 2004, Stellenbosch. South Africa [20] Mertins, K.; Görmer, M.; Kohl, H. Benchmarking 2005. Best Practices: Lösungen für den Mittelstand, Potenziale und Handlungsfelder von Benchmarking, 17. - 18. November 2005 ,Fraunhofer-Institut für Produktionsanlagen und Konstruktionstechnik -IPK-, Berlin. Stuttgart: Fraunhofer IRB Verlag, 2005, S. 283, ISBN: 3-8167-6941-1. [21] Karlsen, D.: CPPD Methodology Building Collaborative Design Services, http://193.71.42.92/websolution/FileRepository/Attachment_Pub2_DownLoad.asp?Sy stemID=270&ID=2, last visit 01.10.2007.

Engineer to Order Supply Chain Improvement Based on the GRAI Meta-model for Interoperability: An Empirical Study A. Errasti1 and R. Poler2 1

2

Supply Chain Consulting, SCC, Ulma Handling Systems, Spain [email protected] Research Centre on Production Management and Engineering, Polytechnic University of Valencia, Spain [email protected]

Abstract. Companies compete in saturated markets trying to be more productive and more efficient. In this context, to manage the entire supply network to optimize overall performance becomes critical. Enterprise Modelling of Decision Systems is an important instrument to structure this complexity. This paper explores the methodology in which the redesign of internal and external operational integrated processes should be done, applying the GRAI Meta Model and the Design Principles for Interoperability, in order to improve the overall performance of an Engineer to Order Supply Chain. This research has also conducted a case study in the Producer Goods Sector from an Original Equipment Manufacturer (OEM) point of view. The main conclusions related to the aim of the paper are that, the reengineered system integrates the Supply Chain Network more effectively, as well as achieving the customers´ objectives in terms of time and cost. Keywords: Business Process Reengineering in interoperable scenarios, Enterprise modelling for interoperability, Modelling cross-enterprise business processes, Experiments and case studies in interoperability

1 Introduction: Engineer to Order Supply Chains The opening of the boundaries of all the markets has caused the necessity to compete with large multinational organisations in niches where just some traditional SMEs performed some decades ago. In this context, organisations have to survive in saturated markets trying to be more productive, more efficient or more innovative (Lummus et al, 99). Three levels of interaction between enterprises can be defined:

522

A. Errasti and R. Poler

x x x

Communication: exchange of necessary information to work together. Coordination: exchange of information and agreements in decision making processes with specific objectives (individual and common). Cooperation: exchange of information and collaborative decision making with a common goal.

SMEs need, more than ever, cooperate in a supply chain context in order to exploit their complementary core competences to optimize overall performance of the entire network. Cooperation can be achieved through integration of the different way of doing business, but this solution normally clash with the desired individual autonomy. Each company has his own models and applications to manage his business processes, thus the solution is to achieve the necessary degree of interoperability between models and enterprise applications. Different problems have to be faced from the point of view of interoperability depending on the decoupling point. This point shows how deeply the customer order penetrates the supply system. Four commonly used classifications of the decoupling point are: Make to Stock (MTS), Assemble to Order (ATO), Make to Order (MTO) and Engineer to Order (ETO). The Make to Order concept, captures de idea that value-adding activities, manufacturing, assembly even distribution, are triggered by orders, rather than forecasts. By performing value-adding activities to order, a company would avoid incurring the risks of forecasting uncertain events, which may ultimately lead to excess inventory and poor service level (Salvador et al, 2006). Thus, Make to Order requires a supply chain which has product and process flexibility. In this context, flexibility means the ability to identify the need for a change and then adapt to the change in a manner that benefits the manufacturing system performance. Some Make to Order production systems have to customize the product, thus an engineering design stage should be integrated before manufacturing. These production systems, called Engineer to Order, are usually project based production system, where the element of repetition is usually limited, in other words “low volume – high variety” (Slack et al, 2004). Suppliers are usually devoted to manufacture some components or subsystems that should be then supplied and assembled in the manufacturing or assembly sites (Ramsay, 2005). Some subcontractors could have expertise in some components or subsystems. Thus, they are required to supply these components and subsystems or variations of them in more than one project. Designs of details are usually planned overlapping with the manufacturing period. This creates multiple and parallel processes. Parallel operations are at the same time interdependent and can therefore be expected to interrupt and disturb the manufacturing processes. Some authors (Caron et al, 1995) add that the lack of supply chain and logistics related management in a project environment has a significant influence on the manufacturing systems. Thus, the decisional interoperability of the internal functions such as engineering, purchasing, manufacturing, etc. and external suppliers to operate in a whole and coherent way must be taken into account in such a way that the decision

Engineer to Order Supply Chain Improvement Based on the GRAI Meta-model

523

points and the action points interact to ensure the smooth functioning of the manufacturing system.

2 Research Objectives Even if some authors argue that few companies are actually engaged in such extensive supply chain integration (Fawcett et al, 2002), especially when it requires a strategic collaboration (Bittitci et al, 2004), the authors of this paper state that the GRAI Meta-model for Interoperability approach could be useful to accomplish an integration reengineering project in order to improve overall supply chain performance. Some GRAI tools (GRAI Grid and Nets, DGRAI Model) have already been applied succesfully while integrating a Make to Stock production system (Errasti et al, 2006), but there is no evidence of application in Engineer to Order production systems. More over, Engineer to Order production systems are usually “low volume-high variety” (Slack et al, 2004), the need of coordination and synchronization and interoperability has not been studied in depth in case studies of “high volume-high variety” Engineer to Order production systems. Thus, this paper explores the method in which the redesign of internal and external integrated processes should be carried out, facing the interoperability problems and aided by the GRAI Meta-model for Interoperability approach and the GRAI Grid and DGRAI Model, in order to improve the overall performance of the supply chain in a Engineer to Order project based production system. This research has also conducted a case study in the Producer Goods Sector from an Original Equipment Manufacturer point of view answering the difficulties mentioned above.

3 Research Methodology The research methodology behind the work presented in this paper, consists of a theory building phase, a theory testing phase and a synthesis phase: x x

x

Theory building: started with an extensive literature review to identify the issues/factors to be considered in the implementation of the GRAI Metamodel for Interoperability in a supply chain. Theory testing: the theory-testing phase of the research was designed around action research principles. Action Research can be seen as a variation of case research, in which the action researcher is not an independent observer (Coughlan, 2002) (Voss, 2002). Conclusions/Synthesis: in the synthesis phase the conclusions of the case study and the findings are shown, which increase the understanding of the reengineering process and the techniques based on Enterprise Modelling of Decision Systems to integrate the supply chain.

524


3.1 Theory Building: Issues/Factors to be Considered

Given the implications of redesigning the operational processes of a supply chain, the decision to do so and how, should be considered a strategic issue for the firm. Thus, the concepts identified in the literature were set around the steps that are typically needed in a strategy development process. Authors like Acur (2000) state that, for a dynamic strategy development process, four stages (inputs, analysis, strategy formulation, strategy implementation and strategy review) are needed and that management and analytical tools can be used for this purpose.

Fig. 1. Schematic representation of the methodology/guide and factors to be considered

The authors of this paper have accepted this approach; nevertheless this research simplifies this process and adapts it to the business units´ operational strategy (Platts, 1990) considering the following factors (Figure 1): x x

The methodology/guide takes into account the position of the Business unit in the Value Chain (Browne, 1995) and sets the stages which should help value creation (Porter, 1980) ( Martinez et al, 2006). A diagnosis or input stage is used to analyse the factors (Gunn, 1987). In this stage GRAI Meta-model and the Design Principles for Interoperability (Dassisti et al, 2006), GRAI Grid (Doumeingts, 1998) and DGRAI (Poler et al, 2002) analytical tools support the analysis of the AS IS System and the TO BE System.


x

x

525

The diagnosis contributes to choosing the content of the strategy (Gunn, 1987) and defining or formulating the strategy (Platts, 1990). The diagnosis also contributes to monitoring the advantages/disadvantages of the future decision system related to Information technology (hardware and software specifications), manufacturing technology (tools and equipment specifications) and organisation (physical system and management structure). After that, a deployment stage of the formulated strategy is set (Feurer, 1990).The deployment is a project-oriented task (Marucheck et al, 1990), where a process of monitoring and reviewing to facilitate the alignment of the organisation to the strategy is set (Kaplan et al, 2001).

3.2 Theory Testing: Empirical Study

3.2.1 Supply Chain Presentation andMmethodology/Guide Adapted for theCcase Study The OEM which led the supply chain improvement, was a Spanish company devoted to design, manufacturing and assembly of vertical transportation equipments (lifts, escalators,..). In order to ease the comprehension of the case study, the main characteristics of the external supply chain (distributors and suppliers network) and the internal supply chain (materials warehouse and manufacturing plant) are described in this section. Figure 2 shows the different types of nodes of the supply chain taken into account in this study: External distributors´ Supply Chain; Internal Supply Chain and External suppliers´ Supply Chain. External Supply Chain

Manufacturing Suppliers Plant

Warehouse

Internal Supply Chain

External Supply Chain

Original Equipment Manufacturer

Distributors Assemblers

Warehouse

Plant

Construction Site

Engineer to Order Replenishment Planning and Inventory system

Fig. 2. Internal and external supply chain considered in the case study

x x

External distributors´ Supply Chain: the modules and subsystems produced by the O.E.M. are delivered by distributors to the construction site where they are assembled. Internal Supply Chain: The OEM production is planned when the design team has finished the engineering stage of each customized lift or escalator. Thus, the manufacturing plant works as an Engineer to Order system. The

526


x

manufacturing plant process is based on mass customization concepts, which try to exploit the advantages of mass production with the customization of the product. For this purpose the product and the process have high modularity and commonality that allows a high customization, combining different parts or modules in the final part of the process (assembly). External suppliers´ Supply Chain: The OEM has classified the suppliers taking account of logistic volume or weight per supply unit, number of references, supplier distance and value per supply unit, as J.I.T. volume suppliers, J.I.T. module suppliers, traditional Make to Order suppliers and traditional Make to Stock suppliers (Figure 3). SUPPLIER J.I.T. VOLUME CLASIFICATION SUPPLIER FACTORS

J.I.T. MODULE SUPPLIER

TRADITIONAL MAKE TO ORDER SUPPLIER

TRADITIONAL MAKE TO STOCK SUPPLIER

LOGISTIC VOLUME OR WEIGHT PER SUPPLIED UNIT NUMBER OF SUPPLIED REFERENCES DISTANCE TO THE O.E.M. LOCATION

VALUE PER SUPPLIED UNIT

Fig. 3. Suppliers´ classifications taking into account some logistics factors

In construction industry supply chains, based on the client’s brief, design consultants design. Thereafter, the project is passed on to the contractor who takes responsibility for the construction of the facility (Thomas, 2002). The contractor subcontracts to subcontractors. The company works usually as subcontractor. These subcontractors are subject to tremendous pressures in terms of Quality, Service and Cost (Errasti et al, 2005). In this context, the company tried to gain a sustainable competitive advantage. For this purpose, the research group aided them to apply the methodology/guide to the Business Unit (Figure 4).


527

Change Drivers : Service quality and cost competitive factors Scope : Elevation Business Unit from O.E.M . point of view Purpose : Better performance through process reengineering

Dynamicstrategymanagementprocess: Dynamic strategy management process: management process Diagnosis

Operational Strategy : Quality service improvement Total cost reduction

GRAI Method Method

Strategy Deployment

- Future Operational planning System implementation MonitoringReviewing Monitoring Reviewing

- Analysis of Current /Future Operational Planning System and suppliers /customers integration Through GRAI Grid and DGRAI - Interoperability problems avoiding by applying the Design Principles for Interoperability - Future System specifications

-Key performance indicators : Product delivery date Customer Order Fulfilment Stock Turnover Logistic and production total lead time

Fig. 4. Schematic representation of the methodology/guide adapted to the Case Study

In the diagnosis stage the GRAI grid and DGRAI tools to analysis the Current System (AS IS) and design the Future System (TO BE) were used and the Design Principles for Interoperability were applied. The Operational Strategy defined was to improve customer service (reduce delivery date and increase order fulfilment) and reduce the total cost of the chain through a redesign of the production and inventory planning system of the OEM and suppliers´ network. The implementation of the future system was monitored with key performance indicators of Customer Service (Delivery date, Order fulfilment) and Cost (Stock, Manpower Costs). 3.2.2 Supply Chain AS IS Analysis and TO BE Design To analyze the production and inventory/material planning current system of the internal supply chain and the suppliers´ network (AS IS), the decision system was monitored using GRAI Grid based on the Meta-model Basis Unit (MMBU) reference (Dassisti et al., 2006). The GRAI Grid showed the main characteristics (decision levels, decision centres, planning periods, planning frequency, decision alternatives, information). To design the TO BE system the Design Principles for Interoperability were embedded in the implementation. In particular some of them were explicitly applied in this study: x

1st DP: “When designing an organisation, evaluate its domain and boundaries of action inside the networked enterprise chain, identifying the necessary actors and the material and immaterial exchanges to perform” In the analyzed supply chain, the inner and suppliers´ teams to improve the

528


x

x

x

x

x

supply chain the key points of their work, the core competencies to develop, the necessary physical and the informative infrastructures were identified. 2nd DP: “When designing an organisation, consider first of all the global reference pattern of its networked enterprise chain. This pattern should represent a networked enterprise chain as interoperable as possible.” In the analyzed supply chain, the inner and suppliers´ key roles and activities to improve the overall performance and the agents involved and their relationships were defined. 3rd DP: “When designing an organization, apply the Meta-model basic unit (MMBU), built from the interoperable networked enterprise chain pattern”. A simplified version of the MMBU GRAI Grid was used to represent the strategic level related to planning and definition activities (design, inventory, quality policies and business plan, etc.) and the operational level related to the operative aspects (general scheduling, synchronisation of processes, scheduling of deliveries, etc.). 4th DP: “When designing an organization, build its aggregate decision structure model. A useful tool for this goal is the GRAI grid” The GRAI grid was used to map the decision systems of the production and inventory/material planning system.Special attention was payed to the clear definition of the information and decision flows and the verification of the consistency of the model using GRAI rules. 7th DP: “Implement a mechanism to exchange decision frames between deciders” In the analyzed supply chain, the connected nodes exchange decision frames concerning production plans in a collaborative way. If the decision periods are different, a lot of inconsistencies will result. 8th DP: “When designing and re-engineering an organization, pay particular attention to local decision centres linked to local decision centres of the other partners. A good solution could be using for linked decisional centres the same horizon but especially the same period” The production and inventory/material planning system of the suppliers was coordinated to the inventory/material planning system of the O.E.M in order to avoid inconsistencies deriving from updated decisions of the partners.

The production and inventory/material planning is concerned with balancing supply and demand. It tries to keep the material flow and the value added activity in manufacturing going on without interruptions. In this case, the production and material planning system worked as a Make to Order system, once the engineering stage was done. It was a weekly based fix order point system called “S+5:5”, because the manufacturing plant supply to the distributors the orders received in the week “S”, 5 weeks later. Thus, the planning period was one week and the planning horizon was six weeks. When monitoring the GRAI Grid a policy constraint was detected. The whole flow of materials was limited by the master production scheduling (MPS) decision level. In this decision level, the planning period and planning horizon of the master production scheduling had a great


529

impact on the system lead time and consequently on the delivery date and on stocks needed to go on without interruptions. Thus, the analysis and design stage of the future system was set around the alternatives of reducing the planning period and the planning horizon of the MPS. In particular, the “D+18:2” planning system, with a planning period of two days and a planning horizon of twenty days, was analysed. This replenishment system could be expected to perform better, because the period and planning horizon were reduced. In theory, the new system could work with less work in process, because it supposed a quicker response of the manufacturing plant to the finished product warehouse. Nevertheless, in order to analyze the feasibility of the future system, the information technology, manufacturing technology and organisations of the internal and external suppliers/customers´ network critical factors and other efficient supply systems (cross docking, milk run,...) were monitored (Figure 5). S+5:5 vs D+18:2

INTERNAL SUPPLY CHAIN

EXTERNAL SUPPLY CHAIN

INFORMATION TECHNOLOGY

•Production order generation in O.E.M. • Purchasing order generation and submission to suppliers

•Suppliers order reception

MANUFACTURING TECHNOLOGY

•Lot or Batch size in the production system •Bottlenecks efficiency •Work in process

•Lot or Batch size in the suppliers´ production system

ORGANISATION

•Plant Manufacturing Pull System •Parts and Raw materials stored in O.E.M. warehouses •Efficiency of the Planning System. Management time •Efficiency of the Inventory System. Management time

•Parts stored in suppliers´ finished products warehouses •Efficient supply system from suppliers (Milk Run with third party logistics)

Fig. 5. Critical information technology, manufacturing technology and organisation factors taking into account when implementing the Future system

In order to analyze the efficiency to operate with the future planning and inventory/material system (Figure 6), a simulation of the Decision System was done using DGRAI tool. DGRAI allowed monitoring if there were bottlenecks or capacity problems in the production planning and inventory/material management teams and also the total quality of the future system. In order to compare the dynamic behaviour of both systems, a simulation of one year was performed. The conclusions were:

530


x x

x

x

Both planning systems were correct from the point of view of supply coordination. The simulation did not evidence synchronization problems between internal and external supply chain. Regarding the manpower consumption, “D+18:2” planning system used a every two day recalculation of the Master Program (consequently the same period for programming and ordering), versus the “S+5:5” planning system that used a weekly recalculation. The simulation showed that the “D+18:2” uses a 40% more of hours of decision makers than the “S+5:5”. Therefore D+18:2 was more expensive than S+5:5 from the point of view of manpower cost. Concerning the impact of the human resource capacity in the decision system performance, an interesting indicator is the quantity of decisions in the queue of decision makers over the time. Both planning systems had a similar behaviour concerning the maximum number of decisions in queue, but the queue time was higher in “D+18:2”, the average number of decisions in queue was a 50% higher in “D+18:2” than in “S+5:5”. In particular the Planning Chief of the internal supply chain was overloaded all the time in “D+18:2”. With regard to the evolution of the Total Quality of Decision System (TQDS) indicator, “D+18:2” was a 4% better in mean than “S+5:5”. But the most important was that “D+18:2” is a 10% better in minimum than “S+5:5”. TQDS was calculated as the weighted mean of the quality of decisions at a given moment. The quality of a decision depends on the quality of information used and the quality of the decision maker and decreases with time (until its re-generation). ENGINEERING Demand Import

H = 3 months

P = 1 months H = 25 days P = 5 days

Demand Export

PRODUCTION CHAIN U.S.M Plan

Cabins Plan

Doors Plan

Machines Plan

Controls Plan

SUPPLIERS CHAIN Chassis Plan

Internal Resources JIT Vol Informatio Mngmt Suppliers n

Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate d Prod. d Prod. d d Prod. d Prod. d Prod. d Prod. d Prod. Shift Staff Plan Plan Expedition Plan Plan Plan Plan Plan IMP

EXP

Plan

Cabins

Doors

Machines

Controls

Chassis

Plan

Stock Levels

Production

JIS Comp MTO Suppliers Suppliers

Aggregate Aggregate Aggregate Aggregate d Supply d Supply d Supply d Supply Shift Staff Plan Plan Plan Plan JIT Vol Suppliers

JIS Comp MTO Suppliers Suppliers

Lift Project Lift Project IMP

External MTS Resources Informatio Suppliers Mngmt n

MTS Suppliers

Plan

Stock Levels

Production

Orders

EXP Demand Master Master Master Master Master Master Expedition Load/Capa Forecastin Orders Orders Expedition Prod. Plan Prod. Plan Prod. Plan Prod. Plan Prod. Plan Teams city g JIT Vol JIS Comp MTO Plan Cabins Doors Machines Controls Chassis Program Expedition Suppliers Suppliers Suppliers

H = 20 days P = 5 days

Master Load/Capa Production city Plan

Wharehou se

Logistics Load/Capa Production city

H = 15 days P = 2 days H = 5 days

Deadline

Deadline

Expedition

Cabins

Doors

Machines

Controls

Chassis

P = 2 days

Tracking IMP

Tracking EXP

Program

Program

Program

Program

Program

Program

Teams Production Program Expedition Production Teams Reprog.

incidences

H = 4 days P = 1 days H = 2 days

Daily

Cabins

Doors

Machines

Controls

Chassis

P = 1 days

Expedition s

Reprog.

Reprog.

Reprog.

Reprog.

Reprog.

Logistics Production Production Teams Reprog.

Orders

Weekly Deliveries

JIT Vol Suppliers

Program

Weekly

Weekly

Deliveries

Deliveries

Daily

incidences Deliveries

Fig. 6. GRAI Grid

Expedition Weekly Program Expedition Daily Program Program Changes


531

3.2.3 Results in Terms of Effectiveness The business unit managers balanced the advantages/disadvantages shown by the study and decided to implement the new production and inventory/material planning system. The performance of the future production and material/inventory planning system was set in quantitative planning parameters such as days of stock reduction and customer service. Five years after the starting up of the reengineering process, due to the new production and material/inventory planning system the outstanding changes were: x x x x x x x

35% of delivery date reduction 50% increase of order fulfilment 15% of Manpower Consumption when planning Master programs 40% of work in process reduction 60% of stock reduction in J.I.T. module suppliers’ warehouses. 20% of stock increase in MTO suppliers forced to work as MTS suppliers. 30% of stock reduction of Make to Stock suppliers parts in OEM warehouse.

4 Conclusions The redesign of internal and external integrated processes of a OEM of the Producer Goods Sector has been done, applying the GRAI Meta-model, the Design Principles for Interoperability and the DGRAI Model, with the objective of improving the overall performance of the Supply Chain. The main conclusions related to the aim of the paper are that the adoption of methodologies based on GRAI Meta Model and Design Principles for Interoperability could be useful when improving an Engineer to Order Supply Chain Network performance.

References [1]

[2]

[3] [4]

[5]

Acur N, Biticci U, (2000) Active assessment of strategy performance. Proceedings of the IFP WG 5.7, International Conference on Production Management, Tromso, Norway. Bittitci US, Martinez V, Albores P, Parung J, (2004) Creating and managing value in collaborative network. International Journal of Physical Distribution and Logistics Management Vol. 34, No.3/4, pp.251-268. Browne J, Sackett PJ, Wortmann JC, (1995) Future Manufacturing Systems-towards the extended enterprise. Computers in Industry, Vol.25, pp.235-254. Caron F, Fiore A, (1995) Engineer to order companies: how to integrate manufacturing and innovative processes. International Journal of Project Management. Vol. 13, No.5.pp.313-319 Coughlan, P., Coughlan D. (2002)“ Action Research: Action research for operations management”.International Journal of Operations and Production Management Vol 22 No 2 pp. 220-240

532


[6]

Dassisti M, Chen D, Scorziello F, (2006) GRAI and SCOR Meta-model and Design Principles for Interoperability. I-ESA’06 Conference, Bordeaux, France Doumeingts G, Vallespir B, Chen D, (1998) GRAI Grid Decisional Modelling. In Handbook on Architecture of Information Systems, Edited by P. Bernus, K. Mertins, G. Schmith, Springer Verlag, pp. 313-337. Errasti A, Oyarbide A, Santos J, Case Research to gain competitive advantage through construction process reeingineering. Faim2005, 15thInternational Conference on Flexible Automation & Intelligent Manufacturing. Errasti A, Poler R, Oyarbide A, Santos J, (2006) Supply chain improvement based on GRAI Method: an empirical study. Proceedings of 13th Euroma International Conference, Glasgow, Great Britain. Fawcett S, Magnan G, (2002) The rhetoric and reality of supply chain integration. International Journal of Physical Distribution and Logistics Management, Vol.32, No 5, pp.339-361. Feurer R, Chaharbaghi K, Wargin J. (1995) Analysis of strategy formulation and implementation at Hewlet Packard. Management Decision, Vol.33, No.10, pp.4-16. Gunn TG (1987) Manufacturing for Competitive Advantage: Becoming a World Class Manufacturer. Ballinger Publishing Company, Boston M.A. Kaplan RS, Norton DP (2001) The Strategy Focused Organization, Harvard Business School Press, Boston Massachussets. Lummus R, Vovurka R, (1999) Defining supply chain management: a historical perspective and practical guidelines. Industrial Management and Data Systems No.99/1, pp.11-17. Martinez, V. & Bititci, U.(2006) Aligning value propositions in supply chains. International Journal of Value Chain Management, 1, 6-18. Marucheck A, Pannesi R, Anderson C, (1990) An exploratory study of the manufacturing strategy in practice. Journal of Operations Management, Vol.9, No.1, pp.101-23. Platts KW (1990) Manufacturing audit in the process of strategy formulation. PhD dissertation, University of Cambridge, Cambridge. Poler R, Lario FC, Doumeingts G, (2002) Dynamic Model of Decision Systems (DMDS). Computers in Industry, Vol.49, pp.175-193. Porter ME, (1980) Competitive Strategy: techniques for analyzing industries and competitors. The Free Press. Ramsay, J. (2005) The real meaning of value in trading relationships. International Journal of Operations & Production Management, 25, 549 Salvador F, Rungtusanatham M, Forza C, Trentin A, (2005) Understanding synergies and trade-offs between volume flexibility and mix flexibility in Build-to-Order strategies. Proceedings of 12th Euroma International Conference, Budapest, Hungary Slack N, Chambers S, Johnston R, (2004) Operations Management. 4th ed., Pearson, London Thomas S, (2002) Contractors risk in Design, Novate and Construct contracts”. International Journal of Project Management. 20 119-126. Voss, C. Nikos Tsikriktsis and Mark Frohlich. (2002) “ Case Research in operations management”.2002.International Journal of Operations and Production Management Vol 22 No 2 pp.195-219

[7]

[8]

[9]

[10]

[11] [12] [13] [14]

[15] [16]

[17] [18] [19] [20] [21]

[22] [23] [24]

Proposal for an Object Oriented Process Modeling Language Prof. Dr. Reiner Anderl, Dipl.-Ing. Jens Malzacher, Dipl.-Ing. Jochen Raßler Department of Computer Integrated Design (DiK), Technische Universität Darmstadt Petersenstr. 30, 64287 Darmstadt {Anderl, Malzacher, Rassler} @dik.tu-darmstadt.de

Abstract. Processes are very important for the success within many business fields. They define the proper application of methods, technologies and company structures in order to reach business goals. Not only manufacturing processes have to be defined from the start point to their end, also other processes like product development processes need a proper description to gain success. For example in automotive industries complex product development processes are necessary and defined prior to product development. Over the last decades several product modeling languages have been developed moving to object oriented modeling languages, such as UML, but the used process modeling languages are still procedural. The paradigm shift caused by object oriented description within product modeling languages has to be transferred to process modeling languages. This paper introduces an object oriented approach for process modeling. Using UML as a starting point an object oriented process modeling method is differentiated. The basic concepts which are needed for process modeling are put into an object oriented context and are explained. The paper also deals with the most important methods behind object oriented process modeling and gives an outlook, what can be achieved by this approach. Keywords: process modeling, object orientation, UML, modeling language

1 Introduction All over industrial appliance the necessity of well-defined and powerful processes are known. These processes range from manufacturing processes over business processes even to product development processes. During the last decades they have been analyzed and defined in the according companies. But within most areas the well-known and defined processes are represented with old methodologies. Discipline-specific methods have been developed to a new level. Applications for that are cross-enterprise collaboration, e.g. in manufacturing

534

Reiner Anderl, Jens Malzacher, Jochen Raßler

or product development networks, and cross-discipline collaboration like mechatronical product development. Within cross-enterprise collaboration the involved companies are not integrated by the means of deliverables anymore, but are integrated in the complete processes now. The cross-discipline collaboration is similar. It has used to be integration by the means of interfaces and key objectives, but now it is integrated at any time of the process. Both examples lead to two major problems. First of all cross integration is new every time a new collaboration starts. Typically a company is involved in several different collaboration networks at a time. They are all different but principally support the same process. Second problem is that most existing process descriptions are based on procedural process description. These are not powerful enough to meet requirements of describing cross collaboration. A short example is given to illustrate the problem. Within product development the VDI2221 describes the sequential process of product development that allows some iteration. The ideas behind that process are roughly 50 years old now. Products and with that product development has changed dramatically. Mechatronical product development requires a coordinated development process of several disciplines like mechanics, electrical and electronical devices or software development. Especially software development does not fit properly into the VDI2221 process. With the “Münchner Vorgehensmodell” (MVM) a new approach on a process model for product development was defined using important stages. Depending on the problem every lived process according to the MVM may take its own way between these stages. Still there is no proper description for flexible processes, but processes like MVM or cross collaborations are required. So a new process modeling language shall meet the following requirements: 1. 2.

Support of hierarchical structures Support of flexible interpretation of a defined process without getting incompatible – support of generalization and specification 3. Robust process definition for flexible proceeding sequences of activities without losing process comparability – support of interchangeability of processes 4. Support of different integration scenarios and levels without changing process description at any time.—support of flexibility of processes 5. Easy to learn and read – audience of those process definitions are very broad Comparing the requirements to the paradigm change in information modeling, which is caused by the introduction of object orientation, a similar approach seems straightforward for the progress of powerful process description. In this paper some existing procedural oriented process modeling languages and those who call themselves object oriented will be mentioned and a new object oriented process modeling language will be introduced. A conclusion closes this paper.

Proposal for an Object Oriented Process Modeling Language

535

2 Existing Process Modeling Languages In this chapter some existing process modeling languages are mentioned. These are IDEF0/SADT, Event-driven Process Chain (EPC), process modeling with UML, Business Process Modeling Notation (BPMN), Integrated Enterprise Modeling, Process Specification Language (PSL) and processes with the Semantic Object Model. These are not all process modeling languages but seem to be the most important. A short statement why these languages do not meet the requirements of modern process definition is included. 2.1 IDEF0 / SADT

IDEF0 is a procedural process modeling language. It explicitly supports hierarchic definition of processes. Complex processes can be defined in different level of details. Each activity can be detailed as own sub process. [1], [2] As it is a procedural language its descriptions are not very flexible regarding changes in the proceeding sequence of activities. IDEF0 remains on unchangeable sequences. It is easy to read but it tends to get very complicated on complex processes. Except the support of the hierarchy IDEF0 meets no mentioned requirements. 2.2 Event-Driven Process Chain (EPC)

Event-driven Process Chain is a procedural process modeling language. Compared with IDEF0 it has more objects in the language. EPC supports events and activities between events. For the process flow EPC allows explicit branching and aggregation of processes. Furthermore there are additional objects, which support the process. These are information and/or resource objects, persons and/or organizations. [3], [4] EPC is a procedural language supporting different level of details. Compared with IDEF0 it is more powerful to support different integration scenarios and levels. EPC is not very flexible regarding to changes in the proceeding sequence of activities. It is easy to read but it tends to get complicated on complex processes. Therefore EPC meets only two of the mentioned requirements. 2.3 Process Modeling with UML

The Unified Modeling Language (UML) offers an all spanning modeling language. Regarding data and information model the language is object oriented. Looking at the process modeling capabilities of UML the processes are still described in a procedural way. Most important process diagrams within UML are the activity, state chart and the sequence diagram. Each of the process diagrams shows the process in exactly one instance. For each instantiation the object oriented nature of the data model allows different processes. But the processes can not be described in a generic way within these diagrams. Solely the use case diagram seems not to fit into that. There some kind of process understanding is modeled in an abstract way. [5], [6], [7]

536


UML is not an object oriented language for process modeling. Each activity is seen as an object. Relations between activities still base on logical states. Processes defined with UML are not very flexible regarding changes in the proceeding sequence of activities. Like EPC process modeling with UML supports different level of details and different integration scenarios and levels. It is quiet easy to read and to handle. Therefore process modeling with UML meets three of the mentioned requirements. 2.4 Business Process Modeling Notation (BPMN)

The Business Process Modeling Notation (BPMN) was developed to provide a notation for process descriptions. The specification includes the visual appearance of the elements and the semantics of the elements. Furthermore it deals with the exchange of process definition either between tools or as scripts (e. g. mapped on the Business Process Execution Language). [8], [2] BPMN representation of processes is quite similar to the UML activity diagram. Processes are defined as a sequence of activities in swim lanes. Again it is a state based connection between object oriented activities. Therefore the verdict upon BPMN is in this case similar to the UML verdict. BPMN meets three of five mentioned requirements. 2.5 Integrated Enterprise Modeling

The Integrated Enterprise Modeling was developed out of SADT. It capsules activities as objects and adds static information as job, product or resources. Due to this further information it is possible to generate views on the complete enterprise, not only on its processes. [9], [2] Integrated Enterprise Modeling represents processes in a SADT kind of style. Due to its retaining on logical sequence of activities it has no real advantage in modeling flexible processes. It still lacks a powerful support of process flexibility. 2.6 Process Specification Language (PSL)

The Process Specification Language (PSL) is a neutral language for process specification to serve as an interchange language to integrate multiple processrelated applications throughout the manufacturing process life cycle. As it only defines itself in informal manner it has no formal and graphical constructs. Therefore it is not capable for process modeling and a big audience. [10] 2.7 Semantic Object Model

The Semantic Object Model methodology is an enterprise architecture, which allows to divide an enterprise model into the model layers enterprise plan, business process model, and resources, each of them describing a business system completely and from a specific point of view. Within the process model the activity objects are connected with events. This concept allows flexible and robust process modeling. Out of this diagram the interaction scheme and the task-event scheme


537

are developed. [2] Within interaction scheme relations also seem to be object oriented, but not within task-event scheme. So both worlds seem to be mixed up. Due to the integrated approach of enterprise plan, process and resources constructs are difficult to understand. 2.8 Short Statement on the Languages

Looking on the process modeling languages above we see that most of them already think in object oriented activities. Here paradigm changes already carried out. The definition of relations mostly remain on state based, proceeding sequences of activities. Only SOM seems to be beyond that, but is not clarified well. To meet all requirements a new approach shall be started.

3 Proposal on an Object Oriented Process Modeling Language The previous chapter has summarized the known and used process modeling languages and their limitations regarding the requirements introduced in chapter 1. Therefore a new approach for a process modeling language will be introduced in this chapter, which uses object oriented techniques and hence meets all requirements. 3.1 Towards an Object Oriented Process Modeling Language

UML is a well known and widely used modeling language for large software systems that uses object oriented techniques to obtain modularization, software reuse, flexibility and easy maintaining, among others. Expansions, such as SysML, introduce additional methods to use UML in other contexts than software engineering. Also the development of BPMN shows that UML is a technology that has a wide acceptance by users, developers and managers. Thus UML is a good starting point for the development of an object oriented process modeling language. Fig. shows the definition of a UML class diagram. The first field shows the class name, the second field lists the attributes, and the third field lists the methods, which can be used within the context of the class. The class itself is time invariant as it is a generic description of the content of the context. But the instance of a class, an object, is time variant, because it holds characteristic values that can be checked to given times and can change over time. This means, the values can change, but the general structure of an object (number and kind of attributes) can not change. class attributes methods

Fig. 1. UML class diagram

538


Having a time variant object it can be derived by time regarding to [11] lim

T oT0

Object (T ) Object (T0 ) T T0

dObject dT

O bject.

(1)

Equation (1) shows that the content of an object, which means the attributes of an instance of a class, may change over time. Given a rule to change the attributes of an object one can express the change of the object’s content as a process instance, which is shown in (2). It is necessary to mention that we use a discrete time T instead of continuous time t to implement “time steps”. This is due to the result of the derivation as different process instances may need different time intervals to execute. O bject

(2)

Process instance

As we have derived the object we now have to derive the object’s content. Fig. 1 uses the word attributes as defined in UML, in equation (3) we will derive the attributes, but using the word information to make the meaning clearer and more generic. lim

T oT0

Information(T ) Information(T0 ) T T0

dInformation dT

Information

(3)

The derivation of information shows that the information may change over time. So the change of information, the change of attributes or data can be expressed as a method, which is shown in (4). Information

(4)

Method

The last field of a UML class diagram and thus in the object holds the methods, which act on the attributes. In the following we use the term operation for UML methods to differentiate between UML and our introduction. Operation and the just derived method are quite similar and are the same in several cases. In the following we derive the operation, which is shown in equation (5). lim

T oT0

OperationT OperationT0 T T0

dOperation dT

O peration

(5)

The meaning of the derivation of an operation is quite complex. To express this mathematically we can use equations (3) to (5), which show, that dOperation / dT is the first derivation of an operation or the second derivation of information. This means dOperation / dT is the gradient of an operation or the curvature of information. The expression gradient of an operation seems quite handsome and opens the question: what does result in the change of an operation? Or, more exact, what does result in a change of the quality of the execution of a method? Think also of the similarity of operation and method. This question directly leads to the answer to the problem, which is


O peration

Resource.

539

(6)

Resources influence the execution of an operation. The use of more or less resources leads to faster or slower execution, influences the quality of the output, may lead to more innovation and so on. Equations (1) through (6) have shown the derivation from a time variant object to a time variant process instance. Generalizing the process instance we get a process class, which again is time invariant. The diagram of a process is shown in Fig. 2 process methods resources

Fig. 2. PML Process class diagram

Further we introduce the term PML, which stands for Process Modeling Language and can be seen as an extension to UML, as SysML is. Thus the known techniques of inheritance, association, and cardinalities can be used. Implementing those techniques processes can be modeled hierarchically with modularization, structure, exchangeability, and reusability. Hence all the requirements described in chapter one are fulfilled. A last topic of the class diagrams that have to be covered are assurances, which is done in the following in a qualitative way. In UML assurances can be defined to guarantee the co-domain of attributes. The assurances are conditions or constraints that have to be met by methods changing those attributes. In PML those assurances are important too, but apply to methods. This is obvious in the derivation’s context. Further, a condition can be seen as a constant signal. With the beginning of the life time of an attribute, which is the same as the life time of an object, the condition starts and remains constant over time. That is, the condition must hold for the life time of the attribute. Deriving the constant signal is straightforward using a Fourier transformation. The transformation results in the delta function; its derivation is a constant frequency signal. Back transformed to the time domain the result is a Dirac impulse [12], which can be interpreted as an event. The event actually can be a condition becoming true, the trigger from a finished method, or information becoming available. Thus the assurances are derived too and can be used for process modeling, which is shown in Fig. 3. process methods {event} resources

Fig. 3. PML class diagram with assurances

540


3.2 Meaning of PML

Above we have shown mathematically the derivation of PML. We have introduced the terms of process instance, which can also be called project, and the process as a generic class description. We now want to clarify those terms and their meaning. Fig. 4 shows the used way to derive PML. Starting from the time invariant UML class we have instantiated a time variant object. This is derived by time and leads to a process instance, or project, which is time variant, and finally generalized to a time invariant process. time invariant

time variant

class

object

process

process instance / project

Fig. 4. Derivation loop of PML

Looking to application level the meaning of all four constructs will be clearer. The generic class model is used to represent the data model in a PDM system, e.g. as STEP AP214. Within one project the class is instantiated and the object holds the actual data of the designed model. The class therefore describes the product in a generic way, while the real contents are stored in its instantiation. The same is true on process level. The PML process class describes the process in a generic way. It allows one to define all methods with assurances and resources needed for the process. The instantiation of a process is a project. This means, the instance of a process defines the current occurrence of resources, used data models etc. This not only leads to a paradigm change in process modeling, but also in the view to processes and projects. 3.3 Using UML Constructs in PML

In this chapter we will give a short overview of using UML constructs within PML to gain the capability of hierarchical and modular modeling. Inheritance. The concepts for inheritance of process classes follow the notation of standard UML classes. Fig. 5 shows the inheritance of process classes. Starting with a generic Creativity Process that has a Creativity Method and requires a problem becoming available as event, but no Resource, two subclasses are inherited. The Intuitive Process, which adds two Resources and the TRIZ Process, which adds one Resource. Both subclasses inherit the Creativity Method from their superclass Creativity Process, TRIZ Process overwrites the Creativity Method with its own technique of creativity. Brainstorming and Brainwriting are subclasses from Intuitive Process, inheriting the Resources and the Creativity Method, which they overwrite. Both of the subclasses define their own additional Resource.


541

Creativity Method takes an argument, problem, which can have assurances, which means starting and ending conditions can be defined. Creativity process creativity method {problem avail.}

Intuitive process

Creativity process creativity method {problem avail.}

Persons Pens

TRIZ solver

Brainstorming

Brainwriting

creativity method {problem avail.}

creativity method {problem avail.}

Whiteboard

Paper

Fig. 5. PML inheritance diagram

The process class also supports abstract methods, as well as public and private methods. Associations. The known concepts of associations from UML classes can be used for process classes. Fig. 6 through Fig. 8 show the concepts of associations, aggregations, and compositions. All associations can use cardinalities to implement the number of relations they use. The techniques introduced above enable generic process modeling that supports structural and hierarchical modeling, including modularization and flexible design. As classes are time invariant no statement about the “running time” is made, e.g. about sequential or parallel process execution. The actual execution is determined instantiating the process classes and can be further described within the project with activity diagrams (logical description) or sequence diagrams (timely description). State diagrams can be used to describe the project states at given times. These instantiation diagrams are quite similar to the state-of-the-art object oriented process modeling languages. process class 1

association name

process class 2

Fig. 6. Association

process class 1

process class 2

Fig. 7. Aggregation

process class 1

process class 2

Fig. 8. Composition

542


3.4 An Example

To illustrate our way for process modeling we prepared a short example coming from manufacturing. We have a small enterprise which is focused on shape cutting manufacturing. Its production process description is shown in Fig. 9. Note that the process looks very similar to an UML class diagram. (Preliminary) work piece

0…1 Work part handling Handling {work part avail.}

Shape cutting Handled work part 0…2

1…2

manual work part handling

automated work part handling

Handling {work part avail.}


Manpower capacity

Machine capacity NC Code

Shape cutting {work part avail.}

0…1

Lathing

Milling

Drilling




Lathe machine capacity NC Code

Milling machine capacity NC Code

Drilling machine capacity NC Code

Screw thread cutting Shape cutting {work part avail.} Screw thread cutting capacity

Fig. 9. Example process diagram for a small enterprise specialized on shape cutting

There are two main processes which are connected. The within the enterprise adopted technologies inherit their attributes from them. Let us assume the enterprise wants to manufacture the product shown in Fig. 10.

Fig. 10. First example product

Handling {work part avail.} Machine 1 NC Code 11

Machine 2 NC Code 12


Milling Shape cutting {work part avail.} Machine 3 NC Code 14


Handled work part


Handled work part


Handled work part

Lathing

Handled work part


Handled work part

In the first manufacturing lot 30 pieces of that product are produced. Due to some reasons of machine and technician availability and lot size the project is instantiated as shown in Fig. 11.

Screw thread cutting




Technician



543



Drilling Shape cutting {work part avail.} Machine 6 NC Code 33


Handled work part


Handled work part

Milling

(Preliminary) work piece


Handled work part

After the first lot the enterprise wants to produce a second lot of five more pieces. Therefore they changed the used machine (see Fig. 12). Please note it is still the same product and the same process. The instantiation only has changed. It is a new project.

Screw thread cutting




Technician


The enterprise produces also another product as shown in Fig. 13.



Shape cutting {work part avail.} Machine 6 NC Code 22

Screw thread cutting Shape cutting {work part avail.} Machine 6

Handled work part

Milling

(Preliminary) work piece


Handled work part

For production of a certain lot the project shown in Fig. 14 is used. Now we have a different product from a different instantiation based on the same process description.

automated work part handling Handling {work part avail.} Machine 5 NC Code 23


In this example it became obvious how powerful process modeling and description with PML is. Once defined we can instantiate different processes leading to same or different results. 3.5 Further Topics to be Mentioned

In the available paper we only have used class diagrams and instances to show our concept. The other UML diagrams seem to fit for PML. The derivation and usage of those diagrams will be covered in future works. The most important diagrams, and those which are in widest use in UML, are sequence, activity and state diagrams. State diagrams can be directly used to show

544


the state of a process instance. Sequence diagrams are more complex and show the running time of a process instance in a given occurrence. That means, it shows which sub processes run parallel or sequential, the instance’ life time, etc. We have started working on this topic and it seems obvious using discrete Fourier transformations or z-transformations to derive sequence diagrams from instance diagrams using time based states of the project. Activity diagrams follow a similar derivation, but the goal is to get a logical description instead of a time-dependent one of the project running time. PML and UML can be linked together using two techniques. The data classes – data which is generated along the value creation chain – can be used as input for methods or be written to the edges of associations. If company structures, resources, and similar information are modeled, this may best fit as associations for the resources. Further, there exists the attributed association, which can be used for explicit cross modeling between PML and UML. Process management will underlay an enormous change, since process management mainly reduces to process modeling. For existing processes this means that changes in the generic process description leads to extensions of the process description using e.g. inheritance to specialize or modify given processes. Another important topic is project management. It is obvious that project management directly influences the process instances. This implies the timely activities and the allocation of resources.

4 Conclusion The strength of the shown approach for process modeling is the complete object oriented view to processes and the differentiation and linkage of and between processes and projects. As in data modeling process modeling can now be done in a generic way. The introduced process description perfectly fits into PDM systems with the process class descriptions. Hence process management is now process modeling at running time. A process in a PDM system can be extended by more classes, that extent existing classes, or specialize them. The instances of those processes are used in projects, which define the parameters of the instances. The implemented technique of processes and projects within PDM systems is then similar to data models, where object orientation has been a standard since years. Further works will focus on the topics of process and project management and will introduce examples of how to use the object oriented process modeling approach to implement real world projects. The object oriented approach of process modeling introduces a paradigm change not only to the view of process and project management, but also enables new possibilities for interoperability. Heavy use of modularization enables exchangeability and process reusability and hence strengthens the integration of third-party processes. This leads to more powerful cross-enterprise collaboration. Another important point is the certification of processes. Depending on products or customers it is necessary to have certified processes. Think of ISO 9000 or certification for medical issues. With PML the process is only certified


545

once but can lead to different instantiations – regardless to the project (in terms of same or different product). Summarizing the development of PML we have explained existing process modeling languages, which call themselves object oriented, but this is only true for the modeled activities. Therefore the modeled processes still look like sequences of activities. In this paper we have developed a new approach. By deriving timedependent objects we got process instances. Taking them alone we do not use the complete power of object oriented modeling. The step from process instances to process classes helped us to define a new object oriented process modeling language. As processes are not modeled on instances anymore, but as abstract classes, we have a completely new representation of processes. Running processes then are projects. With this definition we need a new comprehension on process and project management.

References [1]

IEEE Std 1320.1-1998. IEEE Standard for Functional Modeling Language—Syntax and Semantics for IDEF0. New York: IEEE, 1998. [2] Bernius, P.; Mertins, K.; Schmidt, G. (Eds): Handbook on Architectures of Information Systems, 2nd Edition. Springer Verlag Berlin, Heidelberg (2006) [3] Scheer, A.-W.: ARIS – Business Process Frameworks, 2nd Edition, Berlin, 1998 [4] Scheer, A.-W.: ARIS – Business Process Modeling, 2nd Edition, Berlin, 1999 [5] OMG: Unified Modeling Language: Superstructure v2.1.1, of Feb 2007, www.omg.org, 2007 [6] Eriksson, H.-E.; Penker, M.: Business modeling with UML: business patterns at work. John Wiley & Sons, Inc, New York (2000) [7] Burkhardt, R.: UML – Unified Modeling Language: Objektorientierte Modellierung für die Praxis. Addison-Wesley-Longman, Bonn (1997) [8] OMG: Business Process Modeling Notation Specification, of Feb 2006, www.omg.org, 2006 [9] Spur, G.; Mertins, K.; Jochem, R.; Warnecke, H.J.: Integrierte Unternehmensmodellierung Beuth Verlag GmbH (1993) [10] International Standards Organization (ISO): ISO 18629 Series: Process Specification Language of 2004, www.iso.org, 2004 [11] Luh, W.: Mathematik für Naturwissenschaftler, Bd.1, Differentialrechnung und Integralrechnung, Folgen und Reihen, Aula, Wiesbaden (1987) [12] Clausert, H., Wiesemann, G.: Grundgebiete der Elektrotechnik 2. Wechselströme, Leitungen, Anwendungen der Laplace- und Z-Transformation, Oldenbourg, München (2000)

Enterprise Modeling Based Application Development for Interoperability Problem Solving Marija Jankovic1, Zoran Kokovic1, Vuk Ljubicic1, Zoran Marjanovic1, and Thomas Knothe2 1

2

Faculty of Organizational Sciences, Jove Ilica 154, Belgrade, Serbia {jankovicm, kokovicz, ljubicicv, marjanovic.zoran} @fon.bg.ac.yu Fraunhofer IPK, Berlin, Pascalstrasse 8-9,D-10587, Berlin, Germany [email protected]

Abstract. This paper presents an approach in IV&I (Inventory Visibility and Interoperability) business application development which is based on business processes and user requirements represented in a form of enterprise model. This approach is beneficial in supporting cross-enterprise business application integration when used in conjunction with semantic mediation tools. Finally, an account of the lessons learned and plans for the future is provided. Keywords: enterprise modeling, business process, interoperability, application development

1 Introduction In recent years, technology support needs have become more pronounced due to enterprise infrastructure complexity caused by global expansion. As advanced technologies continue to be developed, additional tools need to be implemented in order to support interoperable integration. It is important to show how industry could lower cost, improve speed-to-market and reuse IT (Information Technologies) investments by developing more capable data management approach based on new technologies [8]. A global automotive, chemical, electronics, or another industry group (that comprise users, application vendors, and other stakeholders) engages its stakeholders to jointly develop and adopt interoperability artefacts that are implemented by the application vendors and, ultimately, tested for conformance and later deployment in the users’ environments.

548

M. Jankovic, Z. Kokovic, V. Ljubicic, Z. Marjanovic, N. Ivezic, Th Knothe

This paper presents the application of the AIF (Athena Interoperability Framework) [1] to bridge the gap between the business and IT domains. The AIF initiative is promoting the usage of enterprise models to describe business processes and user requirements. Applying a MDD (Model Driven Development) vision to software development is important in order to build model based systems and to avoid or reduce the lost of information, as well as to increase the separation of concerns, flexibility and traceability. The paper is based on the validation results of the ATHENA Sub-Project B5.10: Piloting Including Technology Testing Coordination – IV&I (Inventory Visibility and Interoperability) that we participated in. The original IV&I concept was specified by the Automotive Industrial Action Group (AIAG). The primary purpose of the sub-project was to perform validation of the ATHENA results (i.e., advanced tools and methodologies) on an industrial inventory visibility scenario. Within the validation pilot, a collection of ATHENA tools was chosen to enhance the traditional standards-based development method within a number of specific phases of that development approach. To enable the integration and use of the ATHENA tools for the validation pilot, we developed an additional tool: the APOLLO (FOS) inventory visibility application which supported the visibility business process relaying on RDFS (Resource Definition Framework Schema)-based data exchange interface. Our specific goal was to propose the efficient development process for new generation of IV&I tool that achieves interoperable communication with other ASF (Athena Semantic Framework) tools.

2 Problem Statement The motivation to explore new development approaches in cross-enterprise business application integration follows from the need to address high costs efforts, particularly in complex industrial supply chains [2]. In particular, the current generation of IV&I applications lacks the capability to exchange information about the inventory replenishment events in an interoperable manner. An interoperable exchange of the replenishment information among IV&I applications is critical for efficient supply chain management. Given that IV&I tools are not interoperable, the goal is to arrive at a set of standard electronic messages that may be exchanged in an agreed-upon protocol among IV&I–enabled tools. Once a standard message set is implemented by the IV&I tools, the supplier will select only one of the IV&I tools to communicate to all of its customers.

3 Business Case Description The business process is eKanban, in which both suppliers and customers have a web view of Kanban signals and suppliers are required to cover customer materials requirements based on contractual business rules. The guideline that documents

Enterprise Modeling Based Application Development

549

the business process for eKanban is developed by the IVBP (Inventory Visibility & Interoperability Business Process Workgroup). It includes detailed specifications for implementing and applying the eKanban concept across enterprises (the target interoperable eKanban material replenishment and data exchange protocols). This concept is relevant for supplier parks around a large OEM (Original equipment manufacturer) manufacturing location. Suppliers in the automotive industry are very large and have selected their IV&I tool already. For collaborative eKanban implementation an interoperable data exchange between partners is required. The eKanban Use Case Diagram is illustrated in the Figure 1.

Fig. 1. Ekanban Use Case Diagram

The eKanban electronic collaboration process is based on the ‘Customer Managed Kanban’ version of the eKanban process and supports two roles – Customer and Supplier – and four messages – SyncKanbanConsumption, SyncShipmentSchedule, SyncShipment and SyncDeliveryReceipt. The actors interact via the IV&I tool(s) by sending appropriate signals in a following scenario: Customer consumes a Kanban container; when he decides to authorize the replenishment of Kanban container he sends authorization signal; Supplier ships the Kanban container and when the Customer receives the Kanban container he sends receive signal to Supplier.

4 Development Process Proposed development approach may be seen as containing two phases: x x

EKanban business process model and data exchange specification and IV&I tool implementation.

550


Since the AIAG IV&I specification is a set of fragmented documents a holistic model was created by using the MO²GO tool and it’s supporting IEM (Integrated Enterprise Methodology) methodology. The initial goal was to create a computational system model for performing requirements identification, gathering and analysis. With a computational representation, a much more precise description of roles (e.g. Carrier, Supplier), business control concepts (signals, messages) and business objects as well as its reflecting views was possible. The model developed on the basis of the IV&I specification document doesn’t have only a specification character; it plays more of a guide role for an interoperability project that applies lean supply chain management principles such as Kanban. At the process modelling time, we were concerned with the different functions and their logical processes, the actors involved in the function execution, the data documents, the information systems, and the existing data flows that are regarded as necessary. With the MO²GO tool it was possible to integrate all those data into one consistent model. The key benefit that IV&I Reference model brings to the eKanban engineering is that it enables a focus on a standard way of requirements representation [10]. Its purpose is to provide a foundation for systematic development of the AIAG eKanban [7] business process by providing a common frame of reference for different modeling entities at the same abstraction level. The IV&I Reference Model facilitates standard description of business environment (e.g. roles, business objects), processes, services and data exchange requirements. Our approach to integrate PSM (Platform Specific Model) and PIM (Platform Independent Model) into CIM (Computational Independent Model) is shown in the figure 2.

Fig. 2. Enterprise Model Interoperability System specification


551

All relevant concepts and business objects are represented in the eKanban model as instances of the reference class structures. The main focus of the IV&I eKanban project is communication between Customer and Supplier that is supported by IT systems with visualization capability for the purpose of transmitting order requirements and fulfillment response by the Supplier. The information flow is based on the order elements. Therefore, the orders are modelled in more detail than product elements. Important benefit of eKanban Reference model was standardization of information for planning and control. As basic structures of the model high-level class structures for orders were introduced to express four eKanban messages as subclasses from the Massage class. The instances are linked to the appropriate business processes in the model. Implementation relevant specifications are related to them. For example, on the figure 3 is shown that OAIG BOD message definition is linked to SyncKanbanConsumption message, which is represented as instance of Message subclass of Order class. According to the AIAG eKanban use case definition and IEM principle of hierarchical decomposition, the total business process is captured at the highest level of the model, and contains two activities (1) Run eKanban and (2) Establish cooperation by setting up documents. The Run eKanban activity is an abstraction of the eKanban execution. At the top model level, all operational processes are present together in the form of Run eKanban activity. Establish cooperation by setting up documents presents an integration of planning and establishing processes that provide needed resources for executing Run eKanban activity and related operational processes. Next, an additional modeling activity refines the eKanban business process model and data exchange requirements to the atomic concepts and relationships that define the intended data exchange (In the future, the IV&I enterprise model should be a basis for development of IV&I reference ontology in support of the eKanban data exchange). A desired outcome at this stage is to capture the data exchange requirements between supplier and customer in a computable form. Data exchange requirements are represented in the form of table and linked to the relevant elements in the model (see Figure 2).

Fig. 3. Implementation relevant specifications related to the Enterprise Modeling Objects

552


The ability to work directly from a computational model of the business process reduced time to understand related artefact and have good basis for the IV&I tool implementation. The primary direction of exploration in developing the IV&I application was to apply the MO²GO model and to assess the new Semantic Web-based technology for interoperable data messaging exchange interface in the context of the newly proposed semantic mediation architecture within the ATHENA project [5]. The following five major steps were applied for developing the Apollo application: x

x

x

x

x

Identify the IV Functionality. The IEM methodology supported by MO²GO tool has proven to be a very good basis for IV&I tool development. Using MO²GO model we have considerably reduced time necessary for understanding the business processes and requirements to be met by IV&I application. Out of many processes described in the model, we have choosen the ones which were important for fulfillment or our goals. In the model they are represented as subprocesses of Run eKanban process. The following four processes were identified for IV&I tool development (1) Communicate consumed kanban; (2) Authorize kanban; (3) Initiate ship kanban container; (4) Receive kanban container. Define IV&I eKanban Protocol to Process Messages. The similarity of all four processes resides in a fact that all of them have a resource identified as message which is sent form customer’s to consumer’s IV tool or vice versa. As a necessary step to assure data exchange in the IV&I eKanban conformant manner, the IV&I eKanban messages need to be generated and consumed according to the specified protocol. As an output from this phase, detailed mechanism were defined to follow logic of the prescribed protocol. Define IV&I eKanban BOD Processing Functionality. As another necessary step to assure IV&I eKanban conformant data exchange, all the eKanban BOD elements’ semantics were defined. As an output from this phase, detailed description of all the fields’ semantics within the system and with reference to corresponding BOD elements. For the basis for defining the semantisc of fields and making the data model we used XML messages attached to processes in MO²GO tool as Message states as well as from the data type requirements expressed as properties inside the Eventstates (see Figure 3). Determine Message Exchange Framework. Within the ATHENA provided Web Services (WS) execution support, a Web Service communication capability needed to be specified for Apollo to effectively use the ATHENA WS support [6]. Perform Semantic Reconciliation of Messages. To utilize the ATHENA provided Semantic Mediation support, semantic reconciliation of the local interface elements (i.e., message schema) needed to be performed with respect to the IV&I eKanban Reference Ontology


553

5 IV&I Tool Implementation The following are the main components of the developed IV&I tool: x

x

x

x

IVI Web Client. This component has the responsibility to accept and transfer data entered by the user to the Business Component for required processing. It is realized as a Web application that can be accessed using a standard Web browser. Suns’ implementation of Java Server Faces (JSF) 1.2 was the choice for client component [12]. Business Component. This component encapsulates the whole business logic of the IV tool. It has a responsibility of taking input data from both the client interface and XML/RDF Adapter to process it. This point represents one of the benefits of the applied architecture which is that specific business logic is implemented only once for all input data no matter how they got to the system. For implementation of this component, Glassfish implementation of EJB 3.0 (Enterprise Java Beans) were used, both Session Beans for bussines logic and Entity Beans for OR (ObjectRelational) mapping. In order to achieve great perfomance when needed, direct JDBC queries were used [15]. Web Service Interface. This Web service interface is designed to support interoperable communication between tools. This interoperability is gained through set of open standards such as WSDL, SOAP , UDDI etc [13]. When the system is reached through a web service interface instead of client user interface, IV&I tool has to do one more thing before processing it. Message is passed over to XML/RDF adapter that will interpret message content and make message understandable by IV&I business component. Soap with Attachments API for Java (SAAJ Standard Implementation) was used for Web Service interface development. XML/RDF Adapter. This component is responsible for transformation of domain entity model into common message exchange schema. This means that a BOD document is received in RDF or XML format, and needs to be recognized, validated, processed and stored in database. Recognition and validation is done by XML/RDF adapter while processing and updating database is done by previously described IV&I Business Component. For developing XML/RDF adapter we used Sesame, Elmo and related OS (Open-Source) technologies [17].

6 RDF Based Data Exchange Interface The ATHENA semantic mediation capability uses an ontology-based integration approach to address the issues of semantic interoperability. In our case, the IV&I eKanban Reference Ontology (RO) is one such ontology that provides a meta-data model to define possible IV application interface data models in terms of the application domain concepts, their properties, and the relationships among them. Using the ATHENA approach, the reconciliation rules between each application

554


data exchange interface schema and the RO may be defined to map the logic of that IV application data interface using the RO elements. Once these reconciliation rules are available, IV&I eKanban messages may be transformed from one form to another and interoperable data exchange may be achieved using a semantic mediator to run the reconciliation rules. We defined data exchange interface using Resource Description Framework Schema (RDFS) [14]. Developing the RDF interface consisted of the following activities: x

x

x

Defining the eKanban model for understanding received messages. In order for the application to process the messages as intended, the application has to access definition of the language used to implement the messages. The easiest approach was to define message patterns (to include class and property definitions) that the application can rely on when processing the message content. Testing the information contained in the message payload. Even when a mapping of a message content onto a message pattern is succesfully completed, correct processing of the message is not guaranteed. Our approach was to perform certain tests of the message content before making a decision of the message meaning and starting a transaction that could make various databases out of sync. Enabling translation of domain entities into RDF instances. Domain entities are carrying data from domain database and data needed to be transformed into RDF message [18]

A successful result with one message was achieved between applications at General Motors and FOS on one side and “Test Harness” on the other, based on a limited amount of data being transmitted. The results were sufficiently encouraging to merit further research to improve message exchange. Following figure shows developed IV&I tool at the moment of message sending during the AIAG demo.


555

Fig. 4. The IV&I tool look

7 Lessons Learned Overall, we were very pleased how the IEM methodology and MO²GO tool supported the modelling of the eKanban business process leading to a transformation of the eKanban business process specification into a consistent enterprise model that formed basis for IV&I tool implementation. We found eKanban business process model great for communication, coordination and collaboration with AIAG business users and business analysts in order to understand and collect their eKanban requirements. Modeling the networked organization in IEM results in models that capture an extensive set of relationships between the goals, organizations, people, processes and resources. Hence, we discovered it was important to adapt the general IEM method by further revising and extending the methodology concepts in support of the IV&I tools implementation. We were able to introduce specific rules and constraints for the eKanban model by using attributes in the class structure. For instance, a semantic disambiguation was important to emphasize difference between concepts like Signal and Event. A documentation attribute of the Signal subclass states precisely that signal is generated by an Inventory Visibility tool. That information was essential to account for the necessary IT requirements. This is particularly useful considering the dynamic nature of collaboration between Customer and Supplier in the eKanban supply chain. For new partners

556


joining the network, the rich eKanban model provides a valuable source of knowledge on how to “behave” in the network. The interactive nature of eKanban BPM, meaning that we were free to refine it during execution and implementation phase increases it’s potential as source of experience and knowledge. As such, it documents details on how the work was actually done, not only how it was planned. From a knowledge management perspective, process models are carriers of process knowledge; knowledge of how to do things. But through the possibility in IEM of attaching information resources to the tasks at any level, such a model also imposes a structure upon the set of information resources relevant for the work described by the process model. That way, the process models themselves form the basis for information management. Model enrichment with XML Schema and BOD message definitions enhanced this even further. IEM can be extended to link into for languages used in the SOA and MDA approaches, particularly UML, through the visual features of MO²GO. It was very useful for IV&I tool development to have UML diagrams included directly in the model because UML is a de facto modeling standard recognized by the most tool providers and can be converted to schema or code. Besides, most tool providers can consume the UML data exchange format. The ability to work directly from a computational model of the business process reduced time to implement IV&I application. Given model was really helpful during the identification of required application functionalities. Standard way of Data exchange representation and their link to the model was very important. Because this phase of development process was relatively easy, more time could be spent on dealing with interoperability issues. Implementing the RDF interface challenged the RDF processing module in an additional way. In fact, there are many different ways one can write an RDF instance. The differences may be reflected in the structure of the elements as well as in the element types. In addition, the attribute definitions may differ from one application user to another with different sets of attributes used by different users. We tried to cover a broad set of attributes and possible message formats because in this part of the system, robustness is crucial. System must be robust in the case of missing data or unknown message structures. Our design priority was to pull out the maximum of information from a received message.

8 Conclusion and Future Work For systems and enterprises to evolve in a coordinated manner, there is a need for representing knowledge in a way understandable for both business users, system analysts and software developer. In this paper, we demonstrated that a wellstructured IV&I Reference Model has turned out to be a very efficient mean for IV&I tool implementation, allowing capture of eKanban business requirements in a simple and comprehensive way. The most important benefit of the selected approach is the strong support to implement eKanban based on the integration of operational processes to execute eKanban control, and the structures and processes to establish the connection and collaboration between partners. Here, the integrated


557

specifications which are used in the eKanban execution, ensure common understanding between all stakeholders and consistency of data and processes. Modeling has been touted as an appropriate way of providing the necessary abstraction mechanism to comprehend and analyze complex problems in this regard. It appears that no modeling technique or approach is applicable across the whole spectrum of process and stakeholder types. This paper has outlined early work on how results from modeling approaches from the fields of Enterprise Modeling, Ontologies and MDA architecture can be combined to provide a more complete coverage of the overall problem area. We will over the next years work on these problems both standalone and combined, testing solutions out on industrial cases, with a specific focus on achieving both system and business interoperability. Future work is planned in several directions. We plan to use the experience and results from the validation interviews (to be completed with the domain business analysts’ involvement) to develop structured test specification for the analysis of the consistency and completeness of the models created. Such structured test specification will allow easier validation planning of enterprise modelling results in the context of crossenterprise interoperable data exchange development. Another future challenge is to try to integrate business process and workflow management system with semantic mediation system. The idea is to try to use the identified data exchange requirements at the EM level to assist in creating messaging data models and, eventually, the XML Schema or RDF schema definitions for implementation of eKanban-conformant data interfaces. This capability could help drive efficiency and quality of real implementations of the interoperable interfaces with all technical details included.

References [1]

[2]

[3]

M. Jankoviü, N. Iveziü, Z. Marjanoviü, T. Knothe, P. Snack: "A Case Study in Enterprise Enterprise Modeling for Interoperable Cross-Enterprise Data Exchange", IESA’07, Funchal (Madeira Island), Portugal, 2007., Monograph: R. J. Goncalves, J. P. Muller, K. Mertins and M. Zelm (Eds.): "Enterprise Interoperability II: New Challenges and Approaches", Springer, London, 2007., ISBN-13:9781846288579, ISBN 978-1-84628-857-9, e-ISBN 978-1-84626-858-6, pp 541-552.2. IDEAS, Interoperability Development for Enterprise Application and Software Project, (2005), http://www.ideas-roadmap.netATHENA, I. Noviþiü, Z. Kokoviü, N. Jakovljeviü, V. Ljubiþiü, M. Bacetiü, N. Aniþiü, Z. Marjanoviü, N. Iveziü: "A Case Study in Business Application Development Using Open-Source and Semantic Web Technologies", I-ESA’07, Funchal (Madeira Island), Portugal, 2007., Monograph: R. J. Goncalves, J. P. Muller, K. Mertins and M. Zelm (Eds.): "Enterprise Interoperability II: New Challenges and Approaches", Springer, London, 2007., ISBN- 13:9781846288579, ISBN 978-1-84628-857-9, e-ISBN 978-184626-858-6, pp 541-552.2. IDEAS, Interoperability Development for Enterprise Application and Software Project, (2005), http://www.ideas-roadmap.net INTEROP, Interoperability Research for Networked Enterprises Applications and Software NoE, (2005) (IST-2003-508011) http://www.interop-noe.org

558


AIAG, Automotive Industry Action Group, (2006) Inventory Visibility & Interoperability Electronic Kanban Business Process (IBP-2) [5] 5. ATHENA, (2005) Deliverable Number: D.A6.1, Specification of a Basic Architecture Reference Model.Version 1.0 [6] ATHENA, (2004) Deliverable D.A1.1.1, First Version of State of the Art in Enterpri Modelling Techniques and Technologies to Support Enterprise Interoperability, Enterprise Modelling in the Context of Collaborative Enterprises [7] Knothe T., Jäkel F., Schallock B., (2004) ATHENA, IEM / MO²GO Tutorial Theory and Case Studies. Fraunhofer IPK-Berlin, http://www.ipk.fhg.de [8] ATHENA, Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications Project, (2006) http://www.athenaip.org [9] Java Platform, Enterprise Edition (Java EE), Enterprise JavaBeans Technology, Available at: http://java.sun.com/products/ejb/ [10] 10. Java Web Services - SOAP with Attachments API for Java (SAAJ), Available at: http://java.sun.com/webservices/saaj/index.jsp [11] Documentation for Sesame. Available at: http://www.openrdf.org/documentation.jsp [12] Resource Description Framework (RDF) Schema Specification 1.0 W3C 2000, Available at: http://www.w3.org/TR/2000/CR-rdf-schema-20000327 [4]

IS Outsourcing Decisions: Can Value Modelling Be of Help? Hans Weigand Infolab, Tilburg University, P.O.Box 91053, 5000 LE Tilburg, The Netherlands [email protected]

Abstract. Value models are used to support discussions on business models as well as strategic decision-making for networked enterprises. The aim of IT strategy is to make strategic decisions on IT, such as outsourcing, in the light of the contribution of IT to the business as a whole. To facilitate discussions on the contribution of IT, it is necessary to abstract from enterprise software details and focus on the value of IT services. In this paper, we explore how the strategic value modeling approach c3-value can be of help in the decision making process. Keywords: Modelling methods, tools and frameworks for (networked) enterprises, Strategy and management aspects of interoperability, Requirements engineering for the interoperable enterprise

1 Introduction Modern organizations in all sectors of industry, commerce and government are fundamentally dependent on their information systems and the way these systems interoperate with the systems of their partners. These interoperability issues have only become more prominent with the recent IT outsourcing wave. During the 1990s, it was increasingly recognized that competitive advantages of IT are often short-lived, and drawing inspiration from the Resource Base Theory in organization theory, the emphasis shifted towards sustainable advantages based on core capabilities. Whether IT provides such core capability is being doubted. When Eastman Kodak decided in 1989 to outsource its information system completely, this had a significant impact, and although IT outsourcing has not always been a success, no IT manager can afford to ignore the question anymore. IT outsourcing, or more general, “IS sourcing”, in the sense of “the organizational arrangement instituted for obtaining IS services and the management of resources and activities required for producing these services” [4]

560

Hans Weigand

involves many stakeholders. Therefore, there is a need for facilitating and structuring the decision process. To facilitate discussions on the contribution of IT, it is necessary to abstract from enterprise software details and focus on the value of IT services. In this paper, we explore whether and how the strategic value modeling approach c3-value can be of help. This method offers a value rather than process perspective, is supported by graphical models, and envelops insights from both the Porter-style competitive strategy literature as well as the Resource Based Theory. According to the empirical study of Rivard [16], an examination of IT contributions to business performance should build upon the complementarity between the resource-based view and the competitive strategy view, as both sets of variables were found to influence performance. The outline of this paper is as follows. In section 2, we identify issues in IS outsourcing that any method that aims to support sourcing decisions should address. This is based on some key publications in the area. Section 3 gives a short summary of the c3-value method with a redefinition on the relatively unexplored notion of value activity. In section 4, we describe an abstract IT outsourcing decision process and consider the possible contributions of c3-value in each step. Section 5 evaluates the results and provides suggestions for future research.

2 Requirements In the Information Management literature, it is generally conceded that information technology in itself has no competitive value. In a conceptual analysis of IT and competitive advantage, Mata et al [10] concluded that only IS management skills are likely to be a source of sustained competitive advantage, and this position has been supported by several empirical studies. Arguably, it is in line with the Resource-Based Theory (RBT) perspective [2,10] that states that resources per se do not create value; value is created by an organization’s ability to utilize and mobilize these resources. This “ability” is also denoted with the term “competencies” [14]. These competencies take the form of a bundle of skills (bundles are hard to imitate). The word “capability” is used by Peppard and Ward to refer to the strategic application of competencies. If a certain firm has an IT capability, this may be because of various competencies. However, the word “capabilities” is often used as a synonym of competencies, and in this paper we will follow this tradition. According to Peppard and Ward, IS management includes the definition of the role of IS in the organization and the translation of this into processes as well as long term architectures and infrastructure on the one hand, and the development and exploitation of business solutions and technology maintenance at the other. On the basis of this definition, they are able to define 26 IS competencies. Examples are the ability to define information management policies for the organization, or the ability to develop and implement IS solutions that satisfy business needs. These competencies are viewed as competencies of the organization as a whole, and are embodied in processes. In some cases, these processes are well-defined (e.g. system development base on standard IS design methodologies), in other cases they not defined at all. Employees contribute to these processes by means of their

IS Outsourcing Decisions: Can Value Modelling Be of Help?

561

skills, knowledge and attitudes. The latter are identified as “resources”. The Feeny/Willcocks framework [5] identifies 9 IS core competencies, grouped under 3 faces: Design of IT architecture, Delivery of IT service, and Business and IT vision. A few remarks are in order. First, it should be clear that the RBT perspective is concerned with sustainable advantages of the company, but does not dismiss the use of short-term competitive advantages. The latter can be important as part of a first mover strategy. Disruptive technology can provide such a short-term advantage. In this paper, we focus on long-term strategies. A second remark concerns the way resources are defined by what employees contribute by their individual knowledge. This seems overly restrictive. Another kind of resource is the systematic experiential knowledge built up over time, for example, in-depth customer knowledge based on intelligence analysis of customer behaviour. Willcocks et al [17], following the theory of Stewart, calls this kind of knowledge “structural capital”, distinguished from human capital, customer capital as well as social capital. Mehta [12] describes how systematic knowledge management can contribute to essential capabilities. He proposes a so-called Knowledge-Based View (KBV) of the firm. Thirdly, it should be kept in mind that outsourcing can be done in many different ways [8,17]: single-vendor or multiple-vendor, and with varying degree of intensity, among others. From the above, some basic requirements on an IS outsourcing decision process can be derived. One may expect that it indicates how to identify IS competencies and how they contribute to key resources. It should give particular attention to the role of knowledge capital in relation to these resources. It should be realistic about the consequences of outsourcing in terms of additional transaction costs.

3 Value Modelling and c3-value Value modelling has been introduced by Jaap Gordijn under the name e3-value. In this section, we first describe a variant of e3-value called c3-value that specifically supports strategic analysis. In the second part, we zoom in on the notion of value activity. 3.1 c3-value

e3-value [6] is a modeling approach that is originally aimed at supporting the explorations of new business networks. For these explorations, process details are not relevant. What is important is whether a collaboration can be set up that provides value to all participants. We briefly introduce the basic concepts (Fig. 1 shows an intuitive example). An actor is an economically independent entity. An actor is often, but not necessarily, a legal entity. A value object is something that is of economic value for at least one actor. Examples: cars, Internet access, stream of music. A value port is used by an actor to provide or receive value objects to or from other actors. A value port has a direction, in (e.g., receive goods) or out (e.g.,

562

Hans Weigand

make a payment) indicating whether a value object flows into or out of the actor. A value interface consists of in and out ports that belong to the same actor and is used to model economic reciprocity. A value exchange is a pair of value ports of opposite directions belonging to different actors. It represents one or more potential trades of value objects between these value ports. A value activity is an operation that could be carried out in an economically profitable way for at least one actor. Given an e3-value model, attributed with numbers, Net Value Sheets (NVF) can be generated that show net cash flow for each actor involved. This gives a rough indication of whether the model is economically sustainable.

Fig.1. Initial (simplified) e3-value model for Amazon

c3-value is an extension of e3-value to support strategic analysis [17]. Why should a firm choose for one business model rather than another? Following the strategic management literature and balancing the different perspectives, there are three generic answers: x x x

to distinguish itself from competition to (better) fulfill customer needs or future needs to explore its resources, capabilities and partnerships that make up its competitive advantage

Therefore, the strategic analysis process in c3-value contains three dimensions: competition analysis, customer analysis and capability analysis. These dimensions


563

are not exclusive but integrative: if a firm develops a new service to distinguish itself from its competition, this only makes sense when the service fulfils a customer need and the firm is able to deliver that service. So the strategy should always align the three dimensions, and it does not matter so much where we start. As all the three dimensions are constantly changing and evolving, this alignment is not a one-shot action but a continuous effort. Following the three dimensions, c3-value distinguishes three value model views: the Customer Value Model, the Capability Resource Model, the Competitive Value Model and the Competition Analysis Tree (which is not a value model, but an aggregation of Competitive Value Models). 3.2 On the Notion of Value Activity

In the capabilities analysis, c3-value distinguishes resources and competencies, where competencies exploit resources. However, the ontological definitions of these concepts need to be made more precise and integrated with the e3-value ontology such as analyzed in [1]. We start from the e3-value concept of value activity, an activity that can be executed by at least one of the partners in an economically profitable way. In [1] the value activity is identified with the event concept in REA [11] and generalized into “an activity that adds value”. It is reasonable to assume that operations can only be economically profitable if they add value. However, we cannot assume that any value-adding activity can be explored as such on the market, as transaction costs may exceed the benefits. So strictly speaking, value activity (e3-value) is a specialization of value-adding activity. However, the problem with this restricted notion of value activity is that we typically only know whether some activity is profitable after the profitability analysis. For that reason, c3-value generalizes the e3-value definition of value activity to any activity that adds value. However, the goal of the profitability analysis is still to keep only those value activities that can be explored on the market – which blocks endless decomposition of activities. Given this new definition, we can proceed to identify related concepts. A valueadding activity, or event in REA for that matter, adds value to something (transform in REA) while using other things. It is important to distinguish between type and role: we use the word “business objects” for the “things” that play a role in the value activity; a business object can have a subject role of the activity – receiving value – and a business object can have an instrument role in the activity. For example, the value activity “acquire IT” uses instruments such as “IT acquisition skills”, a vendor short-list and “finances”, whereas its subject is the IT infrastructure of the company. Learning is a value activity that increases skills and can use various instruments: it can be context-free information, e.g. a book, but most important from an RBT perspective, is learning from experience. These skills are exploited in other value activities, but most prominently in the source activity itself (in the example: acquire IT). This means that there is a positive feedback loop between skills and activities. We identify a capability (or competence) with skills used in such a feedback loop; so skills are only a capability when they are constantly improved by actual use. Whether it is a core capability can only be decided when comparing

564

Hans Weigand

with competitors. A resource can be defined as a business object that is exploited in some value activity. So a web site may be a resource for an e-commerce firm like Amazon, and the web site development skills a capability.

Fig. 2. Basic value activity pattern

Fig. 2 describes the basic pattern of a value activity, while Fig. 3 gives an example. It is called a pattern because it describes the resources and related value activities that one typically expects around a certain value activity. A value activity adds value to some value subject. The value activity itself uses certain resources on the one hand and skills on the other (both are represented as dashed rounded boxes; in addition, one may use different colours). Resources must be acquired, which is another value activity, and this requires other resources again, like money. The skills are acquired primarily from experience, which is expressed by the flow between the focal value activity and “acquire skills”. The acquisition of skills can be supported by learning technology. The pattern shows one resource and one set of skills to support the value activity, but more resources can be distinguished (for example, raw product as one type and production machine or human personnel as other types), and we may distinguish between different skills. Evidently, this pattern is a generating pattern: starting from one value activity, we generate (at least) two new ones, acquire resource and acquire skills. Applying the pattern recursively to these value activities introduces yet other activities, such as the acquisition of skills in acquiring resources (i.e., procurement expertise). The generative property of the pattern can be used as a design heuristic during the development of value models. Note that the generative process (which is not decomposition!) can terminate for two different reasons: because we reach the boundaries of the actor, or because certain activities don’t seem relevant anymore to expand (economic value is too low).


565

Fig. 3. Example value activity (provide music) as an instantiation of the pattern

Besides the value activity pattern we distinguish a value transfer pattern that is used when the value-adding process is divided over multiple actors. A market transaction incurs new value activities: inbound logistics and outbound logistics for the custody transfer of the resource, as well as search and contracting activities.

4 IS Outsourcing Decision Process Although it has always been conceded that investments in IT should be formally planned and aligned to corporate strategy, it was found in an early study by Ciborra [3] that successful applications of IT are often due more to serendipity than to any formal planning process. This insight should be kept in mind when we are now exploring the structure of a decision process and how c3-value might contribute. We describe an abstract IS outsourcing decision process that incorporates based on Simon’s well-known general decision making model, also used in [5]. Intelligence relates to the problem identification. Design means identifying solution alternatives, and Choice means comparing the alternatives and selecting the best one. This step is followed by the implementation of the decision and subsequent evaluation. Fig. 4 depicts the main steps, typical pitfalls and a brief indication of how c3-value can support. Each step will be discussed below in more detail. It should be noted that the outsourcing decision process is better not considered in isolation, although in practice it often is. The fundamental question is not which IS functions should be outsourced, but how to optimize the contribution of IS to the core capabilities of the firm. In addressing this objective, some IS functions can better be outsourced, some IS functions need reinforcement, while there may also be successful IS contributions that should be explored even more or IS functions that have to adapt to evolving needs of the business.

566

Hans Weigand

Fig. 4. IS outsourcing decision process: main steps, pitfalls and possible contributions of c3-value

4.1 Intelligence The first question is why an organization might consider outsourcing. This is not the same as asking whether a particular IS should be outsourced or not, which is addressed later in the decision process. But why going into a decision process at all? At the time that IS outsourcing was seen as an innovation, this intelligence step amounts to a standard assessment of innovations as they propagate in the market. By now, the situation is different. Organizations should reassess their core competencies continuously. As indicated above, c3-value method has been designed to support strategic decision-making, including the identification of resources and the capabilities to explore and evolve them. Some specific guidelines are also presented in [15] in the context of e3 competences. A less structured approach is described in [7]: here capabilities are simply collected from managers in a GDSS environment. The global capability model is always worked out to a certain level of detail and does not necessarily touch the IS functions yet. 4.2 Design

The next question is what an organization might consider to outsource, that is, the identification of alternatives. There are two ways to arrive at a first candidate list: either by the further exploration of the global capability model, or bottom-up by a systematic assessment of all the IS functions and their contribution to the enterprise resources. As a checklist one may use a general list of IS functions such as


567

provided by [13] or [5]. The general criterion to include a certain IS function in the short-list is that it does not seem to contribute to core capabilities. Although this is not in the primary scope of this article, we note that another short-list is also useful, namely, the core capabilities that appear to be not well served, and that could benefit from more IS support, perhaps by means of insourcing.

Fig. 5. Example local capability model related to the value activity “host web site”

The shortlist of alternatives can be analyzed by means of c3-value. That is, for each function we draw an initial value model that identifies the value relationships with other components, a customer value model that analyzes the real and future needs of the business customer, a Vendor Analysis Tree that provides a systematic comparison with competitors – in this case other departments within the organization that could offer the same function, as well as outsourcing alternatives – and a local resource capability model that explicates the resources and capabilities behind the value offering. For example, if the resource is a certain web site, the initial value model might identify the value of this web site for marketing, as well as the dependencies of the web site on IT infrastructure and so forth (Fig. 5 depicts an example). The customer value model takes a closer look at the marketing function. In particular, this is useful for anticipating possible future needs; for example, the web site may support web presence only at the moment, whereas the marketing department may have a deeper need of targeting the right customer segment, and for that purpose will need a web site with more advanced customer tracking functions. The competition tree might include an external hosting service that offers the same function: the competition tree explicates the second-order values in which the offerings differ. At this point, the analysis is still qualitative, as a quantitative analysis of costs and benefits is only made in the next decision step. It might turn out that the external hosting service excels in terms of availability, whereas the current internal service provides more adaptability.

568

Hans Weigand

4.3 Choice The choice on what to do with the alternatives identified is typically based on a further quantitative analysis of each “promising” alternative taking into account of all the costs involved (including possible switching costs and the “cost of relationship” for instance). For this analysis, several business-economic approaches have been described in the literature, e.g. [9,13]. As there are different outsourcing strategies [8], the question is not only whether to outsource, but also how to outsource. The procedure will further include a ranking of the alternatives from which the most profitable cases are selected. A contribution of the c3-value at this stage may be that it supports the conceptual modelling of the alternatives as well as (drawing on e3-value) a profitability analysis. The conceptual modelling is useful as outsourcing a certain resource has many implications that need to be discussed between the stakeholders involved. When a resource, be it material as a web site, or more abstract as an IT management policy, is outsourced to a vendor, the value offering is usually not changed, but what does change is the learning cycle (acquire skills). Unless special arrangements are made about this with the vendor, it will not be possible anymore to learn from the exploitation of the resource, or other value activities around it (such as the acquisition of the resource). Not just the resource, but also the whole cluster in which it is embedded is moved out. The reason is that value contributions cannot cross organizational boundaries directly; so moving a resource to another organization means that value contributions of this resource to value activities are either removed or explicitly included in a value exchange between the two organizations (but then the value contribution is not direct anymore). If the organization outsources a certain resource but wants to maintain a certain level of exploitation skills, it cannot be done in the old way, but a new design is required (for example, certain skills are kept up to date by monitoring the performance of the vendor from a distance, and by systematic market surveying). These skills are not identical to the skills learned in the pre-outsourcing situation, as the c3-value model will also make clear, but they may be close enough so that the company will not have to invest too much if after some years, the particular IS function has to be backsourced again. 4.4 Implementation

The implementation of an outsourcing decision typically involves the development and subsequent management of SLAs with the selected vendor. It may also include a design of the collaboration process between systems, but the relationship does not necessarily involve interoperability at the system level. c3-value might be very useful for this step, as it is an excellent tool to model the essence of the relationship without going into process details. It can model the primary value offering as well as second-order value objects. These second-order values (quality of service) are preferably based on standard ontologies. For example, in the domain of IT service outsourcing, standard quality areas include Availability, Performance, Support and Security. The quality level should be assessed in at least two ways. One is to assign a certain performance indicator to


569

each area that measures its level, for example MTBF in the case of Availability. Equally important is it to measure the maturity of the service, for which the maturity model of COBIT can be used. 4.5 Evaluation

After the implementation, the organization must evaluate the outcomes of the outsourcing. Does the vendor provide satisfactory results? What are (perhaps unexpected) outcomes of the organizational change? According to recent studies [18], contracts are better made for a short term (2-3 years) only, to avoid lock-in – although this depends on the kind of outsourcing relationship. In all cases, data must be collected to support the end-of-period decisions. According to [8], firms must have a long-term perspective on the evolution of their IT outsourcing relationships. In the above, we stated that the monitoring of the contract and relationship must be a value activity in the new c3-value model. This value activity must be given an organizational position and realization.

4 Conclusion IT outsourcing is a delicate process that involves many stakeholders and is much more than the design of an interoperable system, although the latter may be a result of it. In this paper, we have described an abstract decision process, and we have explored how the c3-value modelling method can be used to support the various steps. In the research literature, we have found several articles that support specific steps in the process, such as the calculation of agency costs, but not a method that supports the process as a whole in a systematic way. We can conclude from this exploratory study that c3-value might support several steps in the process and does provide a coherent framework, firmly based in the resource-based view of organizations. The actual evaluation of the usability of the method is to be given in further action-research projects. Furthermore, we have developed a new definition of value activity (based on Porter’s notion of value-added activity) as well as a new concept, the value activity pattern, which structures the relationships between value activities, resources and capabilities. Value modelling used to be primarily focused on business interactions as value exchanges. However, equally interesting is its application to the analysis of value chains and value creation cycles.

References [1]

[2]

Andersson B. et al (2006) Towards a Reference Ontology for Business Models. In: D.W. Embley, A. Olivé, S.Ram (Eds.): Conceptual Modeling - ER 2006, Tucson, AZ, USA, LNCS 4215 Springer, 482-496. Barney, J.B., (1996) The Resource-based Theory of the Firm. Organization Science 7(5), 131-136.

570

Hans Weigand

[3]

Ciborra C. (1994) The grassroots of IT and strategy. In: Ciborra C., Jelessi T., (Eds), Strategic Sourcing of Information Systems: A European Perspective, Wiley, Chichester, 3-24. Dibbern J., Goles T., Hirschheim, R., Jayatilaka B. (2004) Information Systems Outsourcing: A Survey and Analysis of the Literature. ACM SIGMIS Database – Vol. 35, No. 4, 6-102. Feen, D., Willcocks L. (1998) Core IS Capabilities for Exploiting Information Technology. Sloan Management Review 39(3), 9-21. Gordijn J., Akkermans J..M., Vliet J.C. van, (2000) Business Modeling is not Process Modeling, Conceptual Modeling for E-Business and the Web, LNCS 1921, Springer-Verlag, 40-51. Lin C., Hsu M-L. (2007) A GDSS for Ranking a Firm’s Core Capability Strategies. Journal of Computer Information Systems Summer 2007, 111-130. Kishore R., Rao H.R., Nam K., Rajagopalan S., Chaudhury C. (2003) A Relationship Perspective on IT Outsourcing. Comm of the ACM 46/12, 87-92. Maltz A.B.. Ellram L.M. (1997) Total cost of relationship: an analytical framework for the logistics outsourcing decision. Journal of Business Logistics 18(1), 45-65. Mata F.J., Fuerst. W.L., Barney J. (1995). Information Technology and sustained competitive advantage: a resource-based analysis. MIS Quarterly 19, 487-505. McCarthy W. E. (1982) The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review 57(3), 554-78 Mehta N. (2007) The value creation cycle: moving towards a framework for knowledge management implementation. Knowledge Management Research & Practice 5, 126-135. Ngwenyama O.K, Bryson N. (1999) Making the information system outsourcing decision: a transaction cost approach to analyzing outsourcing decision problems. European Journal of Operational Research 115 (2), 351-367. Peppard J., Ward, J. (2004) Beyond strategic information systems: towards an IS capability (2004) J. of Strategic Information Systems 13 (2), 167-194. Pijpers V., Gordijn J. (2007). e3 competences: Understanding core competences of organizations. Proc. BUSITAL’07 (CAISE workshop). Rivard S., L. Raymond L., Verreault D. (2006) Resource-based view and competitive strategy: an integrated model of the contribution of information technology to firm performance. J. of Strategic Information Systems, 15 (1), 29-50. Weigand H., Johannesson P., Andersson B., Bergholtz M., Edirisuriya A., Ilayperuma Th. (2007) Strategic analysis using value modeling – the c3-value approach. Proc. HICSS ’07, IEEE Press. Willcocks, L., Hindle J., Feeny D., Lacity M. (2004) IT and Business Process Outsourcing: The Knowledge Potential. Information Systems Mgt 21(3), 7-15.

[4]

[5] [6]

[7] [8] [9] [10] [11]

[12]

[13]

[14] [15] [16]

[17]

[18]

Process Composition in Logistics: An Ontological Approach 15 A. De Nicola, M. Missikoff, L. Tininini Isituto di Analisi dei Sistemi ed Informatica “A. Ruberti” – CNR, Rome, Italy {denicola, missikoff, tininini}@iasi.cnr.it

Abstract. Maintenance of complex engineering artifacts is a complex issue that often consumes significant resources. An even more critical situation is represented by the ad-hoc intervention that takes place in the presence of a failure. Autonomic Logistics Services (ALS) is an emerging approach that aims on the one hand to minimize periodical maintenance interventions and on the other to apply advanced diagnostics to anticipate unexpected failures, minimizing ad-hoc interventions. For the latter, ALS requires dynamic service composition, typically consisting of interleaved diagnostics and repairing operations. In the paper we propose an ontological framework supporting ALS and the dynamic composition of its ad-hoc maintenance programs. In particular we propose BPAL (Business Process Abstract Language) as the formal ontological foundation, derived from the (informal) BPMN proposed by the OMG. Keywords: Ontology based methods and tools for interoperability, Business Process Management, Service oriented Architectures for interoperability

1 Introduction The maintenance program for large engineering artifacts (e.g. a radar system or a helicopter) is a very critical factor for the overall success of a large project. While scheduled maintenance interventions are relatively easy to be structured and planned, extraordinary interventions often take place in critical situations and require an ad-hoc planning of operations. Ad-hoc operations are costly and hence, there is an increasing need to reduce extraordinary interventions. An economically-efficient maintenance plan is gaining importance also because many enterprises are increasingly offering a Contractor Logistics Support, i.e., a form of warranty that covers the entire life cycle of the sold product with quality 15 This work is partially supported by the Tocai Project (http://www.dis.uniroma1.it/~tocai/), financed by the FIRB Programme of the Italian Ministry of University and Research (MIUR.)

572

A. De Nicola, M. Missikoff, L. Tininini

parameters directly specified in the support contract, e.g., the minimum acceptable Mean Time Between Failure or Mean Time To Repair, etc. This is particularly critical for complex integrated systems whose life cycle may span over 10-20 years, or even more. The real challenge here is to minimise faults and failures, as they can produce serious damages and far more expensive maintenance interventions, while optimally identifying the sequence of scheduled maintenance events. Ideally, the scheduled maintenance events should be reduced to a minimum while: (i) identifying when an unplanned intervention is required, before the actual failure takes place; (ii) alternatively, provide a timely and effective intervention in case of unpredictable failure events; (iii) in both cases, plan the intervention in an optimal fashion taking into consideration: the structure of the system/device, the diagnosis of malfunctioning, the intervention capacity, the conditions on the field, the specified quality parameters. In other words an ideal approach should schedule the interventions when they are really needed (i.e. right before the failure occurrence would appear), providing the right action, in the right place, involving the right people. In this paper we propose an ontology-based modelling framework, called BPAL (Business Process Abstract Language) to address the problem of defining an ad-hoc maintenance strategy based on the structure of the system and of the diagnostic process, as well as on the conditions of the operational context. This effort is targeted at the implementation of Autonomic Logistics Services (ALSs), where (at least ideally) the maintenance program would be derived automatically and the majority of the common logistics and maintenance actions for a complex system would become automated, thus minimising manpower and human errors. BPAL has been primarily conceived to provide a formal semantics to BPMN, a graphical language for BP modelling that is gaining consensus in the business world. In particular, it provides a procedural semantics for translating BPAL abstract processes into an executable form and a declarative semantics to support the automated analysis by an inference engine. The rest of the paper is organized as follows. Section 2 introduces Autonomic Logistics Services with their main characteristics and objectives. In Section 3, we briefly introduce a central issue of the proposed solution, namely dynamic process composition (DPC). In Section 4, we illustrate the main components and issues related to the BPAL approach, with a specific focus on ALS activities. Then, in Section 5, the expected benefits of the semantic ALS approach are illustrated. Related works are presented in Section 6, while conclusions are finally discussed in Section 7.

2 Autonomic Logistics Services: Objectives and Operations An ALS should provide an advanced level of logistic and maintenance support, according to three main lines of intervention: x

diagnostics: monitoring and analysing anomalies and faults, triggering and supporting a timely and effective corrective maintenance process, along with the related logistics flows and processes;

Process Composition in Logistics: An Ontological Approach

x x

573

prognostics: preventing possible (highly probable) anomalies and faults, by introducing a high flexibility in scheduled maintenance interventions; health management: assessing the system operational environment, and, when necessary, suggesting corrective actions aimed at maintaining the system in the best operational conditions.

For instance, the data concerning a control radar system would be automatically downloaded into a data warehouse that would in turn mine the data for anomalies in an effort to detect existing or impending faults. Additionally, unpredictable critical faults would be detected and isolated in real-time during normal operation and, in order to enhance reliability and safety, they would automatically trigger the ordering and tracking of spare parts, along with the alert, diagnostic and logistic support of specialised personnel, suited for performing the required maintenance intervention. As in many other business contexts, the methods commonly used to represent maintenance and logistics processes are mainly informal, aimed at supporting the enterprise organization at the human-communication level, rather than the system automation and interoperability, by means of a shared formalised knowledge. On the other hand, the ambitious objectives of Autonomic Logistics Services (ALSs) necessarily imply a formal description of both the systemic part of the artifact to be maintained (e.g., the equipments, with their perceivable behaviours in regular and abnormal conditions, the spare parts, the part-of relationships between equipments, the several kinds of faults and failures) and the dynamic part of ALS (in particular the diagnostics and maintenance processes), which is increasingly based on Service Oriented Architectures, where the process logic is represented by standard Business Process (BP) models, e.g., by using BPMN [8]. One side of the problem is of organizational nature. In fact, logistics is an area where two different communities, business people and engineering experts, need to cooperate. In order to close the gap between the ways business people and engineers conceive the diagnostic and maintenance BPs, our solution is based on a semantic approach, combining well-established ontology-based techniques (e.g., the OPAL ontology design patterns [2]) to represent the structural part of the system, with an ontological framework16 to represent the BP semantics, based on the Business Process Abstract Language (BPAL). We propose BPAL as a framework for the management of BP ontologies, primarily conceived to provide a formal semantics to BPMN, an informal BP modelling method gaining consensus in the business world. BPAL is an abstract language (no drawing symbols are provided) having a procedural semantics (allowing a translation to an executable form, BPEL), and a declarative semantics, to be processed by an inference engine.

16 The term “framework” is overloaded. Here we mean a language (lexicon and grammar), a set of axioms, an inference mechanism, and a collection of methods, tools, and best practices aimed at producing a valid BP model. Here we illustrate the BPAL framework at a descriptive level, since a formal treatment falls outside the scope of this paper.

574


3 Dynamic Process Composition Dynamic Process Composition has been investigated for long time in a wide variety of contexts, e.g. in automatic program synthesis. In general, this is a very hard problem extensively elaborated in the past with limited practical results. Here we intend to address the problem in a specific context, starting from a number of pre-existing elements. In particular, we assume that the DPC is based on the following elements: x x x x

Top Generic Processes (TGPs). A set of process skeletons that represent the starting point of an ALS process specification. ALS activities. A set of generic activities, structured according to two hierarchy relations: decomposition and specialization. ALS operations. A set of elementary actions, that can be performed either automatically by a machine, manually by a human expert, or synergically by both. DB storing the history of previous significant interventions.

The process composition starts with the analysis of the data collected on the apparatus, (possibly) requiring a maintenance intervention. The data analysis guides the following steps, that consist of a mix of diagnosis and repair actions. In so doing, the system tries to identify the top generic process, thus providing a first support to the expert. Then, the TGP is progressively refined to include ALS activities and, finally, ALS operations. The latter, when automated, are supported by e-services and a SOA can therefore be used for the enactment of the ALS process. The basic pattern underlying diagnosis-decision-action is basically similar to the patterns that can be found in Game Theory. For this reason, part of our future studies will be devoted to explore solutions developed in this field. In this paper we focus on the basic mechanisms provided in BPAL to support the dynamic composition of BPs, as well as their expansion and refinement. Such mechanisms will be used for the dynamic composition of ALS processes.

4 BPAL Basic Components BPAL is structured according to a number of modeling notions defined in accordance with the business culture (such as activity, decision, role), corresponding also to BPMN constructs. The set of symbols denoting such modeling notions constitute the BPAL lexicon, while the corresponding concepts, expressed as atomic formulae (atoms), represent the core BP ontology. BPAL atoms can be combined to build an Abstract Diagram that, once validated with respect to the BPAL Axioms, corresponds to an Abstract Process. An isomorphism can be defined between an abstract process and a BPMN process, the former providing the formal semantics of the latter. More precisely the main components of the BPAL framework are:


x

x

x

x

x

575

BPAL Atoms, represented in the form of logical predicates, are the core of the BPAL ontological approach. Any business process modeling starts by instantiating one or more BPAL Atoms provided by the process ontology framework. Note that this is a second-order instantiation, since BPAL atoms represent meta-concepts used to create a BP ontology. Atoms represent unary or n-ary business concepts and some special atoms specifically introduced to support the modeling process. As an example, unary predicates can be used to represent an action (e.g. “check the component voltage”) or an actor (e.g. “maintenance service engineer”), while n-ary predicates can represent precedence relations among activities and decision steps, as well as messages exchanged between activities. Furthermore, special atoms are provided, enabling the user to express specialisation or part-of relations among concepts. BPAL Diagram: a set of BPAL Atoms constitute a BPAL (abstract) diagram. Generally speaking, an abstract diagram is an intermediate product, which can be manipulated during the design process. A BPAL diagram is not required to satisfy all the axioms (see below). The operations of assert and retract can be used to incrementally build an abstract diagram, by introducing (and removing) atoms. BPAL Axioms, representing the constraints that a BPAL Diagram must satisfy to be validated as a BPAL Process. They are conceived starting from the guidelines for building a correct BPMN process. As there is no formal specification of BPMN processes, we provide here a “reasonable” solution, derived from the analysis of a number of publications and practical experiences of what a legal BPMN process should be. However, future official specifications can be incorporated in the framework by simply modifying the proposed axiomatization (see below). An example of BPAL axiom can be: “only decision points can have more than one immediate successor activity.” We also distinguish three kinds of Axioms: Diagramming, Domain and Application Axioms, with increasing degree of specialization with respect to the particular domain of interest. A BPAL Diagram is a Draft if it satisfies all Diagramming Axioms: in some sense a Draft Diagram has an intermediate level of refinement between a generic Diagram and a Process. BPAL (abstract) Process, which is a BPAL Diagram that has been validated with respect to the BPAL Axioms. The validation is achieved by supplying the abstract diagram and the BPAL axioms to a reasoner (we are currently experimenting JTP [17] and SWI-Prolog [18].) BPAL Application Ontology, which is a collection of BPAL Processes cooperating in a given application.

In the following subsections each component of the BPAL Framework is elaborated in more detail.

576


4.1 BPAL Atoms

The BPAL atoms are predicates where functors represent ontological categories, while arguments are typed variables representing concepts in the Core Business Ontology (CBO). The CBO is built according to the OPAL methodology [2]. For instance, an activity variable can be instantiated with a process name in the CBO. Variables are characterized by a prefixed underscore and, in building a BP ontology, will be instantiated with concept names of the category indicated by the functor. A process ontology is built by instantiating the following unbound predicates with the constants (i.e., concept names) declared in the CBO. Unary predicates (upre)

x x x

x x x

act(_a) – a business activity, element of an abstract diagram. role(_x) – a business actor, involved with a given role in one or more activities. dec(_bexp) – a generic decision point. Its argument is a Boolean expression evaluated to {true, false}. It is used in the preliminary design phases when developing a BP with a stepwise refinement approach. In later phases, it will be substituted with one of the specific decision predicates (see below). adec(_bexp), odec(_bexp) - decision points representing a branching in the sequence flow, where the following paths will be executed in parallel or in alternative, respectively. cont(_obj) – an information structure. For instance a business document (e.g., purchaseOrder). cxt(_obj) – a context, represented by a collection of information structures.

Relational predicates

x x x x x

prec(_act|_dec,_act|_dec) – a precedence relation between activities, decisions, or an activity and a decision. xdec(_bexp,_ trueAct) - this is a decision where only one successor will receive the control, depending on the value of _bexp. iter(_startAct,_endAct,_bexp) – a subdiagram, having _startAct and _endAct as source and sink, respectively. It is repeated until the boolean expression _bexp evaluates to true. perf(_role,_act) – a relation that indicates which role(s) is dedicated to which activities. msg(_obj,_sourceNode,_destNode) – a message, characterized by a content (_obj), a sending activity (_sourceNode), and a receiving activity (_destNode).

Development predicates The following predicates are used during the BP development process. They are part of the BPAL core ontology, but are not used to categorize business concepts


577

(therefore will not contribute to the generation of the executable image.) Conversely, they provide a support in the development of draft BPs. x x

pof(_upre,_upre) – Part-of relation that applies to any unary predicate. It allows for a top-down decomposition of concepts. isa(_upre,_upre) – Specialization relation that applies to any unary predicate. It allows to build a hierarchy of BP concepts, supporting a topdown refinement.

A BPAL Process is fully refined only if each of its atoms can not be further decomposed or specialised. Finally, we have two operations acting on a BP abstract diagram: x x

Assert (BP_Atom). It allows a new atom to be included in the ontology; Retract (BP_Atom). It allows an existing atom to be removed from the ontology.

To improve readability, multiple operations of the same sort can be compacted in a single operation on multiple arguments, e.g. Assert ([BP_Atom1, ..., BP_Atomn]). 4.2 BPAL Diagrams and Processes

By using BPAL atoms it is possible to compose an abstract diagram first and then, after its validation, a BPAL process. An abstract diagram is a set of BPAL atoms respecting the (very simple) formation rules. Below we illustrate (Figure 1) an abstract diagram; the presentation is supported by a concrete diagram, drawn according to a BPMN style. The node labels are concepts in the CBO.

Fig. 1. A simple BPMN Diagram

The corresponding BPAL abstract diagram is the following. act(a), act(b), act(c), act(d), act(e); prec(a,b), prec(a,c), prec(c,d), prec(b,d), prec(d,e). Please note that the order of the atoms is immaterial in a BPAL diagram and, in the punctuation, comma and colon are equivalent, while the full stop ends the abstract diagram.

578


4.3 BPAL Axioms

The BPAL framework is characterised by a number of axioms that must be satisfied by a BPAL Process. As anticipated, in BPAL we distinguish three categories of axioms and here, for sake of brevity, we only consider diagramming axioms. They are conceived starting from the guidelines for building a correct BPMN process. As said earlier, there is neither a formal specification nor a widely accepted view of the formation rules for a BPMN process, therefore we provide a “reasonable” solution, derived from the analysis of a number of publications and practical experiences. In any case the framework is sufficiently flexible to incorporate future revisions and the proposed axiomatization can be updated as soon as an official specification will be available. A complete treatment of the BPAL axionatic theory is beyond the scope of this paper. Here we outline the main features of the proposed framework, showing how it can provide a good trade-off between completeness and conciseness. BPAL axioms address different features of a BPMN process formalization. Here we report just one axiom, to provide a first insight in the BPAL methodology. Axiom1 - Branching Axiom If a node is followed by two or more immediate successor activities, then it must be a decision. x CBO : S ( x)

^y CBO : precx, y `

S ( x) ! 1 o dec( x)

According to the Branching Axiom, the above reported diagram is an invalid process and needs to be transformed into the following diagram: act(a), act(b), act(c), act(d), act(e), dec(k); prec(a,k), prec(k,b), prec(k,c), prec(c,d), prec(b,d), prec(d,e). This transformation is obtained by a number of updates on the original BPAL abstract diagram, sketchily summarised as follows: assert([dec(k), prec(k,b), prec(k,c), prec(a,k)]) retract ([prec(a,b), prec(a,c)])

Please note that we have now a Generic BPAL abstract process. It is a process since the Branching Axiom is no more violated and therefore the diagram is validated. However, it is Generic, since there is a generic atom dec(k) that needs to be substituted with a specific atom (one of: adec, odec, xdec.) Such a substitution, assuming that in the following steps of the BP design we discover that we need an and branching, will be achieved by the following design operations: assert: adec(k) retract: dec(k)


579

Fig. 2. A Generic BPAL Process in BPMN notation

Further steps of design refinement will involve other BPAL atoms, to specify roles, messages, etc.

5 The Expected Benefits of the Semantic ALS Approach The method presented in this paper represents the core of the SALSA (Semantic Autonomic Logistics Services and Applications) environment, aiming at an extensive application of Semantic Web solutions in the context of Autonomic Logistics services. In SALSA, we envisage a federation of ontologies, as sketchily reported below: x x x x

System Architecture Ontology (SAO), modelling devices and complex artefacts, with their components and operational characteristics; Failures and Malfunctioning Ontology (FMO), modelling the manifest behaviour (or absence of it) revealing abnormal situations; Monitoring and Diagnostics Ontology (MDO), representing the process and activities aimed at identifying the existence of instances of the previous ontology; Maintenance and Repairing Ontology (MRO), modelling the transformations to be applied to the system architecture ontology in order to correct identified failures (i.e., removing instances of FMO).

SALSA includes a reasoner that supports a large part of the above operations. The above ontologies, being federated, have cross-references and refer to a unique name space. This is an important feature that opens the possibility of a high level of automation. For instance, we can link elements of SAO, FMO, and MDO to support the generation of MRO processes. In essence, we assume that the repairing process is dependent on the system architecture and the identified failures, discovered by means of a diagnostic activity.

6 Related Works Several languages for BP have been proposed in the literature. Such languages can be sketchily gathered in three large groups.

580


Descriptive languages. They have been conceived within the business culture, but they lack a systematic formalization, necessary to be processed by an inference engine. We find in this group diagrammatic languages, such as EPC [12], IDEF [3, 4], and BPMN [8, 6]. Also UML-Activity Diagram [9] can be listed here, even if originally conceived for other purposes. The BPs defined with these languages are mainly conceived for inter-human communication and are not directly executable by a computer. Procedural languages. They are fully executable by a computer but are not sufficiently intuitive for being used by humans, and lack a declarative semantics, necessary to be processed by a reasoning engine. Examples of these languages are BPEL [5] and XPDL [6, 16]. Formal languages. They are based on rigorous mathematical foundations, but are difficult to be understood and are generally not accepted by business people. In this group we find several formalisms, e.g. those based on PSL [1, 13], Pi-Calculus [7], Petri-Nets [10]. Finally, there are the ontology-based process languages, such as OWL-S [14], WISMO [11], and WSDL-S [15]. This group of languages have a wider scope, aiming at modeling semantically rich processes in an ontological context, and have been conceived not directly connected to the business world.

7 Conclusions BPAL has been conceived to gather the most relevant features of the above mentioned categories of BP languages. Since its constructs are derived from BPMN, it maintains a close correspondence with this standard and therefore it is easy to provide a diagrammatic environment that satisfies the descriptive need of some communities (e.g., business people.) Many BPMN tools (e.g., Intalio BPMS Designer) allow to generate executable code, typically BPEL, starting from the built diagram. The tight correspondence between the BPMN and the BPAL constructs allows us to easily derive a correspondence between BPAL and BPEL constructs, and then provide the generation of an executable BPEL file starting from a complete BPAL process. Finally, BPAL has a formal background, since it is rooted in mathematical logic, and in particular Horn Logic, used to formally verify the consistency of a BPAL business process. With respect to the semantic Web services proposals, such as WSMO or OWL-S, BPAL adopts the opposite strategy: instead of proposing a “holistic” approach that must be embraced as an exclusive choice, BPAL proposes a progressive approach, complementary to existing commercial SOA solutions. It is complementary with respect to the existing SOA solutions, since you may start with a “non-semantic”, implementation and decide later on to add semantics. It is progressive, since you may decide to what extent you “inject” semantics into your SOA (i.e., what you decide to semantically annotate) and then progressively proceed along the semantic enrichment process as long as the need emerges.


581

References [1] [2] [3] [4] [5]

[6]

[7] [8]

[9] [10] [11] [12]

[13] [14] [15] [16]

[17]

[18]

Bock C, Gruninger M (2005) PSL: A Semantic Domain for Flow Models. Software and Systems Modeling Journal 4: 209-231. D’Antonio F, Missikoff M, Taglino F (2007) Formalizing the OPAL eBusiness ontology design patterns with OWL. I-ESA Conference 2007. IDEF. IDEF0 - Function Modeling Method. [http://www.idef.com/IDEF0.html]. IDEF. IDEF3 - Process Description Capture Method. [http://www.idef.com/IDEF3. html]. Khalaf R, Mukhi N, Curbera F, Weerawarana S (2005) The Business Process Execution Language for Web Services. In Dumas M, van der Aalst W, ter Hofstede AHM (eds) “Process-Aware Information Systems”. WILEY-INTERSCIENCE, Pages 317-342. Mendling J, zur Muehlen M, Price A (2005) Standards for Workflow Definition and Execution. In Dumas M, van der Aalst W, ter Hofstede AHM (eds) “Process-Aware Information Systems”. WILEY-INTERSCIENCE, Pages 281-316. Milner R (1999) Communicating and Mobile Systems: the Pi-Calculus. Cambridge Univ. Press, ISBN 0-521-65869-1. OMG (2006). Business Process Modeling Notation Specification. Version 1.0. February 2006 [www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%2010%20Spec %2006-02-01.pdf] OMG (2007). Unified Modeling Language: Superstructure version 2.1.1. [http://www.omg.org/docs/formal/07-02-03.pdf] Peterson JL (1977) Petri Nets. ACM Computing Surveys 9 (3): 223–252. Roman D, Keller U, Lausen H, et al (2005) Web Service Modeling Ontology. Applied Ontology, 1(1): 77-106. Scheer A-W, Thomas O, Adam O (2005) Process Modeling Using Event-Driven Process Chains. In Dumas M, van der Aalst W, ter Hofstede AHM (eds) “ProcessAware Information Systems”. WILEY-INTERSCIENCE, Pages 119-145. Schlenoff C, Gruninger M et al (2000) “The Process Specification Language (PSL) Overview and Version 1.0 Specification”, NIST. The OWL Services Coalition (2003). OWL-S: Semantic Markup for Web Services. [http://www.daml.org/services/owl-s/1.0/owl-s.pdf]. W3C (2005). Web Service Semantics WSDL-S. [http://www.w3.org/Submission/WSDL-S]. WFMC (2005). Process Definition Interface – XML Process Definition Language, version 2.00. [http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_ 2005-1003.pdf]. Fikes R., Jenkins J., and Gleb F. "JTP: A System Architecture and Component Library for Hybrid Reasoning." Proceedings of the Seventh World Multiconference on Systemics, Cybernetics, and Informatics. Orlando, Florida, USA. July 27 - 30, 2003. Wielemaker J., Huang Z., and van der Meij L.: SWI-Prolog and the Web, Journal of Theory and Practice of Logic Programming (to appear in 2007.)

Interoperability of Information Systems in Crisis Management: Crisis Modeling and Metamodeling Sébastien Truptil1, Frédérick Bénaben1, Pierre Couget2, Matthieu Lauras1, Vincent Chapurlat3, and Hervé Pingaud1 1

2

3

Ecole des Mines d’Albi-Carmaux, Campus Jarlard, Route de Teillet, 81000 Albi, France {truptil, benaben, lauras, pingaud}@enstimac.fr Préfecture du Tarn, Place de la Préfecture, 81000 Albi, France [email protected] Ecole des Mines d’Alès, Parc Scientifique Georges Besse, 30900 Nîmes, France [email protected]

Abstract. In a crisis situation (natural disaster, industrial accident, etc.) several partners have to act simultaneously to solve the emergency situation. Their coordination in such a context is a crucial point, especially in the first moments of the crisis. Their interoperability (precisely their Information Systems interoperability) is a major component of the success of the network. ISyCri 17 French project propose to tackle this topic according to two aspects: (i) responsiveness of the network (its ability to act rapidly and efficiently) and (ii) flexibility of the obtained system of systems (its ability to evolve and follow the changing situation). This is so an agility problem of ISs of partners. This article presents the first results of this work: a metamodel of crisis situation and its ontological links with collaborative process design, and also the treatment of a first case of study, a NRBC 18 exercise. Keywords: ontology, crisis management, interoperability, information system, collaborative process, system of systems, SOA, MDA.

1 Introduction On a crisis situation, different actors have to act (generally) simultaneously in a hurry to reach the shared goal of crisis reduction. These actors are heterogeneous by nature (mission, equipment, culture, etc.). To be efficient, they have to collaborate, or at least to coordinate their actions, in order to build a coherent 17 Interoperability of System in Crisis situation. 18 Nuclear Radiological Bacteriologic Chemical.

584

S. Truptil, F. Bénaben, P. Couget, M. Lauras, V. Chapurlat, H. Pingaud

response. However each performer remains autonomous for the deployment of its means and the achievement of its own objectives (even if a general entity is often in charge of the global authority). Generally, each actor owns its own information system (IS) adapted to its own needs, resources and processes. That is why, we believe, as shown in [1], that the major issue of integration of partners in crisis context is the ability of these information systems to communicate, to exchange information, to share services and to coordinate their behaviors according to the global goal of crisis reduction. This observation is, for the authors, the keystone of the efficiency of crisis reduction. The point of the ISyCri project is to provide partner organizations involved in such a situation with a Mediation Information Systems (MIS) able to merge their respective heterogeneous and autonomous ISs into a global System of Systems (SoS). This MIS, as the linking support between ISs have to meet the two mains requirements: (i) providing a fast and efficient link between ISs (in order to ensure responsiveness) and (ii) following the unavoidable evolutions of the crisis by remaining adapted and rightly dedicated to the specific needs of the crisis situation and to the – possibly changing – group of involved partners working on its resolution (in order to ensure flexibility). Thus the MIS design should deliver an agile result (agile can be seen as the union of responsiveness and flexibility). The global principle of the ISyCri project and its contents will be presented in the first section of this article. We will then focus on the crisis modeling part, as a way to build the first step to MIS design. In order to meet its objectives, the ISyCri project plans to set up a global crisis metamodel. This metamodel can be seen as the combination of two ontologies: one for crisis characterization and one for reaction processes. The knowledge supplies by the instantiation of this metamodel can be used, first to model the adequate MIS to react promptly to the situation and second to maintain the model of the crisis in order to follow its evolution. The proposed metamodel and the ontological objectives will be shown in the second part of this paper. Thirdly, the authors will present the instantiation phase of the metamodel on the treatment of a particular instance: a civilian training exercise concerning a NRBC context. This third part will show the adequacy of the proposed metamodel and the choices the authors made to create the dedicated crisis model. This is a way to test the metamodel and also a capitalization phase offering formalized knowledge on crisis situations for the continuation of the project. ISyCri is a project supported by the French Research Agency (ANR for Agence Nationale de la Recherche 19) involving five main partners: two companies (THALES-Communication and EBM-WebSourcing) and three academic labs (DR/GI from Ecole des Mines d’Albi-Carmaux, IRIT from Université de Toulouse 1 and LGI2P from Ecole des Mines d’Alès). Institutional partners are also providing their user point of view. This project will stand from the end of May 2007 to the beginning of June 2009.

19 French national agency for research.

Interoperability of Information Systems in Crisis Management

585

2 Overview of the ISyCri Project The authors believe that integration of partners is a crucial step on the way of success in crisis reduction. The authors point is to propose to solve this issue of integration of partners by the means of ISs interoperability. According to InterOp 20, Interoperability is “the ability of a system or a product to work with other systems or products without special effort from the customer or user” [2]. For the authors, Interoperability can be seen as the collaborative maturity level (of organizations) adapted to integration, which can be seen as the ultimate collaboration level (of network). 2.1 A Method of Mediation Information System Design

Ensuring partners’ ISs interoperability is not a trivial issue. The authors believe it is rational to tackle this topic on the base of existing partners’ ISs. Another approach could propose to rebuild partners’ ISs, but the authors believe such a radical approach can not be considered as a realistic one. The goal of ISyCri is thus to provide a method of MIS design. The two crucial needs of responsiveness and flexibility (i.e. agility) must be covered. Due to the nature of the MIS (an information system), we propose to develop our design approach on the MDA21 precepts. The general view of this design method is shown on next figure (using the “Y” of the MDA approach):

Fig. 1. Proposed MIS Design method in the MDA context (an overview).

Knowledge about the crisis context allow to model the specific situation according to the crisis metamodel and the corresponding ontology. Using this characterization, the crisis ontology provides a deduced model of an adapted collaborative process: the CIM (which could be enriched and validated). This step 20 InterOp is a European Network of Excellence (NoE) dedicated to Interoperability issues. 21 Model-Driven Architecture.

586


is based on the adaptation of the results about the deduction of collaborative process model (in industrial context) from collaboration characterization (using ontology) presented in [3] and [4]. A model transformation mechanism use this CIM to build (in UML 22 or in a specific DSL 23) the logical view of the MIS: the PIM. This mechanism is directly inherited from [5] and propose a SOA 24 structure for the MIS. Concurrently, the ESB 25 targeted technologic platform is modeled: the PM. ESB technology has been chosen because of its obvious adequacy with SOA principles. Some partners of the ISyCri project are skilled in these technologies. Next, a projection (logic to technology) provides a MIS computable model: the PSM. This design method and ensure the exigency of responsiveness listed below, but concerning the requirement of flexibility a complementary study should be added (such as loops in the method). 2.2 Contents of the ISyCri Project

Obtaining such a MIS design framework implies to divide the whole ISyCri project into several tasks which provide the needed elements to support the MIS design method itself. Those tasks can be listed as follow: 2.

Ontology building: This first task will be developed in section 3. however to summarize, the authors aim at building a global crisis ontology providing a way to deduce adequate collaborative processes from crisis descriptions. This global crisis ontology is built by linking semantically two ontologies which are crisis ontology and response ontology. Crisis is organized in two parts: the studied system (including people, natural site, goods, etc.) and the crisis characterization (containing elements of crisis identification, such as type, gravity, trigger, etc.). Response ontology represents the treatment system deployed to reduce the crisis as well as the collaborative process executed. 6. Logical modeling of MIS: Extracting the embedded knowledge from collaborative process(es) model (CIM) in order to design the logical model (PIM) can be seen as a model transformation task. We already have some results on this field (in industrial collaboration situations) which can easily be extended in crisis context. This work is especially focused on SOA approach. 7. Technical Modeling of architecture and projection from logical view to technological view: We believe ESB can be a pertinent candidate for an adequate technological platform. It is essential to study and to model the structure of such a tool in order to provide the PM. Furthermore, mechanisms of projection of logical view (PIM) onto this technical view (PM) should also be established.

22 Unified Modeling Language. 23 Domain Specific Language. 24 Service-Oriented Architecture, a logic approach for IS conception based on clustering functions. 25 Enterprise Service Bus, a technological solution for service-based IS.


587

8.

Study of the dynamic part: The keystone of the added-value of the ISyCri project is the ability of the MIS to follow changes of the crisis situation. This capacity can be carried by several levels: the process engine could be flexible enough to support evolutions of the dynamical model of the network. This is flexibility at the implementation level. In mind of the authors it is possible to bring flexibility at any MDA levels (PSM, Projection, PIM, CIM). An iterative approach can be used to bring a “loop” in the design process (on precise looping criteria). This study remains obviously a critical task of the ISyCri project. 9. Experimentation: Such a task is a generic part of this kind of project. It will be based on specific use-cases in order to check the described principles.

3 Crisis Characterization and Collaborative Process Deduction This section will present the theoretical aspects of collaborative process inference. The main principle is to use a crisis ontology (including descriptive part and dynamic part, which is the response process) in order to formalize the knowledge available at the moment (about the crisis situation). The result is a partial instantiation of the crisis ontology. The incomplete part (especially the dynamic view) have to be inferred from the existing knowledge using deduction mechanisms and connection rules specific to the generic crisis ontology. The point is to obtain a proposal of a collaborative process adapted and dedicated (by construction) to the specific crisis situation which have been characterized through the ontology. The obtained process could obviously need to be validated and/or completed by experts (crisis expert or member of the collaborative network) in order to become a pertinent dynamic suggestion. 3.1 Ontological Principle

The following picture (Fig. 2) presents the global structure of the crisis ontology the authors aim to use. Its design will be based on a crisis metamodel (in UML) presented in part 3.2.

Fig. 2. Ontological architecture of the deducing mechanism (sub-ontologies and links).

588


ISyCri Ontology contains two main parts (crisis ontology and response ontology) which contains each one two sub-parts (studied system and crisis characterization for the crisis ontology and treatment system and process for the response ontology). These sub-ontologies of ISyCri ontology are connected with each others using semantic links or structural links inherited from the metamodel (links connect elements of ISyCri ontology, for instance, a start event is connected to a crisis through a trigger link). Once defined, such a metamodel covers the whole crisis representation but it cannot express the dynamic of such situations. We need to make it more expressive and absolutely non-ambiguous to have its instances able to provide the dedicated collaborative processes. One possible approach to meet this requirement is to use descriptive logic-based ontologies. We used the approach and definition given by Thomas Gruber [6] to get an ontology which has to be specified as clearly as possible, all concepts being possibly defined axiomatically. So, the main constraints under the building of the ontology are to use only explicit assumptions, excluding any implicit behavior of the system in order to provide a full and clean model usable by the inferential services we planed to use. Technically speaking, our UML metamodel was translated into an OWL-DL ontology. In comparison with OWL-Full or OWL-Lite (subsets of the same language), OWL-DL offers large expressivity possibilities and is the only one which ensures computational completeness and decidability: it is fully usable by computers program. 3.2 Crisis Metamodeling

This part presents the crisis metamodel the authors point to use in order to build the ISyCri ontology presented previously. This metamodel has been built on the basis of the capitalized knowledge about several studied crisis (especially civil and humanitarian crisis) and about risk management [7]. We choose UML language to design this metamodel. This is the first stabilized version. The way of building the ontology from the UML metal-model derivates from [8]. By this way, we ensure not to lose any information nor relation from the UML description. The structures of the ontologies are based on the UML metamodel where each UML class becomes an OWL class. In the same way, UML relationships between classes are OWL properties. The original metamodel was split into two separate parts. The first one describes crisis while the second one is focused on the resolution process. This approach eases the maintenance of the whole system, allowing the replacement of the resolution process ontology. The proposed metamodel may be cut in three main parts (which cover the four parts of the ISyCri ontology presented in Fig. 2 of part 3.1,): the studied system (corresponding to the studied system ontology), the crisis characterization (corresponding to the crisis characterization ontology) and the treatment system (corresponding to the response ontology, that is to say, the treatment system ontology and the collaborative process ontology).


589

Fig. 3. A proposal for crisis metamodel.

x

The studied system: The studied system is defined as the sub-part of the world affected by the crisis. The components of this subsystem have been grouped in different categories such as goods, natural site, people and civil society. All those elements are considered as studied system components which can be concerned by the situation. Goods can be seen as each man-made entities (roads, bridges, buildings, houses, etc.). On the opposite, natural sites are the elements of the studied system which are not man-made, such as rivers, forests, etc. People concerns all the group of persons which are threatened by the crisis situation (people of a city, group of travelers, employees of a company, etc.). Civil society includes legal entities (media, intellectuals, etc.), associations and organizations which act in the crisis area.

x

The studied system contains also risks and dangers. A danger exists continually (on the studied system) and one or several risk(s) may concretize the exposure to this danger. For instance, an area like US WestCoast presents a danger of seismic instability while an earthquake occurrence is a risk attached to this danger. The crisis characterization:

590


x

Crisis includes several elements: some (dynamic) are involved in its occurrence or its evolution while some others (static) are dedicated to its description. Crisis occurs due to one (or several) trigger(s) and, once appeared, is composed with three main components: (i) effect(s), (ii) complexity factor(s) and (iii) gravity factor(s). A trigger is a kind of event which starts the crisis. It is the realization of a risk. An Effect is the noticeable consequence of the studied crisis. It is also considered as an event and can produce other effects. It can be evaluated through indicators. A complexity factor is a danger which impacts directly the nature of the crisis and can affect its type (for instance, a sanitary crisis may evolve into a social crisis due to the “over-communication” through media). A gravity factor is a danger which impacts directly the gravity of the crisis (for instance, a strong wind and a dry weather could affect the gravity of a fire in a forest). The treatment system (including collaborative processes): In order to solve (or at least to reduce) the crisis situation, it is necessary to define a treatment system which aims to drive the situation to a stable and handled state. This treatment system includes actors (institutions or not, on the site or not), their resources, the services they provide, their procedures, their ISs, the MIS (named Collaborative IS on Fig. 4) and the collaborative process it should run. The bottom part of this package is dedicated to collaborative process description (it includes elements of process modeling) and is directly inspired from a metamodel of collaborative process described in [5].

4 Instantiation of an Example In order to test the metamodel, we propose to instantiate it on a specific case of study: a NRBC exercise (27th of February 2004) managed by the Prefecture du Tarn 26 in France. 4.1 Brief Description of the Studied Case

The played scenario is the following: “At 10 AM, the 27th February 2004, the police is informed of an accident between a tanker truck (unknown substance) and a wagon containing chemical products (materializing a cloud). The sent policemen and the around employees of the railway station fall unconscious while several children of the near kindergarten (outside when the accident happened) feel sick.”.

26 Prefecture du Tarn is a French institution in charge of representing the government authority on a local scale (they are among one hundred of prefectures in France).


591

4.2 Model of the Case of Study Using the Crisis Metamodel

We used GME (Generic Modeling Environment, 2005) to describe and store the crisis metamodel. This software tool allows us to describe a model relating to the designed metamodel (with specially chosen graphical icons). The following pictures (Fig. 4 and Fig. 5) present the packages studied system and crisis characterization of the instantiated model of NRBC crisis.

Fig. 4. Studied system

This part of the model contains three natural sites: the Tran river, the ground, and the local atmosphere. It contains also five goods: the railway station, the kindergarten, buildings and houses, the truck and the train. There are four kind of people: people of the city of Marssac, people of the railway station (travelers and employees), children of the school and their parents. Parents are also the civil society. Finally there is one main danger which is area of hazardous material transport and three identified risks associated: explosion, contamination, and panic.

592


Fig. 5. Crisis characterization

As for the crisis characterization, there is one crisis: NRBC_27_02_2004, one trigger: accident between the truck and the wagon, one factor of gravity: the fact that the truck is carrying a tank with unknown substance and two effects: a cloud of escaping chemical products and several sick people (policemen, employees of the station and children). This kind of obtained model can be seen as the basic result showing how the ISyCri ontology instantiation will be performed. According to Vatcharaphun Rajsiri works (see [3]), the main principle is to find a particularly strong links between components of the first ontology (crisis ontology in our case) and the second ontology (response ontology in our case). Then this “bridge” can be use to start the deduction mechanism. For instance, in Mrs. Rajsiri works (concerning ontology of industrial collaborations in order to deduce industrial collaborative process) a strong link exists between objectives of the collaboration and business services provided by partners. Defining needed business services from the expected objectives allow the inference procedure to instantiate a lot of complementary elements of the expected collaborative process. Similarly, in our crisis context, there are strong links between effects and services or risks and procedure, etc. It is this kind of transverse connections which could permit the fulfilling of the collaborative process part of the ontology (exactly as shown in [3] or as exposed in works on strategic alignment such as [9]). Furthermore, the crisis characterization should be an iterative activity (in order to complete the representation and to follow the crisis evolution). It is so necessary to include a friendly-user requirement for the characterization method (and the illustration tool which will be prototyped). This aspect is a crucial point of the remainder of the project due to the essential will of flexibility of the approach. The iterative aspect of crisis modeling is one component of this expected flexibility.

5 Future work As shown before, the use of semantical links between the two ontology (crisis ontology and response ontology) is the first step of MIS determination. So the next


593

step consists in determining these semantical links. For that, the authors use real situations : one situation of a civil crisis (NRBC exercise), one situation of a humanitarian disaster (earthquake of Yogyakarta, and one situation of a terrorist attack. Through the study of these examples, the authors try to determine the deduction rules between the crisis characterization and the collaborative process. This step is based on similar works on collaborative process deduction from industrial situation characterization (see [3]). Once these semantical links known, the largest part of work will be to bring flexibility into the MIS process engine.

6 Conclusion This article presents the French ISyCri project, its contents, its objectives and its first orientations. ISyCri deals with the topic of integration of partners trying to solve a critical situation. This integration matter is tackled through the angle of ISs interoperability. The project propose to include a mediator (MIS for Mediation Information System) between partners in order to support the required interoperability functions (such as data transmission, application management and collaborative process orchestration). ISyCri finally aims to provide a design method of this MIS. It is noticeable that this project is structured with three main parts: (i) crisis characterization and deduction of collaborative process through ontology mechanism, (ii) study of the technical architecture of the mediation information system and (iii) study and experiment on flexibility of the MIS (should the MIS be re-designed when the crisis changes? Should it be adaptable?). It is obvious that in a crisis context, the notion of adaptability or flexibility of the MIS is an unavoidable requirement. The real question is “how to include flexibility and eventual loops of evolution in the MIS design method?”. The answer to this question is a crucial issue of the project and a PhD have been started on this topic. It seems that ontology and the associated deducing process offers a strong basis to challenge this question. Indeed, the authors believe that maintaining a relevant situation model among the duration of the crisis can be the first step to global flexibility. Upholding a right vision of the situation is necessary to maintain the right support for its resolution. The metamodel presented in this article is the first result of this task.

References [1]

[2]

Bénaben F., Pignon J.-P., Hanachi C., Lorré J.-P., Chapurlat V.: Interopérabilité des systèmes en situation de crise, WISG’07, ANR & DGA Interdisciplinary Workshop on Global Security, Troyes, France. (2007). Konstantas D., Bourrières J.-P., Léonard M. and Boudjlida N.: Preface of Interoperability of enterprise software and applications. proceedings of INTEROPESA’05, Geneva. Springer-Verlag; p. v-vi. (2005).

594


[3]

Rajsiri V., Lorré J.-P., Bénaben F. and Pingaud H.: Cartography for designing collaborative processes. Proceedings of INTEROP-ESA’07, Madeira. SpringerVerlag; p.257-261. (2007). Rajsiri V., Lorré J.-P., Bénaben F. and Pingaud H.: Cartography based methodology for collaborative process definition, Establishing the Foundation of Collaborative Networks. Proceedings of Pro-VE’07, Guimaraes. Springer, pp. 479-486. (2007). Touzi J., Bénaben F., Lorré J.-P. and Pingaud H.: A Service Oriented Architecture approach for collaborative information system design. Proceedings of IESM’07, BeiJing. (2007). Gruber T. : Toward principles for the design of ontologies used for knowledge sharing. In : International Workshop on Formal Ontology, Padova. (1993). Gourc D., HDR Gasevic D., Djuric D., Devedzic V., Damjanovic V.: Converting UML to OWL ontologies. Proceedings of the 13th International World Wide Web Conference, NewYork. (2004). Ralyté J., et al.: State of the Art: Exploration of Methods and Method Engineering Approaches. Deliverable DTG 6.1 of InterOp NoE. (2005).

[4]

[5]

[6] [7] [8]

[9]

A Novel Pattern for Complex Event Processing in RFID Applications Tao Ku11,2, Yun Long Zhu1, Kun Yuan Hu1 and Ci Xing Lv1 1

2

Shenyang Institute of Automation of Chinese Academy of Sciences, 110016, Shenyang, China {kutao, ylzhu, hukunyuan, smale}@sia.cn Graduate University of the Chinese Academy of Sciences, 100039, Beijing, China

Abstract. This study investigates Complex Event Processing (CEP) Pattern on RadioFrequency Identification (RFID) applications. RFID technolgy has brought tremendous benefits for the business by incorporating RFID data into supply chain planning and business processing, however, this progress has also raised important problems for RFID data processing. How to mine the signification information from RFID events is a challenge in RFID applications. In this paper, we take an CEP Pattern-oriented approach to process RFID data. A novel event pattern based on semantics operator is proposed. A formalization event hierarchy is used to model complex event with the event ontology, and provides abstract hierarchical views allowing us to view the system activities at different levels. Several complex event patterns are proposed based on semantic event operators. An algorithm is performed to test reorganization performance of patterns, a rule-based method is used to recognize efficiently on primitive event and composite event. The results showed that the advantage of the proposed complex event pattern approach is remarkable. It is concluded that the method of CEP pattern can simplify and improve RFID application. Keywords: Formal approaches and formal models of interoperability, Formal approaches to interoperability

1 Introduction Over the past few years, a great deal of attention has been driven towards RFID applications. RFID technology can store and retrieve remotely the unique scanner codes contained within the specialized RFID tags by means of electromagnetic radiation. Advances in the field of RFID have brought tremendous benefits for the business and industry, especially in incorporating RFID data into supply chain planning and business processes. This progress has also raised important data processing problems [5]. One of the most important aspects is how to deal with

596

Tao Ku1, Yun Long Zhu, Kun Yuan Hu and Ci Xing Lv

RFID data in the form of continuous and potentially infinite streams. There are quite a few academic projects involved in the research of Data Stream Processing (DSP), related projects include the STREAM [17] project, the Tapestry [18], the Telegraph [19], and the Aurora [10] et al. Most of these systems provide the novel algorithms by using synopsis structures to support filter and aggregation on data streams. However, there are few communications on the effect of the semantic and context information contained in the RFID event streams [8] flowing through all of the layers of the enterprise systems, and how to discover the signification information and act upon in real time in terms of the RFID events impacting on high level management goals and business processes. It has proved that data streams processing can not satisfy the requirements for enterprise in real time. Recently, Complex Event Processing (CEP) [1, 2, 21] has received a lot of attention that facilitates RFID events processing. CEP is an emerging technology for building and managing information systems. A major application of CEP is Business Event Management (BEM) in the event-driven real time enterprise. CEP events are created by filtering real-time data and infusing it with defining detail such as timing, or causal relationships discovered by correlating other events. Especially, it has been undertaken to integrate CEP into RFID data processing, such as, in [11] several formal specifications and semantics operators of RFID events are introduced. In [13] complex event language and workflow models are introduced, and to match complex event pattern for RFID. In [14, 15, 16] present Middleware with CEP infrastructure for processing RFID data. However, a great deal of efforts only was focused on raw RFID data processing, such as the elimination of duplicated data and the aggregation of data. In spite of the potential importance of RFID data processing with CEP, the following questions need to be answered: (1) what kinds of complex event patterns are requisite for RFID applications; (2) how to design the pattern and pattern reorganization algorithm; (3) how to map the lower level events into the high level business processing logic. The goal of this paper is to improve the ability of RFID data processing and trigger high-level business logic by applying complex event pattern. To test specifically the ability of complex event patterns for RFID application, we firstly classify the RFID events as hierarchical events by event ontology and propose a formal CEP pattern specification based on pattern operators. This paper presents an algorithm done to test the effects of complex event pattern recognition. The performance comparisons to show the advantages of the proposed CEP approach through simulation studies. The paper is organized as follows: we first give a formal definition of hierarchical RFID events in section 2, the complex event pattern and recognition algorithms are discussed in section 3, and analysis the proposed algorithm performances, followed by conclusions in section 4.

2 The Event Hierarchy In this section, we will formalize the semantics and specification for RFID events. In particular, we will discuss RFID event hierarchies, which is an abstraction hierarchy allowing us to view the system's activities at different levels. And it lets

A Novel Pattern for Complex Event Processing in RFID Applications

597

us focus on what we want to think about. For examples, RFID product and package events are produced by the reader at the different locations on the package production line, which is an object recording of an activity. We do not have to think low-level read and write events at the same time as we think about high-level operations, such as stock in and stock out. To build hierarchical events we must first define RFID event model [9]. As Figure 1 shows that we view RFID event model as being a hierarchical constructer. All read and write events are viewed as a primitive event level; the relationships between events are viewed as complex event level, which include timing, distance relationship et al. The events with the business context are viewed as application event level, which provides real-world business information as context and applies rules to trigger business logic processing. The each of level provides precise definitions of the structure of the event data. An example of event data is described follow: Primitive event level: “At some time, RFID Tag X was observed at some Location”. Complex event level: “At some time, items were put in pallets X at Location L distribution center located at Street/town/country”. Application event level: “a Purchase Order P contains a list of the ordered items”. Below we give the formal definition of hierarchical event. Application Event Level Pattern Abstract Complex Event Level Pattern Abstract Primitive Event Level Fig. 1. A three-level hierarchy for viewing RFID event

2.1 Formalization Basic Events

An event is a record of some occurrence in the physical world. Each event explicitly as part of its data or implicitly as part of its interpretation rule has a type that indicates what happened, and schematized data that describes the details. Events can be extracted from RFID and activities, or any information that users and systems are interested in can be defined as an event. In this section, we will formalize the semantics and specification for RFID basic events [20]. Definition 1. Let Event be an (m+1) tuple E (a1 ,...a m , t ) , let R { A1 ,.... Am } be a set of event attributes with domains Dom( A1 ),....Dom( Am ) . Then an event instance

598


is e where ai Dom( Ai ) and t is a real number, the occurrence time of the event. Let S be an event sequence is a collection of events over R {T } , where the domain of the attribute T is the set of real numbers IR . The events in the event sequence are ranged in an ascending order by their occurrence times. Example 1. RFID readers produce large amounts of tag events. A tag event is generated by a reader when it has detected some RFID tags. Such a tag event flow can be viewed as an event sequence. Each tag event has several attributes like reader ID and Tag ID, indicating logic location that sent the tag event, and the content of the tag event, respectively. A tag event also has a type and an occurrence time associated with it. An example of a real tag event is:

(id, tag-type, reader-id, tag-id, time)

(1)

Definition 2. Let the set of H be a set of event types. Then, An event is a pair (e, t ) where is e H an event type and t IR is the occurrence time of the event. An event sequence S is then an ordered collection of events, i.e. S e1 , t1 !, e 2 , t 2 !,... en , t n !!

Where ei H for all i

(2)

1,...n and t i d t i 1 for all i 1,...n 1 . The length of the

sequence S is denoted by S

n . A sequence that only consists of event types in

temporal order, i.e. ST e1 ,e2 ,...en ! , where ei H for all i 1,...n , ST is called an event type sequence. And event type is denoted by an empty event sequence, or an empty event type sequence is denoted by ! . Example 2. Let H A, B, C , D, E , F ! be the set of possible event types. Formally, an example of an event sequence consisting of events of types e H can be expressed as S A,201 !, B,22 !,... E ,40 !, F ,55 !!

(3)

An event type sequence corresponding to this event sequence is: ST A, B ,...E , F !

(4)

Real-life event sequences are often extremely long, and they are difficult to analyze as such. Therefore, we need a way of selecting shorter sequences suitable for our purposes. This leads us to the definition of an event subsequence. Definition 3. Let S be an event sequence and ST an event type sequence over a set H of event types. A Boolean expression T on event types and/or occurrence times of events is called a selection condition on events of a sequence. An event subsequence of the sequence S is an event sequence that satisfies T , the condition T can contain restrictions on event types, occurrence times of the events, or both of them i.e.


S (T ) (ei , t i ) | (ei , t i ) S satisfy (T ) !

599

(5)

An event type subsequence can either be an event type sequence that satisfies T in the event sequence S , i.e.: ST ( T ) ei | ( ei ,t i ) S satisfy( T ) !

(6)

Or an event type sequence that satisfies T , in the event sequence S , i.e.: S ( T ) ei | ( ei ST satisfy( T ) !

(7)

Example 3. Consider a sequence of the events of type A., for example, this is S ( ei

A) A,30 !, A,50 !, A,60 !!

(8)

2.2 RFID Event Ontology

The Event ontology deals with the notion of reified events. It defines one main Event concept [22]. An event may have a location, a time, factors and name, with the addition of sub-events to represent information about complex events in a structured and non-ambiguous way, as depicted figure 2. RFID Event Ontologies build hierarchy of events by providing a formal description of the kinds of inheritance relatonships and how they are related. We can use terms defined in RFID Event ontologies to describe the high-level event patterns. Such hierarchies are needed, for example, an RFID-tagged pallet may contain a number of RFIDtagged cases, each of which may contain a number of RFID-tagged items. Hierarchical events are typically necessary to model such containment directly. In the following discussion, we will formalize hierarchical event.

600


sub_event NamedEntity

factor

name Event

time

location LocationlEntity subclassOf

FactorEntity TemporalEntity

subclassOf subclassOf

RFID Event

RFID Primitive Event

RFID Composite Event

expand RFID Simple Event

RFID Complex Event

collapse

composedBy

ControlConstructor has

Sequence

has Causal

Temporal

Fig. 2. RFID Event ontology. The dotted lines indicate subclass relationships, while the real lines represent relationship of aggregation and association between classes.

Definition Primitive Event. Given a set of event types and a class of all possible sequences over , a primitive event is defined as: Pr

{S i| ei ,t i ! S i ,|S i| 1, distance (pr) 0, t i z 0}

For each event p Pr , let dom( pe) denote the domain from which the values of p are taken. The distance(pe) returns the distance between event instance p . Definition Composite Event. Given a set of event types and a class of all possible sequences over , a compose event is defined as: Ce {S i u S j o IR | e, t ! S i u S j , | SI | z 1, interval (ei ,e j ) z 0}

Which are composed of primitive events or other composite events by applying several event operators, for example, S i S j , S i S j , and S i S j can be represented as a composite event. The interval(ei ,e j ) returns the interval between two event instances ei and e j . The size of such a composite event, i.e., the number of event instances in such a set, is denoted by | SI | . Informally, an instance of a composite event represents the primitive event occurrences that caused an occurrence of the composite events. Occurrences of primitive events are at a specific point, which are assumed to be atomic. The primitive event can be are classified into domain event, explicit event and temporal event. Domain events are specific to application domain. Explicit event are explicitly defined by an application and raised by the user. The


601

parameters of the explicit event are also specified by the user. Temporal events correspond to absolute and relative temporal events. The absolute temporal event is an event associated with an absolute value of time.

3 Complex Event Pattern In this section we will discuss complex event pattern based on hierarchical event. An event pattern is a template that matches partially ordered sets of events. The event pattern of a rule defines the types of events whose occurrence may trigger the rule, and its expressions can consist of filter expressions combined with pattern operators. Unlike a message, the important part of the semantics of an event is temporal and no-temporal relationship-what the orders will happen among constituent events with or without temporal constraint, causality–what events caused this to occur and what will be the consequences of the current event. In the following discussion, we will describe fundamental complex event patterns. 3.1 Complex Event Pattern Definitions

The CEP event pattern language allows the user to describe patterns of events. However, the current pattern language has revealed weaknesses of design in semantic appropriateness and completeness of certain event operators [3,4]. In this section, we will formalize complex event pattern with novel operators for improving the pattern semantics. Definition 1. Pattern Operators: The operators can be used to specify patterns, flowing, we define the basic operators: 1. 2. 3. 4. 5. 6.

“ each ” to mean “*”, which used to control pattern sub-expression repetition. “ o ” to mean “followed by”, which is a temporal operator that operated on event order: “ && ” to mean “And”, which is logic operator. “ || ” to mean “OR”, which is logic operator. “ ! ” to mean “Not”, which is logic operator that “ time : within, time : interval , and time : at ”: which are temporal operators

that used to control the lifecycle of sub-expressions. Definition 2. Relationship Pattern: Let E A a1 , a 2 ,...t a ! be an A event, let E B b1 , b2 ,...t b ! be a B event, let t be a real number for the occurrence time of the event. A relationship pattern i.e.:

1.

E A * o E B : This pattern matches when every event A followed by an event B .

602


E A * o E B * : This pattern matches when every event A followed by every event B . 3. E A & & E B : This pattern matches when event A and event B are found. 4. E A || E B : Look for either event A or event B .

2.

E A o E B & & EC o E D : This pattern matches on any sequence A followed by B and C followed by D . 6. (E A o E B ) & & ! EC : This pattern matches only when an event A is encountered followed by event B but only if no event C was encountered. 7. E A o E B where time : intevel (ms ) : This pattern matches if an event A arrives followed by event B within ms seconds.

5.

Definition 3. Filter Pattern: This pattern subscribes to event sequence, evaluates a specified logical condition based on event attributes, and, if the condition is true, publishes the event to the destination event sequence, i.e.: (E A (a i ) || E A (a j ) ) * o (E B && ! E B (b i

a i || bi

a j ))* where timer:with in (ms) a or a

j This pattern fires after every A event with the i attribute arrived, and bi ms B seconds where the attribute of B is not same as followed by event wait of A .

Definition 4. Type-Based Filtering Pattern: We can filter duplicate RFID data Based on Type of events. If E A and E B are observed within ms seconds, and E A # E B , then mark E A as a duplicate event. if ((E A (a i ) o E B (b i ) where timer:with in (ms) ) & & ( i

1 ... m , a i

bi ) )

E A # E B E A is a duplicate event

Definition 5. Content-Based Filtering Pattern: We can express theft event based on events content filtering, let E A be represented item read event, let E B be represented administer event, then: if ( (E A (a i ) o ! E B (b i ) timer:with in (ms) ) & & a i E A theftby E B

item & & b i

ad min ister )

Definition 6. Map Pattern: This pattern would involve causal relationship, aggregation relationship, and temporal relationship. i.e.: let EC be represented a virtual event that caused by E A and E B , ( E A & & E B ) o EC Example. RFID package event: If a time distance-constrained periodic event E A is observed followed by a distinct event E B , then it implies that objects produced by E A are being packed in the object produced by E B . if ((E A (a i ) * o E B (b i ) where timer:with in (ms) ) & & ( i E A, EB , E A % EB

1 ... m , a i z bi ) )


603

3.2 RFID Application Scenarios

One example of a RFID application environment is the production line automation, a RFID readers-rich environment inside our test laboratory (Fig.3). In this laboratory, RFID readers that are installed on both sides of the conveyor belt and multi-layer shelves provide information about productions. The simulation environment is used to keep track of every individual product, the stage of the production process, and how many packages are leaving the warehouse, et.al. The readers potentially produce a vast amount of data. However, information consumers prefer a high-level view of the primitive sensor data. Thus, the CEP used in this application scenario has to cope with high-volume data and be able to aggregate and transform it before dissemination. Composite event detection can help process the primitive events produced by the large number of sensors and provide a higher-level abstraction to users.

A

RFID Antenna 1

B

RFID Antenna 2

C

LED Monitor 1

D

LED Monitor 2

E

Multilayer Shelf

F

Shelf Antenna

G

Conveying belt

Fig. 3. The Production Line with multi-readers

1.

A user may subscribe to be notified when products are packaged in some type pallet, or products are removed from shelves. 2. A user may be interested in composite events about what products come from what batch the pallet originated. 3.3 Complex Event Pattern Recognition

In this section, we will discuss the methods for recognition of complex event patterns. There are many algorithms proposed for complex event detection [6, 7]. Traditional graph-based event processing systems detect complex events in a bottom-up fashion shown as Figure 4, it uses an event graph to detect composite events .Each node in the event tree represents either a primitive event or a composite event. Primitive event nodes are leaf nodes from which composite event nodes are constructed.

604


Time

Pattern Rules Pattern detection

Complex Event Event Primitive event node

Composite event node

Fig. 4. Complex Event Pattern Recognition Framework

However, such a bottom-up event detection approach is inapplicable to detecting RFID events. We improve algorithm performance by grouping rules into sets and a link list data structure is also used to group together a set of logically related events and rules. The proposed algorithm is show as Figure 5. Algorithm: Graph-based complex even pattern recognition. Input: D, a primitive event set; R, a rule set. P, a pattern set. Output S k , the complex event subsequences set. Method: S1 Å Single-elements in the event sequence S e1 ,t1 ! ,... en ,t n !! P1 Å Single-elements in the pattern sequence P p1 ,... p n ! Call Graph (D, R, S k , Pk ) Procedure Graph (D, R, S k , Pk ) (1) S k m ) Read from event sequences (2) Pk m ) Read from the set of patterns (3) for each primitive event d i Dk do (4) for each pattern element p j Pk do (5) (6) (7)

for each size (k+1) graph g formed by the merge of d i if g R and g Pj then Build event hierarchy


605

(8) else Insert g into S k 1 ; (9) If S k 1 z ) then (10) Graph (D,R, S k 1 , Pk 1 ); (11) return; Fig. 5. Complex Event Pattern Recognition Algorithm

3.4 Algorithm Performance Analysis

The algorithm tests were made on a PC with 1.4GMHz Pentium IV processor, running Window 2003 as the operating system with 1 GB of RAM. In our experiment, the prototype is implemented in Java language, there are 50 event types were defined representing primitive or simple events, and there are 100 rules implemented using the Rule Definition Language were defined. The rules incorporate different complexities in their definition, such as event expressions with simple, composite and event set constructions; and the use of different operators in conditions expressions. Also, every rule produces one or more events. 200

2400

160 140

2000

120

Event

time (s)

Our method Traditional method

2800

Our method Traditional method

180

100

1600

80

1200

60

800

40

400 20

0

0 0

1000

2000

3000

4000

5000

6000

Primitive Event

Fig. 6. Comprision Event processing Time

0

2

4

6

8

10

Algorithm

Fig. 7. Amount of events produced in algorithm evaluation

In figure 6 presents the comparison of event processing time that taken to perform the evaluation of primitive event. The horizontal axis corresponds to the quantity of primitive events processed, and the vertical axis corresponds to the amount of time (in seconds) taken in the evaluation of the events In general, our method is better than traditional method in terms of capabilities of event processing because of our elaborated data structures and optimization strategies. In figure 7 the amount of events produced in the evaluation of each set of algorithms implemented in our method and traditional implementation, through simulation studies, it is proved that as the number of events produced increases, the growth

606


rate in event production has an exponential tendency, and the algorithm execution time tends to grow linearly.

4 Conclusions In this paper, a novel semantic-based complex event processing pattern is discussed in detail by formalizing event ontology and event pattern. The performance evaluation on pattern recognition shows that event pattern processing has the capabilities to react to the occurrence of some complex event pattern rather than a single event. It can be concluded that leveraging CEP in RFID applications can bring more sophisticated application functionality; therefore, we believe that CEP technology can provide a robust infrastructure layer to simplify RFID application deployment and scaling. Future work can be in the area of CEP query optimization techniques.

Acknowledgments This work was supported by the Hi-Tech research and development program of China under contract No. (20060104A1118), National Science and Technology Key Project of China under contract No. (2006BAH02A09), National Natural Science Foundation Key Project of China under contract No. (2002CB312204)

References [1] [2]

[3] [4] [5]

[6]

[7]

Louis Perrochon, E.J., Stephane Kasriel, and David C. Luckham, Enlisting Event Patterns for Cyber Battlefield Awareness. 2006.. Shyh-Kwei Chen, J.-J.J., Henry Chang. Complex Event Processing using Simple Rule-based Event Correlation Engines for Business Performance Management. in Proceedings of the 8th IEEE International Conference on E-Commerce Technology on Enterprise Computing, E-Commerce, and E-Services. 2006. Y. Bai, F. Wang, and P. Liu: Efficiently Filtering RFID Data Streams. To Appear in Proc. of the First International VLDB Workshop on Clean Databases (CleanDB'06). J. L. David Maier1, Peter Tucker2, Kristin Tufte1, and Vassilis Papadimos1, "Semantics of Data Streams and Operators," 2005. F. W. a. P. L. Shaorong Liu "Integrated RFID Data Modeling: An Approach for Querying Physical Objects in Pervasive Computing," in CIKM’06, November 5–11, 2006, Arlington, Virginia, USA. 2006. S. Chakravarthy, J. D. Yang, and S. Yang, “A formal framework for computing composite events over histories and logs,” University of Florida, E470-CSE, Gainesville, FL 32611, Tech. Rep. UF-CIS TR-98-017, November 1998. S. Chakravarthy, V. Krishnaprasad, E. Anwar, and S.-K. Kim, “Composite Events for Active Databases: Semantics, Contexts, and Detection,” in 20th International Conference on Very Large Databases (VLDB), 1994, pp. 606–617.


[8]

[9]

[10] [11]

[12]

[13]

[14]

[15]

[16]

[17]

[18] [19]

[20]

[21] [22]

607

Q. Jiang, R. Adaikkalavan, and S. Chakravarthy, “Towards an Integrated Model for Event and Stream Processing,” TR CSE-2004-10, CSE Dept, Univ. of Texas at Arlington, 2004. Roger S. Barga, Jonathan Goldstein, Mohamed Ali and Mingsheng Hon”Consistent Streaming Through Time: A Vision for Event Stream Processing”, Microsoft Research Redmond, WA, 3rd Biennial Conference on Innovative Data Systems Research (CIDR) January 7-10, 2007, Asilomar, California, USA. D.J.Abadi, D, Carney, U. Cetintemel, et al. Aurora: A New Model and Architecture for Data Stream Management. VLDB Journal, 12(2):120-139, 2003 Wang, F., Liu, S., Liu, P., Bai, Y.: Bridging Physical and Virtual World: Complex Event Processing for RFID data Streams. In: Proc. of the 10th International Conference on Extending Database Technology, Munich Germany (2006) Daniel Gyllstrom, Eugene Wu, et al, SASE: Complex Event Processing over Streams. In Proceedings of the Third Biennial Conference on Innovative Data Systems Research (CIDR 2007), Asilomar, CA, January 2007. C. Zang, Y. Fan, Complex event processing in enterprise information systems based on RFID, Enterprise Information Systems, Volume 1, Issue 1 February 2007 , pages 3-23 Liang Dong, Dong Wang, Huanye Sheng, Design of RFID Middleware Based on Complex Event Processing, in: Cybernetics and Intelligent Systems, 2006 IEEE Conference on, June 2006 On page(s): 1-6 Byung-Kook Son, Jun-Hwan Lee1, et al, An Efficient Method to Create Business Level Events Using Complex Event Processing Based on RFID Standards. In IFIP International Federation for Information Processing .2007 CHRISTOF B, TAO L, STEPHAN H, et al. Integrating smart items with business processes an experience report, In: Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS), 2005:227-235. Babcock B, Babu S, Datar M, Motwani R, Widom J, Models and issues in data streams. In: Popa L. ed. Proc, of the 21st ACM SIGACT-SIGMOD-SIGART Symp. On Principles of Database Systems. Madison: ACM Press, 2002. 1-16. Terr D, Goldberg D, Nichols D, Oki B. Continuous queries over append-only databases SIGMOD Record, 1992.21(2):321-330. Avnur R, Hellerstein J.Eddies: Continuously adaptive query processing In: Chen W, Naughton JF, Bernstein PA, eds. Proc. of the 2000 ACM SIGMOD Int’l Conf. on Management of Data Dalias: ACM Press.2000.261-272. P. Ronkainen. Attribute similarity and event sequence similarity in data mining. PhLic thesis, Report C-1998-42, University of Helsinki, Department of Computer Science, Helsinki, Finland, Oct. 1998 David C. Luckham, The power of events: an introduction to complex event processing in distributed enterprise systems [M].Boston: Addison Wesley, 2002. Zhen Liu, Anand Ranganathan, Anton Riabov. Specifying and Enforcing High-Level Semantic Obligation Policies. Eighth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'07) pp.119-128

Part VII

Architectures and Frameworks for Interoperability

Enterprise Architecture: A Service Interoperability Analysis Framework J. Ullberg, R. Lagerström, P. Johnson Industrial Information & Control Systems, KTH Royal Institute of Technology, Osquldas väg 12, SE-100 44 Stockholm, Sweden {johanu, robertl, pj101}@ics.kth.se

Abstract. Enterprise architecture is a model-based approach to IT management used for promotion of good IT decision making. Thus, an enterprise architecture framework needs to support various forms of analysis. Creation of enterprise architecture models is costly and without intrinsic value, therefore it is desirable to create models that effectively support the sought after analysis. This paper presents an extended influence diagram describing theory of enterprise service interoperability. The theory is augmented with a metamodel containing the information needed to perform analysis of interoperability. A fictional example is provided to illustrate the employment of the metamodel and the theory in the context of IT decision making. Keywords: Measuring, validating, and verifying interoperability, Enterprise modeling for interoperability, Modelling methods, tools and frameworks for (networked) enterprises, Formal approaches and formal models of interoperability, Enterprise applications analysis and semantic elicitation

1 Introduction Enterprise architecture is an approach to enterprise information systems management that relies on models of the information systems and their environment. Instead of building the enterprise information system using trial and error, a set of models is proposed to predict the behavior and effects of changes to the system. The enterprise architecture models allow reasoning about the consequences of various scenarios and thereby support decision making. In order to predict which enterprise architecture scenario is preferable, three things are needed. Firstly, models over the two scenarios need to be created. Secondly, it is necessary to define what is desirable; the goal, i.e. high service interoperability. Thirdly, we need to understand the causal chains from scenario choice to goal. Suppose that scenario A features services with high availability

612

J. Ullberg, R. Lagerström, P. Johnson

affecting the interoperability positively but has several service descriptions which are not complete, affecting the interoperability negatively. However, scenario B is built up on service orchestration descriptions of high compatibility with respect to the available services, promoting high interoperability of the system. To make a decision on which scenario to choose is often difficult, particularly without a formal analysis. In order to perform this kind of analysis, the enterprise architecture models need to contain the proper information. In the above example, where the decision maker is interested in service interoperability, the models need to answer questions regarding service availability, service description completeness, and service orchestration description compatibility. The kind of information contained in a model is given by its metamodel, so it is important that enterprise architecture metamodels are properly designed. In order to determine if a metamodel is amenable to the analysis of a certain quality attribute, such as interoperability, it would be helpful with a structured account of that analysis. We will use a notation called Extended Influence Diagrams (EID) [1] in order to formalize the analysis of interoperability. Figure 1 depicts the relation between an enterprise architecture scenario, modeled using a metamodel, the analysis of the scenario, the formal specification of the analysis through an extended influence diagram and finally the output: the interoperability level.

Fig. 1. The relation between metamodels, enterprise architecture scenarios, analysis, formal specification of analysis, and the result of the analysis

The main contribution of this paper is a metamodel that supports the creation of enterprise architecture models amenable to service interoperability analysis. Also introduced are formalizations of such an analysis using extended influence diagrams. The remainder of this paper is delineated as follows; extended influence diagrams are introduced in section 2. Section 3 presents the framework for service interoperability analysis in the form of an extended influence diagram. Section 4

Enterprise Architecture: A Service Interoperability Analysis Framework

613

evaluates the usefulness of a number of common enterprise architecture metamodels. Section 5 proceeds to detail the content of the metamodel that supports service interoperability analysis. The applicability of the metamodel is demonstrated in the subsequent section 6. Finally, section 7 concludes the paper.

2 Extended Influence Diagrams Extended influence diagrams are graphic representations of decision problems coupled with a probabilistic inference engine. These diagrams may be used to formally specify enterprise architecture analysis [1]. The diagrams are an extension of influence diagrams, [2][3] which in turn are an enhancement of Bayesian networks [4][5]. In extended influence diagrams, random variables associated with chance nodes may assume values, or states, from a finite domain (cf. Figure 2). A variable could for example be service availability. These variables are connected with each other through causal or definitional arcs. Causal arcs capture relations of the real world, such as “higher service availability increases the system interoperability”. With the help of a conditional probability matrix for a certain variable A and knowledge of the current states of the causally influencing variables B and C, it is possible to infer the likelihood of node A assuming any of its states. Extended influence diagrams support probabilistic inference in the same manner as Bayesian networks do; given the value of one node, the values of related nodes can be calculated. For more comprehensive treatments on influence diagrams and extended influence diagrams see [1], [2], [3], [4], [5], [6], [7] and [8].

Fig. 2. An extended influence diagram and a simple example. With a chosen scenario in the decision node, the chance nodes will assume different values, thereby influencing the utility node [9].

3 A Framework for Enterprise Service Interoperability Analysis This section presents an extended influence diagram that captures theory from the field of service interoperability. The extended influence diagram is mainly influenced by [10][11][12][13][14]. Interoperability is the ability of two or more systems or components to exchange information and to use that information [15]. Adopted to the domain of services, enterprise service interoperability is the ability of services in an enterprise to exchange information and to use that information. Enterprise Service

614


interoperability is divided into run-time enterprise service interoperability and design-time enterprise service interoperability, cf. Figure 3.

Fig. 3. The extended influence diagram for enterprise service interoperability containing factors influencing service interoperability and thereby of interest when performing analysis.

3.1 Run-Time Enterprise Service Interoperability

Run-time interoperability is concerned with the interoperability of services that in the scenario under evaluation are supposed to be working together. It is divided into three sub categories; firstly, there are properties that can be assessed within the scope of a single service, service run-time interoperability. Secondly, the quality of service pair interaction captures aspects that can be measured by pair-wise comparison of all service pairs supposed to interact. Finally, some properties must be analyzed in a wider scope than that of pairs, namely in the power set scope (excluding the empty set and the sets with only one member), this is denoted quality of interaction for power set 3.1.1 Service Run-Time Interoperability. The measurable properties of each service that are of importance at run time are the inherent properties of the service, cf. the node quality of service in Figure 3, service bus compatibility which is the service’s compatibility with the communication medium, the service bus and quality of service orchestration


615

description, consisting of properties relating to the orchestration descriptions, i.e. a specification detailing the interaction of services [11]. The node quality of service is defined by the nodes correctness and availability. Correctness is the ability of the service to perform the intended task correctly. Availability of a service can be measured in terms of mean time to failure and mean time to repair. From a run-time point of view there are three properties of the service orchestration description that need to be attended. The first is that the orchestration description calls the operations of the service in a syntactically correct manner, syntactic compatibility with respect to service. The second, behavioral semantic compatibility with respect to service, is the subject of the orchestration description’s ability to act in conformity with the dynamics of the service. Generally this means to call the operations of the service in a permissible order. Finally, the denotational semantic compatibility with respect to service is concerned with the real world, the orchestration description and the service are denotationally equivalent if they refer to the same phenomenon in the real world [16], so that the service really executes what the orchestration description intended. 3.1.2 Quality of Service Pair Interaction. When studying services in pairs there are two additional properties that can be assessed, namely protocol compatibility and syntactic compatibility. The first is a match of protocols so that the services share at least one compatible protocol. The latter is a comparison of the provided and invoked operations of the services, e.g. that the provided methods of the service provider must have the same syntax as the requests sent from the consumer for communication to be possible. 3.1.3 Quality of Interaction for Power Set. When studying even larger sets of services, two additional factors of importance can be added to the theory. Both factors are concerned with semantic compatibility and are similar to those of Section 3.1 regarding semantics. The first, behavioral semantic compatibility, captures the behavior of the interaction, two concepts (e.g. services) are equivalent with respect to their behavioral semantics if they display the same dynamics, i.e., if their interaction patterns are equivalent [16]. The second, denotational semantic compatibility is concerned with the actual meaning of the services’ operations, so that they refer to the same operation in the real world. 3.2 Design-Time Enterprise Service Interoperability

Design-time service interoperability is the matter of analyzing the effort needed for possible future constellations of services to interoperate, regardless of their current relationship to each other. Design-time interoperability is, as in the case of runtime interoperability, divided into three categories covering aspects of a single service, pairs of services and the power set of services, cf. the node service designtime interoperability as well as the previously mentioned quality of service pair interaction and quality of interaction for power set in Figure 3.

616


Different from run-time interoperability is however how these services, pairs, and sets are selected, rather than only regarding services that in the currently assessed scenario are supposed to work together, the focus now is on all services available in the enterprise as well as all pairs and sets of services that possibly could work together in some future scenario. As seen from Figure 3 the properties of concern for the pairs and the power set are the same as for run-time interoperability, see Section 3.1. 3.2.1 Service Design-Time Interoperability At design time two of the properties measurable per service are common with those of interest at run time, the service bus compatibility and the quality of service as described in Section 3.1. Other properties that are of interest at design time are quality of service description, covering aspects of the service descriptions, descriptions containing for instance the behavior and abilities of the service [17], and service orchestration language compatibility stating to which degree the service is compatible with available languages for service orchestration. Finally, the node existence in service description repository corresponds to a validation that the description of the service is placed in a repository, a storage area used for discovery of services [18]. The quality of the service description is divided into five parts where the first, completeness, considers the service description coverage, i.e. that all abilities of the service are included in its description. Understandability means that the description can be easily understood. The third, syntactic correctness¸ ensures that the service description is syntactic correct with respect to the actual operations of the service. Behavioral semantic correctness implies that the dynamics in the description corresponds to that of the service itself, and finally denotational semantic correctness which is the matter of the service description really describing the same action that the service performs.

4 Enterprise Architecture Frameworks for Analysis With the requirement on enterprise architecture models to support enterprise architecture analysis follows a specific requirement on enterprise architecture metamodels. Specifically, all entities and attributes that are required for a complete analysis as specified in an extended influence diagram must be found in the enterprise architecture metamodel, in order for the corresponding model to be amenable to analysis. See Figure 4. A substantial number of enterprise architecture frameworks have been proposed in recent years, including the Zachman Framework [19], the Department of Defense Architecture Framework (DoDAF) [20] the Open Group Architecture Framework (TOGAF) [21], the Federal Enterprise Architecture (FEA) [22], the General Enterprise Reference Architecture and Methodology (GERAM) [23], Architektur integrierter Informationssysteme (ARIS) [24], the Metis Enterprise Architecture Framework (MEAF) [25], and more. When considering the suitability of the metamodels related to these frameworks to the enterprise architecture analysis considered in preceding sections, we have found significant difficulties.


617

Firstly, a number of metamodels are not detailed enough to provide the information required for the analysis. We are interested in information such as for instance the complexity of a service. This is information that would typically be represented as an attribute in an entity in a metamodel. Many metamodels, including the Zachman Framework, the TOGAF and the GERAM, do not systematically propose attributes, thereby underspecifying their metamodels with respect to the analysis proposed in the previous section. The frameworks that do specify attributes, e.g. DoDAF, FEA, and MEAF, contain few of the specific attributes required for the analysis described in Section 3. Finally and perhaps most importantly, many of the frameworks do not contain the entities that would be required.

Fig. 4. The properties found in an extended influence diagram determine what entities and attributes should be present in an enterprise architecture metamodel.

5 The Metamodel for Enterprise Service Interoperability Analysis In this section, we present the metamodel suggested for enterprise service interoperability analysis. The metamodel is constructed to satisfy the requirements of the preceding section, containing all of the entities and attributes necessary to conduct analysis of interoperability. 5.1 Entities in the Metamodel

Services are independent building blocks that collectively represent an application environment, much like components of a software system. Services possess a number of qualities that components lack, e.g. the complete autonomy from other

618


services which allows a service to be responsible for its own domain and services are typically limited in their scope to support a specific business function or a group of related functions [10]. For communication among services, each service has a service interface. The service interface contains the protocols a service needs for communication and it specifies which operations the service provides or invokes [11][26]. Services also have service descriptions. These are used for advertising and describing the service capabilities, behavior, quality, and its interface [17]. An example of a service description language is WSDL (Web Service Definition Language). Services use a service bus, often referred to as an enterprise service bus (ESB), as a communication medium. The service bus is a middleware-like solution to manage message and transaction traffic [12]. As the amount of services and the number of versions of each service steadily increases it has become critical to keep track of the service descriptions. Thus, the need for a service description repository, i.e. a storage area containing all service descriptions and making the descriptions searchable. Each time a service requestor needs a service the requestor can find the most appropriate service for its intentions in the repository. A standard repository solution is the UDDI [18]. The service orchestration description is the specification that details and controls the orchestration of services to interact [11]. These descriptions are written in a service orchestration language, where BPEL (Business Process Execution Language) is considered an industry standard.

Fig. 5. The enterprise architecture metamodel for service interoperability analysis with its entities, attributes, and relations.


619

5.2 Attributes of the Metamodel

For the purpose of service interoperability analysis, a metamodel without attributes would be inadequate. In an enterprise architecture model, many important concepts are best captured as entity attributes. As seen in Figure 5, some entities have attributes that correspond to the service interoperability extended influence diagram. The availability of a service, for instance, is of importance for the interoperability (according to the extended influence diagram of Section 3). Consequently, the service entity of our model explicitly contains the attribute availability. Analogously, the service description entity contains the attribute completeness, also found as a node in the extended influence diagram. Other attributes in the metamodel directly related to nodes in the EID are service correctness and service description understandability. There are variables in the extended influence diagram not directly related to one attribute in the metamodel, e.g. service bus compatibility. This is represented in the metamodel by the attribute in service called compatible service buses and by the attribute type in the entity representing the service bus. If there is one compatible service bus in service that matches the service bus type, this means that the service and the service bus are compatible. Syntactic compatibility, protocol compatibility, and existence of service description in repository are other attributes evaluated in a similar manner. The values of two types of nodes in the extended influence diagram cannot be derived from the metamodel. These are the denotational and behavioral semantic compatibility and correctness nodes. It is well known that it is both practically and philosophically difficult to determine denotational equivalence. Although behavioral equivalence is possible to determine, it requires detailed dynamic models beyond the scope of the present work [16].

6 Modeling and Analyzing Using the Metamodel – An Example This section presents an example of an enterprise service interoperability analysis used as decision support for a Chief Information Officer (CIO) at LIAM Energy, a large power distribution company in Sweden. LIAM Energy has initiated an implementation of an Automatic Meter Reading (AMR) system. A pre-study revealed that a service-oriented solution would be the most appropriate and would provide the company with long-term business value. The CIO faces a choice between three suppliers of AMR software where no supplier is able to deliver all the wanted functionality, thus a combination is desirable. Our CIO will also face the task of integrating the meter reading system with the company’s existing service-oriented ERP system for billing purposes. This integration is needed because new regulations require distribution companies to keep track of outages and only bill their customers for actual electricity usage. Several possible scenarios must therefore be considered and the CIO decides that a formal evaluation of the candidate scenarios is to be performed. Based on the metamodel of Section 5 information on the entities and their attributes are

620


collected, see Figure 6 for one scenario containing three services from three different vendors. Some examples of information that is gathered are the semantic correctness of the service description and the provided and invoked operations of the service interfaces. To find information on for instance provided operations, the code of the services was studied while information on the availability of services was found by performing interviews with the developers of the service. All collected variable values were then translated into discrete states, such as Low, Medium, or High, and used as input to the enterprise service interoperability analysis employing Bayesian theory as described in Section 2. When collecting information for the models, there is an issue of credibility. Low credibility may lead to a large uncertainty in the analysis, making it difficult for the CIO to take a rational decision. For instance, studying the code to find the operations of the service is a tedious work but, if done well, this will provide the CIO with high credibility of the gathered information. Whereas, interviewing personnel, e.g. developers and architects, to find the availability of the service is less credible and also dependent on the experience of the personnel and the bias of the interviewer. Oftentimes it is very expensive to collect the information needed for a perfectly credible analysis. Since the analysis is based on the formalism of Extended Influence Diagrams this credibility variation can be handled, thus the presented method of analysis provides the CIO with an uncertainty degree in the result, shown in Figure 7 as bars indicating the range of values the result may assume.


621

Fig. 6. The enterprise architecture model of scenario A. In the model the service calculate energy cost has been enlarged to visualize its attribute values; correctness being High with 90 % certainty and availability being Medium with 80 % certainty.

The final result of the analysis is shown in Figure 7. As can be seen from the figure, scenario 2 didn’t achieve any service interoperability at all due to the choice of service bus with which only one of the services was compatible. Even though not detailed in this paper, the method allows for analysis of subcomponents and it is therefore possible to discover that scenario 3 has decent run-time interoperability but almost no design-time interoperability. Further, it is possible to see that scenario 1 and 4 both have near to perfect run-time interoperability and that scenario 4 scores a bit higher on design-time interoperability, yielding the higher total score. The CIO can now make a rational decision, choosing the set of services providing the degree of interoperability needed by the enterprise.

622


Fig. 7. The comparison between the service interoperability of the different scenarios, the black I-bars indicate the uncertainty of the assessments.

7 Conclusion This paper has presented an enterprise service interoperability analysis framework in the form of an extended influence diagram with attributes affecting service interoperability and an enterprise architecture metamodel supporting the analysis. The metamodel consists of entities with accompanying attributes that can be used to create enterprise architecture models from which it is possible to extract precisely the information that is needed for quantitative enterprise service interoperability analysis. An example was provided illustrating the use of the metamodel and the extended influence diagram for analysis.

Acknowledgements The authors would like to thank Per Närman for his previous work on the topic of system quality analysis using enterprise architecture models [27].

References [1]

[2]

[3]

[4]

Johnson, P., et al.: Enterprise Architecture Analysis with Extended Influence Diagrams. In: Information System Frontiers, vol 9(2), Springer, The Netherlands (2007) Shachter, R.: Evaluating influence diagrams. Operations Research, 34(6) pp 871-882, Institute for Operations Research and the Management Sciences, Hanover Maryland (1986) Howard, R.A., Matheson, J.E.: Influence Diagrams. Decision Analysis Vol. 2(3), pp. 127–143, Institute for Operations Research and the Management Sciences, Hanover Maryland (2005) Neapolitan, R.: Learning Bayesian Networks. Prentice-Hall, Inc. Upper Saddle River, NJ, USA (2003)


[5] [6]

[7] [8] [9]

[10] [11] [12] [13]

[14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26]

[27]

623

Jensen, F.V.: Bayesian Networks and Decision Graphs. Springer New York, Secaucus, NJ, USA (2001) Johnson, P., Lagerström, R., Närman, P.: Extended Influence Diagram Generation. In: Enterprise Interoperability II – New Challenges and Approaches, pp. 599-602, Springer, London (2007) Shachter, R.: Probabilistic inference and influence diagrams. Operations Research, 36(4), pp 36-40 (1988) Johnson, P., Ekstedt, M.: Enterprise Architecture – Models and Analyses for Information System Decision Making. Studentlitteratur, Lund, Sweden (2007) Lagerström, R.: Analyzing System Maintainability Using Enterprise Architecture Models. In: Proceedings of the 2nd Workshop on Trends in Enterprise Architecture Research (TEAR’07), pp. 31-39, St Gallen, Switzerland (2007) Erl, T.: Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Prentice Hall, New Jersey (2004) Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall, New Jersey (2005) Marks, E., Bell, M.: Service-Oriented Architecture: A Planning and Implementing Guide for Business and Technology. John Wiley & Sons, New Jersey (2006) Kasunic, M., Anderson, W.: Measuring Systems Interoperability: Challenges and Opportunities. Technical Note, CMU/SEI-2004-TN-003, Software Engineering Institute, Carnegie Mellon University, Pittsburgh (2004) Linthicum, D.: Enterprise Application Integration. Addison-Wesley, New Jersey (2000) IEEE: Standard Glossary of Software Engineering Terminology. Std 610.12-1990. The Institute of Electrical and Electronics Engineers, New York (1990) Saeed, J.: Semantics. Second Edition, Blackwell Publishing, Oxford, UK (2003) Papazoglou, M., Georgakopoulos, D.: Service-Oriented Computing. In: Communications of the ACM, Vol. 46 No. 10 (2003) Gottschalk, K., Graham, S., Kreger, H., Snell, J.: Introduction to Web services architecture. In: IBM Systems Journal, Vol. 41 No. 2 (2002) Zachman, J.A.: A Framework for Information Systems Architecture. IBM Systems Journal, IBM, vol 26(3), pp 454-470 (1987) Department of Defense Architecture Framework Working Group: DoD Architecture Framework, version 1.0. Department of Defense, USA (2004) The Open Group: The Open Group Architecture Framework, version 8 Enterprise Edition. Reading U.K. (2005), http://www.opengroup.org/togaf/ Office of Management and Budget: FEA Consolidated Reference Model Document Version 2.1. OMB, USA (2006) IFAC-IFIP: Task Force on Architectures for Enterprise Integration Geram: Generalized enterprise reference architecture and methodology, version 1.6. (1999) Scheer, A.W.: Business Process Engineering – Reference Models for Industrial Enterprises 2nd Edition. Springer Verlag, Heidelberg, Germany (1994) Troux Technologies: Metis Architect – Datasheet. http://www.troux.com (2007) Papazoglou, M.: Service-Oriented Computing: Concepts, Characteristics and Directions. In: Proceedings of the Fourth International Conference on Web Information Systems Engineering (WISE’03), IEEE (2003) Närman, P., Johnson, P., Nordström, L.: Enterprise Architecture: A Framework Supporting System Quality Analysis. Will appear in: Proceedings of the 11th International IEEE EDOC Conference, Annapolis, USA (2007)

Logical Foundations for the Infrastructure of the Information Market Michael Heather1, David Livingstone2, Nick Rossiter2 1

2

Ambrose Solicitors, St Bede’s Chambers, Jarrow NE32 5JB, UK, [email protected] School of Computing, Engineering and Information Sciences, Northumbria University, NE1 8ST, UK WWW home page: http://computing.unn.ac.uk/staff/CGNR1/ {david.livingstone,nick.rossiter}@unn.ac.uk

Abstract. The European knowledge-based economy has a complex product to market to the rest of the world. Techniques of the past, based on the closed-world assumption, have proved useful in many types of local information systems. However, theory and practice suggest that this approach may be inadequate for the infrastructure required. In databases the relational model through SQL has maintained wide dominance in business data processing. However, interoperability between different databases, even when based on the relational model, is proving a major problem. Predicate logic (consistent and complete to first-order) has many advantages for practical application. Interoperability however requires higher order logic as the arguments themselves are relations and functions. Higher order logic in the context of set theory behaves less satisfactorily according to Gödel’s theorems as such logic cannot satisfy all three of soundness, completeness and effectiveness. This may be a fundamental reason why interoperability is proving to be so difficult. This paper looks at underlying problems and suggests that they may be avoided by the use of categorial higher order logic. Cartesian categories are complete, consistent and decidable. They can be employed as an engineering technique to construct a general architecture of interoperability. Keywords: Formal approaches and formal models of interoperability, Interoperability infrastructure and IT platforms, Interoperability-related standards, legal and security issues, Architectures and platforms for interoperability, Interoperable knowledge management

1 Introduction Information systems are basic building materials for the knowledge-based economy of the 2000 Lisbon strategy. The Lisbon agenda of March 2000 set out a strategy resulting in the eEurope 2005 Action Plan to build the knowledge-based

626

Michael Heather, David Livingstone, Nick Rossiter

economy of the single market [17]. The fundamental basis of knowledge is information which has to be handled appropriately by both the technology and by the law. What was appropriate for the physical media of the last millennium cannot be just carried over to the new digital media. Modern information systems operate at every level: from data held in a single purpose fixed device, through common PCs at home or mobile computing with business systems of an SME, to databases, intra-acting locally and at national level, inter-acting between nation states and even then open to wider global systems outside of Europe. This interoperability requires global coherence, which mirrors the interoperation of the EU itself. The reported slow progress with the Lisbon agenda is reflected in a similar tardy development of interoperable information systems. The latter is perhaps one of the causes of the former. The report of Wim Kok, quoted in [5], recommended that the agenda be re-focused on growth and employment to remedy the small progress over the first five years in member states. Like national employment the focus needs to be on the details of operation on local information systems. Particular attention needs to be paid to the delivery of the Lisbon agenda. In order to achieve these objectives, the Union must do more to mobilise all the resources at national and Community levels so that their synergies ... can be put to more effective use ([6] at p.9) There is a problem with logic. Successful local systems are first order but they need to participate in higher-order activity. The quest for synergy between levels runs into problems arising from semantic interoperability. There are two fundamental types of data: images and text. Images can be structured, as in graphs, or unstructured, as in photographs. Text can be structured, as in relational databases, or ‘unstructured’, as in natural language [16]. There is also process data, represented as transactions in many current systems. Music as performed is an interesting example of process data whose permanent form is expressed as graphics with notes on musical staves and as text with expressions in italics such as andante. Syntactical interoperability is already achieved for digital and analogue data, either where the data is unstructured or where the data has a natural structure representable in a form that holds the informational content, for instance as ordered pixels or natural language text. These may be universally recognisable as in pictures or other interpretable materials where a common understanding readily exists. For instance an English text is interoperable throughout the world only in its native state or by translation into some other natural language. Consequently there are not too many problems with interoperability of the natural data. We simply need operations at the syntactical level, which Google does well for text and for well-established image formats like jpeg, tiff and gif. However, these forms of information are essentially raw data. When value is added to the data through the application of analytical methods, we obtain structured data, for which inter-communication is problematical. In the past these problems were minimised because the data was used mainly in a local setting, that is intracommunication was needed where any standard was common to the locality. Interoperability itself is concerned with the inter-communication of data at

Logical Foundations for the Infrastructure of the Information Market

627

different and therefore usually heterogeneous localities. Table 1 summarises those definitions in the form of a table. The importance of exactitude in transmission of data around the single market and commercial inter-communication with the rest of the globe needs to be emphasised. Table 1. Natural and Structured Data Types

Type

Structure

Examples

Applications

Images

Structured

Graphics

Business graphics

Natural (‘Unstructured’)

Photographs

Publishing

Structured

Relational databases

Business data

Natural (‘Unstructured’)

The web

Google

Text

Inter- mediate Data

Meta-structure added Semi-structured data Fitting spare parts to unstructured data (as in XML), Semantic Web, CAD/CAM Engineering Drawing with instructions

Process Data

Dynamic

Banking Transactions ATM accounting Biometric identity

Iris data

2 Exactness The concept of exactness is important in commerce. Customers always want what is ordered, whether it is good for their services or not, and not some approximation of the order. Of course in the real world there are always experimental errors but these can normally be controlled in a local environment and in practical terms can be minimised according to how much the customer wants to pay. Commerce has always had an international dimension but until very recently it has tended to be locally based. Communications between local bases have been point to point, with transportation by land, sea or air and conversations by mail, telephone or wireless broadcasting. The world consisted of a large number of mainly autonomous locally-based entities with simple inter-connection where the main effort is intraactivity at the local level, fit for the purpose with merchantable quality. A satisfactory theory can rely on linear models, linear logic, etc [8]. Local equates with classical and of the same type. Exceptionally large systems, even if of the same type, may lie outside local operating conditions. For example the large database cannot be maintained by one person and a very large database cannot be copied because in the meantime it is changed. However, distinction is usually qualitative rather than quantitative.

628


Non-locality on the other hand may still be composed of what approximates to a set of localities of the same type. It then operates as a classical organisation. The US legal system is able to operate this way with a federal law coordinating different local state laws. The early days of the EU imposed the same laws on the member states which at that time were few in number. But the character of Europe is diversity and variety, in language, culture, customs and style with quite different ways of working in manufacturing, commodities and providing services. When the number of member states of Europe became enlarged, imposing the same laws became impossible and there was a move to harmonisation. It is a comparable position with information systems in different states. Co-ordinating systems of the same type is only a first-order activity but for heterogeneous systems higher-order operations are needed. Legal systems are archetypal general information systems. Intensionally the legal systems of the member states of Europe are identical and feed into the overarching European law in the European Court of Justice. But each local legal system is extensionally different. We shall see here how the theory of interoperating business information follows the same practice. The topos in Figure 4 could represent the legal systems of Europe just as easily as information systems. Exact operations with systems of the same type mean it is easy to assume that the same conditions will apply for different type systems but in reality the results can be radically different and unpredictable even leading to dangerous results and therefore a subject for rigorous risk management. These may be derived from theory or experimental results, preferably both. The theory in this respect is shown by the Austrian mathematician Kurt Gödel. Gödel was able to show in his doctoral thesis of 1929 on the completeness theorem [9] that first-order predicate logic is complete. The significance is that consistent logical propositions may be applied as a model of first-order systems. Thus a digital computer operating with a von Neumann architecture gives satisfactory results with first-order limits. Most of the work in applied mathematics in the last two centuries has been gauged on clever theories to keep within the first-order limits. However, there are applications which have defied such analytical methods like turbulence where it has been necessary to resort to more qualitative techniques as found in chaos theory. These do not provide exact results. This can also be explained by Gödel’s theory of undecidability which is perhaps even better known [10]. Gödel’s theorem shows that both intensional and extensional systems which rely on axiom and number are undecidable 27. Traditional mathematical modelling, which relies on set theory cannot therefore be applied directly to higher order behaviour. An example of undecidability in the case of a computational machine relying on the Church-Turing thesis is the halting problem. A commercial example of this can be found in the implementation of Codd’s relational model [1] as it is utilised in modified form in much of current data processing. As we shall see in the next section, in its pure form the relational 27 There is the question of even how to define completeness, consistency, decidability, soundness and effectiveness. The literature itself is not consistent and we will therefore leave aside what these words mean in a set theoretic context and rely below on corresponding categorial concepts as definitive.


629

model works well for atomic data because it is within Gödel’s principle of firstorder predicate logic and is therefore complete. That is the relational model and its corresponding calculus give exact results for atomic data. While the commercial version of the relational model SQL is a vast improvement on earlier data models, it has compromised some of the relational model features and is neither complete, nor decidable. The relational model is sometimes trumpeted as an example of the effectiveness of logic in computer science [11]. This is only for theoretical computer science. Implementations of the model show a divergence between theory and practice. Of course real-world data does not consist of homogeneous independent items making up atoms. This has resulted in various techniques such as normalisation with a series of normal forms: first normal form, second, third, etc, which attempt to squeeze real-world phenomena into a collection of first-order relations, to behave optimally with regard to update and search operations. Hence data, lacking any naturally regular atomic form, may be squeezed by normalisation into such a structure in a consistent manner.

3 Practical Examples of Interoperability Problems The relational model predominates in much of commerce today as the format for structured information. Yet there are very significant interoperability problems between one relational database and another. Some of these can be attributed to problems with the underlying SQL standard as described below. 3.1 Variants of SQL

Vendors of SQL DBMS support different variants of SQL, all in varying degrees differing from the versions of the SQL International Standard 28, either having additional features and/or omitting features. Table 2. Effects of Variants of SQL on Interoperability

Features

Achievements

Problem in interoperability

Full facilities

Not achieved by MySQL

Very difficult between MySQL and other DBMS

Hierarchies, manipulation

Peculiar to Oracle

Difficult between DB2 and Oracle in network/hierarchical structures

Recursive union, assembling Peculiar to DB2 networks

28 Information Technology – Database Languages - SQL, ISO/IEC 9075:2003 (2003).

630


Implementation of integer type

Oracle treats as numeric(38)

Difficult between Oracle and other DBMS in formatting and rounding numbers

Dates

Different logical formats

Difficult between all systems in reliable data format recognition

Some features described in the standard are labelled implementationdependent, meaning they are independent of the standard. Others are implementation-defined, meaning the manner in which the feature is achieved is at the discretion of the implementer. Therefore it is not always possible to guarantee a semantically valid transfer of data from one SQL DBMS to another, since the recipient DBMS may treat the received data in a different way to that which the sending DBMS would have treated it, had it carried out ostensibly the same operations. This situation arises because the standards are not based completely on scientific or mathematical principles. Standards are also influenced by the software vendors, who are looking for pragmatic and strategic ways in which their products can be promoted. Examples of problems at the data level are shown in Table 2. Therefore if two databases are to be interoperable, it is much simpler if they are both managed by the same DBMS package, because then the only problems in this context are those arising from the consistent application of one variant of SQL. For this and other reasons, such as reduced DBMS maintenance and licence fees, in practice multiple-vendor SQL DBMS are unheard of, except where they arise due to force of circumstance, for example the merger of two previously independent companies. 3.2 SQL versus the Relational Model

The relational model is based on two mathematical theories: first-order predicate calculus and relations ([1] at p.v). Interestingly the relations permitted are not completely general (at p.467-477). In particular a collection of n-ary relations of assorted degrees is strongly encouraged where n is an integer, giving the degree of a particular relation. Both a single universal relation and a collection of binary relations are strongly discouraged, as the former loses flexibility in logical navigation and the latter is cumbersome and unnatural. Further if the collection of n-ary relations is constrained to be in first normal form with all values atomic, then the predictable regular form greatly simplifies the query language. No version of SQL implements the full relational model, either that specified by Codd or evolved from Codd’s model by others, for example see [3]. Some differences between SQL and the relational model are summarised in Table 3. The different structures of set and bag respectively for the relational model and SQL are of particular interest. Sets, bags and other container-types such as sequences of tuples are specifically defined and cannot be used interchangeably. However, there are means of carrying out conversions from one kind of container type to either of the other two, in an attempt to make it trivial to achieve mathematical exactitude in defining and manipulating the different kinds of tuple containers. Current work at


631

Northumbria University in the Open Database Project shows the need for rigorous definition at the local level in prototyping languages like Raquel [14] to produce an open source implementation of the features specified in the Third Manifesto [3]. The aim is to keep as close as possible to the philosophy of the pure relational database model including object classes as data types orthogonal to relations, an open architecture satisfying this philosophy, a design for the architecture and an implementation of that design. Interoperability is facilitated by the use of pure relational languages such as Raquel, together with conversion techniques for mapping between different container types. Table 3. Differences between SQL and the Relational Model

Feature in SQL

Feature in relational model

Consequence for SQL

Default structure is bag

Structure is set

Duplicate rows permitted, inconsistency in updates

Row identifier

No identifiers

Physical bias to extension

Rows may be sequenced

No sequencing of rows

Data is apparently ordered

Set operations such as union Set operations such as union Set operations are based on based on column position based on column name physical, not logical, ordering of columns Duplicate column names allowed in output

No duplicates allowed

Confusing output

3.3 Closed World Assumption

The definition of a relation should be a logical predicate such that each tuple in a relation corresponds to a logical proposition that is true for that predicate. By the Closed World Assumption (that is the CWA) any tuple not in the relation represents a false proposition. This is an attempt to satisfy Gödel’s decidability principle: that tuples in the relation are true and tuples outisde the relation are false [2]. However it is not possible for a relational DBMS to guarantee that all the tuples in a database represent true propositions, only that they all consistently meet a set of integrity constraints that partially represent the real-world logical predicate. This is because the typing system is based on set inclusion principles rather than constructive ones. Therefore decidability may be a problem with all relational systems. Nulls are another example of where database approaches based on CWA run into difficulties. ([1] at p.383-387) suggests that the relational model should permit nulls as markers, with two interpretations: missing-but-applicable and missing-andinapplicable. Nulls are not data values. A four-valued logic is then employed to manipulate such data with the outcome of true, false or two types of maybe. SQL claims to have a three-valued logic since logical variables may take the values true, false or null. However, it is not clear that null can be safely equated with maybe and a number of problems arise as shown in Table 4. From the Gödel perspective,

632


nulls make a system undecidable. It is therefore not surprising that practical implementations such as SQL have many problems in handling nulls. Some more recent versions of the relational model do not permit nulls, for example [3]. It is likely that the handling of nulls will be facilitated by the use of metadata to describe the reason for the null. The questionable CWA assumption also raises problems in proving that the result of a query is logically valid. This gives rise to undecidability and a lack of completeness. Compounding the problem is that many users look for plausible results, often on small volumes of data. Table 4. Problems with Handling of Nulls by SQL

Case

Result

Problem

Creation of nulls whether value is missing-butapplicable or missing-andinapplicable

No distinction

Semantic simplification

Use of null to represent maybe Three values for Boolean in the Boolean type logic

Contrary to normal view of Boolean logic as binary valued

Comparing a null value with a maybe with join/restrict, true Difference in outcome null value in set operations between set operations and other operations such as join Split table into a set of subtables using restrict; union resulting sub-tables

No guarantee that this will be Restrict only returns rows the original table where the comparison returns true; hence those returning null are ignored and lost

Aggregation operators applied Count includes them; others to columns containing some ignore them nulls

Arbitrary application

Aggregation operators applied Count returns zero; others to columns containing all return null nulls

Arbitrary application

Second order distributivity (e.g. fuzzy sets)

Logical equivalences are not Inconsistent treatment of nulls true

It is perhaps worth raising the question as to whether object-oriented databases would overcome some of the disadvantages above. The answer is no, as objects will suffer from all the problems of sets and methods are implemented through an enriched type system, similar to sketches or perhaps 3-categories. The objectoriented approach needs to be founded in category theory to be complete and decidable. Codd said (at p.22): “One of the main reasons that object-oriented DBMS and prototype products are not going to replace the relational model and associated DBMS products is their systems appear to omit support for predicate logic. It will take brilliant logicians to invent a tool as powerful as predicate logic. Even then such an invention is not an overnight task. Once invented it may take


633

more than a decade to be accepted by logicians. Thus features that capture more of the meaning of data, which is important, should be added to the relational model, instead of being proposed as replacements” [1]. Intuitionistic logic offers a more convincing way forward. Compared to first-order Boolean predicate logic the intuitionistic is more naturally applicable to open systems, is constructive and avoids the problem of impredication.

4 Interoperability and Categories In category theory [15] alternative meanings of decidability, completeness, satisfiability, soundness and consistency, all used by Gödel, converge. They come together in the composition diagram in Figure 1(a). The negation of these terms or where they fail wholly or in part are all subsumed in the diagram of punctured composition [7] in Figure 1(b). At one level the composition diagram of Figure 1(a) is a formal categorial representation of Gödel’s result that first-order predicate logic is complete. This diagram therefore satisfies a local intra-operability of a single system and first-order interoperability between simple systems. The difference is that moving to higher orders such as axiomatic number systems is undecidable. However, that limitation does not apply to a process view of the arrow. Composition is still satisfied by the diagram but where the arrows can be a different type or from different levels. We have shown in [19] that free interchange between four levels can satisfy any realisable system. The conditions for interoperability come from adjointness [18] between the two composition triangles in Figure 2.

'

Fig. 1. Commuting Diagrams for a) Composition, b) Punctured Composition: (gRf)=(gRf)

Critical details of these two triangles are the values K, H, respectively the unit and counit of adjunction [13] in Figure 3. F is the functor that carries the data across from the left system to the right system. G is the underlying functor giving the rules for that transmission. f,g respectively represent dynamic data in the left

634


and right systems. L is an object in category L and R an object in category R. Note that this only defines information in one direction. For two-way communication there has to be a self-adjointness of both left and right systems. As explained above in the example of legal systems this is a process of harmonisation. The systems do not need to be identical, that is K may be other than A and կ other than H.

Fig. 2. Cartesian closed adjointness. Each circle superimposes clockwise ands anticlockwise closed arrows as identity functors indicated by the contravariant arrow heads (top and bottom representing initial and terminal objects respectively). The left (L) and right (R) categories are themselves opposites as shown by the arrowhead directions.

4.1 Architecture for Interoperability

Fig. 3. Roles in Adjointness of a) K, b) H

The architecture for interoperability between more than two systems is then a composition diagram of the form shown in Figure 4. Fundamental category theory


635

shows that for physical existence the real world operates as a cartesian closed category. All the categories drawn above are therefore cartesian closed. The theory also shows that any such operation involves only two categories (L,R) and a context category C, that is a left system communicates with a right system in the context of all other systems. All other systems are therefore a single context category. More precisely this is a topos T as in Figure 4. Remember that interoperability is really a global character where everything is connected to everything else. We are not dealing with discrete systems. The context category described above is only a view and is really the limit of the topos. So C Æ T. And of course L and R are themselves subobjects of T. This is the essence of interoperability where category theory, or nothing less than category theory, can give the required insight to construct exact and decidable interoperating information systems. Category theory has long been associated with graph theory. A graph-based approach to interoperability such as that by [20] using metamodels is broadly in the same direction as our work.

Fig. 4. Architecture for Interoperability: Topos T involving categories L,R and Context Category C

5 Conclusions From the work of Gödel, first-order predicate systems are complete, consistent and decidable. Much of the attention in defining a relational data model has focused on keeping to a strict first-order system. The treatment of issues such as normalisation, nulls and recursion by workers developing a pure relational model [3, 1] is designed to avoid the need to handle higher-order logic in set theory. Indeed the relational model in its proper form is classified as one of the outstanding successes of logic in computer science [11]. The more casual treatment of such factors in SQL has led to systems, which are no longer consistent and decidable, giving many problems in interoperability. The kinds of problems with SQL standardisation are

636


covered in [4] where underlying weaknesses in standards are thought to occur early on in the standardisation chain, such as through a weakness in the standards idea or the standards process. Interoperability is essentially a higher-order problem, For higher order systems we need composability to achieve the same rigour as found in first-order predicate systems. Composability is a cornerstone of category theory and an architecture has been proposed, based on the topos, for achieving interoperability while meeting Gödel’s requirements.

Acknowledgements We are grateful to Hugh Darwen for his comments on the SQL standard and the relational model and to the contributors at the AREIN workshop, Madeira, March 2007 where a preliminary version of this work was first presented [12].

References [1] [2]

Codd, E F, The Relational Model for Database Management Addison-Wesley (1990). Date, C J, Gödel, Russell, Codd: A Recursive Golden Crowd http://www.dcs.warwick.ac.uk/ahugh/TTM/goedel.pdf 6pp July 17th (2006). [3] Date, C J, & Darwen, Hugh, Databases, Types and the Relational Model: The Third Manifesto 3rd ed, Addison Wesley (2006). [4] Egyedi, T, Experts on Causes of Incompatibility between Standard-Compliant Products, in: Enterprise Interoperability: New Challenges and Approaches Doumeingts, G, Müller, J, Morel, G, & Vallespir, B, (edd) Springer 553-563 (2007). Network, Relaunch of the Lisbon Strategy [5] Euractiv http://www.euractiv.com/en/innovation/growth-jobs-relaunch-lisbon-strategy/ article131891 (2005). [6] European Commission, Internal Guidelines in: Integrated Guidelines for Growth and Jobs 2005-2008 2005/0057, http://ec.europa.eu/growthandjobs/pdf/ COM2005_141_en.pdf (2005). [7] Freyd, P, & Scedrov, A, Categories, Allegories, North-Holland (1990). [8] Girard, Jean-Yves, Une extension de l’interpretation de Gödel, à l’analyse, et son application à l’élimination des coupures dans l’analyse et la théorie des types, Studies in Logic and the Foundations of Mathematics North-Holland 63-92 (1971). [9] Gödel, Kurt, Über die Vollständigkeit des Logikkalküls Doctoral Thesis, D1.736 33pp, University of Vienna (1929). Reprinted in Feferman, S, ed. Gödel Collected Works, volume 1 (1986). [10] Gödel, Kurt, Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme, I. Monatshefte für Mathematik und Physik 38 173-198 (1931): translated in Jean van Heijenoort, From Frege to Gödel: A Source Book on Mathematical Logic Harvard 596-616 (1967). [11] Halpern, Joseph Y, Harper, Robert, Immerman, Neil, Kolaitis, Phokion G, Vardi, Moshe Y, Vianu, Victor, On the unusual effectiveness of logic in computer science Bulletin of Symbolic Logic 7(2) 213-236 (2001). [12] Heather, Michael, Livingstone, David, & Rossiter, Nick, Higher Order Logic and Interoperability in Global Enterprise, AREIN I-ESA 26-30 March 12pp (2007).


637

[13] Lawvere, F W, Adjointness in Foundations, Dialectica 23 281-296 (1969). [14] Livingstone, David, Open Database Project, CEIS, Northumbria University, http://computing.unn.ac.uk/openDBproject/ (2007). [15] Mac Lane, Categories for the Working Mathematician, 2nd ed, Springer (1998). [16] Probst,G, Raub, S, & Romhardt,K, Managing Knowledge Building-Blocks for Success Wiley (2000). [17] Rodrigues, Maria Joao, The Debate Over Europe and the Lisbon Strategy for Growth and Jobs, 2005.10.21, http://www.mariajoaorodrigues.eu/files/ The_Debate_over_Europe_and_LS.doc (2005). [18] Rossiter, Nick, & Heather, Michael, Conditions for Interoperability, 7th ICEIS Florida, USA, 25-28 May 2005, 92-99 (2005). [19] Rossiter, Nick, Heather, Michael, & Nelson, David, A Natural Basis for Interoperability, in: Enterprise Interoperability: New Challenges and Approaches Doumeingts, G, Müller, J, Morel, G, & Vallespir, B, (edd) Springer 417-426 (2007). [20] Ziemann, J, Ohren, O, Jae, kel, F-W, Kahl, T, & Knothe, T, Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel, in:Enterprise Interoperability: New Challenges and Approaches Doumeingts, G, Müller, J, Morel, G, & Vallespir, B, (edd), Springer p.199-208 (2007).

Meeting the Interoperability Challenges of eTransactions among Heterogeneous Business Partners: The Advantages of Hybrid Architectural Approaches for the Integrating Middleware G. Gionis, D. Askounis, S. Koussouris, F. Lampathaki National Technical University of Athens, Athens, Greece {gionis, askous, skoussouris, flamp}@epu.ntua.gr

Abstract. Escalating economic and societal demands of today, along with the continuous advancements in ICT, push enterprises and organisations to move towards networked paradigms and leverage electronic transactions in the everyday practice. Although technical solutions providing for the necessary organisational, semantic, and technical interoperability means to enable e-transactions have been rigorously justified during the last years, their adoption and application into the everyday business practice by enterprises and organisations still remains limited. Specific characteristics of the existing solutions, such as inflexible workflows, predefined formats and content for the exchanged documents, hardcoded business and legal rules, use of proprietary technologies and inability to be readily deployed and validated for their efficiency, act as the main inhibitors for any potential users. The present work discusses the needed characteristics of centralized and decentralized architectures for e-transactions among business partners, identifies the weak points of every pattern and proposes a hybrid architectural approach that brings together the best features from both paradigms. Furthermore, specific insights, methodologies and underlying technologies are proposed with an objective to support the effectiveness of the architecture and its components in integrating processes, data and services achieving fully electronic transactions among businesses and governments in many European countries.. Keywords: electronic transactions, architectures, interoperability, ERP

1 Introduction Today, escalating economic and societal demands, along with the continuous advancements in Information and Communication Technologies (ICT), set a growing agenda of pursuits for enterprises and organisations and challenge the capabilities of their underlying technical infrastructures to support them effectively

640

G. Gionis, D. Askounis, S. Koussouris, F. Lampathaki

in their struggle of gaining steam against their competitors and establishing their position in the market. In this world novel business practices such as the paradigm of electronic transactions (eTransactions) are constantly taking up momentum. Just as Porter [17] in 2001 stated that it is not a question for enterprises whether or not to move to the Internet but when and how to do it in order to create new value, today the silver bullet decision for businesses and organisations does not lie any more in the dilemma of adopting or not ICT enabled eTransactional practices but how to integrate them as quickly and effectively as possible to their operation to achieve the biggest possible benefits. However, specific characteristics of the proposed solutions, such as inflexible workflows, predefined formats and content for the exchanged data, predefined business and legal rules, traffic of sensitive business information through third party systems, use of proprietary technologies and inability to be readily deployed and validated as to their efficiency act as the main inhibitors for the potential users. This renders current solutions costly, rigid and difficult to adapt to meet the requirements of evolving enterprises [21]. Many of these drawbacks can be largely attributed to the adopted architectural patterns – namely fully centralized (server based) or purely decentralized (peer to peed) – and the specificities that these patterns bring about in terms of rigidity, operational philosophy, technological maturity and cost that contradict fundamentals of the eTransactions business perspective as it viewed by enterprises and organisations. In this paper we begin by outlining in section 2 the framework of what constitutes ICT enabled eTransactions from the enterprises’ viewpoint. Following in section 3 we present a view on the underlying state of the art in enabling technologies and platforms, discuss the advantages and disadvantages of the two main architectural paradigms and establish the characteristics of a hybrid architecture bringing together the best of breed in features from both worlds. In section 4 we present the features of this hybrid architectural approach and roadmap the creation of a corresponding platform based on it.

2 Interoperability Challenges of eTransactions: The Enterprises Viewpoint Enterprises and organisations realize the entire spectrum of their everyday transactions through a series of consecutive cycles of requesting, receiving, filing, issuing and sending business documents (order forms, invoices, payment responses, etc) that take place in parallel with the corresponding physical operations that are carried out during the transactions (shipping products, receiving products, rendering services, etc). In the back-end of each stakeholder there are a number of internal processes whose business logic defines the flow of these sendreceive activities. However it is through these send-receive endpoints that the two stakeholders communicate with each other. In simple cases the business logic of the internal processes is entirely confined within the interior of each stakeholder thus producing a straightforward workflow. In real world situations however this is hardly the case, especially when long

Meeting the Interoperability Challenges of eTransactions

641

successive cycles of send-receive business documents are required. In such cases the internal business logic inevitably intervenes during the execution time in the way send-receive endpoints are sequenced making the “a priori” knowledge of the complete workflow virtually impossible. This is illustrated in the following example taken from [23] where during a transaction the invoicing procedure between seller B and buyer A may be supplemented either by a Credit Note or a Debit Note. Such a case is very often when there are discrepancies between the items stated in the Invoice and the items actually received (prices, volume, etc). There are two options: A pays for the items received (the amount is different form the one stated in the Invoice), then sends a response to B for the amount paid and B issues a corresponding credit to A (Credit Note). 2. A sends a note to B (Debit Note) for the items received, B re-issues the Invoice, A pays the proper amount according to the new Invoice and sends a response to B for the amount paid

1.

Table 1: Fulfilling the Invoicing Procedure Either with a Credit Note or a Debit Note Invoicing Between Seller A and Buyer B with a Credit Note B: issues an Invoice B: sends the Invoice to A A: receives the Invoice A: arranges for payment (internal process) A: issues a Response A: sends the Response to B B: receives the Response B: issues a Credit Note B: sends the Credit Note to A A: receives the Credit Note

Invoicing Between Seller A and Buyer B with a Debit Note B: issues an Invoice B: sends the Invoice to A A: receives the Invoice A: issues a Debit Note A: sends the Debit Note to B B: receives the Debit Note B: re-issues the Invoice B: sends the Invoice to A A: receives the Invoice A: arranges for payment (internal process) A: issues a Response A: sends the Response to B B: receives the Response

All business documents affiliated with business transactions are produced by data that exist within the enterprises’ technical infrastructures. Therefore the heterogeneity of the stakeholders’ infrastructures mandates a corresponding heterogeneity in the way business documents are represented by every partner in terms of semantics and format of their content. The following table illustrates an example of how a segment of the same data in an invoice that is sent from partner A to partner B is represented differently when the invoice is stored inside each one of the stakeholders’ systems.

642


Table 2: Different Representations of the same Segment of Data within the Stakeholders’ Infrastructures System of Partner A Company Name Sui Generis S.A. Billing Address 7 Panepistimiou str, Athens, Greece

Postal Code Customer ID Invoice Number

13713 7130713 1370137

System of Partner B Partner Name Sui Generis S.A. Street Name Panepistimiou Street Number 7 City Athens Country Greece Zip Code 13713 Partner ID 7130713 Invoice ID 1370137

Consequently, for any two potential business partners to engage in eTransactions they need to find an ICT-based, systematic way, for addressing the following challenges: x

x

Defining and executing workflows of service endpoint that correspond to issue, send, receive, etc functionalities of underlying systems that have been externalised as web services – the process integration and dynamic service composition challenges. Transforming business documents between different formats based on a mapping between the semantics used by the underlying systems – the data integration challenge.

Based on the status of the underlying technological state of the art, today the above challenges are feasible to be realized in a one-to-one basis between two stakeholders. However, if an enterprise or organisation aspires to realise the “Business Perspective” of eTransaction, it would have to apply this one-to one approach with every single one of its business partners (one-to-many approach) something that is feasibly impossible due to its exponential complexity and corresponding cost. Following on the definitions of interoperability in organisational, semantic and technical aspects, this paper focuses in solving the problem in the latter two levels (i.e. semantic and technical) by introducing an architecture with the ability to integrate existing systems by defining and executing dynamic service workflows of externalised (web service) functionalities and transforming business documents among different formats based on underlying models of processes and data of these systems.

3 Discussion on the Underlying State of the Art Interoperability as a driver for eTransactions constitutes a challenging field where scientific advances are very often accompanied by significant benefits for the adopting stakeholders – according to Gartner ICT interoperability products alone constitute a thriving market that surpasses 200 M€ per year worldwide. Therefore the underlying state of the art appears to be quite progressed, incorporating from


643

methodologies, frameworks and standards for process, data and service integration to commercial of the self (COTS) solutions and integrated platforms for eTransactions. 3.1 Products and Platforms for eTransactions

Several approaches emerge today with the objective to help in the integration of business partners and provide them with capabilities for eTransactions [26]. Following we provide a small overview of the foremost examples for such commercial, open source and research community middleware. Microsoft BizTalk Server [3] is a business process management server that enables companies to automate and optimize business processes. It includes tools to design, develop, deploy, and manage business processes. The environment also provides the ability to design, build, and execute dynamic business interactions that span applications, platforms, and organizations. The current version of BizTalk supports specifications (XLANG) for modeling business processes and incorporates an orchestration engine for executing and monitoring processes. Oracle Application Server [16] is a new release of the core service oriented architecture platform underlying Oracle Fusion Middleware. It is designed to address three challenges, service oriented development of applications, eventdriven business process optimization and a unified workplace with pervasive multichannel access. SAP Netweaver Platform [18] is an application builder platform for integrating business processes across various systems, databases and sources. It is a service oriented application and integration platform that is designed to interoperate with various proprietary technologies and commercial platforms like Microsoft .NET, Sun Java EE, and IBM WebSphere. Freebxml [7], an initiative that aims to foster the development and adoption of ebXML related technology through software and experience sharing. In contradiction to other initiatives around ebXML, Freebxml does not define specification, but instead provides implementations of already existing ebXML specifications. 3.2 Peer to Peer and Server-based Approaches: Advantages and Disadvantages

Up until now middleware integration platforms have mostly been realized on the basis of centralized, client/server, models [1]. Different flavours of client/server constellations exist today, ranging from centralized hub-and-spoke systems to point-to-point links between two trading partners [20]. In all cases a central instance mediates between one or several users, provides the necessary functionality for seeking, negotiating and binding services and finally orchestrates the collaboration processes and handles message exchanges. However when it comes to business integration of enterprise services across the boundaries of firms, central systems cannot be considered as an ideal solution to cope with “mission critical” issues such as increasing workload, scalability and risk of failure. In central systems all services are inevitably assembled and executed on

644


the central server’s runtime, thus consuming a significant amount of its computation power that may diminish the performance of the overall system. Additionally, such systems present by design reduced scalability since any changes in the server are propagated and affect all the interconnecting clients. Finally the existence of a single, central point of failure makes this architectural approach even more inappropriate for business transactions. On the other hand decentralized, peer to peer (P2P), architectures do not present such problems. P2P networks typically do not have the notion of clients or servers, but only equal peer nodes that concurrently work as both clients and servers to the other nodes that are part of the network. Instead of a central instance being responsible for the setup and control of business relationships, P2P transactional systems enable users to dynamically and autonomously negotiate and establish an agreement for the automatic execution of business processes. Therefore, theoretically, this approach clearly provides paramount advantages in many respects for business transactions. From an economic point of view, the absence of cost and risk of ownership and maintenance of a central server and the corresponding infrastructure is avoided. The improved scalability and ability to deal with transient populations of users can be considered as a further important argument for deploying distributed eTransactional systems. Furthermore two trading partners do not have to exchange documents via a third-party with the risk of having sensitive data intercepted but have the benefit of direct, unmediated and potentially synchronous communication. However, P2P based architectures are also compensated by a number of drawbacks. Such environments consist of numerous autonomously acting peers that require sophisticated and reliable mechanisms for partner retrieval to cope with the quickly changing network topologies, in the opposite a central server could easily maintain one single catalogue indexing all currently connected users. A second issue is the assurance of user authentication and access control, where as opposed to a centralized architecture, there is not a single entity that can act as neutral mediator, maintaining certificates of the respective participants’ identities. Apart from these, the negotiation and establishment of collaboration protocol agreements (CPAs) is more complex than in the case of central system since there is no central instance available that could provide standardized guidelines. Finally, the progress and state of the conducted transactions must be maintained (“mirrored”) by all the engaged peers, since the orchestration of services is performed in a decentralized way. Further challenges such as the introduction of methods for authentication, non-repudiation, logging, time-stamping and maintaining of all transaction information are still left to be investigated. 3.3 Best of Breed of the Two Approaches

According to [27], The different models for semantic interoperability are classified based on two fundamental dimensions: 1) choosing one of two possible ways to set up integration mappings, one in which each service schema is mapped to any other (any-to-any) and another in which each one is mapped to a single schema (any-toone), and 2) choosing whether the integration logic is executed in a single,


645

distinguished node (centralized) or the execution is distributed among multiple, functionally equivalent nodes (decentralized). By using this criterion, if we try to classify the aforementioned advantages and disadvantages of each architectural approach we end up with the following table that illustrates the strong points (3) and weaknesses (x) of every architecture to integrate the mapping and logic of their interconnected users. Table 3: Classifying Advantages and Disadvantages of Server-Based and P2PArchitectures According to the Different Categorisations of Semantic Interoperability Model for Mapping Integration Any-to-One Any-to-Any

Server-Based

3

P2P

Model for Logic Integration

Centralized

Decentralized

x x

3

According to the table in a Server-Based system the advantages lie with the fact that users are required to do the mapping of their processes, data and services in an Any-to-One way (each partner maps only against the Server). However the Server resumes the entire burden of executing the necessary logic i.e. service workflows and document transformation in a centralized way, which is the main disadvantage due to the created high workloads. On the other hand, in a P2P platform, according to the table, the main disadvantage is that business partners are required to perform and maintain an Any-to-Any mapping of their processes, data and services which leads to a very high level of complexity (each partner maps against every other partner in the environment). The advantage though is that there can be decentralized execution of the necessary logic, i.e. every two partners can define mutual service workflows and document transformation mappings. Among all the possible categorisations in the above table the ideal situation would be an architecture where business partners could integrate their mappings in a Any-to-One way (each partner mapping against one central instance) in order to keep the level of complexity low and then be able to proceed to the execution of the integrated logic in a decentralized way (any two partners being able to engage in a transaction directly among themselves without any third-party mediation). These two points are the fundamental design principles of the architecture we propose in the following section of this paper.

4 Roadmapping Hybrid Architectural Approaches for eTransactions 4.1 Architectural Overview

According to Gartner [8] monolithic, centralized architectures that focus only within the enterprise, and not on business partners and customers, are worthless.

646


Newer architectural models need to put us on a track to make real the loosely coupled enterprise, and push for an increasing capability to collaborate among all kinds of applications. Proportionally, the Enterprise Interoperability Research Roadmap [6] defines the concept of interoperability service utility to denote an overall system that provides enterprise interoperability to its users as a utility-like capability in a “plug-n-play” way. The proposed architecture embraces this general philosophy for extroverted, easy to use applications by specifying an environment with the ability to promote peer-to-peer eTransactions between business partners through a centralized support – hybrid architecture. The architecture facilitates the direct exchange of business documents between the partners through the provision by a central instance (server) of customized service workflows and data mapping schemas.

Fig. 1: Architectural Overview

The architecture comprises three distinct components – the repository, the server and the adapters. Collaborating together these components constitute an integration platform that enables stakeholders of heterogeneous nature to engage and sustain networked enterprise paradigms based on dynamically composed, end to end integrated services. The Repository stores semantic information about the characteristics of the platform users in the form of models about the processes, corresponding service endpoints and data models each user can support based on its underlying infrastructures. Additionally, such a Repository may even store higher level models of business and legal rules depicting the followed business practices and underlying framework guidelines according to business nature of the engaged partner or the geographic location where the transaction is executed [12]. The Server acts as the integrating component among the users providing them with the necessary capabilities to engage in eTransactions directly among


647

themselves. Specifically, for every transaction between two stakeholders the Server makes use of the information in the Repository in order to synthesize specific workflow based on the process models and the existing service endpoints supported by the partners, provides specific data mappings based on the underlying data models of the partners to enable the transformation of business documents between different system formats, and may also provide for the necessary monitoring and management of the transaction flow where required . The Adapter which is the only component in the architecture that depends to some extend on the configuration of the users’ infrastructures provides the technical capabilities for the direct exchange of information among the users. The Adapters, based on the input by the server, execute dynamic workflows, perform document transformation and interconnect to the users’ internal infrastructures by calling the supported externalised service endpoints. 4.2 Technology Viewpoint

In order to support the server’s integrating capabilities the repository must incorporate a series of semantic models of processes and data, specifically: x

x x

Generic process models in the form of XML description – e.g. XMI-based representations of UMM models [14], [15], BPMN collaboration models [5], ebXML BPSS [13]. At the moment, BPMN appears to be the most preferable specification due to the fact that there is already a considerable amount of work on how to transform such models into BPEL [4] which is an XML-based executable description of service workflows. Generic business documents in an XML-based format. For this purpose the the readily available UN/CEFACT Core Components [24] and Naming and Design Rules [25] may be used. XML descriptions of the users profiles and their mutual agreements that apply during their transactions – e.g. ebXML Collaborations Protocol Profiles and Agreement

In order to create such a diverse semantic repository a multidisciplinary modelling methodology that will provide a holistic view upon processes, data, services and rules in a specific business domain is required. Although several successful approaches do exist, such as in [19], [11], they address only one or two aspects of the problem, namely processes or processes and services. The modelling approach we propose comprises three dedicated modeling levels for business processes, business documents and business and legal rules. The business process modelling level comprises two distinct categories of process models – private and public – each one of which captures a specific description view of a business process. Private process view shows all activities which are performed within the process, like internal decisions or internal administrative work. Public process view only shows activities that are useful to understand the relevant process outputs and communication with external entities. The significant process logic has to be indicated as well in this view. Activities of the external entity (i.e. the other collaborating partner) are not described.

648


At the business document level, document models are created through syntax independent blocks of data – i.e. by utilising the UN/CEFACT Core Components Technical Specification [24] that already implements a considerable number of readily available data components. The overall business document structure can be modelled either according to existing data components (UN/CEFACT or UBL core components of business documents) or from scratch (which is the case especially for documents for governmental transactions). The business and legal rules level must contain models with the ability to reference both process and document models. To this end a specific rules metamodel needs to be created taking into consideration the specifics of the business domain to be facilitated in order to define a vocabulary of all the entities referenced by the rules. The metamodel must incorporates concepts such as events and conditions that trigger the rule, action that the rule bears during its execution, application fields that the rule effects (i.e. external process and document models) and finally originating legal structures in the case of legal rules [10]. In the proposed architectural approach the server is a component that is layered between the repository and the adapters with the objective to provide a series of supportive services that eventually enable business partners to engage in electronic transactions without ever assuming the burden of delivering the entire transactional load like in pure server based approach. To fulfil its purpose it must comprise mechanisms for: x

x

Generating executable service workflows for any transaction between two specific partners. This is achieved by retrieving the corresponding public process models from the repository, matching their service endpoints in order to define a common collaboration model and finally transforming this to executable sequence of services. From a technological perspective the final service workflow can be produced by converting a collaborative BPMN process model to its corresponding BPEL script. Synthesizing generic business documents that fulfil both partners’ data requirements based on their underlying business document models in the repository and providing dedicated XML mapping to transform the generic business documents into specific business document to be stored in each partners’ system.

Every adapter in the client side of the proposed architecture assumes the burden of conducting the transaction by executing the workflows and applying the transformation schemas provided by the server. To achieve this functionality it requires a dedicated component capable of executing the workflows by calling the prescribed services, in our case a BPEL engine will do since the execution script is in BPEL and one simple function from transforming XML documents from one format to another based on a predefined transformation schema.

5 Conclusions and Future Work In this paper we have outlined the ICT challenges of what signifies ICT enabled eTransactions paradigm from the enterprise’s viewpoint. Furthermore we


649

presented an in-depth view in the underlying state of the art in terms of enabling technologies, COTS middleware and research initiatives for service, process and data integration. Additionally we discussed the advantages and disadvantages of the two most common architectural paradigms, namely centralized and decentralized, and establish the characteristics of a hybrid architecture bringing together the best of breed in features from both worlds. Following we analysed the features of this hybrid architecture and roadmapped the creation of a corresponding platform by introducing specific insights, methodologies and underlying technology to support the effectiveness of the architecture and its components in integrating processes, data and services. Next steps in this work include the specification in design and technological level of additional features in the proposed architecture such as the capability to provide for online contract negotiation between the partners, advanced authentication of new users of the environment, non-repudiation of the conducted actions, logging and time-stamping of the exchanged business documents in order to constitute a full scale collaboration platform capable of achieving the objective of organisational interoperability.

References [1]

S. Androutsellis - Theotokis, V. Karakoidas, G. Gousios, D. Spinellis, Y. Charalabidis: “Building an e-Business Platform: An Experience Report”, in P.Cunningham, M. Cunningham (eds.), “Innovation and the Knowledge Economy: Issues, Applications, Case Studies”, European Commission eBusiness Yearly Edition, IOS Publishing, 2005, Part1, Volume 2, pp199-206 [2] Athena project, Deliverable D.A1.1.1 First Version of State of the Art in Enterprise Modelling Techniques and Technologies to Support Enterprise Interoperability, available online at www.athena-ip.org, 2007 [3] BizTalk Server, available online at http://www.BizTalk.org, 2003 [4] BPEL4WS specification, version 2.0, available online at http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsbpel, 2005 [5] BPMN specification, available online at http://www.bpmn.org [6] Enterprise Interoperability Research Roadmap, available online at http://cordis.europa.eu/ist/ict-ent-net/ei-roadmap_en.htm, pages 19-24, 2006 [7] Freebxml, available online at http://www.freebxml.org/, 2007 [8] Gartner, Enterprise Architecture Special Report: Overview, available online at http://www.gartner.com/pages/story.php.id.2230.s.8.jsp, 2007 [9] GENESIS project, Deliverable D3.1 Analysis of the Data Modelling State of the Art, available online at www.genesis-ist.eu, 2007 [10] George Gionis, Yannis Charalabidis, Katerina Sourouni, Dimitris Askounis, Enabling Cross-Border Interoperability: Modelling Legal Rules for Electronic Transactions in the European Union, in the proceedings of the 3rd International Conference in Interoperability for Enterprise Software and Applications I-ESA 2007, Madeira, March 28th - 30th, 2007 [11] Gong, Ruinan Li, Qing, Ning, Ke, Chen YL, O'Sullivan, David, Business process collaboration using semantic interoperability: Review and framework, semantic WEB - ASWC 2006, proceedings Lecture Notes In Computer Science 4185: 191-204 2006

650


[12] Charalabidis Y., Askounis D: “Interoperability Registries in eGovernment: Developing a Semantically Rich Repository for Electronic Services and Documents of the new Public Administration”, HICCS, January 7-10, 2008, Hawaii. [13] OASIS,ebXML - BPSS v1.10, available online at http://www.untmg.org, 2003 [14] OMG, XML Metadata Interchange (XMI) Specification, Version 1.4, available online at http://www.omg.org/cgi-bin/doc?formal/02-01-01, 2001 Meta-Object Facility (MOF), Version 1.4, available online at [15] OMG, http://www.omg.org/technology/documents/formal/mof.htm, Application Server, available online at [16] Oracle http://www.oracle.com/appserver/index.html, 2004 [17] M. Porter, Strategy and the Internet, Harvard Business Review, pp. 63–78.G, March 2001 NetWeaver, available online at [18] SAP http://www.sap.com/platform/netweaver/index.epx, 2007 [19] Seng, Jia-Lang, Lin, Woodstock, An ontology-assisted analysis in aligning business process with e-commerce standards, Management & Data Systems 107 (3-4): 415-437 2007 [20] A. Svirskas, B. Roberts, An architecture based on ebXML and Peer-to-Peer technologies and its application for dynamic virtual enterprises of European SMEs, in the proceedings of the XML Europe 2004 (XML Europe 2004), Amsterdam, The Netherlands, 2004 [21] D. P. Truex, R. Baskerville, and H. Klein, Growing Systems in Emergent Organizations, Communications of the ACM, vol. 42, no. 8, pp. 117-123, 1999 [22] Tsalgatidou, A., Pilioura, T., An Overview of Standards and Related Technology in Web Services, International Journal of Distributed and Parallel Data Bases, Special Issue on E-Services, 12(2); p. 135-162, Sep 2002 [23] Universal Business Language version 2.0, available online at http://docs.oasisopen.org/ubl/os-UBL-2.0/UBL-2.0.html, June 2007 [24] UN/CEFACT: Core Component Technical Specification, available online at http://www.unece.org/, 2006 [25] UN/CEFACT, UN-CEFACT - XML Naming and Design Rules Version 2.0, available online at http://www.untmg.org, 2006 [26] Y. Charalabidis, V. Karakoidas, S. Theotokis, D. Spinelis, Enabling B2B Transactions over the Internet through Application Interconnection, in P.Cunningham, M. Cunningham (eds.), “eAdoption and the Knowledge Economy: Issues, Applications, Case Studies”, European Commission eBusiness Yearly Edition, IOS Publishing, December 2004 [27] G. Vetere, M. Lenzerini, Models for semantic interoperability in service oriented architectures, IBM Systems Journal, Vol 44, NO 4, page 894, 2005

A Model-driven, Agent-based Approach for a Rapid Integration of Interoperable Services * Ingo Zinnikus, Christian Hahn, Klaus Fischer DFKI GmbH, Saarbrücken (Germany) {ingo.zinnikus, christian.hahn, klaus.fischer}@dfki.de

Abstract. In cross-organisational business interactions, integrating different partners raises interoperability problems especially on the technical level. The internal processes and interfaces of the participating partners are often pre-existing and have to be taken as given. This imposes restrictions on the possible solutions for the problems which occur when partner processes are integrated. In this paper, we describe a solution which supports rapid prototyping by combining a model-driven framework for cross-organisational business processes with an agent-based approach for flexible process execution. We show how the W3C recommendation for Semantic Web service descriptions can be combined with the model-driven approach for rapid service integration. Keywords: Model Driven Architectures for interoperability, Agent based approaches to interoperability, Service oriented Architectures for interoperability, Semantic-web based interoperability approaches

1 Introduction Flexible and rapid integration of collaborating partners into executable business processes requires methods and tools for resolving interoperability problems which arise from heterogeneous IT environments. The European project ATHENA (Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications) provides a comprehensive set of methodologies and tools to address interoperability problems of enterprise applications in order to realize seamless business interaction across organizational boundaries. For improving the effectiveness, timeliness and competitiveness of the IT solutions needed, currently, service-oriented architectures (SOA) are considered * The work published in this paper is (partly) funded by the E.C. through the ATHENA IP. It does not represent the view of E.C. or the ATHENA consortium, and authors are solely responsible for the paper’s content.

652

Ingo Zinnikus, Christian Hahn, Klaus Fischer

the most appropriate approach for flexible integration of partners. It enables partners to offer the functionality of their systems via a public service interface (e.g. using WSDL, [1]) and hide the sensitive parts behind it. A very important second advantage of SOA is the possibility of a loose coupling of partners. New partners can enter the system with little effort whereas obsolete partners are able to leave it easily. Since, in our view, agents are an abstraction of services, we use an agent-based approach for modelling and executing the collaborative business interaction. Due to the rather static nature of many business scenarios, often a rather fixed execution platform as e.g. BPEL4WS [2] is used. However, even in traditional collaborative settings, points or situations of choice occur, where the specific partner which delivers a specific task, can be selected even at execution time, thus allowing a certain flexibility. Especially in the case where additional smaller non-OEM manufacturers providing e.g. vehicle parts like radios or tires are integrated in the sales process, the system needs to become robust against temporary unavailable partners. We argue that the application of agents enables a flexible business process execution. Since existing services have to be integrated, the agents are situated in a service-oriented and specifically, a Web service environment. Two tasks which involve interoperability problems have to be tackled: x x

integrate services which are "fixed" i.e. known in advance when the process is specified. Provisioning services at design time which are additionally required or could be beneficial for improving the overall result or reducing costs.

When integrating partners into a collaborative process, interoperability problems occur on a syntactical as well as on a semantical level [3]. For solving the interoperability problems related to service and process integration, the Semantic Web initiative proposed to harness formalized knowledge representation, i.e. ontologies, for aligning heterogenous data models. Several proposals for semantically enhanced service descriptions were submitted for standardisation, namely, OWL-S [4], WSMO [5] and SAWSDL [6], which has just reached the status of a proposed recommendation within W3C. SAWSDL extends the de-facto standard for service description (WSDL) by annotating elements in a service description and providing schema mappings for transformation of data. The annotation of elements can be used for service discovery whereas the mapping information can be used for invocation of a service. It is this latter feature which makes SAWSDL an interesting candidate for service integration, because, based on a well established standard (WSDL), a service provider can supply its partners not only with a syntactical description of his service interface via a WSDL file, but additionally with the information required for ad-hoc invocation of his service. In this paper, we use a model-driven approach for the integration of existing services and, by using SAWSDL service descriptions, show how a SAWSDL description of partner services can be used to accelerate the integration process. The paper is organized as follows. In Section 2 we will sketch the business case of our pilot application which we use as motivational background, containing static interactions with dynamic features. Section 3 is devoted to our technical approach.

A Model-driven, Agent-based Approach for a Rapid Integration

653

Here, we present the approach developed in ATHENA and used within our pilot for the integration of cross-organizational processes. We describe how the W3C recommendation SAWSDL can be used for facilitating service integration in Section 4, discuss related work in Section 5 and conclude the paper by taking a look at the lessons learned in Section 6.

2 Scenario In 2002, due to new laws in EU legislation, the market of car distribution changed fundamentally. Instead of being limited to selling only one brand, vending vehicles of different brands under one roof was facilitated. Dealers now can reach a broader audience and improve their business relations for more competitiveness. As a consequence, many so-called multi-brand dealers have appeared. Today, multi-brand dealers are confronted with a huge set of problems. Rather than having to use the IT system of one specific car manufacturer, multi-brand dealers are now faced with a number of different IT systems from their different manufacturers. One specific problem is the integration of configuration, customization and ordering functionality for a variety of brands into the IT landscape of a multi-brand dealer. We describe an integrated scenario, where multi-brand dealers use services provided by the different car and non-OEM manufactures and plug them into an integrated dealer system.

Fig. 1. Overview over the architecture of the solution.

The desired to-be-scenario with its general architecture is depicted in Figure 1. The systems of the different car and non-OEM manufacturers are integrated via an integrator component. This integrator enables the dealer to access the software of the manufacturers in a uniform manner. The paper will focus on the manufacturer integration (Section 3) and present the model-driven, agent-based integration approach for cross-organizational processes modeling. For the service integrator, the generated process models are executed as software agents on Jack [7], an agent platform based on the BDI-agent theory (belief-desire-intention, [8]). In the following, we will describe this approach in detail.

654


3 Agent-based Modelling and Execution of Inter-organisational Processes Business process modelling and execution in this collaborative environment requires a set of methodologies and tools which support the transition from an analysis to an execution level and integrate the process with a pre-existing IT infrastructure. In business-driven scenarios, a top-down approach is often applied [9]: a human-comprehensible analysis model which is used for communication among analysts is enriched with process and data details which yields a design model. For generating run-time artifacts, the design model is enriched by technical details leading to a technical model which in turn is transformed into executable code. We follow the approach outlined in Kahl et al. [10] where business processes are modelled on different abstraction levels and transformed down from a business layer to a technical and an execution level. An agent-based approach is applied for modelling and transforming the technical layer to the execution layer. In [10], for the technical level a platform-independent metamodel for service-oriented architectures (PIM4SOA, an ATHENA result [11]) was used. In this section, we concentrate on the technical level. The scenario as described in Section 2 involves a complex interaction between the partners. The design of such a scenario implies a number of problems which have to be solved: x x x x

the different partners (may) expect different atomic protocol steps (service granularity) changing the protocol and integration of a new partner should be possible in a rapid manner (scalability) the execution of the message exchange should be flexible, i.e. in case a partner is unavailable or busy, the protocol should nevertheless proceed the partners expect and provide different data structures

These are typical interoperability problems occurring in cross-organisational scenarios which in our case have to be tackled with solutions for agents and SOAs. A core idea in the ATHENA project was to bring together different approaches and to combine them into a new framework: a modelling approach for designing collaborative processes, a model-driven development framework for SOAs and an agent-based approach for flexible execution. It turned out that these approaches fit nicely together, as e.g. the PIM4SOA metamodel and the agents’ metamodel bear a striking resemblance to each other. Hence, the first problem is solved by specifying a collaborative protocol which allows adapting to different service granularities. Scalability is envisaged by applying a model-driven approach: the protocol is specified on a platformindependent level so that a change in the protocol can be made on this level and code generated automatically. Flexibility is achieved by applying a BDI agent-based approach. BDI agents provide flexible behaviour for exception-handling in a natural way (compared to


655

e.g. BPEL4WS where specifying code for faults often leads to complicated, nested code). Finally, the mediation of the data is tackled with transformations which are specified at design-time and executed at run-time by transforming the exchanged messages based on the design-time transformations. For integrating consortial partners and their services, partners define the shared process together. The common information/data model can also be defined together. Roughly speaking, two alternatives are possible (analogous to the local-as-view vs. global-as-view distinction, cf. [12]): the common data structure is defined independently from the local data model of each partner. Each partner then defines a (local) mapping from the common data model to the local model. The main advantage of this approach is scalability, i.e. the number of mappings which have to be specified is reduced from m*n (in the case of m partners interacting directly with n partners) to m+n [13]. The mapping in turn can be executed (at run-time) either by the consumer of the service or the partner service itself. The first solution is the one preferred by Semantic Web service descriptions, e.g. SAWSDL where the service provider describes the mapping to e.g. XML Schema. The mapping is used by a service consumer who invokes the service. The second solution means that the service consumer always sends the same message (e.g. a SOAP message) to a partner service and does not care about the local data model. This is reasonable if specifying as well as testing the mapping is tedious and the mapping underlies many changes. In a global-as-view approach, the common data model is defined as view on the local data models of the partners. A disadvantage of this approach is that the integration of a new partner requires changing the common data model. PIM4SOA: A Platform-Independent Model for SOAs

In this section, we give a summary of a metamodel for service-oriented architectures which allows modelling service-oriented processes in a model-driven manner. Processes are specified at design-time, transformed to and executed on a specific agent platform. External partner services are provided as Web services and integrated into the specified process. The PIM4SOA is a visual platform-independent model (PIM) which specifies services in a technology independent manner. It represents an integrated view of SOAs in which different components can be deployed on different execution platforms. The PIM4SOA model helps us to align relevant aspects of enterprise and technical IT models, such as process, organisation and product models. The PIM4SOA metamodel defines modelling concepts that can be used to model four different aspects or views of a SOA: Services (see Figure 2) are an abstraction and an encapsulation of the functionality provided by an autonomous entity. Service architectures are composed of functions provided by a system or a set of systems to achieve a shared goal. The service concepts of the PIM4SOA metamodel have been heavily based on the Web Services Architecture as proposed by W3C [14].

656


Fig. 2. PIM4SOA Service Aspect.

Information is related to the messages or structures exchanged, processed and stored by software systems or software components. The information concepts of the PIM4SOA metamodel have been based on the structural constructs for class modelling in UML 2.0 [15]. Processes describe sequencing of work in terms of actions, control flows, information flows, interactions, protocols, etc. The process concepts of the PIM4SOA metamodel have been founded on ongoing standardization work for the Business Process Definition Metamodel (BPDM) [16]. Non-functional aspects can be applied to services, information and processes. Concepts for describing non-functional aspects of SOAs have been based on the UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms [17]. Via model-to-model transformations, PIM4SOA models can be transformed into underlying platform-specific models (PSM) such as XSD, Jack BDI-agents or BPEL.


657

Fig. 3. PIM4SOA Model for Pilot (part).

Transforming the metamodel to an agent platform and integrating partner services

The business protocol between dealer (dealer software), integrator and manufacturers is specified as PIM4SOA model (see Figure 3). In order to execute collaborative processes specified on the PIM level, the first step consists of transforming PIM4SOA models to agent models that can be directly executed by specific agent execution platforms. In our case, the Jack Intelligent agent framework is used for the execution of BDI-style agents. The constructs of the PIM4SOA metamodel are mapped to BDI-agents represented by the Jack metamodel (JackMM). For detailed information on JackMM we refer to [18]. In this service-oriented setting, the partners provide and exhibit services. Partner (manufacturer etc.) services are described as WSDL interfaces. The WSDL files are used to generate integration stubs for the integrator. We use a modeldriven approach for mapping WSDL concepts to agent concepts, thereby integrating agents into a SOA and supporting rapid prototyping. The partner models are transformed to a Jack agent model with the model-tomodel transformation developed in ATHENA. The following sketch outlines the metamodel mappings (see Figure 4).

658


Fig. 4. PIM4SOA and WSDLMM to JackMM transformation.

A ServiceProvider (i.e. ServiceIntegratorProvider in Figure 3) is assigned to a Team (which is an extension of an Agent). The name of the ServiceProvider coincides with the name of the Team, its roles are the roles the Team performs. Furthermore, the team makes use of the roles specified as bound roles in the CollaborationUse (i.e. Dealer and Manufacturer), in which it participates. For each of these roles, we additionally introduce an atomic Team. The Process of the ServiceProvider is mapped to the TeamPlan of the non-atomic Team. This TeamPlan defines how a combined service is orchestrated by making use of the services the atomic Teams (i.e. ManufacturerTeam and DealerTeam in Figure 5) provide. Finally, Messages that are sent by the roles we already have transformed are mapped to Events in JackMM.

Fig. 5. Jack Model generated from PIM4SOA (part).

The process integrator and the manufacturers are modelled as Web services. Their interface is described by WSDL descriptions publishing the platform as Web service. In the pilot, only the process integrator is executed by Jack agents which


659

are wrapped by a Web service, whereas the manufacturers and other partner services are pure Web services. For integrating Web services into the Jack agent platform, we map a service as described by a WSDL file to the agent concept Capability which can be conceived of as a module. A capability provides access to the Web services via automatically generated stubs (using Apache Axis). A capability comprises of plans for invoking the operations as declared in the WSDL (it encapsulates and corresponds to commands such as invoke and reply in BPEL4WS). By executing the model transformations we automatically derive the JackMM model illustrated in Figure 5 (for more details, cf. [18]). This Jack model can in turn be automatically transformed into Jack code (e.g. in Figure 6) which can be modified with the Jack development environment, if necessary. It should be stressed that these model transformations and the respective code generation can be done automatically if (i) the PIM4SOA model is defined properly and (ii) the WSDL descriptions are available. The only interventions necessary for a system designer are the insertion of the proper XSLT transformations and the assignment of the capabilities to the agents/teams responsible for a specific Web service invocation.

Fig. 6. Generated Jack Team Plan for ServiceIntegrator.

660


4 Interoperable Services: Improving the Integration Process The integration of partners as described in the previous section is based on the assumptions that partners provide their service description in a WSDL format and that the mapping between heterogeneous data formats is specified especially for integrating the partner service at a pre-defined place in the process. However, a more flexible way of integrating is required if a SOA should tap its full potential. Therefore, a service description which supports flexible integration has to contain additional mapping information for mediating different data structures. In our automotive scenario, there are a number of standards which can form the basis for the global information model (e.g. STAR standard for automotive retail industry 29). The concepts of the standard and their relation to each other are either integrated into the common data model or used as annotation of the data model. If the local data model of the partners differs from the common model, the local partner is responsible for defining a mapping from the common model to the local model. If we assume that partners or other external services use the same vocabulary for their service description (or their annotation), the concepts can be used to annotate service descriptions and specify a mapping from the global data structure to the partner services and vice versa. This assumption of a shared vocabulary among actors is reasonable, since in our scenario product data underlies strong standardization pressure. As mentioned in the introduction, the Semantic Web standard SAWSDL is a suitable candidate for improving the integration process described in the previous section since it is open enough to allow for annotation with arbitrary ”models”, i.e. ontologies, embodied in the global data structure. Furthermore, SAWSDL contains references to a liftingSchemaMapping and a loweringSchemaMapping. A liftingSchemaMapping takes as input XML data (that adheres to a given XML schema) and produces semantic data (that adheres to a semantic model, in our case the global data model) as output. The application of a loweringSchemaMapping has the reverse effect. Both mappings can be used to facilitate the integration steps described in the previous section. Partners annotate their WSDL with mappings to and from the global data structure and produce a corresponding SAWSDL description. The transformation to Jack models can still be done according to the model-driven approach. The XSLT transformations which were necessary for each integration task can now be isolated and embedded into the service description. This allows reusing the service description at different steps inside and outside of the collaboration. Annotating an existing WSDL description of a service for integration is an additional effort for a partner; however, the advantage is reusability of a service description if the collaborative process changes.

29 www.starstandard.org/


661

5 Related Work Apart from the wealth of literature about business process modelling, enterprise application integration and SOAs, the relation between agents and SOAs has already been investigated. [19] cover several important aspects, [20] propose the application of agents for workflows in general. [21] and [22] present a technical and conceptual integration of an agent platform and Web services. However, the model-driven approach and the strong consideration of problems related to crossorganisational settings have not been investigated in this context. Furthermore, our focus on tightly integrating BDI-style agents fits much better to a model-driven, process-centric setting than the Web service gateway to a JADE agent platform considered by e.g. [21].

6 Conclusions and Summary From a research transfer point of view, the following lessons could be learned: x

x x

Evidently, a model based approach is a step in the right direction as designtime tasks are separated from run-time tasks which allows performing them graphically. Moreover, it is easier to react to changes of the different interacting partners as only the models have to be adapted but not the runtime environment. A model-driven, agent-based approach offers additional flexibility and advantages (in general and in the scenario discussed) when agents are tightly integrated into a service-oriented framework. The new Semantic Web service standard SAWSDL supports integration of services into an existing business process.

In this paper, we presented a pilot developed within the EU project ATHENA in the area of multi-brand automotive dealers. For its realization, several integration problems on different levels had to be solved. We described a solution which supports rapid prototyping by combining a model-driven framework for cross-organisational service-oriented architectures with an agent-based approach for flexible process execution. The model-driven approach can be extended using Semantic Web service descriptions for service integration.


E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) 1.1. W3C, 2001-03-15 2001. Business process execution language for web services, version 1.1. Technical report, OASIS, 2003-05-05 2003. Omelayenko, B. and Fensel, D. (2001): A two-layered integration approach for product information in B2B e-commerce. In Madria, K. and Pernul, G., editors, Proceedings of the Second International Conference on Electronic Commerce and

662

[4]

[5]

[6]

[7] [8]

[9]

[10]

[11]

[12]

[13]

[14]

[15] [16]

[17]

[18]


Web Technologies (EC WEB-2001), number 2115 in LNCS, pages 226–239. Springer-Verlag. Martin, D., Burstein, M., Hobbs, J., Lassila, O., McDermott, D., McIlraith, S., Narayanan, S., Paolucci, M., Parsia, B., Payne, T., Sirin, E., Srinivasan, N., Sycara,K. (2004): OWL-S: Semantic Markup for Web Services. W3C Member Submission, 22 November 2004. Available from http://www.w3.org/Submission/OWL-S/. de Bruijn, J., Bussler, C., Domingue, J., Fensel, D., Hepp, M.,Keller, U., Kifer, M., König-Ries, B., Kopecky, J., Lara, R., Lausen, H., Oren, E., Polleres, A., Roman, D., Scicluna, J., Stollberg, M. (2005): Web Service Modeling Ontology (WSMO). W3C Member Submission, 3 June 2005. Available from http://www.w3.org/Submission/WSMO/. Farrell, J., Lausen, H. (ed.) (2007): Semantic Annotations for WSDL and XML Schema. W3C Proposed Recommendation, 05 July 2007. Available from http://www.w3.org/TR/sawsdl/. JACK Intelligent Agents, The Agent Oriented Software Group (AOS), http://www.agent-software.com/shared/home/, 2006. Rao, A.S., Georgeff, M.P. (1991): Modeling Rational Agents within a BDIArchitecture. In: Allen, J., Fikes, R., Sandewall, E., eds.: 2nd International Conference on Principles of Knowledge Representation and Reasoning (KR91), Morgan Kaufmann publishers Inc.: San Mateo, CA, USA (1991) 473–484. Koehler, J., Hauser, R., Küster, J., Ryndina, K. and Vanhatalo, J., Wahler, M. (2006): The Role of Visual Modeling and Model Transformations in Business-driven Development. Proceedings of GT-VMT 2006, pages 1-12, 2006. Kahl, T., Zinnikus, I., Roser, S., Hahn, C., Ziemann, J., Müller, J.P., Fischer, K. (2007): Architecture for the Design and Agent-based Implementation of Crossorganizational Business Processes. 3rd International Conference on Interoperability for Enterprise Software and Applications (I-ESA 2007). Benguria, G., Larrucea, X., Elvesæter, B., Neple, T., Beardsmore, A., Friess, M. (2006): A Platform Independent Model for Service Oriented Architectures. 2nd International Conference on Interoperability of Enterprise Software and Applications (I-ESA 2006). Lenzerini, M. (2002): Data integration: a theoretical perspective. In Proceedings of the Twenty-First ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems (Madison, Wisconsin, June 03 - 05, 2002). PODS ’02. ACM Press. Fensel, D., Ding, Y., Omelayenko, B., Schulten, E., Botquin, G., Brown, M., and Flett, A. (2001): Product data integration for B2B e-commerce. IEEE Intelligent Systems, 16(4):54–59. W3C, Web Services Architecture, World Wide Web Consortium (W3C), W3C Working Group Note, 11 February 2004. http://www.w3.org/TR/2004/NOTE-wsarch-20040211/ OMG, UML 2.0 Superstructure Specification, Object Management Group (OMG), Document ptc/03-08-02, August 2003. http://www.omg.org/docs/ptc/03-08-02.pdf IBM, Adaptive, Borland, Data Access Technologies, EDS, and 88 Solutions, "Business Process Definition Metamodel - Revised Submission to BEI RFP bei/200301-06", Object Management Group (OMG), Document bei/04-08-03, August 2004. http://www.omg.org/docs/bei/04-08-03.pdf OMG, UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms, Object Management Group (OMG), Document ptc/04-09-01, September 2004. http://www.omg.org/docs/ptc/04-09-01.pdf Hahn, C., Madrigal-Mora, C., Fischer, K., Elvesæter, B., Berre, A.J., Zinnikus, I. (2006): Meta-models, Models, and Model Transformations: Towards Interoperable Agents. MATES 2006.


663

[19] Singh, M., Huhns, M. (2005): Service Oriented Computing: Semantics, Processes, Agents. John Wiley & Sons, Chichster, West Sussex, UK (2005). [20] Vidal, J.M., Buhler, P., Stahl, C. (2004): Multiagent systems with workflows. IEEE Internet Computing, 8(1):76–82, January/February 2004. [21] Greenwood, D., Calisti, M. (2004): Engineering Web Service –- Agent Integration. IEEE Systems, Cybernetics and Man Conference; 10-13 October, 2004, the Hague, Netherlands. [22] Dickinson, I., Wooldridge, M. (2005): Agents are not (just) web services: Considering BDI agents and web services. AAMAS 2005 Workshop on Service-Oriented Computing and Agent-Based Engineering (SOCABE).

BSMDR: A B/S UI Framework Based on MDR Panxiang Zhang, Song He, Qing Wang, Huiyou Chang Department of Computer Science, ZhongShan University, GuangZhou 510275, China {percy_zhang, hesong0326}@hotmail.com, [email protected], [email protected]

Abstract. The MDR(Model-Driven Runtime) environment is able to execute a PIM for a specific purpose such as generate system UI framework, which precisely models system UI and improves the UI development efficiency and maintainability. Model-Driven UI system such as Fuse or Versuf is aimed to GUI or general web UI rather than B/S UI of MIS. In this paper, we describe a B/S MIS’s UI framework based on Model-Driven Runtime. Firstly, we introduce the modeling process of UI requirement Analysis Model in the requirement analysis stage, including the task model and domain model. Then the paper shows how BSMDR transform such models into Platform Independent Model, including Object Model, Layout Model, Content Model, Presentation Model, Interaction Model and Mapping Model. Finally, we focus on the design and implementation of the BSMDR Framework, demonstrate our approach with an example. Long-term application shows that BSMDR can generate most of the presentation layer pages and greatly facilitate the User-interface development. Keywords: MDA, MDR, BS UI Framework

1 Introduction 1.1 Background

MDA is a software development framework presented by OMG[1](Object Management Group) in July, 2001. It is proposed in order to adapt to the shifting changes of the software requirements and development technology, upgrade the software develop process to a higher abstract level – Analysis Model. Model can precisely describe the system (or part of the system) with modeling language, which can be easily understood by computer[2]. MDA defines three models, CIM, PIM and PSM, from requirements analysis, system design and architecture, including technical details of the system aspects.

666

Panxiang Zhang, Song He, Qing Wang, Huiyou Chang

CIM(Computation independent model) is independent from software and used to describe business logic. PIM(platform independent Model) describes the system’s architecture. And PSM(platform specific Model) describes the model based on specific software development environments. The essence of MDA technology is abstract to get the PIM which is independent form realization technology and can precisely describe the system, then transform tools will convert PIM into specific technology-related PSM, and finally generate code. MDR(Model Driven Runtime) proposed by Jorg Pleumann and Stefan Haustein in 2003, abandoned the PIM to PSM conversion process and the PSM to code generation process in MDA, was able to dynamically analyze and generate code in runtime[3]. In MDR environment, we only need to provide PIM and API of storage and reading PIM. Then provide MDR runtime analytical models, code can be dynamically generated. MDR hide PSM and the PSM code generation process in its analytical model and the process of implementation. It provides different MDR for realization on different platforms, which helps different platforms share PIM to achieve MDA's original purpose. 1.2 MDR and Limitation of MDA

MDR solve many limitations in MDA[1]: Iteration is not required in MDR-Based System, PIM can generate code directly through the interpreting and executing of MDR, and therefore there are no complex issues brought by MDA. 2. MDR-based system abandoned PSM model, transition of these model and code generation process, which makes the system easier to maintain and debug. 3. MDR-based system to provide the storage and reading process of the PIM, the interpreting and executing of models are dynamic, so we can directly maintain the PIM and then MDR will dynamically interpret and execute these models.

1.

Although MDR systems abandon PSM, Model transition and code generation process, which will bring us some influence, MDR still retains many key features in MDA: MDR model is platform-independent. MDR preserves PIM’s feature of MDA, which makes PIM can still be shared in the use of different platforms. 2. MDR is still PIM-driven. In MDR-based software development process, PIM is defined firstly to drive the entire software development process. The difference is, in MDA System we must give definitions of PSM, PIM to PSM and the PSM code generation process, while in MDR systems MDR dynamically complete these processes. 1.

BSMDR: A B/S UI Framework Based on MDR

667

1.3 Our Work

The essence of MDR is still Model-Driven. There are many model-driven interface systems such as FUSE[4] and Vesuf[5] System. But all of these models are targeted at the graphical user interface or the common Web interface rather than B/S information system user interface. B/S information system UI is more suitable for model-driven development than WUI[6] and GUI or other UI frameworks[7,8] because: WUI is information-presentation oriented, while B/S Information System is always designed as task-oriented. B/S info system's user interaction model is more simple and fixed than WUI. 2. B/S information System use client browser as interaction platform. Endusers with different types of browsers require a rapid model-driven development prototype. 3. B/S information System UI doesn’t contain complex business logic but page layout and presentation code, which facilitates the page code generation. 1.

In this paper, we study the deficiencies of current B/S information system's UI models, propose a new B/S information system UI model, including Interface Requirements Analysis Model and Platform Independent Model. Interface Requirements Analysis Model is created in the requirements analysis phase by domain modeling experts. PIM is created in design and development phase to drive the interface code generation. At last, our paper focuses on the design and implementation of the MDR-based B/S information System UI Framework.

2 UI Requirements Analysis Model Interface requirement analysis modeling, built by the domain model experts is used in the interface required anlysis phase. This model consists of two parts, the task model and the domain model. The task model represented by the UML use case diagram is used to describe the users, the interface, use cases and the relationship among all of them. The domain model represented by the UML classes diagram is used to describe the conception object of the interface and the relationship of data sources among the conception objects. 2.1 Task Model

Task model describes the tasks directly participated in B/S information system by terminal user. It specifies interface of B/S information system, and use case of information system included by each interface in a high level. Information system’s use cases reflect original task attended by user participating in information system, such as creating and editing an In-Store Sheet etc.

668


Task model is presented by Use-Case Diagram of UML, which will be explained as follow diagram. Storing of the task model adopts the form of XMI compatible with UML.

Fig. 1. Example of Task Model

2.2 Domain Model

Domain model describe the concept class inferred by user interface system or object in the real world, store the object or entity dealt by user interface system. It just shows the abstract object. MDR can use it directly only after the system transforms the domain model to the object model of PIM. Domain Model is presented by class diagram of UML. Storing of the domain model adopts the form of XMI compatible with UML.

Fig. 2. Example of Domain Model

3 Modeling of PIM Platform Independent Model includes Object Model, Layout Model, Content Model, Presentation Model, Interaction Model and Mapping Model. Object Model is a more detail domain model, describing object, properties of object and properties of the properties of the object. Frame model describes the layout and the


669

division of the frame in the page. Representation model describes the page style of the generated page, and this model is open to users for customization of the UI. Interaction model describes interaction and navigation on the page. Mapping model describes the mapping relationships among other models of PIM. The content model is interface content’s modeling, corresponding with a division of layout model. It includes static text, dynamic text, image, navigation, page cited and information component. := (*) := (ID,<StaticText>||| |<PageReference>|) := (<SrcType>,) <SrcType> := (PAGE|SESSION|REQUEST) := ([,Length][,Width]) := (NavigationGroupID,()*) := (,URL,| <ButtonNavigation>|) := () <ButtonNavigation> := (<ButtonText>) := () <PageReference> := (ReferenceURL) := (,|)

The B/S information systems are relatively simple in interactive, generally completed by navigation. This definition of the interface system framework includes two interactive mode, link interaction and function interaction. Because of this interface framework for the user interface is based on HTML / JSP / JavaScript. All the interactive can be completed by JavaScript. Our paper referring to the function interaction is JavaScript interactive function. 3.1 Object Model

Object Model is more detail domain model. Generally, the class of it is corresponding to the class of domain class. Besides class name, property name and data source name, object model includes the following data. x x x x x x x x

Usually, the database’s table name of class is the database’s table name. (if more than one database table with the class, class only shows the primary database table, and secondary tables are defined in the attribute). Page name, is an attribute in the manifestation name on the page. Reserved field, this attribute is for the system’s future extension. Reserved attribute is used or not, means whether reserved attribute is used or not. Validation, system provides simple verification. The more complicated logic inspection needs to write codes during the period of developing. Text’s max length, aims at checking whether a string is legal length or not. Required Value. The yes Value refers to the submission of data, the data can not be empty or NULL, convenient for the data inspection. Default value. Pre-defined a value for the data.

670


x

Data sources of data were divided into four: no data source, predefine data sources, SESSION data sources and REQUEST data sources.

:= (*) := (,,) :=,,,, <PageName>,,,,,<MaxLen>, , ,) := (String|[Positive|Zero|Negative]Integer|Positive|Zero|Negative] Numeric|Bool|EmailAddr|DateTime) := (NoneSrc|OrdinarySrc|SessionSrc|RequestSrc) := (*) <SessionSrc> := (<SrcName>,,) := (<SrcName>,,)

Since there is no corresponding UML model to describe object model, we use XML to store it. 3.2 Layout Model

The layout model describes the B / S information system interface’s layout model. The main description of the layout model is the division of the interface, before division, the entire interface is a whole. The division can be divided to subdivision. Sub-division can also be divided to sub-sub-division. Next, there is an example to explain the division using the formal symbols. The division includes five leaf division and two non-leaf division, the serial numbers of leaves is 2, 4, 5 and 7, respectively, of the non-leaf numbers 1 and 3. Number 6 and number 7 average number 3, taking 50% each.

Fig. 3. Example of Layout Model

In this paper the layout of the interface uses the symbols of the figure 3. Formal description of the symbols divided into five: Root division, horizontal division, vertical division, leaves division and derivatives. Fig. 4 shows the result of Fig. 3.

Fig. 4. Result Layout of Fig 3


671

3.3 Presentation Model

Presentation model is the content model presenting in the page. The content model of static text, dynamic text, photographs, and page navigation group in the presentation model is simple and corresponds with HTML tags. And we focus on the information components (form component and list component) of Presentation model. Form component includes information group ID, title and column count. ID is used only identification information packet. Title is displayed on the head of the form. And column count is listed on a page the number of column. := ( InfoGroup>*, * <MappingRelation>*) := (,<PageName>,) := (,,, ,,,[,] [,]) := (|<SingleLineTextBox>|<MultiLineTextBox>|| ||||<SpecialCtrl>) <MappingRelation> := (,)

Generally, list component shows the results of inquiries. Its presentation model includes such attributes: List ID, title, Pagination Item Count Each Pagination. And it also includes the mapping relation between list component and attribute of object model, the attribute’s location column. Its logic definition is like above BNFs. 3.4 Mapping Model

Mapping model describes the relationships of object model, layout model, content models, presentation models and interactive model. The mapping relationship between layout model layout and content model uses the layout number and content model ID. The framework can be linked, for the content will be placed in designated layout in the interface. The mapping relationship between content model layout and interactive model uses the navigation number and interactive model ID. There is an interactive function only in the navigation of the content model. Through this mapping relation, framework can generate interactive code. The mapping relationship between content model and presentation model uses content ID and presentation model ID. So framework can present pre-defined page through the pre-defined content. The mapping relationship between presentation model and object model has implied, and does not need the establishment of another model mapping and additional XML storage space.

672


Fig. 5. Example of Mapping Model

4 Design and Realization 4.1 Architecture, Develop Process and Execute Process

Fig. 6. System Architecture

Fig. 6 shows the entire architecture of our system, including the following parts: x x

System participants are domain experts, design/develop specialists and customers. UI Model, including UI Requirements Analysis Model (UIRAM) and Platform Independent Model (PIM), as described above chapter.


x

x x

673

System Component contains MDR, UIRAM Component, PIM Component, XMI/XML Access Component, Presentation Model Edit Tools and JSP pages. MDR is the core of system. It reads system UI PIM and generates page code according to the request of JSP page. UIRAM abstracts the requirements analysis model, configures the requirements analysis model and initializes the PIM. PIM component abstracts the PIM, reads, caches and persistence the PIM. Model Storage and Cache. We store UIRAM into XMI files, PIM into XML files, while Cache is used to accelerate the speed of MDR analysis and execute. UML tools and other extensive tools.

The development of BSMDR divides into the following 5 phase.

Fig. 7. Development Process

x x x x x

Domain Expert uses UML tools to create UIRAM(including task model and domain model), defines functions and conception objects in the Interface. Initialize PIMs with UIRAM created in step 1. Design/Develop specialists revise and review PIMs with tools or directly edit it. Design/Develop specialists edit JSP page code. The JSP pages only need to include code for MDR to generate UI framework and some special control. User can revise the display style of pages by editing the presentation model.

The entire process above is model-driven. Only the JSP pages development process needs to write a small number of interface code, and other processes are directly create or modify models.

674


Fig. 8. UI Running process

The execution of MDR and generation of page code is also model-centric. 1) User requests certain JSP page from server. 2) Servlet analyzes JSP page and send request to MDR component with code dev specialist written in JSP. 3) MDR requests the PIM component for the PIM models requested in current process when receive a JSP request. 4) PIM component gets Models from Cache or XML files and return to MDR. 5) MDR generates page code with models get from step 4 and code generation algorithms. 6) Servlet gets the page code in step 5 and then adds it into JSP pages, and finally generates the result html page. 4.2 Design, Class Diagram and Interface Design

Fig. 9. Class Diagram

As Figure 9 shows is the system class diagram. MDRInterface includes the following four interfaces, generatePageCode can generate page html code by pageName parameter, generateContextHTML generate content model’s html code according to content model itself, generateDivHTML generate html code based on tables, and setCodeGeneratorPlugIn is used to set plugin for MDR code generation. Plugin is mainly used to customize the page code style and minimize the scale of model. In B/S information system, the UI is almost the same, for example, forms colors, the style controls, button styles, etc. So it is helpful to use code generation plugin to generate a unified interface code, without the tedious work to configure of presentation models. The definition of code generation plugin is in Fig. 9.


675

In Class Diagram, besides MDRInterface and CodeGenerationPlugin, PIMModel manage PIM and its related operations. PIMModelPersistence manage the persistence work of PIM, which including Read Model from XML and save Model to XML process. RequirementModel manage the UIRAM and its related operations. RequirementModelReader is used to read model from UML XMI files. And DataObject, MappingObject, ContextObject, PageDiv, PresentationModel, InteractionObject, TaskModel, DomainObject as show in diagram. 4.3 Case Study

Through UI required analysis stage, we get Interface requirement analysis modeling. Here I will introduce an example to explain how the B/S information system generates code by PIM. Firstly, we defined a layout model. In the layout model we can define how many divisions we need. Then in each division block, we can define the data presented in that block.

Fig. 10. Layout/Content/Object Model

Configure Object Model instance. Each attribute can be edited as Fig. 11 shows.

Fig. 11. Object Model in detail

List Component in Fig. 12 as an independent component in content model, we can configure this component for result display. We also can configure the details of the component in presentation model.

Fig. 12. A list Component

Interactive model we should only give the image’s name and the JavaScript function name as the top buttons in Fig. 13 shows. After all these settings, we get the following result page.

676


Fig. 13. Result Page

5 Conclusions BSMDR UI Framework greatly enhance the UI develop efficiency of the B/S information system. First, it moves the concern point of UI development to a macro level, developers just need to focus on models rather than pages or code in every phase of development; second, it reduces the code amount, page code can be generated automatically by writing MDR code or special control code; Third, the process of developing UI and developing system is efficiently join together, task model and domain model can be shared in both sides, all of those facilitates the efficiency of development. BSMDR UI Framework also improves the Maintainability of the information system. Customers can directly revise the presentation model to change the display style of UI, reduce the maintenance job of design/development specialists. Code Generation Plugin reduces the duplicated code and enhanced the flexibility of the code generation process. Update of UI Framework can be done by reviewing the UI models, which is easier to maintain. In this paper, through analysis and model of UI requirements analysis model and PIM, we design and implement a B/S information system UI framework. UI code can be generated by dynamically analyze and execute the MDR model and MDR component as section 4.2 described. This paper still has many items need for further improvement. Interaction Model of BSMDR is simple and can fulfill most of the system requirements, but it also restricts the interaction ability and application field of system. This paper hasn’t performed much works on the Cross-platform study, especially the crossplatform application of BSMDR framework. Modeling tools is not obligatory in our system, but efficiency can be greatly enhanced when it is provided. We use BNF to describe PIM in this paper, and how to describe in UML is also an important topic in further research.


677

References [1] [2] [3] [4] [5]

[6] [7]

[8]

Object Management Group. http://www.omg.org/mda/. 2001 Anneke Kleppe, Jos Warmer, Wim Bast, MDA Explained:The Model Driven Architecture:Practice and Promise, Addison Wesley, 2003 Jorg Pleumann, Stefan Haustein. A model-driven runtime environment for web application. Springer Verlag, UML Conference 2003, LNCS. 2003. Frank LonczewskiInstiute. Providing user support for interactive applications with FUSE. Proceeding of ACM Press, 1997. Lars Braubach, Alexander Pokahr, Daniel Moldt, Andreas Bartelt, Winfried Lamersdorf. Tool-Supported Interpreter-Based User Interface Architecture for Ubiquitous Computing. Springer-Verlag Berlin Heidelberg DSVIS 2002 LNCS 2545 2002: 89-103. Piero Fraternali, Paolo Paolini. Model-driven development of Web applications of the AutoWeb system. ACM Press 2000 Transaction. 2000: 323-382. Jurgen Falb, Thomas Rck, Edin Arnautovic. Fully-automatic generation of user interfaces for multiple devices from a high-level model based on communicative ats. Proceedings of the 40th Hawaii International Conference on System Sciences. 2007. Christian Janssen, Anette Weisbecker, Jurgen Ziegler. Generating User Interface from Data Models and Dialogue Net Specification. INTERCHI 1993. 1993.

A Proposal for Goal Modelling Using a UML Profile Reyes Grangel1, Ricardo Chalmeta1, Cristina Campos1, Ruth Sommar1, Jean-Pierre Bourey3 1

2

3

Grupo de Investigación en Integración y Re-Ingeniería de Sistemas (IRIS), Dept. de Llenguatges i Sistemes Informàtics, Universitat Jaume I, 12071 Castelló, Spain {grangel, rchalmet, camposc}@uji.es Combitech, SE-164 84 Stockholm, Sweden [email protected] Laboratoire de Génie Industriel de Lille, Ecole Centrale de Lille, 59561 Villeneuve d’Ascq Cedex, France [email protected]

Abstract. UML has become the standard object-oriented language for modelling systems in the domain of Software Engineering. More and more relationships are being established between this domain and the Enterprise Modelling context, and the number of advantages of using UML as knowledge representation language is also growing. Some recent research works, such as the MDE approaches, suggests it would be interesting to provide concrete methods and mechanisms that facilitate the much-needed link between enterprise models and the requirements defined to develop the computer system. UML is a good candidate to connect these two levels, that is to say, the CIM level and the PIM level from an MDA perspective. In this paper, we present a Proposal for Enterprise Knowledge Modelling based on UML, which focuses on representing enterprise knowledge. This Proposal is developed at the CIM level and presents different models for capturing the software requirements of a Knowledge Management System at the CIM level. In particular, the metamodel concerning the goal dimension and the UML Profile implemented from it are shown. Finally, the resulting Goal Diagram is explained by means of an example. Keywords: Enterprise Modelling, Knowledge Representation, Goal Modelling, Model Driven Architecture, UML Profile

1 Introduction Enterprise Modelling refers to the externalisation and expression of enterprise knowledge [1], which provides a holistic view of an enterprise and considers all its dimensions, i.e. processes, decisions, information, behaviour, resources and so forth [2]. Nowadays, there are a great number of languages, standards,

680

R. Grangel, R. Chalmeta, C. Campos, R. Sommar, J.-P. Bourey

methodologies and their corresponding tools, such as GRAI [3], IEM [4], MEML [5], IDEF [6], etc., available for use. On the other hand, Unified Modeling Language (UML) has become a standard language for object-oriented modelling and has been used successfully for modelling software systems in very different domains [7]. However, UML is a general-purpose modelling language that can also be useful for modelling other types of systems such as, for example, an enterprise [8, 9]. Other works, such as [10], point out the possibility of using UML as a language for Enterprise Modelling, while in [11] it is explained how and under what conditions this can be performed. However, the benefits of model-driven approaches and the new specification of UML2 specification suggest the need to provide more practical examples for Enterprise Modelling with UML based on these recent works [12], and especially for Enterprise Knowledge Modelling. Some work, such as [13], has been carried out in this line, but this proposal is not enterprise-oriented and thus it does not take into account the different dimensions of the enterprise for modelling [14]. The main weakness of Enterprise Modelling is the lack of strong links between enterprise models and software generation [15]. One solution, as pointed out in [16], is that the role of enterprise models should be that of facilitating the design, analysis and operation of the enterprise according to models, i.e. it should be driven by models (model-driven). In this context, UML is a good candidate to establish the necessary links between enterprise models and systems models in general (and, more particularly, requirement engineering) using the extension mechanism of UML Profiles. Taking this context into account, the aim of the research presented in this paper was to consider the possibility of using UML for Enterprise Modelling with two objectives: first, to provide an extension of UML (one of the modelling languages most commonly used by engineers to develop software) focused on representing enterprise goals and, second, to establish the basis for connecting enterprise goals and system models. To achieve this, the capacity of UML2 to extend the language to a specific domain was used, and a UML2 Profile for Enterprise Goal Modelling was implemented. The paper is organised as follows. Section 2 outlines two approaches related to the aim of establishing connections between enterprise and system models. In section 3, the Proposal for Enterprise Knowledge Modelling using UML is described. Section 4 presents one of the metamodels and UML Profiles implemented in this Proposal, in particular the one related to the goal dimension. Finally, section 5 outlines the main conclusions.

2 Linking Enterprise Models and System Models Linking enterprise models in general and, more particularly, enterprise goals and strategies to the first step in software development, that is to say, requirements elicitation, is one of the recent research trends bridging the domains of Enterprise Modelling and Software Engineering. This section offers a brief summary of two initiatives developed to connect the enterprise and system models.

A Proposal for Goal Modelling Using a UML Profile

681

2.1 MDA

Model-driven approaches are a good solution to try to put to rights the shortcomings of Enterprise Modeling for generating code from enterprise models. Model Driven Engineering (MDE) or Model Driven Development (MDD) approaches are a new paradigm in the context of Software Engineering. Such a perspective attempts to improve the software development process by focusing on models as the primary artifacts and transformations as the primary operation carried out on models (which are used to map information from one model onto another). As a result, they may have important consequences on the way information systems are built and maintained [17, 18]. As an example, Model Driven Architecture (MDA) [19] defined by the OMG [7], is intended to promote the use of models and their transformations as a fundamental way of designing and implementing different kinds of systems. The main purpose of this approach is to separate the functional specification of a system from the details of its implementation on a specific platform. This architecture therefore defines a hierarchy of models from three points of view [15, 19, 20], namely: x

x

x

Computation Independent Model (CIM): which is used to represent domain and system requirements. It is based on business models and shows the enterprise from a holistic point of view, that is independent of the computation. Platform Independent Model (PIM): which is used to model system functionality but without defining how it will be implemented and on what platform; it is focused on information and sets out from a computational point of view. Platform Specific Model (PSM): the PIM is transformed into a platformdependent model according to the platform selected for use and is focused on a technological point of view.

Nowadays, the model-driven approach is followed by numerous projects such as MODELWARE [21], ATHENA [22], and INTEROP [23] in the European Union, and Model Driven Architecture (MDA) [19] defined by the OMG. MDA is an emerging paradigm. A lot of work is being carried out within the OMG framework in relation to PIMs, PSMs, and so forth, but the characterisation of CIMs and the features that an enterprise model must satisfy in order to be considered a CIM and generate appropriate software is still in progress [15]. The main problem involved in enterprise modelling at the CIM level is how to accomplish a clear definition of the various aspects that the actors want to take into account. The domain and purpose of modelling, together with the aspects that must be highlighted, should be defined, and then the most suitable Enterprise Modelling Language (EML) will have to be chosen [24]. Therefore, the number of issues that can be modelled at the CIM level raises the complexity of CIM models and their transformations, especially when the final aim is to capture enterprise knowledge.

682


2.2 GORA Methods

At the same time, another areas of research have emerged that recognise the importance of guaranteeing the quality of requirements by goals, especially Goal Oriented Requirements Analysis (GORA) methods, which aim at bridging the gaps between stakeholders’ needs and requirements specifications [25]. These methods use mainly progressive top-down approaches [26, 27, 28]. They start with the definition of the customers’ needs and, by refining and breaking the needs down into more concrete goals, allow elicitation of the system requirements using a topdown approach. The result is generally structured as a directed AND-OR graph. Its upper parts show the needs and its lower parts show the requirements. These approaches can be combined or interlaced with use case modelling techniques [29, 30, 31, 25] in order to get a clear connection between the goal-oriented methods and the requirements elicitation processes. For example, [25] proposes such an approach, which allows collaborative tasks to be supported and goals to be decomposed from multiple perspectives. All these methods and techniques are devoted but no limited, to information systems and software engineering and can be used in a broader context such as Enterprise Modelling. As pointed out by [32], in this context Enterprise Modelling can be used in connection with requirements engineering and goal-oriented approaches. In this way, it is possible to establish links between the goals of the enterprise defined at several levels of granularity, (for example from the strategic, tactical, and operative levels) and the requirements system to be implemented in order to reach these goals. However, one weakness of these approaches is that they generally use different formalisms both at the enterprise level for expressing strategic goals and at the IT system development level. For example, a specific formalism is developed in [32] for describing a Strategic Dependency model. In the following sections, a Proposal based on the definition of a UML Profile, which allows for the development of an integrated approach based on a unique formalism, is presented.

3 Proposal for Enterprise Knowledge Modelling The study presented on this paper focuses on Enterprise Goal Modelling. It belongs to a wider research project [33] which aims at modelling Enterprise Knowledge at the CIM level and the result of using it in enterprises is a graphical model of the Enterprise Knowledge Map. In general terms, this Proposal is based on MDE and, more particularly, on the MDA defined by the OMG. According to this approach, the process of developing a computer system is based on the separation of the functional characteristics of the system from the details of its specification on a specific platform. Therefore, the Proposal defines a framework for modelling enterprise knowledge on the CIM level at two levels of abstraction, which are required due to the great complexity of this level (see Table 1):


683

2.

CIM-Knowledge: this corresponds to the top level of the model at the CIM level; the enterprise is represented from a holistic point of view, thus providing a general vision of the enterprise focused on representing enterprise knowledge that will later be detailed in a local way in successive lower levels. 4. CIM-Business: here, the vision of enterprise knowledge is detailed by means of a representation of its business, according to three types of models, i.e. the Organisational, the Structure and the Behaviour Model. Table 1. Proposal for Enterprise Knowledge Modelling.

The Proposal follows the MDE premise as a fundamental concept together with the following principles, it is focused on Enterprise Modelling, since it takes into account dimensions of the enterprise and previous works leading to initiatives such as UEML 30 [35] and POP* 31 [33]; and it is a user-oriented modelling framework, since it should be developed at the CIM level by domain experts. From a technological point of view, this Proposal was implemented using the capacity of UML2 to extend a metamodel, that is to say, by defining a UML2 Profile for each aspect of the enterprise to be taken into account. A summary of the Proposal showing its levels of abstraction, metamodels and the profiles that are developed, as well as the models and diagrams proposed for each level, can be seen in Table 1. The Proposal was developed following these steps: Definition of the models and diagrams that can be used to obtain the Enterprise Knowledge Map. The models and diagrams defined within the Proposal are presented in Table 1. 2. Definition of the metamodels shown in Table 1, so that the elements used for Enterprise Knowledge Modelling can be represented at the conceptual level. 3. Definition of the UML Profile for Enterprise Knowledge Modelling, following these steps for each of the profiles detailed in Table 1:

1.

30 Unified Enterprise Modelling Language, first developed by the UEML Thematic Network [34] and currently being worked on by INTEROP NoE [23]. 31 Acronym of the different enterprise dimensions: Process, Organisation, Product, and so on (represented by a star), proposed by ATHENA IP [22].

684


x x x

Definition of stereotypes, tagged values and constraints of the profile. Extension of the metaclasses of the UML2 Metamodel. Detailed description of the profile.

4.

Implementation of the Profile using a UML tool (IBM Rational Software Modeler Development Platform 32 or MagicDraw UML 12.0. 33, for example). 5. Validation of the Profile by means of a real case study.

In the next section, one of the profiles that make up the UML Profile for Enterprise Knowledge Modelling is presented as an example of how the goal dimension is taken directly into account in this Proposal, since there are some implicit concepts related to GORA concepts inside the other models of the Proposal. Therefore, the main steps outlined above are shown in the next section for the goal dimension, that is to say, the suggested Goal Metamodel, the ’UML Profile for GM’ that is implemented, and an example to illustrate the Goal Diagram.

4 UML Profile for GM The Goal Metamodel was defined with the objective of representing the elements related to the goal dimension in enterprises at conceptual level. Based on [36], the main elements that can be represented at the conceptual level are shown in Table 2. Table 2. Conceptual elements to be represented in the goal dimension.

32 http://www-306.ibm.com/software/rational/ 33 http://www.magicdraw.com/


685

Fig. 1. Goal Metamodel: an excerpt from the Organisational Metamodel.

Figure 1 depicts an excerpt from the Organisational Metamodel (the Goal Metamodel), showing only the constructs needed to represent the enterprise goals defined from Table 2, which are the following: x

Objective: this represents any target that enterprises want to achieve, it is possible to define it at different hierarchical levels, such as the strategic, tactical and operative levels. At the strategic level, this construct is also used to represent the enterprise’s mission and vision. For this class, the following properties are defined:

-

-

x x

type: this specifies the category of the objective, which is one of the following defined in the enumeration “ObjectiveType”: mission, vision, strategic, tactical or operative. isLeaf: this indicates whether it is possible to divide the objective into other sub-objectives. level: this indicates the hierarchical levels on which the objective is defined: one of the following levels defined in the enumeration “LevelType” is possible: collaborative, strategic, tactical or operative.

Strategy: this represents how the enterprise wants to achieve the objectives proposed at the strategic level. Plan: this represents the organisation of the work at different hierarchical levels in order to accomplish the objectives and strategy defined in the enterprise. For this class, the following properties are defined:

-

-

type: this specifies the kind of plan, which can be one of the types defined in the enumeration “PlanType” i.e. business, action or initiative. period: this specifies the interval of time that the plan is defined for.

686


x

Variable: this represents any factor that is able to influence the execution of the plans defined in the organisation. For this class, the following properties are defined:

-

type: this specifies one of the categories defined in the enumeration “VariableType” i.e. values, strengths, weaknesses, opportunities, threats, keySuccess, policies or attitudes.

Figure 2 shows the diagram of the “UML Profile for GM” that was implemented using MagicDraw UML 12.0., which was developed from the Goal Metamodel shown in Figure 1.

Fig. 2. Diagram of the “UML Profile for GM”.

Finally, Figure 3 shows the Goal Diagram for a real case applied to an audit enterprise, where some of the requirements needed for the computer system can be observed; this diagram can be mapped onto the use case at system level. The diagram presented in Figure 3 is located at the CIM-Business level. This diagram is useful to show the goal structure defined by an audit enterprise in order to fit its strategic plan. The Goal Diagram is included within the Organisation Model (see Table 1), since it is linked to the following diagrams developed in this real case: x x x

Organisational Structure Diagram: this shows the human resources and skills that are needed to accomplish the goals depicted in the Goal Diagram. Analysis Diagram: this is focused on representing the Performance Measurement System defined by the audit enterprise to measure the degree to which the goals depicted in the Goal Diagram are being accomplished. Business Rules Diagram: this is dedicated to showing some of the Business Rules defined by the audit enterprise, for example, those related to the values such as ’Professional ethics’ and ’Moral integrity’ defined in the Goal Diagram.


687

Moreover, the issues represented in the Goal Diagram are the origin of the several diagrams included in the Structure and Behaviour Model (see Table 1). For example, the Tactical Objective defined in the Goal Diagram, ’To develop a software to support the auditing process’, is linked to a Process Diagram, which shows the IDEF0 diagram of this process. It is also connected to the Resource Diagram which describes the requirements needed to implement the Computer System related to the accomplishment of this objective.

Fig. 3. Goal Diagram for an audit enterprise.

5 Conclusion The Proposal for Goal Modelling presented in this paper is a first attempt to establish links between enterprise and system models. This Proposal is part of a wider research project aimed at defining a set of UML profiles for bridging the

688


Enterprise Modelling and the System Development domains. Combining the main advantages of using a common basic formalism (i.e. UML) with its adaptation to specific concerns and viewpoints through the definition of UML Profiles and, lastly, with an MDA approach makes it easier to define the links between models at both the enterprise level and the system level.

Acknowledgments This work was funded by CICYT DPI2006-14708 and the EC within the 6th FP, INTEROP NoE (IST-2003-508011). The authors are indebted to TG2 [23].

References [1] [2]

[3] [4] [5] [6] [7] [8] [9] [10] [11]

[12]

[13]

[14]

[15]

Vernadat, F.B.: Enterprise Modeling and Integration: Principles and Applications. Chapman and Hall (1996) Doumeingts, G., Chen, D.: Interoperability development for enterprise applications and software. In Cunningham, P., Cunningham, M., Fatelnig, P., eds.: Building the Knowledge Economy: Issues, Applications, Case Studies. eBusiness, IOS Press Amsterdam (2003) Doumeingts, G., Vallespir, B., Chen, D.: Decisional modelling GRAI grid. In: International Handbook on Information Systems. Springer-Verlag (1998) 313–337 Spur, G., Mertins, K., Jochem, R.: Integrated Enterprise Modelling. Beuth Verlag GmbH (1996) Krogstie, J.: Extended Enterprise MEthodology, Final version 1-12-d-2002-01-0. Technical report, EXTERNAL (IST-1999-10091) (2002) IDEF: Integrated DEFinition methods. http://www.idef.com/ (2008) OMG: Object management group. http://www.omg.org/ (2008) Eriksson, H.E., Penker, M.: Business Modeling with UML: Business Patterns at Work. J. Wiley (2000) Marshall, C.: Enterprise Modeling with UML. Designing Successful Software Through Business Analysis. Addison Wesley (2000) Panetto, H.: UML Semantics Representation of Enterprise Modelling Constructs. In: ICEIMT. (2002) 381–387 Berio, G., Petit, M.: Enterprise Modelling and the UML: (sometimes) a conflict without a case. In: Proc. of the 10th ISPE Int. Conf. on Concurrent Engineering: Research and applications. (2003) 26–30 Grangel, R., Bourey, J.P., Chalmeta, R., Bigand, M.: UML for Enterprise Modelling: basis for a Model-Driven Approach. In Doumeingts, G., Müller, J., Morel, G., Vallespir, B., eds.: Enterprise Interoperability. New Challenges and Approaches, Springer, London (2007) 91–102 Abdullah, M.S., Kimble, C., Paige, R., Benest, I., Evans, A.: Developing a UML Profile for Modelling Knowledge-Based Systems. In: Model Driven Architecture. Volume 3599 of LNCS., Springer, Heidelberg (2005) 220–233 IFIP-IFAC: Generalised enterprise reference architecture and methodology (GERAM). Technical Report Version 1.6.3 (1999) http://www.cit.gu.edu.au/ bernus/taskforce/geram/versions. Grangel, R., Chalmeta, R., Campos, C., Coltell, O.: Enterprise Modelling, an overview focused on software generation. In Panetto, H., ed.: Interoperability of ESA


[16] [17]

[18]

[19] [20]

[21] [22]

[23] [24]

[25]

[26] [27]

[28]

[29] [30]

[31]

[32]

[33]

[34]

689

Workshops of the INTEROP-ESA International Conference EI2N, WSI, ISIDI and IEHENA 2005, Hermes Science Publishing (2005) 65–76 Fox, M.S., Gruninger, M.: Enterprise Modelling. AI Magazine 19 (1998) 109–121 Berre, A.J., Hahn, A., Akehurst, D., Bezivin, J., Tsalgatidou, A., Vermaut, F., Kutvonen, L., Linington, P.F.: Deliverable D9.1. State-of-the art for Interoperability architecture approaches, Model driven and dynamic, federated enterprise interoperabilityarchitectures and interoperability for non-functional aspects. Technical report, INTEROP NoE (IST-2003-508011) D9 (2004) Aagedal, J.., Bézivin, J., Linington, P.F.: Model-Driven Development. In Malenfant, J., Ostvold, B.M., eds.: ECOOP 2004 Workshop Reader. Volume 3344 of LNCS., Springer, Heidelberg (2005) 148–157 OMG: MDA Guide Version 1.0.1. Document number: omg/2003-06-01 edn. (2003) Berrisford, G.: Why IT veterans are sceptical about MDA. In: 2nd European Workshop on MDA with an emphasis on Methodologies and Transformations, Kent, Computing Laboratory, University of Kent (2004) 125–135 MODELWARE: Modeling solution for software systems Project (IST-2004-511731). http://www.modelware-ist.org/ (2008) ATHENA: Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications IP (IST-2001-507849). http://www.athena-ip.org (2008) INTEROP: Interoperability Research for Networked Enterprises Applications and Software NoE (IST-2003-508011). http://www.interop-noe.org (2008) Grangel, R., Chalmeta, R., Campos, C.: Requirements for Establishing a Conceptual Knowledge Framework in Virtual Enterprises. In Abramowicz, W., Mayr, H.C., eds.: Technologies for Business Information Systems, Springer (2007) 159–172 Kaiya, H., Saeki, M.: Weaving Multiple Viewpoint Specifications in Goal Oriented Requirements Analysis. In: APSEC’04: Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC’04), IEEE Computer Society (2004) 418–427 Antón, A.I.: Goal-Based Requirements Analysis. In: IEEE International Conference on Requirements Engineering (ICRE’96). (1996) 136–144 van Lamsweerde, A.: Goal-Oriented Requirements Engineering: A Guided Tour. In: RE’01: Proceedings of the 5th IEEE International Symposium on Requirements Engineering, IEEE Computer Society (2001) 249 Kaiya, H., Horai, H., Saeki, M.: AGORA: Attributed Goal-Oriented Requirements Analysis Method. In: 10th Anniversary Joint IEEE International Requirements Engineering Conference (RE’02), IEEE Computer Society (2002) 13 Rolland, C., Souveyet, C., Achour, C.B.: Guiding goal modelling using scenarios. IEEE Transaction on Software Engineering 24 (1998) 1055–1071 Antón, A.I., Carter, R.A., Dagnino, A., Dempster, J.H., Siege, D.F.: Deriving goals from a use-case based requirements specification. Requirements Engineering Journal 6 (2001) 63–73 Santander, V.F.A., Castro, J.: Deriving Use Cases from Organizational Modeling. In: RE’02: Proceedings of the 10th Anniversary IEEE Joint International Conference on Requirements Engineering, IEEE Computer Society (2002) 32–42 Yu, E.S.K., Liu, L., Li, Y.: Modelling Strategic Actor Relationships to Support Intellectual Property Management. In: ER’01: Proceedings of the 20th International Conference on Conceptual Modeling, Springer-Verlag (2001) 164–178 Grangel, R., Chalmeta, R., Schuster, S., Peña, I.: Exchange of Business Process Models using the POP* Meta-model. In Bussler, C., Haller, A., eds.: BPM 2005. Volume 3812 of LNCS., Springer, Heidelberg (2006) 233–244 UEML: Unified Enterprise Modelling Language Thematic Network (IST-200134229). http://www.ueml.org (2008)

690


[35] Opdahl, A.L., Henderson-Sellers, B.: 6. Template-Based Definition of Information Systems and Enterprise Modelling Constructs. In: Ontologies and Business System Analysis. Idea Group Publishing (2005) [36] Williams, T.: The Purdue Enterprise Reference Architecture. In Elsevier, ed.: Proc. of the Workshop on Design of Information Infrastructure Systems for Manufacturing. (1993)

Index of Contributors

Abecker, Andreas ....................... 381 Åhlfeldt, Rose-Mharie.................. 41 Anderl, Reiner .................... 471, 533 Apostolou, Dimitris .................... 381 Askounis, Dimitrios............ 159, 639 Badr, Y. ...................................... 301 Barthe, A-M................................ 437 Bastiaans, Joris ........................... 183 Bastida, L. .................................. 221 Bénaben, Frédérick..... 145, 437, 583 Beneventano, Domenico............. 329 Benguria, Gorka ........................... 29 Berreteaga, A.............................. 221 Biennier, F.................................. 301 Bourey, Jean-Pierre .................... 679 Bucko, Jozef ............................... 135 Campos, Cristina ........................ 679 Cañadas, I. .................................. 221 Chalmeta, Ricardo ...................... 679 Chang, Huiyou............................ 665 Chapurlat, Vincent...................... 583 Charalabidis, Yannis .................. 289 Chungoora, N. ............................ 411 Couget, Pierre............................. 583 Dahlem, Nikolai ......................... 329 De Labey, Sven .......................... 233 De Nicola, A............................... 571 Delina, Radoslav ........................ 135 Dirgahayu, Teduh....................... 261 El Haoum, Sabina....................... 329 Errasti, A. ................................... 521 Eskeli, J. ..................................... 499

Esper, A. .....................................301 Fernando, Terrence .......................99 Figay, Nicolas .............................423 Fischer, Klaus .............................651 Folmer, Erwin .............................183 Gautier, Gilles...............................99 Ghodous, Parisa ..........................423 Gionis, George ....................159, 639 Gocev, Pavel ...............................397 Gramza, M. .................................499 Grangel, Reyes............................679 Hahn, Axel ..................................329 Hahn, Christian ...........................651 Harding, Jenny ............................381 He, Song .....................................665 Heather, Michael.........................625 Hiel, Marcel ................................197 Hu, Kun Yuan .............................595 Imache, R. .......................................3 Izza, S. ....................................3, 353 Jäkel, Frank-Walter.....................511 Jankovic, Marija..........................547 Johnson, P. ..................................611 Jun, Wei ......................................275 Kääriäinen, J. ..........................55, 85 Kalaboukas, Kostas.....................159 Knothe, Thomas..................511, 547 Kokovic, Zoran ...........................547 Kommeren, R..............................499 Koumpis, Adamantios.................209 Koussouris, Sotirios ............159, 639 Ku1, Tao .....................................595

692

Index of Contributors

Lagerström, R............................. 611 Lampathaki, F............................. 639 Lauras, Matthieu......................... 583 Levashova, Tatiana..................... 343 Leymann, Frank.................. 171, 485 Li, Xiaoping ............................... 315 Liu, Shu ...................................... 451 Livingstone, David ..................... 625 Ljubicic, Vuk.............................. 547 Lorré, J-P.................................... 437 Lounis, Y........................................ 3 Lv, Ci Xing................................. 595 Malzacher, Jens .......................... 533 Marjanovic, Zoran ...................... 547 Mavridis, Androklis.................... 209 Mentzas, Gregoris ...................... 381 Mertins, Kai................................ 511 Mihók, Peter ............................... 135 Missikoff, M............................... 571 Mitschang, Bernhard .................. 171 Mo, Tong.................................... 247 Montanari, Daniele ..................... 329 Nie, Lanshun .............................. 461 Palová, Dana............................... 135 Parviainen, P............................... 499 Pashkin, Mikhail......................... 343 Pesola, J-P. ................................. 499 Piddington, Colin.......................... 99 Pingaud, Hervé ........... 145, 437, 583 Poler, R....................................... 521 Popplewell, Keith ....................... 381 Protogeros, Nicolaos .................. 209 Quartel, Dick .............................. 261 Rabe, Markus...................... 113, 397 Radeschütz, Sylvia ..................... 171 Rajsiri, V. ................................... 437 Raßler, Jochen ............................ 533 Reinelt, Matthias ........................ 329 Rollmann, Thomas ..................... 471 Rossiter, Nick ............................. 625

Rules ...........................................397 Santos, Igor ...................................29 Scheibler, Thorsten .....................485 Schroth, Christoph ..................15, 71 Shilov, Nikolay ...........................343 Shiyang, Ye.................................275 Sinatti, Stefano............................125 Sliman, L.....................................301 Smirnov, Alexander ....................343 Söderström, Eva............................41 Sommar, Ruth .............................679 Sourouni, Aikaterini Maria .........159 Steegmans, Eric ..........................233 Stojanovic, Nenad.......................381 Tao, Huang..................................275 Tektonidis, Dimitrios ..................209 Tininini, L. ..................................571 Touzi, Jihed.................................145 Truptil, Sébastien ........................583 Ullberg, J.....................................611 Välimäki, A.............................55, 85 Van Den Heuvel, Willem-Jan .....197 van Sinderen, Marten ..................261 Vincent, L. ..............................3, 353 Völz, Diana .................................471 Wang, Qian .................................315 Wang, Qing.................................665 Wang, Qingqing..........................315 Wang, Zhongjie .......... 247, 367, 451 Weigand, Hans....................197, 559 Weinaug, Heiko ..........................113 Wills, Christopher.......................209 Xu, Xiaofei.......... 247, 367, 451, 461 Young, R.I.M. .............................411 Zanet, Michele ............................125 Zhan, Dechen ..............................461 Zhang, Panxiang .........................665 Zhu, Yun Long............................595 Zinnikus, Ingo.............................651

Index of Keywords

agent .....................................................................................................................343 Agent based approaches to interoperability.................................................. 197, 651 Agility.......................................................................................................................3 Agility Evaluation ....................................................................................................3 architectures..........................................................................................................639 Architectures and platforms for interoperability .................... 71, 171, 197, 233, 625 ATL prototype......................................................................................................145 BS UI Framework ................................................................................................665 Business....................................................................................................................3 Business Aspects of Interoperability ....................................................................113 business interoperability.......................................................................................329 Business models for interoperable products and services...............................29, 247 Business Process Management.............................................................................571 Business Process Reengineering in interoperable scenarios................. 113, 301, 521 business schema representation ............................................................................329 collaboration.........................................................................................................135 collaborative business processes ..........................................................................183 collaborative process .................................................................................... 145, 583 context ..................................................................................................................343 crisis management ................................................................................................583 cross-enterprise business processes ......................................................................183 cultural diversity in collaborated team work ........................................................471 Decentralized and evolutionary approaches to interoperability.................... 125, 461 design methodologies ...........................................................................................183 Design methodologies for interoperable systems ................. 125, 171, 233, 315, 367 different organisational structures ........................................................................471 eGovernment Interoperability...............................................................................289 eGovernment Ontology ........................................................................................289 electronic transactions ..........................................................................................639 Engineering interoperable systems ......................................................... 15, 233, 499 Enterprise application Integration for interoperability ......................... 315, 461, 485 Enterprise applications analysis and semantic elicitation.....................................611

694

Index of Keywords

Enterprise Information System.................................................................................3 enterprise interoperability.....................................................................................381 Enterprise modeling for interoperability .............. 113, 159, 247, 261, 289, 301, 611 Enterprise Modelling ............................................................................................679 Enterprise modelling for interoperability .............................................................521 Enterprise Modelling in the Context of Interoperability ......................................511 ERP ......................................................................................................................639 Experiments and case studies in interoperability..................................................521 Federation.............................................................................................................423 Formal approaches and formal models of interoperability ................... 595, 611, 625 Formal approaches to interoperability ..................................................................595 Frameworks ..........................................................................................................511 Fuzzy Logic..............................................................................................................3 Global Engineering...............................................................................................471 Goal Modelling.....................................................................................................679 healthcare informatics ............................................................................................41 identity management ............................................................................................135 Industrial case studies and demonstrators of interoperability................... 55, 85, 499 Inference...............................................................................................................397 Information security ...............................................................................................41 information sharing ..............................................................................................135 information system ...............................................................................................583 Information System ..............................................................................................353 Information Technology...........................................................................................3 Integration ............................................................................................................353 Intelligent infrastructure and automated methods for business system integration.........................................................................................................221 interaction.............................................................................................................183 interoperability ..................................................................................... 411, 583, 639 Interoperability .........................................................................................................3 Interoperability best practice and success stories .............................................55, 85 Interoperability for Enterprise Application Integration ........................................171 Interoperability for integrated product and process modeling..............................171 Interoperability for knowledge creation, transfer, and management ....................315 Interoperability for knowledge sharing ................................................................315 Interoperability in SME........................................................................................511 Interoperability infrastructure and IT platforms ...................................................625 Interoperability issues in electronic markets ..........................................................15 Interoperability of E-Business solutions....................................................... 125, 247 Interoperability of Enterprise Application............................................................423 Interoperability performance analysis ....................................................................15 Interoperability-related standards, legal and security issues.................................625 Interoperable enterprise architecture ........................................................ 15, 71, 301 Interoperable inter-enterprise workflow systems ...........................................71, 125 Interoperable knowledge management .................................................................625 interoperable systems ...........................................................................................183 Knowledge Base...................................................................................................397

Index of Keywords

695

Knowledge Integration .........................................................................................471 knowledge management .......................................................................................381 Knowledge Representation...................................................................................679 knowledge services...............................................................................................381 Knowledge transfer and knowledge exchange .......................................................99 Managing challenges and solutions of interoperablity ...................................29, 197 Manufacturing ......................................................................................................397 manufacturing knowledge sharing........................................................................411 Matching...............................................................................................................353 MDA............................................................................................................. 583, 665 MDR.....................................................................................................................665 Measuring, validating, and verifying interoperability ..........................................611 messages...............................................................................................................183 metamodel..........................................................................................................329 Meta-data and meta-models for interoperability ..................................................159 Metaddata for interoperability ..............................................................................289 meta-model...........................................................................................................145 Model Driven Architecture...................................................................................679 Model Driven Architectures for interoperability .......................... 367, 451, 485, 651 Model Driven Interoperability..............................................................................423 model-driven architecture.....................................................................................183 Modeling cross-enterprise business processes.............................................. 113, 159 modeling language ...............................................................................................533 Modelling .............................................................................................................397 Modelling cross-enterprise business processes ....................................................521 Modelling methods...............................................................................................113 Modelling methods, tools and frameworks for (networked) enterprises................................................................................. 221, 261, 559, 611 morphism..............................................................................................................145 object orientation..................................................................................................533 Ontologies and Semantic Web for interoperability ..............................................315 ontology........................................................................................................ 343, 583 Ontology....................................................................................................... 353, 397 Ontology based methods and tools for interoperability................ 171, 367, 437, 571 Open and interoperable platforms supporting collaborative businesses...............437 OWL-S .................................................................................................................353 patient privacy ........................................................................................................41 patient safety...........................................................................................................41 POIRE ......................................................................................................................3 process modeling..................................................................................................533 Product Design .....................................................................................................397 product development ............................................................................................471 Quality and performance management of interoperable business processes ........451 quality of service ..................................................................................................275 Rational Unified Process ......................................................................................209 Requirements engineering for the interoperable enterprise ............................15, 559 security .................................................................................................................135

696

Index of Keywords

Security issues in interoperability.........................................................................301 Self-organisation ..................................................................................................343 semantic interoperability ......................................................................................343 Semantic Preservation ..........................................................................................423 semantic web ........................................................................................................381 Semantic Web.......................................................................................................397 semantics ..............................................................................................................411 Semantics .............................................................................................................353 Semantic-web based interoperability approaches.................................................651 service...................................................................................................................343 Service..................................................................................................................353 service level agreement ........................................................................................275 service matchmaking ............................................................................................275 Service oriented Architectures for interoperability ........................... 71, 197, 221, 233, 261, 301, 451, 485, 571, 651 Service Oriented Computing ................................................................................209 Similarity..............................................................................................................353 Simulation ............................................................................................................397 SOA......................................................................................................................583 Socio-technical impact of interoperability......................................................99, 461 standards...............................................................................................................183 Strategy and management aspects of interoperability ....................................29, 559 Support for cross-enterprise co-operative Work.....................................................71 system of systems .................................................................................................583 The human factor in interoperability ................................................................85, 99 tools ......................................................................................................................183 tools and frameworks for (networked) enterprises ...............................................113 Tools for interoperability.......................................................... 55, 85, 125, 437, 499 transformation ......................................................................................................145 trust............................................................................................................... 135, 381 trusted scenario.....................................................................................................135 UML .....................................................................................................................533 UML Profile .........................................................................................................679 virtual organisation...............................................................................................381 Web services.........................................................................................................275 Web Services........................................................................................................209 web-based platform ..............................................................................................135

Enterprise Interoperability III: New Challenges and Industrial Approaches

Enterprise Interoperability III: New Challenges and Industrial Approaches

Enterprise Interoperability II: New Challenges and Approaches (v. 2)

Interoperability of Enterprise Software and Applications

Asymmetric Catalysis on Industrial Scale.. Challenges, Approaches and Solutions

Human Security: Approaches and Challenges

Advances in Production Management Systems: New Challenges, New Approaches

Challenges for Industrial Production

Industrial Tourism: Opportunities for City and Enterprise

Enterprise Resource Planning: Global Opportunities and Challenges

COM and .NET Interoperability

Industrial Environmental Performance Metrics: Opportunities and Challenges

COM and .Net Interoperability

Net and COM Interoperability Handbook

Turbulence: new approaches

Turbulence, New Approaches

New Challenges in Superconductivity

Turbulence: New Approaches

New Approaches to Enclosures

Children's Literature: New Approaches

Gender and justice: new concepts and approaches

Challenges for China's Development: An Enterprise Perspective

Industrial restructuring: World Bank experience, future challenges

ENTERprise Information Systems, Part III - CENTERIS 2011

Enterprise Architecture and New Generation Information Systems

Enterprise Interoperability IV: Making the Internet of the Future for the Future of Enterprise

Enterprise architecture and new generation information systems

Public Enterprises: Unresolved Challenges and New Opportunities

Political Parties: Old Concepts and New Challenges

Unconventional Weapons and International Terrorism: Challenges and New Approaches (Cass Series on Political Violence)

Cities in Transition New Challenges, New Responsibilities

Enterprise Interoperability III: New Challenges and Industrial Approaches