Model-Generated Workplaces: An Interoperability Approach

Transcription

1 Model-Generted Workplces: An Interoperbility Approch R. K. Rolfsen 1, D. Boell 2, C. Pronios 3, T. Knothe 2, M. Anstsiou 3, B. Elvesæter 1 nd H. Jørgensen 4 1 SINTEF ICT, Forskningsveien 1, N-0314 OSLO, Norwy {rolf.k.rolfsen, brin.elvester}@sintef.no 2 Frunhofer IPK Berlin, Corporte Mngement, Psclstrsse 8-9, 10587, Berlin, Germny {dieter.boell, thoms.knothe}@ipk.fhg.de 3 INTRACOM TELECOM, 19,7 Km Mrkopoulo Ave., 19002, Peni Athens, Greece {hpro, mn}@intrcom.gr 4 AKM AS, Vollsveien 9, N-1327, Lysker, Norwy h.jorgensen@kmodeling.com Abstrct. This pper presents n pproch to using model-generted workplces (MGWP) in tndem with service-oriented rchitectures in order to meet interoperbility needs in corporte environment. More specificlly, the interoperbility study nd reserch undertken is bsed on use cse scenrio relted to the process of product portfolio mngement (PPM) in lrge enterprise of the Telecommuniction sector, INTRACOM Telecom. Strting from enterprise modelling constructs, Web-bsed workplces re creted tht offer nvigtion nd work views to the end user, supporting ll his opertionl tsks s depicted in the enterprise model. Interction with enterprise informtion repositories is fcilitted vi n underlying service-oriented rchitecture. 1 Introduction A model-generted workplce (MGWP) is working environment for the business users involved in running the business opertions of the enterprise. It is user pltform tht provides the grphicl front-end for humn users to interct with softwre services supporting their dy-to-dy business ctivities. The workplce cn be tilored to meet the specific requirements of different roles or persons within n enterprise, providing customized presenttion nd opertion views. This is chieved through model-configured nd user-composble services (MUPS). These services mke use of knowledge models to generte business-oriented nd context-wre grphicl user interfces (Jørgensen et l., 2004) (Elvesæter et l., 2005).

2 2 R.K. Rolfsen, D. Boell, C.Pronios, M. Anstsiou, T. Knothe, B. Elvesæter nd H. Jørgensen This pper presents n pproch of using model generted workplces (MGWP) in tndem with service-oriented rchitectures in order to meet the interoperbility needs in corporte environment. More specificlly, the interoperbility study nd reserch undertken re bsed on use cse scenrio relted to the process of product portfolio mngement (PPM) in lrge enterprise of the Telecommuniction sector, INTRACOM Telecom. Strting from enterprise modelling constructs, Web-bsed workplces re creted tht offer nvigtion nd work views to the end user, supporting ll his opertionl tsks s depicted in the enterprise model. Interction with enterprise informtion repositories is fcilitted vi n underlying service-oriented rchitecture. This work hs been performed within the context of the IST integrted project ATHENA (ATHENA, 2004). The pper is structured s follows: In section 1, the scenrio of PPM is briefly described, while section 2 summrizes the interoperbility needs in the scenrio nd the interoperbility issues tht the specific pilot ddresses. The technicl solution is presented in section 4 including the infrstructure used in INTRACOM Telecom nd the pproch nd design of MGWP. Section 5 concludes the pper with the chllenges tht need to be delt with s prt of future work of this reserch effort. 2 Use Cse Scenrio: Product Portfolio Mngement The PPM is process involving decisions mde t different levels, where the compny s ctive products list is constntly updted nd revised. Therefore, new products re evluted, selected nd prioritized; existing ones my be ccelerted, killed or reprioritized; nd resources re llocted nd rellocted to the ctive development projects. The objective is to llocte resources in wy to mximize sles nd profits nd minimize risks, s well s to chieve blnce of development projects tking under considertion risks, technology nd mrket trends. The PPM is of significnt importnce especilly to lrge enterprise with mny business units nd complex products, the development of which requires the collbortion of mny different engineering tems inside the sme business unit or corporte environment, s well s within business network of collbortive enterprise. In this study, the focus is on intr-enterprise level. The PPM involves mny business processes (new product development, product mngement, supply chin mngement), nd mny ctors t vrious positions tht perform different tsks from strtegic level (e.g. Business Unit Mnger, Sector Mnger), nd tcticl level (Product Mnger, Project Mnger) to opertionl level (Tem Leder, Engineer). Within this scenrio, we focus on the Product Mngement nd on supporting the role of the Product Mnger. At INTRACOM Telecom the objective of Product Mngement is to identify the need for product/product-line, justify the inclusion of product/product-line in the compny solutions nd control the execution of the development rodmp. In doing so, it needs to stnd between the product development nd mnufcturing deprtments s well s the sles, technicl support nd public reltions ones. The Product Mnger is ssigned to product or product fmily nd is responsible for developing or overseeing ll spects of the product

