Abstract

12 pages
14 views

An interoperability classification framework for method chunk repositories

Please download to get full document.

View again

of 12
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
An interoperability classification framework for method chunk repositories
Transcript
  An Interoperability Classification Framework forMethod Chunk Repositories Per Backlund 1 , Jolita Ralyté 2 , Manfred A. Jeusfeld 3 , Harald Kühn 4  Nicolas Arni-Bloch 2 , Jan B.M.Goossenaerts 5 , and Frank Lillehagen 6   1 University of Skövde, P.O. Box 408, SE 541 28 Skövde, Sweden Per.Backlund@his.se 2 CUI, University of Geneva, Rue de Général Dufour, 24, CH-1211 Genève 4, Switzerland {Jolita.Ralyte, Nicolas.Arni-Bloch}@cui.unige.ch 3 Tilburg University, CRISM/Infolab, 5000 LE Tilburg, The Netherlands Manfred.Jeusfeld@uvt.nl 4 BOC Information Systems GmbH, Rabensteig 2, A-1010 Vienna, Austria Harald.Kuehn@boc-eu.com 5 Eindhoven University of Technology, Den Dolech 2, Paviljoen D 12, Postbus 513, 5600MB Eindhoven, The Netherlands J.B.M.Goossenaerts@tm.tue.nl 6 TROUX Technologies AS, PO Box 482, N-1327 Lysaker, Norway Frank.Lillehagen@Troux.com Abstract. The competitiveness and efficiency of an enterprise is dependent onits ability to interact with other enterprises and organisations. In this context in-teroperability is defined as the ability of business processes as well as enterprisesoftware and applications to interact. Interoperability remains a problem andthere are numerous issues to be resolved in different situations. We proposemethod engineering as an approach to organise interoperability knowledge in amethod chunk repository. In order to organise the knowledge repository we needan interoperability classification framework associated to it. In this paper wepropose a generic architecture for a method chunk repository, elaborate on aclassification framework and associate it to some existing bodies of knowledge.We also show how the proposed framework can be applied in a working exam-ple. 1 Introduction Interoperability is defined as “the ability of Enterprise Software and Applications tointeract” (Interop, 2005). We claim that it is impossible to provide one universalmethod for interoperability problems solution and we propose to define a knowledgebase of reusable method chunks each of them addressing one or more specific interop-erability problems. In order to support situation-specific method construction andapplication, a collaborative tool must be developed supporting method chunks con-struction and storage as well as their selection and reuse in different projects. Thespecialisation of such a knowledge management tool for the interoperability domain  requires the creation of a mapping from the method chunks to the interoperabilityproblems, i.e. an indexation mechanism associating each method to one or severalwell-defined interoperability problems. The definition and classification of interopera-bility problems is necessary for interoperability situation assessment and selection of the method chunks satisfying this situation.In this paper we view information systems development as knowledge work (Iivari,2000; Backlund, 2004) with the aim of exploring an interoperability classificationframework for a Method Chunk Repository which can be used to solve industry rele-vant interoperability problems. We propose method engineering as a means for deal-ing with some aspects of interoperability. However, in order to make an interoperabil-ity method chunk repository useful we must supply a classification of interoperabilityproblems which can be used to guide the repository user in composing methods. Theproposed repository should deal with interoperability problems within informationsystems development; hence we will anchor the classification scheme in the informa-tion systems body of knowledge (Iivari et al., 2004).The focus cannot be placed on the applications alone. In order to achieve meaning-ful interoperability organisations must be interoperable on, at least three levels: a busi-ness layer, a knowledge layer and an ICT systems layer [4]. This includes the businessenvironment and business processes on the business layer, the organisational roles,skills and competencies of employees and knowledge assets on the knowledge layer,and applications, data and communication components on the ICT layer. Similarly, butfrom a more software-architecture oriented view, Schulz et al. [12] conclude thatinteroperability is achieved on the following levels: inter-enterprise coordination,business process integration, semantic application integration, syntactical applicationintegration, and physical integration. According to these authors interoperabilityshould be analysed from an enterprise view (i.e. interoperability between two or moreorganisations), an architecture & platform view (i.e. between two or more applica-tions/systems) and an ontological view (i.e. the semantics of interoperability).As can be seen from the above descriptions, interoperability is a multifaceted con-cept. In order to be able to match a specific problem situation of a particular case tomethod chunks enabling the problem solution, we need a mechanism supportingmethod chunks indexation on the one hand and situation assessment on the other hand.This mechanism is referred to as a matching/classification framework. It must bringdiverse bodies of knowledge together and extend them with interoperability concepts.The remainder of this paper is organised as follows. In section 2 we introduce a col-laborative Method Engineering platform based on a method chunk repository for in-teroperability. The building blocks of the Method Engineering platform and the rolesinvolved in platform use are presented. In section 3 we briefly analyse interoperabilityproblems in an enterprise context and present a framework to classify interoperabilityproblems and method chunks. Section 4 illustrates how the classification framework isapplied to an industrial case. The paper ends with a review of this work, and outlinesfuture research.  2 Collaborative Method Engineering Platform for Interoperability A collaborative platform for situational method engineering must support two mainactivities: situation-specific method construction and method application in the corre-sponding system development project. The method construction activity requires ca-pabilities for reusable method chunks definition, storage and classification with re-spect to the problems they help to solve. It also aims to support the characterisation of each project situation and selection and assembly of method chunks fitting the situa-tion at hand. The method application requires services for the obtained method enact-ment and evaluation of its applicability in the corresponding situation. The knowledgeabout positive or negative experience of method application is captured in terms of best practices and/or experience reports.Fig. 1Fig. 1illustrates the architecture of our platform divided into three layers: us-age , service and data . Case User   Case UserSituated MethodEngineer   Situated MethodEngineerMethod Chunk Engineer   Method Chunk EngineerClassificationManager   ClassificationManagerClassificationFramework    ClassificationFramework Method Chunk Repository(MCR)Method ChunksApplication CasesMC construction andservice definition   MC construction andservice definitionCase situationassessmentMC selection andassembly   Case situationassessmentMC selection andassemblyMC enactment andCase solutions   MC enactment andCase solutionsClassificationconstruction andevolution   Classificationconstruction andevolutionService LayerUsage LayerData LayerCase User   Case UserSituated MethodEngineer   Situated MethodEngineerMethod Chunk Engineer   Method Chunk EngineerClassificationManager   ClassificationManagerClassificationFramework    ClassificationFramework Method Chunk Repository(MCR)Method ChunksApplication Cases   Method Chunk Repository(MCR)Method ChunksApplication CasesMC construction andservice definition   MC construction andservice definitionCase situationassessmentMC selection andassembly   Case situationassessmentMC selection andassemblyMC enactment andCase solutions   MC enactment andCase solutionsClassificationconstruction andevolution   Classificationconstruction andevolutionService LayerUsage LayerData Layer   Fig. 1. Architecture for a collaborative method engineering platform The data layer  concerns the knowledge repository, called the  Method Chunk Re- pository (MCR), used by the platform. This repository contains two types of intercon-nected knowledge: the method knowledge expressed in the form of reusable methodchunks and the knowledge related to the experience of method chunks application inspecific industrial cases. A method chunk  is an autonomous, cohesive and coherentpart of a method providing guidelines and defining related concepts to support therealisation of some specific information system development activity in a particularcontext. Within the scope of the Interop NoE (Interop, 2005), our objective is to defineand store method chunks providing solutions for various interoperability issues. Themetamodel of a method chunk can be found in (Ralyté and Rolland, 2001; Mirbel and  Ralyté, 2005). Furthermore, the MCR collects the practice and experience of using themethod chunks in terms of  application cases .Each case included exhibits a number of interoperability issues that instantiate theinteroperability issue types identified in the classification framework  . In order tomatch the problem situation of a particular case to method chunks thus enabling asolution, we need a mechanism supporting method chunks indexation on the one handand situation assessment on the other hand. This mechanism is referred to as a match-ing/classification framework. In this work we focus our attention to the classificationpart of this framework. Each method chunk stored in the MCR is explicitly related toone or several interoperability issues defined in the classification framework.The service layer  of our platform provides several services supporting method en-gineering and method usage activities including: construction of method chunks andrelated services, classification framework management (construction, extension, andadaptation), method chunks selection, adaptation and assembly for specific cases, andcase-specific method enactment and validation.Finally, the usage layer  defines different categories of platform users including:method chunk engineer, classification manager, situated method engineer and caseuser. The method chunk engineer  is an expert in the method engineering domain.His/her role is to populate the MCR with method chunks, which can be extracted fromexisting traditional methods or defined from scratch on the basis of domain knowledgeand experience. The method chunk engineer will also develop services for methodchunks application and provide a descriptor (Ralyté and Rolland, 2001; Mirbel andRalyté, 2005) for each method chunk characterising, with the help of the classificationframework, the context of its application and the interoperability issues it helps tosolve.The classification manager  is responsible for defining and managing the methodchunk classification framework. Such a framework should be extensible and evolu-tionary. Good knowledge about the information systems development domain andsome selected application or problem domain, such as interoperability in our case, isrequired to enact this role.The situated method engineer  is in charge of constructing a case-specific methodfor each case. His/her work consists of three main tasks: characterising the case situa-tion by using the classification framework, selecting method chunks satisfying thissituation and assembling retrieved method chunks in order to provide a coherent andcomplete method for the specific case.Finally, the case user  will apply the case-specific method in the development of acorresponding project and will provide an experience report including the evaluationof the applied method chunks and their fitness to this case.The interoperability classification framework forms an important part of the MCRstructure since it is used for method chunk classification as well as for case assess-ment. Therefore, we focus our attention to a set of interoperability problems in orderto illustrate its applicability in an industrial case. However, it may be noted that theframework itself comprises a broader scope.  3 Classification of Interoperability Issues Based on a survey of literature (Rahm and Bernstein, 2001; Xu and Newman, 2006;Botta-Genoulaz et al., 2005; Domínguez and Zapata, 2000) and collective industrialexperience in NoE Interop (Interop, 2005) and IP Athena (Athena, 2005) we identifyand characterise a set of interoperability issues in enterprise information systems (sec-tion 3.1) prior to proposing a classification framework in section 3.2. 3.1 Interoperability Classes Interoperability issues can be summarised to comprise five different classes: •  Business Management  , • Process Management  , • Knowledge Management  , • Software Management  , and •  Data Management  .In general, they reside in the various levels of the framework presented in (Schultz etal., 2003) including: communication (interconnection and protocols), data (access toand change of information), service (access to and exchange of services/functions),processes (sequences of activities and rules), knowledge (knowledge assets and organ-isational roles) and business (method of work, legislation and contracts) level. In thefollowing we briefly illustrate these classes in order to characterise the basic condi-tions for the classification framework..The utilisation of repetitive business processes across multiple organisations consti-tutes a potential area for improvement throughout the entire supply chain. Many as-pects are generic and involve repeated periodic processing of similar or identical or-ders. Business decision-making activities are of paramount importance to enterprises,affecting day-to-day operations as well as medium and long-term planning and execu-tion of activities. Therefore, an integral mechanism is required to support the decision-making process at various levels, by considering results coming out of daily opera-tions. The provision of (near) real-time aggregated views of key business informationin relation to the above business decision-making activities can be done by accessingand integrating data in existing legacy systems. Such aggregated views will enableactors to take more accurate and timely decisions, exploiting to the full extend thecapabilities of existing ICT systems.The time from order to delivery could be shortened by better process interoperabil-ity. This can be achieved by the ability of a process to make its requested and offeredservices/interfaces “visible”. Shortening the time between different processes, e.g.from raw materials suppliers, has a direct effect on the delivery date. In this contextwe identify the fact that applications focus on transactions as opposed to processes asan issue to take into account.The knowledge associated to a product over its entire lifecycle needs to be sharedbetween stakeholders. This entails an adequate and common understanding of product
Related Documents
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x