Model-Generated Workplaces: An Interoperability Approach R. K. Rolfsen 1 , D. Boell 2 , C. Pronios 3 , T. Knothe 2 , M. Anastasiou 3 , B. Elvesæter 1 and H. Jørgensen 4 1 SINTEF ICT, Forskningsveien 1, N-0314 OSLO, Norway {rolf.k.rolfsen, brian.elvesater}@sintef.no 2 Fraunhofer IPK Berlin, Corporate Management, Pascalstrasse 8-9, 10587, Berlin, Germany {dieter.boell, thomas.knothe}@ipk.fhg.de 3 INTRACOM TELECOM, 19,7 Km Markopoulo Ave., 19002, Peania Athens, Greece {hpro, mana}@intracom.gr 4 AKM AS, Vollsveien 9, N-1327, Lysaker, Norway [email protected]Abstract. This paper presents an approach to using model-generated workplaces (MGWP) in tandem with service-oriented architectures in order to meet interoperability needs in a corporate environment. More specifically, the interoperability study and research undertaken is based on a use case scenario related to the process of product portfolio management (PPM) in a large enterprise of the Telecommunication sector, INTRACOM Telecom. Starting from enterprise modelling constructs, Web-based workplaces are created that offer navigation and work views to the end user, supporting all his operational tasks as depicted in the enterprise model. Interaction with enterprise information repositories is facilitated via an underlying service-oriented architecture. 1 Introduction A model-generated workplace (MGWP) is a working environment for the business users involved in running the business operations of the enterprise. It is a user platform that provides the graphical front-end for human users to interact with software services supporting their day-to-day business activities. The workplace can be tailored to meet the specific requirements of different roles or persons within an enterprise, providing customized presentation and operation views. This is achieved through model-configured and user-composable services (MUPS). These services make use of knowledge models to generate business-oriented and context-aware graphical user interfaces (Jørgensen et al., 2004) (Elvesæter et al., 2005).
Transcript
Model-Generated Workplaces: An Interoperability Approach
R. K. Rolfsen1, D. Boell2, C. Pronios3, T. Knothe2, M. Anastasiou3, B. Elvesæter1 and H. Jørgensen4 1 SINTEF ICT, Forskningsveien 1, N-0314 OSLO, Norway
Abstract. This paper presents an approach to using model-generated workplaces (MGWP) in tandem with service-oriented architectures in order to meet interoperability needs in a corporate environment. More specifically, the interoperability study and research undertaken is based on a use case scenario related to the process of product portfolio management (PPM) in a large enterprise of the Telecommunication sector, INTRACOM Telecom. Starting from enterprise modelling constructs, Web-based workplaces are created that offer navigation and work views to the end user, supporting all his operational tasks as depicted in the enterprise model. Interaction with enterprise information repositories is facilitated via an underlying service-oriented architecture.
1 Introduction
A model-generated workplace (MGWP) is a working environment for the business users involved in running the business operations of the enterprise. It is a user platform that provides the graphical front-end for human users to interact with software services supporting their day-to-day business activities. The workplace can be tailored to meet the specific requirements of different roles or persons within an enterprise, providing customized presentation and operation views. This is achieved through model-configured and user-composable services (MUPS). These services make use of knowledge models to generate business-oriented and context-aware graphical user interfaces (Jørgensen et al., 2004) (Elvesæter et al., 2005).
2 R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
This paper presents an approach of using model generated workplaces (MGWP) in tandem with service-oriented architectures in order to meet the interoperability needs in a corporate environment. More specifically, the interoperability study and research undertaken are based on a use case scenario related to the process of product portfolio management (PPM) in a large enterprise of the Telecommunication sector, INTRACOM Telecom. Starting from enterprise modelling constructs, Web-based workplaces are created that offer navigation and work views to the end user, supporting all his operational tasks as depicted in the enterprise model. Interaction with enterprise information repositories is facilitated via an underlying service-oriented architecture. This work has been performed within the context of the IST integrated project ATHENA (ATHENA, 2004).
The paper is structured as follows: In section 1, the scenario of PPM is briefly described, while section 2 summarizes the interoperability needs in the scenario and the interoperability issues that the specific pilot addresses. The technical solution is presented in section 4 including the infrastructure used in INTRACOM Telecom and the approach and design of MGWP. Section 5 concludes the paper with the challenges that need to be dealt with as part of future work of this research effort.
2 Use Case Scenario: Product Portfolio Management
The PPM is a process involving decisions made at different levels, where the company’s active products list is constantly updated and revised. Therefore, new products are evaluated, selected and prioritized; existing ones may be accelerated, killed or reprioritized; and resources are allocated and reallocated to the active development projects. The objective is to allocate resources in a way to maximize sales and profits and minimize risks, as well as to achieve balance of development projects taking under consideration risks, technology and market trends.
The PPM is of significant importance especially to a large enterprise with many business units and complex products, the development of which requires the collaboration of many different engineering teams inside the same business unit or corporate environment, as well as within a business network of collaborative enterprise. In this study, the focus is on intra-enterprise level.
The PPM involves many business processes (new product development, product management, supply chain management), and many actors at various positions that perform different tasks from strategic level (e.g. Business Unit Manager, Sector Manager), and tactical level (Product Manager, Project Manager) to operational level (Team Leader, Engineer).
Within this scenario, we focus on the Product Management and on supporting the role of the Product Manager. At INTRACOM Telecom the objective of Product Management is to identify the need for a product/product-line, justify the inclusion of a product/product-line in the company solutions and control the execution of the development roadmap. In doing so, it needs to stand between the product development and manufacturing departments as well as the sales, technical support and public relations ones. The Product Manager is assigned to a product or product family and is responsible for developing or overseeing all aspects of the product
Model-Generated Workplaces: An Interoperability Approach 3
including product definition, product development, product launch, current product management, and product phase-out.
3 Interoperability Needs and Expectations
The analysis of the interoperability needs within the PPM scenario has revealed several problems as these are perceived by its actors in their daily work.
An important observation is that currently the communication among the different product portfolios and the collaboration of the various teams is insufficient. Collaborative work needs to be supported by providing actors with the tools in addition to information and communication support they need to efficiently perform their work through a single point of entry (workplaces).
It is worth noting that the PPM scenario reveals interoperability needs for supporting ad-hoc and event driven collaboration activities as opposed to standard workflow ones, when events and process variables are well defined.
Furthermore, the efficient performance of the product portfolio process requires federated information coming from marketing, product development execution, as well as from the product life cycle management. It is a knowledge intensive process, as it presupposes a very good and holistic view of the enterprise: strategy and objectives, skills and competences, as well as experience coming from previous development projects.
Decision-making activities on various levels of the enterprise are poorly supported due to lack of information integration from various ICT systems, as well as timely information updates. The relevant data and information needed by PPM participants for performing their tasks and make accurate decisions are spread across several systems. Figure 1 presents a high-level overview of the as-is situation of the systems and functions needed and used by a set of PPM actors.
Business DevelopmentManager
Product Development Manager
Product Manager
Team Manager
ERP System
Project Planning
Project Finance
Warehouse Management
Sales Data
Contract Management
Production Planning
ADARES
SIS
iKnow
Product Issues Management
Document Management
Marketing Intelligence
Product Issues Management
HR Management
Quality Engineer
Fig. 1. A high-level overview of the as-is situation.
4 R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
In addition to the above, cohesion of the decision-making activities with strategic plans and operational results needs to be supported.
Based on this analysis, we have identified several interoperability issues on all three levels of the enterprise: Business, Knowledge and ICT levels. The pilot implementation in ATHENA focused on the following interoperability issues:
1.
2.
3.
4.
5.
Link decision-making activities with strategic plans, development and operational results. Enterprise description and knowledge management in various aspects and dimensions (organization, role, decision, process, product, system). Product related knowledge sharing within and between product life cycle phases. Provision of (near) real-time aggregated views of key business information existing in legacy systems exploiting to the full extend the capabilities of existing ICT systems. Ability of integrated applications execution via a single point of entry.
4 Technical Solution
It is clear that the requirements presented have, over time, led to various system architecture implementations in an effort to reach some level of interoperability. Service-oriented architectures are just entering their maturity phase and can provide a solid and elegant solution. Of course, investing in the adoption and implementation of a service-oriented architecture across business boundaries is a major undertaking that has been shown to be beyond the capabilities of most present-day enterprises, which have to continuously support and upgrade their current (legacy) system architectures used in their day-to-day operations. The situation is more accentuated in cases where the evolution of said systems was not undertaken under the auspices of a central IT systems planning entity, which could mediate between conflicting system requirements.
In this respect, it would be of great utility if systems’ interoperability could be achieved without interfering with the operation of existing systems and the enterprise’s core business. The aim would to incrementally position existing systems in a proper service-oriented architecture framework and impose “order” without resorting to full-scale enterprise system replacement which might be unattainable for a multitude of reasons.
Figure 2 illustrate the salient differences between current application systems and modern service-oriented systems. Consider a value chain consisting of n different enterprises (or divisions of) and corresponding software systems that together realize different software services to various customers.
In application system architectures different customer services are typically implemented in segmented application silos, even though the same organizations participate in the value chain. The silo effect introduces several system weaknesses with respect to interoperability:
Model-Generated Workplaces: An Interoperability Approach 5
• Business functionality is embedded in applications coupled by several compile and deployment time dependencies. This inflexibility forces an organization to implement the same functionality in different and non-interoperable applications (enterprise n providing functionality y1 and y2).
• Information duplication and inconsistency across application systems. • Interoperability issues are visible to customers forced to use different
application clients or different ‘portions’ of a Web portal to access the non-interoperable set of services provided by the value chain.
• Rigid value chain hinders introduction and exchange of business partners.
xBusiness serviceprovidingfunctionality ‘x’ Traceability through layers
[used by | composed of |provided by]
Servicecomposition
s
Integrated Web portalRichclient
y
z
c
Server
Service dependency
1 … n m
Fig. 2. System architecture: application (to the left) and service-oriented (to the right)
The service-oriented system architecture addresses these problems:
• The application silos are broken up into shared and network-visible services that enable better interoperability.
• Services are autonomous and can be used by other services so that information can be shared across different business networks.
• Services can be composed to fit the needs of the users. This enables support for building integrated Web portals to support the businesses. Since different clients access the same set of shared services, interoperability issues are no longer visible to the users.
• Flexibility in choosing the service provider (illustrated with functionality z being offered by provider n and m), which enables support for more dynamic businesses.
Since this architecture was designed to facilitate interoperability, it is clearly a suitable approach to fulfilling the PPM use case requirements, but the problem of actually designing and implementing the appropriate service layers over existing systems is by no means trivial.
6 R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
4.1 INTRACOM Telecom Infrastructure
The current IT infrastructure relevant to the PPM case is shown in the figure 3. The lower (Legacy systems) layer encompasses the existing IT systems, while the next two layers contain the services that expose legacy data to the service-oriented architecture. Legacy systems are built on various platforms (Windows, Unix), using different technologies, of different levels of maturity and are operated by different entities. Since these systems cannot be replaced in the short to medium term, the design of the service layers based on a model-driven approach may be the key to their (an otherwise unattainable) integration in an architecture satisfying the interoperability needs identified earlier. However, a model-driven approach is a top-down process that will eventually need to encompass existing functionality in the bottom layer, functionality which cannot be re-implemented.
ERP Product Performance
IknowDocument Repository
OtherLegacy
Legacy ProxyWeb serverNetweaver
Athena Server
Legacy Systems
Shared & Network-
visible Service Layer
User-compo-sable
Service Layer
iKNOW app + iVIEWS
SAP Enterprise Portal
MS SQL Server 2000
MS Windows 2003 Server
iKNOW
NET Web Services
MS IIS + ASP.NET
MS SQL Server 2000
MS Win Server 2K3
Legacy Proxy
mySAP 2004
Oracle DB Server 9.1
MS Windows 2000 Server
ERP
ADARES Application
REMEDY Platform
Oracle DB Server 9.1
MS Windows 2K Server
Product Performance
Web Services
Apachee + Axis
mySQL 5.1
MS Win Server 2K3
Web Server
Web Services
Netweaver 2004 Suite
MS SQL Server 2000
MS Win Server 2K3
Netweaver
Web Services
Service Orchestration
Java + Apachee
MS Win Server 2K3
Athena Server
Fig. 3. INTRACOM Telecom Infrastructures and Repositories
The infrastructure shown, both legacy systems and systems specifically created during this study (Athena-project, bieze shaded), instantiates a service-oriented architecture that is used by the systems instantiating the model generated workplaces and provides to them the requested information.
4.2 Model-Generated Workplaces
Figure 4 depicts an operational view of a model-generated workplace, exemplified with two different persons accessing ICT services and knowledge assets using different model-generated views, e.g. Gantt charts for project monitoring, Web forms for activity reporting, bar graphs visualizing budget spending, and Web documents reporting on activities. The different views may reflect the same knowledge asset in a different form or manner that best suit the role or person using that asset in a given business context. Information represented in the different views is based on the same knowledge models and therefore ensuring information consistency. MGWP will typically be implemented as Web portals and MUPS specify Web elements that can be generated in such portals.
Model-Generated Workplaces: An Interoperability Approach 7
MG
WP
Kno
wle
dge
laye
rGraphsGantt
chartsWebforms Reports
…
MUPS
Knowledgemodels
b
c
a c
b
BPMM2
BPM2
Partial View2
Integrated View2
a
b
a yra yr
z
IntegratedBPMM1 & SCMM
IntegratedPBM1 & SCM
a yra yrSCM SCMM
z
SM SMM
MUPService
MUPService
MUPService
MUPService
MG
WP
Kno
wle
dge
laye
rGraphsGantt
chartsWebforms Reports
…
MUPS
Knowledgemodels
b
c
a c
b
BPMM2
BPM2
Partial View2
Integrated View2
a
b
a yra yr
z
IntegratedBPMM1 & SCMM
IntegratedPBM1 & SCM
a yra yrSCM SCMM
z
SM SMM
MUPService
MUPService
MUPService
MUPService
Fig. 4. Operational view of model-generated workplaces
4.2.1 Approach The overall objective of the MGWP approach is to generate workplaces as customized views (graphical user-interfaces) to a common enterprise model. The views can be either navigation (presentation) views or work (operation) views.
A navigation view reflects a particular enterprise model at a given time, while work views are interactive views to a common active (live) enterprise model, i.e. a customized view to active knowledge modelling (Jørgensen et al., 2005). The models in concern are enterprise models and workplace models, including:
• Reference models that describe enterprise specific object types like product type structures, department organization, document templates and forms, and reference processes.
• Instance models that describe the actual enterprise such as work progress, product portfolio, organization and IT systems and services.
• User-interface models that describe the layout and interaction design of the model-generated workplaces
A workplace model describes the workplace structures, object views and available services for an organization group, person or role.
4.2.2 Framework and Design In the ATHENA project the MGWP approach has three main components:
• The enterprise models modeled in MO²GO and Metis/Metis Enterprise Server.
• The MPCE (Modelling Platform for Collaborative Enterprises) is an ATHENA result that store and exchange enterprise models (Jørgensen et al., 2005). Another ATHENA result, POP* (Product, Organization, Process and other enterprise dimensions), is a kernel language to support the exchange of enterprise models, both vertically from high level abstraction down to detailed views as well as horizontally between the business partners.
8 R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
• The Web portals Process Assistant (PA) and Troux Internet Portal (TIP), respectively as workplace environments for MO²GO and Metis enterprise models.
In order to generate useful customized views from an enterprise model, it is necessary to ensure an appropriated level of model granularity (Knothe et al., 2007) (Knothe et al., 2006) (Knothe et al., 2005). In the INTRACOM Telecom cases the model has to contain detailed information about process flow as well involved roles, relevant documents and IT applications. In order to achieve the necessary granularity level the following modelling procedure was applied (see figure 5).
Define the enterprise processes
(main activities)
Model tasks(particular activities)
Assign rolesto every task
Assign relevant documents
and IT systems to tasks
Derive views for each role
Fig. 5. Modelling procedure for an MGWP aware enterprise model
Based on the MGWP-aware enterprise model in MO²GO, the Process Assistant generates documentation of reference models in HTML. Figure 6 shows examples of the Process Assistant for INTRACOM Telecom. To the left we see the front page, which is a navigation entry to the different reference models defined in the MO²GO enterprise model. To the right is an example of a process presentation view in HTML and a model view of the same process in MO²GO Web-based model client.
Fig. 6. Process Assistant for INTRACOM Telecom enterprise model
Model-Generated Workplaces: An Interoperability Approach 9
It is also possible to model (make available) contextual link connections between Process Assistant and TIP, in such a way that a user may invoke TIP from Process Assistant and vice versa.
The MGWP in TIP is a work view of the underlying enterprise model stored in Metis Enterprise Server. Technically, we operate with two kinds of enterprise models, a general enterprise model that represents the substantial knowledge of the enterprise as a whole, and workplace models that define the content, layout and functionality of the model-generated role specific workplaces in TIP.
The reference process model from MO2GO is imported into Metis through MPCE and POP*. This model is used as a baseline for the instance process models. The Metis enterprise model is then populated with organization dimension, product dimension and system dimension. The system dimension constitutes the user interface and functionality of the TIP work places. Respectively through user interface models and service models. Integrations with external services and legacy systems are modeled either as Active Knowledge Modelling (AKM) services or Web services. The AKM service type is used both for internal queries into the enterprise model and for invocations or calls of external parameterized URL services. Web services are made available in the models through bottom-up import from WSDL into Metis. Modelling is thus used both bottom up and top down to create a visual arena where top down business concerns and bottom-up technical realities can be aligned. Figure 7 shows an example of typical models in the system dimensions and how these models are assigned to a specific role based workplace. In this case the workplace for a product manager.
Fig. 7. Types of system dimension models and role assignment
In the ATHENA project we have defined the metamodel User Interface Modelling (UIM) as a metamodel in Metis. The metamodel is just partly implemented. The following concepts are central for our scenario:
• Page (UIM): Objects of Page (UIM) are Web pages in TIP. The contents of the page are derived from the objects that “is content of” this page. The content may be organized by a sequence number. For those objects of Page (UIM) with property filename equals “index” or empty, are start pages for the current workplace.
• Explorer (UIM): An Explorer (UIM) object is a content of a page, and it consists of two vertical divided frames. The left frame is a Tree View (UIM) and the right one is the target frame for the service result of current selected tree node.
10 R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
• Item (UIM): An object of Item (UIM) may represents a service (AKM service or Web service), a collection of sub items, and a placeholder for a certain type of objects. The Item (UIM) object is used as a placeholder in order to model features to objects in run-time. E.g. if one need different services available for tasks depending on the status of the tasks.
Since the workplaces in TIP are generated by or based on models that are stored in a repository, the functionality and the user interface of the workplaces can easily be change in run time. Traditionally, it has been common to make a distinction between end-user applications and development tools. When having configurable applications and/or applications that are partly configured at run time such as TIP, the distinction becomes less clear.
Fig. 8. The user interface model and corresponding user interface in TIP
The workplace for the Product Manager is based on a workplace model with the UIM-model shown in figure 8. The UIM-model describes an explorer view. The explorer tree consists of an organized sequence of nodes, modeled as Item (UIM):
• Process Assistant: Represents an AKM service that invokes the start page of Process Assistant for INTRACOM Telecom.
• Product management (reference processes): Represents an AKM service that returns the reference processes the Product Manager are responsible for.
• Products: Represents an AKM service that gives access to all product objects in the enterprise model.
• WIBAS Documents: Represents an AKM service that returns all document objects related to the tasks that are connected to the WIBAS product.
• WIBAS Product Management: Represents an AKM service that returns all WIBAS tasks the Product Manager is responsible for.
Figure 9 shows an operational view for a task. The resources available for the task are modeled in the workplace model. The model describes that each task, which is a WIBAS Product Manager task, will have relevant documents and a link to the description of the task in Process Assistant available as sub nodes in the tree view. The documents are accessible through iKnow, a document management system at INTRACOM Telecom. The model also describes that TIP will use a Web service to get the document location in iKnow.
Model-Generated Workplaces: An Interoperability Approach 11
Fig. 9. A task operational view
The GUI of the process work view (the right frame in figure above) is currently not modeled by UIM models. It is based on a default object viewer, but configurable through configuration files regarding e.g. what attributes to be avaliable.
5 Challenges and Future Work
Present experience with the development of Model-Generated Workplaces in the PPM scenario strongly supports the effectiveness of the approach for creating role specific application spaces that can support day-to-day tasks while adhering to the corporate standards captured in the enterprise model. The actual usefulness and usability of the MGWP for the selected role (Product Manager) will be evaluated in the near future but it has been clearly shown that the generated workplaces can go far beyond a traditional application development approach. However, in its current state this approach does not extend to the actual execution layer and it does not guarantee or propose some proper support from the actual information retrieving services. Further work or technologies will be needed in order to bridge this gap. Future directions for extending the MGWP concept so it can evolve into an end-to-end interoperability solution framework may be inspired by the following observations and challenges:
• The actual design and implementation of underlying information retrieving Web services does not stem from the Enterprise Models. The services pre-exist and are currently “linked” to appropriate tasks in the models. This creates a “boundary” or “mismatch” between the model-generated workplace, which is formally created, and the services supporting it, which usually are not. This is not a problem in services supporting document-related tasks, which can be uniformly designed, but it is a problem in all other types of data services. The main issue is the need to “match” constructs resulting from two very different processes at the boundary of the Enterprise Model and the existing (legacy) systems (in other words, the Shared and Network-visible Service Layer).
12 R.K. Rolfsen, D. Boell, C.Pronios, M. Anastasiou, T. Knothe, B. Elvesæter and H. Jørgensen
• Even more so, TIP User-Composable Services (MUPS) presuppose the existence of a “complete” set of visible services or the ability to transparently combine and orchestrate existing services in order to support all tasks modeled and supported by TIP. This is not a workplace task but is a barrier in the effective utilization of such a workplace. Further efforts should identify ways of formally creating a description of this “complete” set of services needed and expected by the workplace.
• The last step in the modelling procedure is quite fuzzy (Fig. 5). The question is how to derive the role specific view from a model “automatically”. An approach could be the customization of appropriated services (e.g. Web services) based on the enterprise model on demand. Subsequently the model has to contain all necessary information in order to customize the right service. This means a high level of granularity and increase of model complexity. A solution to manage this issue has to be developed.
• In order for model-configured solutions to really achieve knowledge sharing across the roles and disciplines involved in PPM, actual product structures must be captured in the models, so that workplaces can be adapted to them. This is implemented by recent extensions to the Metis/TIP Web service plug-in, where large data structures from XML business documents (e.g. Web service results) can be mapped to model concepts and automatically imported. The workplaces can also update legacy system data by replicating the tasks that invoke update Web services for each component, element, or parameter in the product models.
6 References
[1] ATHENA IP, IST 507849, 2004. Homepage: http://www.athena-ip.org. [2] B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen, (2007) Integrated
Enterprise Service Architecture. In Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005.
[3] Jørgensen, H. D., Krogstie, J., Ohren, O. P., and Johnsen, S. G. (2004): Interactive Models for Tailorable and Evolving Information Systems, Journal of Applied Systems Studies, Vol. 5 (1).
[4] Jørgensen, H.D., Karlsen, D., Lillehagen F. (2005): Collaborative Modeling and Metamodeling with the Enterprise Knowledge Architecture, Enterprise Modeling and Information Systems Architectures, An International Journal, Vol. 1 (1)
[5] Thomas KNOTHE, Timo KAHL, Dieter BOELL , Kristof SCHNEIDER, (2007) Framework for Establishing Enterprise Modeling in the Context of Collaborative Enterprises contributed to HICSS Conference, Haway USA, 2007.
[6] Knothe, T.; Jochem, R., (2006) Quality Criteria for Enterprise Modelling in the context of networked Enterprises, Conference I-ESA 2006, 20-24 March, Bordeaux, France, 2006.
[7] T. Knothe, K. Schneider, D. Böll, T. Kahl, S. Schuster, F. Lillehagen, J. Krogstie, H. Grenager Solheim, (2005) First Version of Establishing and management approach, Deliverable - A1.4.1, ATHENA, Integrated Project - Contract n°:IST-507849, http://www.athena-ip.org.