3 Model-Generted Workplces: An Interoperbility Approch 3 including product definition, product development, product lunch, current product mngement, nd product phse-out. 3 Interoperbility Needs nd Expecttions The nlysis of the interoperbility needs within the PPM scenrio hs reveled severl problems s these re perceived by its ctors in their dily work. An importnt observtion is tht currently the communiction mong the different product portfolios nd the collbortion of the vrious tems is insufficient. Collbortive work needs to be supported by providing ctors with the tools in ddition to informtion nd communiction support they need to efficiently perform their work through single point of entry (workplces). It is worth noting tht the PPM scenrio revels interoperbility needs for supporting d-hoc nd event driven collbortion ctivities s opposed to stndrd workflow ones, when events nd process vribles re well defined. Furthermore, the efficient performnce of the product portfolio process requires federted informtion coming from mrketing, product development execution, s well s from the product life cycle mngement. It is knowledge intensive process, s it presupposes very good nd holistic view of the enterprise: strtegy nd objectives, skills nd competences, s well s experience coming from previous development projects. Decision-mking ctivities on vrious levels of the enterprise re poorly supported due to lck of informtion integrtion from vrious ICT systems, s well s timely informtion updtes. The relevnt dt nd informtion needed by PPM prticipnts for performing their tsks nd mke ccurte decisions re spred cross severl systems. Figure 1 presents high-level overview of the s-is sitution of the systems nd functions needed nd used by set of PPM ctors. Tem Mnger Qulity Engineer Product Development Mnger iknow Project Plnning Sles Dt ERP System Project Finnce Contrct Mngement Wrehouse Mngement HR Mngement Production Plnning Document Mngement Mrketing Intelligence SIS Product Issues Mngement ADARES Product Issues Mngement Business Development Mnger Product Mnger Fig. 1. A high-level overview of the s-is sitution.

4 4 R.K. Rolfsen, D. Boell, C.Pronios, M. Anstsiou, T. Knothe, B. Elvesæter nd H. Jørgensen In ddition to the bove, cohesion of the decision-mking ctivities with strtegic plns nd opertionl results needs to be supported. Bsed on this nlysis, we hve identified severl interoperbility issues on ll three levels of the enterprise: Business, Knowledge nd ICT levels. The pilot implementtion in ATHENA focused on the following interoperbility issues: Link decision-mking ctivities with strtegic plns, development nd opertionl results. Enterprise description nd knowledge mngement in vrious spects nd dimensions (orgniztion, role, decision, process, product, system). Product relted knowledge shring within nd between product life cycle phses. Provision of (ner) rel-time ggregted views of key business informtion existing in legcy systems exploiting to the full extend the cpbilities of existing ICT systems. Ability of integrted pplictions execution vi single point of entry. 4 Technicl Solution It is cler tht the requirements presented hve, over time, led to vrious system rchitecture implementtions in n effort to rech some level of interoperbility. -oriented rchitectures re just entering their mturity phse nd cn provide solid nd elegnt solution. Of course, investing in the doption nd implementtion of service-oriented rchitecture cross business boundries is mjor undertking tht hs been shown to be beyond the cpbilities of most present-dy enterprises, which hve to continuously support nd upgrde their current (legcy) system rchitectures used in their dy-to-dy opertions. The sitution is more ccentuted in cses where the evolution of sid systems ws not undertken under the uspices of centrl IT systems plnning entity, which could medite between conflicting system requirements. In this respect, it would be of gret utility if systems interoperbility could be chieved without interfering with the opertion of existing systems nd the enterprise s core business. The im would to incrementlly position existing systems in proper service-oriented rchitecture frmework nd impose order without resorting to full-scle enterprise system replcement which might be unttinble for multitude of resons. Figure 2 illustrte the slient differences between current ppliction systems nd modern service-oriented systems. Consider vlue chin consisting of n different enterprises (or divisions of) nd corresponding softwre systems tht together relize different softwre services to vrious customers. In ppliction system rchitectures different customer services re typiclly implemented in segmented ppliction silos, even though the sme orgniztions prticipte in the vlue chin. The silo effect introduces severl system weknesses with respect to interoperbility:

5 Model-Generted Workplces: An Interoperbility Approch 5 Business functionlity is embedded in pplictions coupled by severl compile nd deployment time dependencies. This inflexibility forces n orgniztion to implement the sme functionlity in different nd non-interoperble pplictions (enterprise n providing functionlity y 1 nd y 2 ). Informtion dupliction nd inconsistency cross ppliction systems. Interoperbility issues re visible to customers forced to use different ppliction clients or different portions of Web portl to ccess the noninteroperble set of services provided by the vlue chin. Rigid vlue chin hinders introduction nd exchnge of business prtners. Appliction clients 1 Appliction servers n Legend Rich client Worksttion r y 1 Web site Appliction w/embedded services x providing functionlity x Interoperbility issues s b y 2 Web portl Web site c t z dependency 1 Appliction dependency (compile & deployment time) n Enterprises in vlue chin Customers consumers Usercomposble service lyer Shred nd network-visible service lyer providers Worksttion Legend Business service x providing functionlity x composition Rich client r y Integrted Web portl b r t y b c s x z z s Server 1 Server Server n Server m y Trcebility through lyers [used by composed of provided by] c dependency t z Fig. 2. System rchitecture: ppliction (to the left) nd service-oriented (to the right) The service-oriented system rchitecture ddresses these problems: The ppliction silos re broken up into shred nd network-visible services tht enble better interoperbility. s re utonomous nd cn be used by other services so tht informtion cn be shred cross different business networks. s cn be composed to fit the needs of the users. This enbles support for building integrted Web portls to support the businesses. Since different clients ccess the sme set of shred services, interoperbility issues re no longer visible to the users. Flexibility in choosing the service provider (illustrted with functionlity z being offered by provider n nd m), which enbles support for more dynmic businesses. Since this rchitecture ws designed to fcilitte interoperbility, it is clerly suitble pproch to fulfilling the PPM use cse requirements, but the problem of ctully designing nd implementing the pproprite service lyers over existing systems is by no mens trivil.

6 6 R.K. Rolfsen, D. Boell, C.Pronios, M. Anstsiou, T. Knothe, B. Elvesæter nd H. Jørgensen 4.1 INTRACOM Telecom Infrstructure The current IT infrstructure relevnt to the PPM cse is shown in the figure 3. The lower (Legcy systems) lyer encompsses the existing IT systems, while the next two lyers contin the services tht expose legcy dt to the service-oriented rchitecture. Legcy systems re built on vrious pltforms (Windows, Unix), using different technologies, of different levels of mturity nd re operted by different entities. Since these systems cnnot be replced in the short to medium term, the design of the service lyers bsed on model-driven pproch my be the key to their (n otherwise unttinble) integrtion in n rchitecture stisfying the interoperbility needs identified erlier. However, model-driven pproch is top-down process tht will eventully need to encompss existing functionlity in the bottom lyer, functionlity which cnnot be re-implemented. Athen Server Usercomposble Lyer Web s Orchestrtion Jv + Apchee MS Win Server 2K3 Athen Server Netwever Web server Legcy Proxy Shred & Networkvisible Lyer NET Web s MS IIS + ASP.NET MS SQL Server 2000 MS Win Server 2K3 Legcy Proxy Web s Apchee + Axis mysql 5.1 MS Win Server 2K3 Web Server Web s Netwever 2004 Suite MS SQL Server 2000 MS Win Server 2K3 Netwever ADARES Appliction iknow pp + iviews Iknow ERP Document Repository Product Performnce Other Legcy Legcy Systems REMEDY Pltform Orcle DB Server 9.1 MS Windows 2K Server Product Performnce mysap 2004 Orcle DB Server 9.1 MS Windows 2000 Server ERP SAP Enterprise Portl MS SQL Server 2000 MS Windows 2003 Server iknow Fig. 3. INTRACOM Telecom Infrstructures nd Repositories The infrstructure shown, both legcy systems nd systems specificlly creted during this study (Athen-project, bieze shded), instntites service-oriented rchitecture tht is used by the systems instntiting the model generted workplces nd provides to them the requested informtion. 4.2 Model-Generted Workplces Figure 4 depicts n opertionl view of model-generted workplce, exemplified with two different persons ccessing ICT services nd knowledge ssets using different model-generted views, e.g. Gntt chrts for project monitoring, Web forms for ctivity reporting, br grphs visulizing budget spending, nd Web documents reporting on ctivities. The different views my reflect the sme knowledge sset in different form or mnner tht best suit the role or person using tht sset in given business context. Informtion represented in the different views is bsed on the sme knowledge models nd therefore ensuring informtion consistency. MGWP will typiclly be implemented s Web portls nd MUPS specify Web elements tht cn be generted in such portls.

7 SM SCM r y SMM SCMM Integrted BPMM 1 & SCMM b Integrted PBM 1 & SCM r y z BPMM 2 b BPM 2 b c Integrted View 2 c Prtil View 2 Model-Generted Workplces: An Interoperbility Approch 7 MGWP Gntt chrts Web forms Grphs Reports Knowledge lyer MUP z MUP MUP MUP MUPS Knowledge models Fig. 4. Opertionl view of model-generted workplces Approch The overll objective of the MGWP pproch is to generte workplces s customized views (grphicl user-interfces) to common enterprise model. The views cn be either nvigtion (presenttion) views or work (opertion) views. A nvigtion view reflects prticulr enterprise model t given time, while work views re interctive views to common ctive (live) enterprise model, i.e. customized view to ctive knowledge modelling (Jørgensen et l., 2005). The models in concern re enterprise models nd workplce models, including: Reference models tht describe enterprise specific object types like product type structures, deprtment orgniztion, document templtes nd forms, nd reference processes. Instnce models tht describe the ctul enterprise such s work progress, product portfolio, orgniztion nd IT systems nd services. User-interfce models tht describe the lyout nd interction design of the model-generted workplces A workplce model describes the workplce structures, object views nd vilble services for n orgniztion group, person or role Frmework nd Design In the ATHENA project the MGWP pproch hs three min components: The enterprise models modeled in MO²GO nd Metis/Metis Enterprise Server. The MPCE (Modelling Pltform for Collbortive Enterprises) is n ATHENA result tht store nd exchnge enterprise models (Jørgensen et l., 2005). Another ATHENA result, POP* (Product, Orgniztion, Process nd other enterprise dimensions), is kernel lnguge to support the exchnge of enterprise models, both verticlly from high level bstrction down to detiled views s well s horizontlly between the business prtners.

8 8 R.K. Rolfsen, D. Boell, C.Pronios, M. Anstsiou, T. Knothe, B. Elvesæter nd H. Jørgensen The Web portls Process Assistnt (PA) nd Troux Internet Portl (TIP), respectively s workplce environments for MO²GO nd Metis enterprise models. In order to generte useful customized views from n enterprise model, it is necessry to ensure n pproprited level of model grnulrity (Knothe et l., 2007) (Knothe et l., 2006) (Knothe et l., 2005). In the INTRACOM Telecom cses the model hs to contin detiled informtion bout process flow s well involved roles, relevnt documents nd IT pplictions. In order to chieve the necessry grnulrity level the following modelling procedure ws pplied (see figure 5). Define the enterprise processes (min ctivities) Model tsks (prticulr ctivities) Assign roles to every tsk Assign relevnt documents nd IT systems to tsks Derive views for ech role Fig. 5. Modelling procedure for n MGWP wre enterprise model Bsed on the MGWP-wre enterprise model in MO²GO, the Process Assistnt genertes documenttion of reference models in HTML. Figure 6 shows exmples of the Process Assistnt for INTRACOM Telecom. To the left we see the front pge, which is nvigtion entry to the different reference models defined in the MO²GO enterprise model. To the right is n exmple of process presenttion view in HTML nd model view of the sme process in MO²GO Web-bsed model client. Fig. 6. Process Assistnt for INTRACOM Telecom enterprise model

9 Model-Generted Workplces: An Interoperbility Approch 9 It is lso possible to model (mke vilble) contextul link connections between Process Assistnt nd TIP, in such wy tht user my invoke TIP from Process Assistnt nd vice vers. The MGWP in TIP is work view of the underlying enterprise model stored in Metis Enterprise Server. Techniclly, we operte with two kinds of enterprise models, generl enterprise model tht represents the substntil knowledge of the enterprise s whole, nd workplce models tht define the content, lyout nd functionlity of the model-generted role specific workplces in TIP. The reference process model from MO2GO is imported into Metis through MPCE nd POP*. This model is used s bseline for the instnce process models. The Metis enterprise model is then populted with orgniztion dimension, product dimension nd system dimension. The system dimension constitutes the user interfce nd functionlity of the TIP work plces. Respectively through user interfce models nd service models. Integrtions with externl services nd legcy systems re modeled either s Active Knowledge Modelling (AKM) services or Web services. The AKM service type is used both for internl queries into the enterprise model nd for invoctions or clls of externl prmeterized URL services. Web services re mde vilble in the models through bottom-up import from WSDL into Metis. Modelling is thus used both bottom up nd top down to crete visul ren where top down business concerns nd bottom-up technicl relities cn be ligned. Figure 7 shows n exmple of typicl models in the system dimensions nd how these models re ssigned to specific role bsed workplce. In this cse the workplce for product mnger. Fig. 7. Types of system dimension models nd role ssignment In the ATHENA project we hve defined the metmodel User Interfce Modelling (UIM) s metmodel in Metis. The metmodel is just prtly implemented. The following concepts re centrl for our scenrio: Pge (UIM): Objects of Pge (UIM) re Web pges in TIP. The contents of the pge re derived from the objects tht is content of this pge. The content my be orgnized by sequence number. For those objects of Pge (UIM) with property filenme equls index or empty, re strt pges for the current workplce. Explorer (UIM): An Explorer (UIM) object is content of pge, nd it consists of two verticl divided frmes. The left frme is Tree View (UIM) nd the right one is the trget frme for the service result of current selected tree node.

10 10 R.K. Rolfsen, D. Boell, C.Pronios, M. Anstsiou, T. Knothe, B. Elvesæter nd H. Jørgensen Item (UIM): An object of Item (UIM) my represents service (AKM service or Web service), collection of sub items, nd plceholder for certin type of objects. The Item (UIM) object is used s plceholder in order to model fetures to objects in run-time. E.g. if one need different services vilble for tsks depending on the sttus of the tsks. Since the workplces in TIP re generted by or bsed on models tht re stored in repository, the functionlity nd the user interfce of the workplces cn esily be chnge in run time. Trditionlly, it hs been common to mke distinction between end-user pplictions nd development tools. When hving configurble pplictions nd/or pplictions tht re prtly configured t run time such s TIP, the distinction becomes less cler. Fig. 8. The user interfce model nd corresponding user interfce in TIP The workplce for the Product Mnger is bsed on workplce model with the UIM-model shown in figure 8. The UIM-model describes n explorer view. The explorer tree consists of n orgnized sequence of nodes, modeled s Item (UIM): Process Assistnt: Represents n AKM service tht invokes the strt pge of Process Assistnt for INTRACOM Telecom. Product mngement (reference processes): Represents n AKM service tht returns the reference processes the Product Mnger re responsible for. Products: Represents n AKM service tht gives ccess to ll product objects in the enterprise model. WIBAS Documents: Represents n AKM service tht returns ll document objects relted to the tsks tht re connected to the WIBAS product. WIBAS Product Mngement: Represents n AKM service tht returns ll WIBAS tsks the Product Mnger is responsible for. Figure 9 shows n opertionl view for tsk. The resources vilble for the tsk re modeled in the workplce model. The model describes tht ech tsk, which is WIBAS Product Mnger tsk, will hve relevnt documents nd link to the description of the tsk in Process Assistnt vilble s sub nodes in the tree view. The documents re ccessible through iknow, document mngement system t INTRACOM Telecom. The model lso describes tht TIP will use Web service to get the document loction in iknow.

11 Model-Generted Workplces: An Interoperbility Approch 11 Fig. 9. A tsk opertionl view The GUI of the process work view (the right frme in figure bove) is currently not modeled by UIM models. It is bsed on defult object viewer, but configurble through configurtion files regrding e.g. wht ttributes to be vlible. 5 Chllenges nd Future Work Present experience with the development of Model-Generted Workplces in the PPM scenrio strongly supports the effectiveness of the pproch for creting role specific ppliction spces tht cn support dy-to-dy tsks while dhering to the corporte stndrds cptured in the enterprise model. The ctul usefulness nd usbility of the MGWP for the selected role (Product Mnger) will be evluted in the ner future but it hs been clerly shown tht the generted workplces cn go fr beyond trditionl ppliction development pproch. However, in its current stte this pproch does not extend to the ctul execution lyer nd it does not gurntee or propose some proper support from the ctul informtion retrieving services. Further work or technologies will be needed in order to bridge this gp. Future directions for extending the MGWP concept so it cn evolve into n end-to-end interoperbility solution frmework my be inspired by the following observtions nd chllenges: The ctul design nd implementtion of underlying informtion retrieving Web services does not stem from the Enterprise Models. The services preexist nd re currently linked to pproprite tsks in the models. This cretes boundry or mismtch between the model-generted workplce, which is formlly creted, nd the services supporting it, which usully re not. This is not problem in services supporting documentrelted tsks, which cn be uniformly designed, but it is problem in ll other types of dt services. The min issue is the need to mtch constructs resulting from two very different processes t the boundry of the Enterprise Model nd the existing (legcy) systems (in other words, the Shred nd Network-visible Lyer).

12 12 R.K. Rolfsen, D. Boell, C.Pronios, M. Anstsiou, T. Knothe, B. Elvesæter nd H. Jørgensen Even more so, TIP User-Composble s (MUPS) presuppose the existence of complete set of visible services or the bility to trnsprently combine nd orchestrte existing services in order to support ll tsks modeled nd supported by TIP. This is not workplce tsk but is brrier in the effective utiliztion of such workplce. Further efforts should identify wys of formlly creting description of this complete set of services needed nd expected by the workplce. The lst step in the modelling procedure is quite fuzzy (Fig. 5). The question is how to derive the role specific view from model utomticlly. An pproch could be the customiztion of pproprited services (e.g. Web services) bsed on the enterprise model on demnd. Subsequently the model hs to contin ll necessry informtion in order to customize the right service. This mens high level of grnulrity nd increse of model complexity. A solution to mnge this issue hs to be developed. In order for model-configured solutions to relly chieve knowledge shring cross the roles nd disciplines involved in PPM, ctul product structures must be cptured in the models, so tht workplces cn be dpted to them. This is implemented by recent extensions to the Metis/TIP Web service plug-in, where lrge dt structures from XML business documents (e.g. Web service results) cn be mpped to model concepts nd utomticlly imported. The workplces cn lso updte legcy system dt by replicting the tsks tht invoke updte Web services for ech component, element, or prmeter in the product models. 6 References [1] ATHENA IP, IST , Homepge: [2] B. Elvesæter, R. K. Rolfsen, F. Lillehgen, nd D. Krlsen, (2007) Integrted Enterprise Architecture. In Proc. of the 12th ISPE Interntionl Conference on Concurrent Engineering (CE 2005), Fort Worth, Texs, USA, [3] Jørgensen, H. D., Krogstie, J., Ohren, O. P., nd Johnsen, S. G. (2004): Interctive Models for Tilorble nd Evolving Informtion Systems, Journl of Applied Systems Studies, Vol. 5 (1). [4] Jørgensen, H.D., Krlsen, D., Lillehgen F. (2005): Collbortive Modeling nd Metmodeling with the Enterprise Knowledge Architecture, Enterprise Modeling nd Informtion Systems Architectures, An Interntionl Journl, Vol. 1 (1) [5] Thoms KNOTHE, Timo KAHL, Dieter BOELL, Kristof SCHNEIDER, (2007) Frmework for Estblishing Enterprise Modeling in the Context of Collbortive Enterprises contributed to HICSS Conference, Hwy USA, [6] Knothe, T.; Jochem, R., (2006) Qulity Criteri for Enterprise Modelling in the context of networked Enterprises, Conference I-ESA 2006, Mrch, Bordeux, Frnce, [7] T. Knothe, K. Schneider, D. Böll, T. Khl, S. Schuster, F. Lillehgen, J. Krogstie, H. Grenger Solheim, (2005) First Version of Estblishing nd mngement pproch, Deliverble - A1.4.1, ATHENA, Integrted Project - Contrct n :IST ,