Egidijus Ostašius
email: egidijus.ostasius@vgtu.lt

Assessing Maturity for e-Government Services

Keywords: e-government, public e-service, assessment, e-service maturity, benchmarking, sophistication

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Electronic government (or e-government) has not a long history since the first official government sites appeared in the middle of 1990s delivering information and services. There exist a number of different definitions of e-government [START_REF] Jansen | Assessing E-government progress -why and what[END_REF]. According to one of them e-government beside constituency participation, governance by transforming internal and external relationships is a continuous optimization of service delivery through technology, the Internet, and new media [START_REF] Group | Key issues in E-Government Strategy and Management[END_REF]. Electronic services (or eservices), the core parts of e-government are in continuous processes of improvement and evolutional changes in order to provide better services to their customers. That causes the need for the measure of how big these trends of changes are and what is the growth in such kind of evolution. A number of methods and models were proposed and applied (e.g., [START_REF] Baum | Gartner's Four Phases of E-Government Model[END_REF], [START_REF] Layne | Developing fully functional E-government: A four stage model[END_REF], [START_REF] Ronaghan | Benchmarking E-Government: A Global Perspective[END_REF], [START_REF] Hiller | Privacy strategies for electronic government[END_REF]). Mostly they are based on stage models that describe and predict main aspects of e-government and supporting e-services.

Stage models are used for evaluating and benchmarking the level of maturity of the developed e-services [START_REF]9th Benchmark Measurement. Digitizing Public Services in Europe: Putting ambition into action[END_REF], categorizing, evaluating the progress and guiding the directions for public service development, help in understanding the current e-service status [START_REF]Electronic Service Delivery, including Internet use by Commonwealth Government Agencies[END_REF], for directing where to go and assessing the developing process [START_REF] Safad | The 24/7 Agency: Criteria for 24/7 Agencies in the Networked Public Statskontoret[END_REF]. They are also used to rank the countries for e-government implementations and their trends (e.g., [START_REF]9th Benchmark Measurement. Digitizing Public Services in Europe: Putting ambition into action[END_REF], [START_REF]Leveraging e-government at a time of financial and economic crisis[END_REF], [START_REF] West | Improving Technology Utilization in Electronic Government around the World, 2008[END_REF], [START_REF]Intelligence Unit. Digital economy ranking[END_REF]) although because of differences in assessment methods these surveys show some very different results [START_REF] Vintar | How much can we trust different egovernment surveys? The case of Slovenia[END_REF]. Usually stage models are defined by various stages of e-government, which reflect the degree of technical sophistication and interaction with users [START_REF] Moon | The Evolution of E-Government among Municipalities: Rhetoric or Reality?[END_REF] (e.g., (1) information necessary to start the procedure to obtain the service available on the website(s), (2) interaction: downloadable or printable form to start the procedure to obtain the service on the website(s), (3) twoway interaction: electronic forms to start the procedure to obtain the service on the website(s), (4) transaction: full electronic case handling of the procedure by the service provider, (5) proactive, automated service delivery [START_REF]9th Benchmark Measurement. Digitizing Public Services in Europe: Putting ambition into action[END_REF]). But after the empirical investigation of real e-services there do not appear to be discernible steps or stages in e-government. Rather, after an initial e-government presence, governments adopt egovernment slowly and incrementally [START_REF] Coursey | Models of E-Government: Are They Correct? An Empirical Assessment[END_REF] -development of services is not sudden jumps, but even increase. That leads to the thoughts that there is a need for developing methods and models that describe e-government and their e-services more accurate.

On the other hand these models just express the potency of examined cases of egovernment services but do not consider the structure of e-services and the intensity (volumes) of their usage in real world. It's often the will "If we build it, they will come!" not come true. At the end of the day, e-government is what it is, not what it was predicted to be [START_REF] Coursey | Models of E-Government: Are They Correct? An Empirical Assessment[END_REF]. That prompts that evaluating the e-services we should take into account not only the potential possibilities of the provided e-service that are based on the speculations of e-government models -the 'potential maturity' of e-service but also take into consideration the empirical data of the usage of the e-services.

The investigation of the problem why the e-service with high maturity level is not used in such volumes as it was expected is far beyond the scope of this paper. In this article, we ask if the e-services with the same maturity level ('potential maturity') but different intensity of their online usage should be evaluated at the same rate.

We present more accurate assessment method for e-service maturity that is based on stage models, service decomposition into the components -operations, which are related to the total intensity of their usage, as well as intensity of online service usage. In our case we decided on the stage model [START_REF]9th Benchmark Measurement. Digitizing Public Services in Europe: Putting ambition into action[END_REF] that was approved and used for several years by collaborating Member States for the eGovernment performance benchmarking in EU though the method can be used for any other type of stage model that were listed before. The method first of all can be used for self-assessment of trends of maturity of e-services in different time periods of e-service development evolution. It could be also useful for benchmarking, comparing different e-services with each other or indicating weak aspects of the e-service and eliminating these weaknesses by appointing directions for further development. Finally, the presented method was adopted for use with the set of evaluation criteria that are based on generic e-service model [START_REF] Ostasius | Modeling e-services in public sector[END_REF] when assessment is carried out in accordance with the stage model definitions for each criterion.

Case Study: Driver's License Service

We'll analyze and evaluate the maturity of the driver's license (DL) service -a standard procedure to obtain a driver's license for a personal vehicle not for professional use which is one of the 'traditional benchmark' public services [START_REF]9th Benchmark Measurement. Digitizing Public Services in Europe: Putting ambition into action[END_REF].

In our case DL service structure is composed of service operations (marked as 1, 2, ..., 5) that are detailed by service cases (marked as 3 a, 3 b, ..., 5 b). DL service operations:

1 Issue a new driver license.

2 Change/renew driver license.

3 Change of status of driver license: 3 a. activate driver license, 3 b. reports on driver license losses. 4 Obtain information on the right to drive or driver license: 4 a. obtain information on the right to drive: granted / deprived, 4 b. obtain information on driver license: produced / sent / handed, 4 c. obtain information on driver license validity, 4 d. obtain information from driver license register, 4 e. obtain information on driver examination: statement / protocol / reference. 5 Obtain information on driver license production or expiration: 5 a. obtain information on driver license production, 5 b. obtain information on expiration of driver license. A particular DL service may consist of one or more non contradictory operations. As the maturity level for different operations of the service may be different we'll apply the model for every separate operation individually.

Service operations number 1 and 2 may be assessed by 3 rd or 4 th stage depending on service conditions: 3 rd stage -if it is not possible to accept required data not electronically and customer must physically deliver lacking data documents to the service provider office; 4 th stage -if all required data for the service are accepted online. The service operations number 3 and 4 may be assessed by: 3 rd stage -if the request is delivered to service provider not electronically; 4 th stage -if the request is delivered online. The service operation number 5 may be assessed by 4 th or 5 th stage: 4 th stage -if the customer of the service did not provide contact data that could be used to send him information and 5 th stage -if service provider prompts the customer automatically online.

According to [START_REF]9th Benchmark Measurement. Digitizing Public Services in Europe: Putting ambition into action[END_REF] the overall DL service maturity level would be assessed to stage 5 that correspond to the possibly highest evaluation level for this kind of service. It is because the current method is referenced to the highest evaluation of the service operation that is service operation number 5 in our case and that satisfy the model 5 th stage conditions. But such an assessment of the service for DL service does not fit for the rest operations of the service. Though the service operation number 5 would be assessed to stage level 5 is it correct to assess the whole service to 5 th stage level? It is obvious that such a method of service evaluation when the service is composed of operations with different maturity level is not precise.

E-service Maturity Level Assessment Method

E-service maturity level according to the method described in [START_REF]9th Benchmark Measurement. Digitizing Public Services in Europe: Putting ambition into action[END_REF] is formed as follows: the maturity level evaluation M n for the online service n, (n=1, ..., N, N -number of services that participate in evaluation) is calculated in percentages using current stage model level evaluation of the service K n and highest possible stage model level H n for the service n:

M n = K n (100 / H n ) (1)
where n -index of the service, n=1, ..., N, M n -maturity evaluation level for service n, H n -possible highest stage model level for service n: H n ∈{1, 2, 3, 4, 5} (according to recommendations for DL service [START_REF]9th Benchmark Measurement. Digitizing Public Services in Europe: Putting ambition into action[END_REF] this level is 5), K n -stage model level evaluation defined by the experts according to the definition of the stage model levels: K n ∈{0, 1, 2, 3, 4, 5}, when the highest evaluation level is H n =5. The overall maturity level M for the services that participate in assessment is:

N M = 1/N Σ M n (2) n=1
We'll apply formula (1) for the maturity level evaluation for every separate operation j of service n. In this case the maturity level evaluation M' n1 of service n is calculated as follows:

P n R jn M' n1 = 1/ P n Σ (1/ R jn Σ k ijn (100 / h jn )) (3) j=1 i=1
where i -evaluation index for operation j of service n, i=1, ..., R jn , R jn -number of evaluations of operation j for service n, k ijn -evaluation rate for evaluation i of operation j for service n: k ijn ∈{0, 1, 2, 3, 4, 5}, h jn -possible highest evaluation rate for operation j of service n: h jn ∈{1, 2, 3, 4, 5}, k ijn ≤h jn . Evaluation formula (3) we'll make more accurate by introducing usage coefficients α jn for operation j of service n that correspond to the intensity of the service operation usage as a part of the intensity of the usage of all service operations. In this case maturity level evaluation M' n2 for service n:

P n R jn M' n2 = Σ α jn (1/ R jn Σ k ijn (100 / h jn )) (4) j=1 i=1
P n where α jn = ω jn / Σ ω jn , j=1

ω jn -total intensity of usage of operation j for service n (number of operations j for service n per time period T) via traditional and electronic (online) space, P n Σ α jn = 1, for every n. j=1

After collected statistics on intensity of the usage of operation j for e-service n we can evaluate the volume S' n of the service which is delivered online: P n S' n = 1/ P n Σ β jn 100

(5) j=1 where β jn = ϕ jn / ω jn , ϕ jn -intensity of online operations -number of online operations j for service n per time period T, P n 1 / P n Σ β jn ≤ 1, for every n. j=1

The statistics on intensity of the usage of operation j for e-service n we'll use for the service maturity evaluation M' n3 :

P n R jn P n M' n3 = Σ Σ (ϕ ijn / Σ ω ln ) k ijn (100 / h jn ) (6) j=1 i=1 l=1
where ϕ ijn -intensity of online operations (number of online operations j for service n per time period T) for evaluation i, ω ln -total usage intensity of operation l for service n (number of operations l for service n per time period T) in traditional and electronic (online) space. We'll use (2) formula for the total evaluation of maturity M' for all e-government services:

N P n R jn P n M'= 1/N Σ Σ Σ (ϕ ijn / Σ ω ln ) k ijn (100 / h jn ) (7) n=1 j=1 i=1 l=1

In case, when there is a set of evaluation criteria (e.g., see [START_REF] Ostasius | Applying e-service model in assessment and comparison of services[END_REF]) that are defined by stage models, the maturity evaluation M' n4 of every operation j (j=1,…, P n ) for service n (n=1,…, N) instead of one we use several criteria k' njl (l=1,…, L nj ) with possible highest evaluation rate h' njl and "weights" w njl . Here formula (6) will be as follows:

P n L nj M' n4 = 1/ P n Σ α jn Σ w njl (k' njl (100 / h' njl )) (8) j=1 l=1
where l -evaluation criteria index for operation j of service n, l=1,..., L nj , L nj -number of evaluation criteria for operation j of service n, k' njl -evaluation rate according to the criterion l of operation j for service n, h' njl -possible highest evaluation rate of criterion l for operation j of service n, k' njl ≤h' njl , w njl -"weight" for evaluation criterion l of operation j of service n, L nj Σ w njl = 1, for every n and j. l=1

E-service Maturity Evaluation Sample

For the method illustration we'll use artificial data that show service maturity evaluations in different situations of evolution of DL service development. E-service maturity evaluations are presented graphically in Fig. 1. (For more detailed data refer to Electronic Table in [START_REF]DL Service Assessment: maturity evaluation data[END_REF]). Different cases A, B, C, D, E and F represent DL service with different usage intensity and different maturity level for the operations of the service.

In our sample every operation j for service n (DL service) is evaluated according to 2 possible maturity levels: lower and highest possible maturity evaluation rate (R jn =2; j=1, …, 5):

1 Case A presents situation when there is no online service operation though some general information is presented in official web site: maturity level 1. Case B presents situation when some service operations are online but evaluated at the lower rate: maturity level 3. Cases C, D and E represent intermediate situation when service operations are in two levels: maturity level 3 and 4. Case F represent situation when all service operations are evaluated in the highest rates that means the service has fully matured.

Comparing maturity evaluations (see Fig. 1) we'll notice that evaluation M' n3 represents the maturity trend more accurately comparing it with M n , M' n1 and M' n2 evaluations that ignore the usage intensity of online service operations in different levels of their maturity and that's these evaluations are not informative in this case. When the usage intensity of service operations is the same for different service operation evaluation (cases C, D and E) service maturity evaluation M' n3 grows according to the growth of service operations: more usage intensity in higher maturity level higher maturity of the service. Evaluations M' n2 and M' n3 for every separate operation of the service represent its own maturity.

In real situations in order to evaluate the service maturity the experts should make a decision for every separate operation of the service on the level of the maturity and they should apply presented formulas to calculate the total service maturity using the statistics of the operation usage. It may be helpful to use Electronic Table similar to presented in [START_REF]DL Service Assessment: maturity evaluation data[END_REF].

Conclusions and Future Work

This article proposed a more accurate method for assessing maturity of e-services. The assessment method is based on stage models, service decomposition into the components -operations. Evaluation of maturity of e-service depends on statistics such as the total intensity of the usage of every separate operation and the intensity of the usage of online service operation. The option of the e-service maturity evaluation is presented when there is used more than one criterion for maturity evaluation of every operation of the service. The advantage of the method was illustrated by modeling evaluation of the service with artificial data.

Still, there are several requirements that should be satisfied to be able to use the method in practice. First of all the service should be accurately decomposed into separate operations. There should be collected reliable statistical information of the usage of each operation in traditional and electronic space.

The method is focused to be used for self-assessment of maturity of e-services in their development process or for benchmarking, for comparing different e-services one with each other or for comparing the same e-services that are provided by different administrations (e.g., municipalities) or even in different countries.

For the future the presented method should be tested and validated for the maturity evaluating on real data of e-services.

Fig. 1 .

 1 Fig. 1. E-service maturity evaluations

  Issue a new driver license; 1.1 if not all data are accepted online this operation is evaluated in level 3; 1.2 if all data are accepted online this operation is evaluated in level 4. 2 Change/renew driver license; 2.1 if not all data are accepted online this operation is evaluated in level 3; 2.2 if all data are accepted online this operation is evaluated in level 4. 3 Change of status of driver license: 3.1 if the messages about the DL status is transmitted not electronically this operation is evaluated in level 3; 3.2 if the messages about the DL status are transmitted online this operation is evaluated in level 4. 4 Obtain information on the right to drive or driver license: 4.1 if the request and data are transmitted not electronically this operation is

	evaluated in level 3;
	4.2 if the request and data are transmitted online this operation is evaluated
	in level 4.
	5 Obtain information on driver license production or expiration:
	5.1 if responding to the request of the customer information is transmitted
	online this operation is evaluated in level 4;
	5.2 if information is transmitted online without the request of the customer
	(proactively) this operation is evaluated in level 5.


Rolando Vargas Vallejos

Paulo Fernado

Pinto Barcellos

Margareth Rodrigues De Carvalho Borella

Rosimeri Machado
email: rosimeri.machado@ponzoni.com.br

Identifying the Reasons Why Companies Abandon Collaborative Networks

Keywords: Collaborative Network Organization, Collaborative Network Method, Network Failure

The present work identified possible factors that led some collaborative network organizations to close. The case study was based on experiences obtained in networks that took part of the Collaborative Network Program of the State of Rio Grande do Sul (Brazil). One of the Program creators, managers, consultants and entrepreneurs of six networks that broke down were interviewed based on a semi-structured instrument. The analysis of the Collaborative Network method indicated that important factors could motivate the failure of networks, which were validated with the integrated model of alliance failure proposed by Park and Ungson [1]. The article ends by suggesting some improvements in the Collaborative Network Program of the State of Rio Grande do Sul to become more efficient and contribute to the network success.

Introduction

The collaborative network model of cooperating to compete started with the studies of Brandenburger and Stuart [START_REF] Brandenburger | Value-based Business strategy[END_REF] and Brandenburger and Nalebuff [START_REF] Brandenburger | Coopetition[END_REF] who popularized the term "coopetition" [START_REF] Rodrigues | Structure and cooptation in organization network[END_REF]. Porter [START_REF] Porter | On Competition. The Harvard Business Review Book Series[END_REF] who has systemized competition strategies of individual companies, also considers the strategy of cooperation as an alternative to compete and develop a competitive advantage.

There are several studies of Collaborative Networks Organizations (CNOs) success in the State of Rio Grande do Sul [START_REF] Vallejos | A framework to create a virtual organisation breeding environment for small and medium enterprises[END_REF] and [START_REF] Barcellos | Collaborative Networks: an innovative approach to enhance competitiveness of small firms in Brazil[END_REF], among others. However, few studies describe the failures of Collaborative Networks. For this reason, this paper aims at contributing to the development and/or improvement of methods and practices to be used for the success of future Collaborative Networks.

The Collaborative Network Program of the State of Rio Grande do Sul (CNPRS) is an initiative of the Government in order to stimulate small and medium enterprises to become more competitive. The Program begun in 2000 and, therefore, it is important to identify the reasons why companies, which integrate collaborative networks, abandon them. This identification may help to create new successful CNOs, and especially to support the existing ones. The research question therefore is: which are the reasons why enterprises that belong to CNPRS give it up?

2 Failures in Collaborative Network Organizations: Theoretical Background

In the last two decades, a special attention has been paid to CNOs, which are formed by several entities (e.g., organizations and specialists) that are autonomous, geographically distributed, and heterogeneous in terms of their operating environment, culture, social capital, and goals. These entities collaborate with each other to achieve common goals, and their interactions are supported by Information and Communication Technology (ICT) [START_REF] Camarinha-Matos | Collaborative Networks: A new scientific discipline[END_REF]. Under an economic perspective, a network organization may be an answer to the competitive pressure over individual enterprises to increase their competitiveness in production, new products development and launching, new technologies access, and knowledge share among suppliers, customers and competitors [START_REF] Balestrin | Criação de Conhecimento nas Redes de Cooperação Interorganizacional[END_REF]. A large number of research projects involving CNOs are carried out worldwide, and a growing number of practical cases have been reported. Camarinha-Matos and Afsarmanesh [START_REF] Camarinha-Matos | A framework for virtual organization creation in a breeding environment[END_REF] have raised the need for modeling to understand, manage, simulate, and predict the behavior of CNOs.

The concept of breeding environment has emerged as the necessary context to support the effective creation of CNOs. Shortly, Virtual organization Breeding Environment (VBE) is an association of organizations and their related supporting institutions, adhering to a long-term cooperation agreement, and adopting common operating principles and infrastructure. The target of this association is the preparation of its members and the increase of their chances to collaborate in potential Virtual Organizations [START_REF] Castells | A era da informação: economia, sociedade e cultura[END_REF].

All of these aspects have been discussed by studies that approach CNOs success. This study, however, refers to causes that lead to unsuccessful CNOs. According to the Park and Ungson Model [START_REF] Park | Interfirm Rivalry and Managerial Complexity: A Conceptual Framework of Alliance Failure[END_REF], problems with trust, reputation and commitment among network members undermine the network desired objectives such as equity, efficiency and adaptation, leading to failure (Figure 1). Others factors have been reported as contributors to the network failure:

• the growing number of members that increases the conflict risk, disrupting the CNO [START_REF] Messner | Networking network studies: an analysis of conceptual configurations in the study of interorganizational relationships[END_REF]; • CNO institutional consolidation problems leading to cognitive, social and political blocking, as well as attitudes that do not generate new benefits to the network members [START_REF] Pereira | Desistência da Cooperação e Encerramento de Redes Interorganizacionais: em que momento essas abordagens se encontram?[END_REF]; • no achievement of common objectives centered on knowledge acquisition, learning, cost reduction, gains of scale, adaptation to change, risk decreasing, assets integration, and training [START_REF] Ebers | Explaining interorganizational network forming[END_REF].

Collaborative Networks in the State of Rio Grande do Sul

The State of Rio Grande do Sul, the southernmost state in Brazil, bordering with Argentina and Uruguay, seeking to incorporate the development of small and medium size enterprises as an alternative to foster the state's economy, is encouraging the building of organizational networks since the year 2000. The State, through the Development and International Affairs Department (SEDAI), established a Collaborative Network Program, emphasizing the associative culture among small businesses that operate in various segments such as industry, commerce, service, agribusiness, and, recently, the third sector. The program aims at "... promoting the formation of collaborative networks joining business strategies, mutual cooperation between enterprises and institutions in order to establish integration among the State and the various sectors of the society" [START_REF]Secretaria do Desenvolvimento Assuntos Internacionais do Rio Grande do Sul -SEDAI: Manual de Orientação dos Consultores do Programa Redes de Cooperação[END_REF].

The effective operation of the program is based on a specific method developed by SEDAI, which is transferred to universities. The universities are the partner institutions that hold the knowledge about the peculiarities of each region and play the role of liaison between the public and private sector. The university has a program coordinator and is responsible for the selection of consultants who are qualified according to the program method. These consultants are responsible for identifying networking opportunities, diagnosing the existence of common ground among business, and assisting in actions planning to build collaborative networks.

The working method is the same for any sector, and the developed networks under this design process present the same organization strategy and tools. The steps shown in Figure 2 form the SEDAI Collaborative Network method [START_REF]Secretaria do Desenvolvimento Assuntos Internacionais do Rio Grande do Sul -SEDAI: Manual de Orientação dos Consultores do Programa Redes de Cooperação[END_REF].

Networks formed by the Collaborative Network method are structured to allow CNO members to participate in the network activities through the board, councils, and working committees. CNO governance responsibilities are split as follows:

General members meeting. It is the forum where proposals that involve the interests of the network are approved or disapproved. The process is democratic, where every member has one vote, regardless of the company size. According to the established rules, each network requires a minimum quorum of participants to validate the decisions.

Board. Responsible for developing the statute, the code of ethics, operational procedures, and legal rules to represent the network interests. The board is elected by majority vote. Each network defines the succession process in accordance with its legal rules.

Councils. Play the role of assisting the board in order to reach network interests, and are usually formed by boards of directors, ethics and taxation. Councils are also elected by majority vote. Manager/executive. (Only present in some networks) is usually a professional hired by the network to fulfil the role of reconciling members' interests, in order to implement strategies approved by general members meetings, as well as to deal with the network routines.

Market sector Identification Aw areness of entrepreneurs

Staff. Operational issues related to the network running.

Coordinators. Members are responsible for strategic committees, which play an active role. The Coordinator appointment is due to member's leadership and to his identification with the area of each committee activity.

Strategic committees.

Are formed by members whose roles in the committee must fit their profiles. Strategic committees are the base of collaborative networks operation and performance in accordance with the SEDAI Collaborative Networks method. In general, committees are divided into four activity areas: Marketing, Innovation, Expansion and Negotiation. Committees have autonomy to develop proposals of activities to be implemented by the CNO. The general members meeting is the adequate forum where such propositions are approved.

The Research Method

This is a descriptive study based on multiple cases, where one of the program creators and managers, one senior consultant and one program coordinator of the CNPRS were interviewed, also twelve entrepreneurs of six collaborative networks located in the region of Caxias do Sul, which became extinct, were interviewed. These collaborative networks were constituted through the SEDAI Collaborative Network method. The University of Caxias do Sul (UCS) was the Program partner university.

The first phase of this study involves the analysis of the senior consultant' interview, showing the relevant and probable causes that contributed to the failure of these networks, validated with the UCS Program coordinator and one of the program creators and managers. In the second phase, those factors that contributed to the networks failure were identified from the content analysis of semi-structured interviews with twelve entrepreneurs. The respondents were the companies' owners, former members of six collaborative networks. Two companies were interviewed in each of the studied networks (Furniture, Wine and Grape, Non-Governmental Organizations, Footwear, Glazing and Electronic Security Equipment sectors).

The Collaborative Network method was analyzed, and important factors that could motivate the failure of those networks were identified. Finally, those identified factors were validated with the integrated model of alliance failure proposed by Park & Ungson [START_REF] Park | Interfirm Rivalry and Managerial Complexity: A Conceptual Framework of Alliance Failure[END_REF].

Identifying the Failures Factors of Rio Grande do Sul CNO's

Factors blamed for CNOs failure in the state of Rio Grande do Sul can be divided into two groups according to: (1) consultants' point of view, and (2) entrepreneurs' point of view.

Consultant's Point of View

The analysis of the consultants' interviews has identified factors that may explain the reason for some failures occurred within CNPRS. These factors were validated with the UCS Program coordinator and one of the program creators and managers of the CNPRS, and can be classified in two main groups, one inside and the other outside the CNO. Factors are presented in Figure 3.

Inside CNO Factors.

There are specific characteristics of the CNO that have proven to be relevant for the failure or success of the network itself. Among them, the following factors can be mentioned:

The CNO president's profile. Entrepreneurs should be trained to develop leadership and conflict management. They must be trained to develop better network governance.

Attitudes and behaviors as an outcome of participants' mind models. When there is a concentration of less flexible participants in the group their attitudes and behaviors tend to a radical positioning, and a group mind model is difficult to be built.

Trust among CNO participants. This is a mandatory factor to explain CNOs failure. Trust absence is a barrier to a joint work of the participants as a sole entity.

The need for several professionals in the CNO. The lack of professionals in the CNO can erode trust among participants leading to an inadequate internal environment, which will end up by the network organization failure. The method adopted by SEDAI. The SEDAI Collaborative Networks method is a robust one. However, some points call for attention according to the experience acquired along time by the consultants from the University of Caxias do Sul involved in CNOs support. Some of these concerns are referred in the following items.

Government concern with CNPRS. From the Government side, the CNPRS is not sustainable since the financial support from the Government to the program is subject to break offs, generating troubles to partner universities which have to maintain an operational structure to keep the project running.

CNPRS consultants' selection, evaluation, and hiring process. In the beginning of the CNPRS, the consultant selection process was based on interviews with several people such as the university extension program director, the CNPRS coordinator, and a psychologist. However, that process has changed along the years. Right now, it is not a rigorous process anymore.

CNPRS consultants training.

There was a well-structured training program for the consultants but its duration time was being reduced gradually. Nowadays, that procedure is just past.

CNPRS consultants' ability, competence, and commitment. The consultant role is basic for the network organization start up and initial footsteps. The development of adequate attitudes and behavior by consultants is required for their commitment to the program. The consultant works in the CNPRS forefront. Thus, the personal factor is relevant for the consultant development but it is not considered by the SEDAI method.

CNPRS consultants' main objectives and task targets measurement. Usually consultants are measured by the quantity of CNOs, which are created without any concern with the quality of the resulting network organizations.

Type and duration time of the CNPRS contract with consultants. Another aspect to negatively impact on consultants' motivation is the type of the contract they are submitted to, under a clause of limited duration, and an explicit expiration date.

CNPRS focus on CNOs set up.

The SEDAI method does not foresee the network organization follow up by consultants; the focus is on the CNO set up.

CNPRS evaluation system.

The CNPRS evaluation is done through an executive summary made by the program supervision -the partner university -that is sent to SEDAI. The success factor is not considered.

Entrepreneur's Point of View

Empirical results of twelve interviewed entrepreneurs of six extinct collaborative networks located in the region of Caxias do Sul are represented in Figure 4. These aspects can be considered as possible variables to drive the decision of abandoning their networks.

Based on the content analysis, the conclusion that the entrepreneurs' decision of abandoning the collaborative network is related with the particular culture of each network member, according to his own way to conduct his business, was reached to. Structural aspects are important in providing network sustainability; however, structural discrepancies among network members make it difficult to establish a common culture in the collaborative network. Some respondents' comments show the coexistence of individual and network iteration causes that could have influenced the decision to leave their networks, as shown below:

"... one was leaving after the other...", "... there were complaints about the travel time for the meetings ..."," ... some members were participating only to learn how other companies were working and did not share anything ...", "... when only three companies remained in the CNO, we decided to close the network, finally ..." (Respondent of the Furniture Industry Network). "...I was the youngest member of the network, the others were older than me and they had more experience with the grape business ...", "... everyone distrusted of what I said ...", "... they thought that my ideas were too modern ...","... with the members' lack of trust, I decided to leave the network ..." (Respondent of the Wine and Grape Industry Network).

Conclusions

The analysis of the interviews with one of the CNPRS creators and managers, consultants and entrepreneurs indicate that CNOs that are being developed in industrial districts have some advantage -as, for instance, a common business culture and a sense of community -when compared to networked organizations that are geographically spread. It is a belief that despite being geographically concentrated in a same place CNOs should be prior prepared to form alliances.

Considering the Park and Ungson Model, it is possible to say that the research shows the "rivalry among firms" and the "management complexity". It was detected from the interviews that those firms that fail to consolidate the CNO do not build trust, reputation, and commitment. For that reason, equity, efficiency and adaptation cannot be developed. To minimize this situation for the future, in the particular case of SEDAI Collaborative Network method, improvements are suggested, having in mind some method phases and activities.

In the present work, CNOs' inside and outside possible failure factors are differentiated. Among the internal factors, a lack of structure and preparation to allow network participants better prepare for developing trust, attitudes and the necessary behaviors to collaborate were detected. Even though, in the Collaborative Network method the following steps are considered: (1) network structuring, (2) long term planning (that is questioned by the consultants), and (3) network consolidation. These steps should be strengthened because the interviewed entrepreneurs have raised questions like: lack of commitment, individualism, resistance to change, lack of trust, no information sharing, and relationship problems. Other important inside CNO factor is the qualification of the CNO president and its professionals, pointed out by the consultants as preparedness of the president and lack of professionals, and by the entrepreneurs as lack of leadership and low educational level of CNO members. Furthermore, entrepreneurs should be trained to develop leadership and conflict management. Some of them will be a CNO president in the future. Network success depends on entrepreneurs' commitment and management ability. Thus, they must be trained to develop the best network governance. Therefore, the creation of a new step in the SEDAI Collaborative Network method is suggested: qualification and preparation of CNOs presidents.

Considering the outside CNO factors, other contribution of the present work is the identification of the need for investing in the preparation and qualification of the CNPRS' consultants. In the beginning, the CNPRS Program included a structured consultants training but its duration time was increasingly reduced. Furthermore, the consultant qualification must be considered as one of the criteria for selection, evaluation and hiring processes. Thus, the creation of a new step in the SEDAI Collaborative Network method is suggested: qualification and training of consultants. From the Government side, the CNPRS needs to be supported constantly. The effectiveness of the CNPRS method will assure the future success of the network.

Fig. 1 .

 1 Fig. 1. An Integrated model of Alliance Failure

Fig. 2 .

 2 Fig. 2. The SEDAI Collaborative Network Method

Fig. 3 .

 3 Fig. 3. Failure factors according to CNPRS consultants

Fig. 4 .

 4 Fig. 4. Reasons for abandoning CNOs according to Entrepreneurs

Acknowledgments. The University of Caxias do Sul is supporting this work.


Darío Rubén

Angel Ortiz Franco
email: dfranco@cigip.upv.es

Pedro Bas

Raul Gómez-Gasquet

Rodriguez Rodriguez

Rubén Darío Franco

Angel Ortiz Bas

Pedro Gómez-Gasquet

Raúl Rodriguez Rodriguez

Open Ecosystems, Collaborative Networks and Service Entities Integrated Modeling Approach

Keywords: VBE modeling, CN Management System, Service Entities

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The scientific community related to Collaborative Networked Organizations (CNO) research has agreed on the usefulness and convenience of considering Virtual organizations Breeding Environments (VBE) as fertile spaces where CN lifecycle takes place, from its creation to its final dissolution. Similar considerations have been stated for Open Service Ecosystems [START_REF] Osório | Open Services Ecosystem Supporting Collaborative Networks[END_REF]. In this work, both terms are used interchangeably as in [START_REF] Osório | Open Services Ecosystem Supporting Collaborative Networks[END_REF].

Broadly speaking, VBE are expected to establish normative rules, define reference processes and to host a set of registered nodes which, in turn, will be selected to arrange, setup and launching a new CN.

Two research streams have been heavily developed, and contributed, in the past, from both VBE and CN management perspectives. Moreover, in the ECOLEAD project [START_REF] Camarinha-Matos | Ecolead: A Holistic Approach to Creation and Management of Dynamic Virtual Organizations[END_REF], VBE [START_REF] Ecolead D22 | ECOLEAD D22.1 VBE Management System (VMS) Requirements and Architecture Design[END_REF] and CN [START_REF] Ecolead D | Requirements and mechanisms for VO planning and launching[END_REF] management systems were characterized and functionally described but interactions among both systems were just briefly mentioned.

Based on such previous works, what this paper addresses: Is it possible to design and implement a single IT system managing, in an integrated way, both VBE and CN operations? If so, which architectural principles must be considered?

Service Entities have been proposed [START_REF] Franco | Modeling extended manufacturing with service-oriented entities[END_REF], [START_REF] Franco | Supporting Structural and Functional Collaborative Networked Organizations Modeling with Service Entities[END_REF] as a third component of the model which would play a main role in supporting the engineering and operating of those CN in a VBE, based on a service-oriented approach.

This paper aims at contributing in that integration by means of two mechanisms:

-The functional alignment of the three main lifecycles, namely Ecosystem (or VBE), CN and Service Entities respectively, and -The definition and identification of the corresponding modeling perspectives as architectural support of an integrated management system. The rest of the paper has been structured as follows: Section 2 introduces a set of background concepts that are needed for better understanding the focus of this contribution. In Section 3, main processes of the above mentioned three lifecycles will briefly described. Section 4 discusses on the functional integration of those lifecycles and Section 5 shows how the integration is proposed from the alignment of their corresponding modeling views perspective. Finally, in Section 6, some conclusions and next actions are introduced.

Related Concepts

Virtual Breeding Environments and Collaborative Networks

Collaboration between partners is a preferred way to ensure optimal resource balance and to get perdurable benefits [START_REF] Jagdev | Anatomy of enterprise collaborations[END_REF]. Time of preparation and difficulty of launching a CN will increase in the same proportion of the number of potential partners and complexity of collaborative processes to be carried out.

Virtual Breeding Environments [START_REF] Camarinha-Matos | Collaborative networks: a new scientific discipline[END_REF] are aimed to harmonize the preparedness level of involved organizations while, at the same time, a collaborative infrastructure is deployed in order to deal with interoperability problems at different levels: communications, data, services, processes or business [START_REF] Ruggaber | ATHENA-Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications[END_REF].

In VBEs, the main goal is to restrict the number of potential participants by drawing a border to the open universe and allowing some partners to come inside. Those partners have to agree on common operating principles: business semantics, strategies or goals, distributed business processes management practices or even common ICT tools. Rapidness and flexibility in CN preparation and launching are requirements that any VBE management system must accomplish.

Service Entities

Service Entities (SE) are proposed as modeling constructs for CNOs, for both the Structural and Functional dimensions. As they have been defined, a Service Entity [START_REF] Franco | Modeling extended manufacturing with service-oriented entities[END_REF] is the result of logically tying together:

-A finite set of business services -understood as functional capabilities that a service provider may offer to third parties by means of public interfaces -which jointly define the expected behavior of these entities and, -A finite set of attributes which allow characterize and distinguish among them. There exist two different types of SE: Abstract Service Entities (ASE) and Concrete Service Entity (CSE).

-

Functional Lifecycle Integration

The synergies of an integrated approach for VBE and CN management have been raised by Romero et al in [START_REF] Romero | VO breeding environments & virtual organizations integral business process management framework[END_REF]. In that work, a common framework for VBE and CN is proposed. Along the respective lifecycles, the authors introduce a set of business processes which provide the expected functional linkage between VBE and CN roles. Despite this process-centric contribution, building an integrated system for VBE and CN will still require additional elements in order to achieve a truly operational status for managing extended business process involving also the nodes.

As a complement, this work takes advantage of the SE approach in order to realize the integration as expected. Next sections describe how this approach is also integrated with those already mentioned.

Ecosystem Lifecycle

The Ecosystem Manager is in charge of managing the creation; operation and dissolution of ecosystems (see Fig. 1).

First stage is aimed at setting up and running all the technical tasks supporting the creation of the ecosystem. In the ColNet platform, this task mostly deals with the initialization of databases, creation of empty repositories and main roles assignment.

Main processes of the operational phase are also represented in Fig. 1. For this work, most relevant ones are:.

-Service Entities Management: this task is related to the profiling of generic nodes (ASE) that later on will exist inside the ecosystem.

-Reference Process modeling: refers to the design of business processes that include ASE as its main actors and their services as functional blocks to be included in the process model.

-Business Documents and messages: aimed at defining the actual business documents and message schemas that may rule the information exchanges and co-ordination patterns inside the ecosystem.

-Collaborative Networks Management: includes the creation of CN and supervising some activities related to their lifecycle. The final stage is aimed at supporting the ecosystem dissolution that will consist of a set of activities collecting the knowledge gathered from its operational phase.

CN Lifecycle

As depicted in Fig. 2, CN are created, operated and dissolved. For creating a new Cn, the CN manager will request its approval to the ecosystem manager of the VBE to which the CN will belong to. Once approved, the CN configuration can be started.

During the operational stage of the CN, the manager will have several duties to accomplish. Among them, it is possible to mention the management of:

-Network structure: this task implies to decide which available resources of the network will be invited to join the network for future transactions. -Concrete nodes management: interested nodes may request joining a CN as preferred partners. Other nodes will be invited to join the CN. -Network business documents and messages: actual XML schemas that are used for both information exchange and co-ordination purposes in the CN.

-Network processes: aimed at creating the collaborative processes that will represent the operational perspective of the CN. -Network monitoring: ColNet also provides managers with simple monitoring tools intended to monitor main CN parameters. After the CN has met its business goals, the manager may decide on keep it operational or proceed to its dissolution. In this case, proper mechanisms will be needed to support both the inheritance management and the final repositories disposal.

Service Entities Lifecycle

Each Ecosystem member is represented by a CSE instance. This role can be played by any organizational or physical resource (for instance, a whole company, a single department of that company, a person of that department, a truck of that company, etc.) being able to provide functional capabilities, from a service-oriented perspective, that will be contributing to the extended business process execution.

As shown in Fig. 3, the Service Entities (SE) lifecycle is composed of three main stages: preparation, operation and dissolution.

At the preparation stage, the node manager will need to register it into the ecosystem. That means to identify which generic node (ASE) better describes the node being registered and creating a concrete instance (CSE) of it. Once they are operative, nodes may perform some specific tasks:

-Decide on invitations received from different collaborative networks. If some invitation is accepted, the node becomes part of the network and it can receive different requests from the CN in terms of functional contributions or transactions.

-Send an application to be considered a potential member of a CN. This mechanism goes in the opposite direction than the previous one. Here, the node offers its capabilities and services to some specific network. If accepted, it can start interacting with that network. -Receive, accept and perform all the tasks coming from the network

Integrated Functional Approach

In the previous section, three lifecycles were introduced. This section will briefly explain how them are linked together in order to build up the integrated approach proposed here. Main blocks of the Fig. 4 are schematic representations of the abovedescribed lifecycles. For better comprehension, only main processes linkage is shown.

Since the ecosystem is considered the main enabler, during its operational phase, other two lifecycles will take place:

-Service Entities: where incoming members are registered on it, and, later on, they will be ready to join future collaborative networks opportunities.

-Collaborative Networks: network managers may request the creation of a new collaborative network to the ecosystem manager by selecting the initial members from those entities already registered into it. After the open ecosystem is created and configured, its management phase is launched. This comprises, among many others, two main activities: memberships' management and collaborative network management support.

When the creation of a new CN is decided, network managers will request its approval to the ecosystem manager. Once approved, the CN will be operative.

The operational phase of the network has many activities. For illustrating this approach, just two main processes have been included: managing the network topology, i.e. nodes being part of it; and also defining the business processes or current networked operations.

While at the same time, organizations have also started their registration process into the ecosystem. Once it is completed, they become full members of the ecosystem and they move to the network participation phase.

At this functional level, the management of the network topology is aligned with the process of organizational adhesion to a single CN. This interaction may occur as many times as the company is either invited to join a CN or offering its services to it. Finally, when the CN is operative, single organizations are asked to provide their services, either manual or automated, in order to realise different extended business process instances. The approach proposed here considers that such expected integration can only be achieved if also the involved entities -ecosystems, collaborative networks and organizations -share a common integrated modelling framework.

Integrated Modeling Views

In the previous section, the integrated approach has been illustrated from a functional perspective. This section now describes how such integration will be realized by means of an integrated modeling framework where all the corresponding modeling views for VBE, CN and SE are properly aligned.

In the ARCON [START_REF] Camarinha-Matos | Towards a Reference Model for Collaborative Networked Organizations[END_REF] reference modelling framework for CN, a set of modelling perspectives has been proposed for their modelling.

Moreover, a modelling framework for service-based ecosystems, which identified a set of common modelling perspectives for both VBE and CN has been also proposed in [START_REF] Franco | Towards a Modeling Framework for Service-Oriented Digital Ecosystems[END_REF]. The considered set of modelling perspectives includes: Processes, Services, Information/Data, Resources, Organization and Performance (see Fig. 5).

The proposed integrated approach aligns VBE/Ecosystem and CN modeling views while it also shows how Service Entities, either abstract or concrete ones, are used as integration mechanism providing consistence to VBE and CN modeling activities.

Using Abstract Service Entities in the Integrated Modeling Approach

Abstract Service Entities are composed of two integrated sets that define their structure: a defined set of attributes and a set of business service interfaces.

Attributes will be used to univocally distinguish among all its corresponding instances created while the ecosystem is operating. For the integration purposes stated here, these attributes will include, for instance, a unique name for them. This attribute will allow CN modellers to use it as actors of reference processes of the ecosystem.

As it, the ecosystem would include a set of reference processes which later on can be used to be instantiated for creating different CN. Those processes would use generic references to nodes (actors) as ASE allows. Then, a reference process may include a Manufacturer, Component Supplier and Raw Material Supplier as actors of those generic processes.

When a reference process is imported into a specific CN, the ASE can be replaced by actual CSE belonging to that CN and which have been created by instantiating the corresponding ASE.

On the other hand, business services interfaces represent functional capabilities that each SE is able to provide to compose business processes. In the case of ASE, service interfaces must be considered as service specifications that, later on, concrete nodes will provide to a CN. When used at ecosystem level, service interfaces can be used as functional parts of the reference processes. Once reference processes are instantiated into specific CNs, these business services will be implemented by actual CSE to realize process instances.

In this way, all the services defined for the ASEs are grouped into the corresponding Ecosystem y CN Service modeling view.

Using Concrete Service Entities in the Integrated Modeling Approach

Concrete Service Entities are instances of actual ASE defined at the ecosystem level. From the integrated modelling approach introduced here, CSE are integrated as described.

-Ecosystem/Resources: once instantiated, CSE become resources of the ecosystem. The attributes will characterize each single entity inside the ecosystem.

-CN/Resources: all the CSE registered at the ecosystem become potential nodes of a CN. The network manager will decide on the final CN structure and actual CSE will be picked up to create a new CN.

-CN/Processes: CSE become actors of actual CN processes. Moreover, concrete services (implemented ones) will allow realizing actual extended processes instances inside the CN.

-CN/Services: this view is formed from all the services provided by the current CSE belonging to a specific CN.

Conclusions

This paper has introduced an approach for integrating the modeling needs arising when a functional alignment of VBE or Open Ecosystems, Collaborative Networks and Services Entities is expected. The proposal is based on two main pillars: a) the functional alignment of the corresponding lifecycles and their adoption as main functional requirements to design and implement an integrated management system for them, and b) the identification and alignment of their corresponding modeling perspectives by including the Service Entities approach as a main enabler of such integration. Thus, the ColNet platform, not focus of this work, is the result of creating an integrated system, supporting distributed business processes design and execution in collaborative networks in the context of a service-based open ecosystem.

The ColNet prototype can be accessed at www.spr.upv.es/ColNet and next research steps will include additional use cases for fully validating the overall approach.

Fig. 1 .

 1 Fig. 1. Main processes at each stage of the ecosystem's lifecycle.

Fig. 2 .

 2 Fig. 2. Main processes at each stage of the collaborative network's lifecycle.

Fig. 3 .

 3 Fig. 3. Main processes at each stage of the Concrete Service Entity's lifecycle.

Fig. 4 .

 4 Fig. 4. Functional integration of lifecycles.

Fig. 5 .

 5 Fig. 5. Integration of modeling perspectives for Ecosystems, CN and Service Entities.

  An Abstract Service Entity is a generic building block used to represent different 'types' of entities that are present in the problem domain, mainly at Ecosystem level. ASEs are not linked to any specific instance of entities they are defining. They only represent the abstract definition of the attributes and also the specifications of the business service interfaces being defined for them.

-Concrete Service Entity: CSE are expected to be real entities of the problem domain, CSE are instances of actual ASE. Instantiating an ASE means to provide meaningful values to its attributes and specific implementation for its service interfaces (i.e. bank account validation and account balance sheet). At modeling level, this means to create an open repository where CSEs can be searched, discovered and used to create and launch CN instances.


Hamideh Afsarmanesh
email: h.afsarmanesh@uva.nl

Mahdi Sargolzaei
email: m.sargolzaei1@uva.nl

Mahdieh Shadi
email: m.shadi@uva.nl

A Framework for Automated Service Composition in Collaborative Networks

Keywords: Software service composition, service discovery, business process modeling, business service, collaborative network, coordination language

This paper proposes a novel framework for automated software service composition that can significantly support and enhance collaboration among enterprises in service provision industry, such as in tourism insurance and e-commerce collaborative networks (CNs). Our proposed framework is founded on service oriented architecture (SOA) paradigm, in which software services implementing on-line business services that are provided by different enterprises, will be formally defined, using an extended BPMN notation to capture their semantics and behavior, as well as the WSDL notation to capture their syntax. Furthermore, with registering the syntax, semantics and behavior of these software services in a service repository at the CN, the task of service discovery in this framework can go far beyond the current practice, which comprise of service search by name, to the possibility of discovering by service behavior. The paper addresses enhancement of automated software service integration in CNs, through the application of the Reo coordination language, which is used to formalize interaction among the composed services. The main reason for using Reo in this context is that it supports separating the computations needed by software components in an integrated system from their interactions. The suggested framework provides more flexibility, adaptability, as well as cost-effectiveness in service composition, when supported in collaborative networks.

Introduction

Nowadays, in a number of application areas such as tourism and e-commerce, an increasing number of SME organizations are formalizing the definition of their provided business services. This formal definition is usually provided as business processes (BPs), e.g. a BP is defined to represent the reservation of a hotel room or an airline ticket, and they usually apply certain standards such as BPMN or UML for this definition. The resulted sets of BPs at the SME are then used by software developers that implement them as software services. For a large number of service industries such as the tourism, insurance, banking, etc. most of their business services provided to the customers are now accessible on line (through Internet), i.e. developed as web services, e.g. the on-line hotel reservation web service. These web services are typically accessible by customers through user-friendly interfaces, which automate the execution of their requested transactions e.g. making a hotel or airline reservation, at the local SME sites.

But SME organizations are increasingly interested in working together and joining their knowledge, skills, resources, capabilities, and capacities, and in establishing collaborative networks (CNs) [START_REF] Camarinha-Matos | A comprehensive modeling framework for collaborative networked organizations[END_REF]. One form of CNs, the so called Virtual Organization (VO), is usually established for one of the following two purposes. One purpose is to target one specific emerged opportunity in the market or society, for which a number of organizations would be selected by the VO broker and invited to accept the joint responsibility of fulfilling tasks needed to achieve the common goal of the VO. A second purpose is for innovation, when usually a VO broker identities a potential opportunity that can be fulfilled through merging abilities, resources, capacities, etc. of a number of SMEs who get invited to the VO [START_REF] Kaletas | Emerging technologies and standards[END_REF].

In order for VOs to compete in the market and society with real large existing organizations, the base for collaboration among its partner SMEs must also be preestablished before the VOs can operate. For this purpose, usually another form of CN, the so called Virtual organizations Breeding Environment (VBE) [START_REF] Afsarmanesh | On the classification and management of Virtual organisation Breeding Environments[END_REF] is established as an association/community of SMEs in a sector, who have general common and/or compatible interests, who are interested in involvement in VOs, and who are also willing to work and share their potentials and competencies with other organizations. Since VBEs on one hand gather and organize large amount of information/knowledge about their member organizations, and on the other hand establish the base for common/uniform interoperation among their member organizations, they represent valuable communities, and therefore usually they do not dissolve [START_REF] Camarinha-Matos | A framework for virtual organization creation in a breeding environment[END_REF]. But sometimes VBEs metamorphose either through expansion with another related area of activity, or narrowing down and focusing on a subset of the original activities. Formation of a VBE is typically aimed at bringing the following set of advantages to its member organizations [START_REF] Afsarmanesh | On Management of 2nd Generation Virtual organizations Breeding Environments[END_REF]:

(i) Capturing more opportunities and bigger market, and thus making more profits through sharing their customers (ii) Reducing individual costs through focusing/applying only their core competence, while benefiting from the existence of complementary expertise in the network (iii) Increasing the ability to take risks, through sharing and distribution of potential losses, while agreeing to share their profits Focusing on the service industry, which is the main emphasis of this paper, in order to join others and collaborate effectively, SMEs in a VO must together act as a single entity, and therefore they must share their business services and software systems with each other as if they all belong to and co-work within one single real organization. But to share software services, they must be formally and uniformly defined. Such unification in definition format can occur at the VBE level. As such, once in a VO, other SME partners will be able to share them, e.g. to integrate them with each other and/or together create new value-added services and innovate in this industry.

For example, consider the case of one SME (SME-S1) in a VBE (V1) planning to simply create an integrated tourism package, including the reservation of flight-ticket, hotel-room, day-trip and dinner at restaurants, and assume that these business services are all already implemented by several different SMEs at the VBE as web-services by different other SMEs in this VBE. In fact once SME-S1 identifies the most-fit SMEs to work with for creating this package as an integrated service, SME-S1 (as the VO broker) can start forming a VO together with these other SMEs. However, today due to the lack of uniformity in full and formal definition of implemented business services at SMEs, the creation of such an integrated single tourism package and providing it as an on-line service to the customer is quite challenging. In this paper we aim to address this challenge and define an approach and architecture that can in fact support the semi-automation of this challenging task.

Today, even without any automation, for developing such an integrated service, the following steps are needed to be taken:

(a) SME-S1 must first identify any and all potentially relevant web-services shared by other SMEs in the V1. But clearly to identify relevant webservices for this purpose, it is not enough for SME-S1 to only have access to the syntax information of these web-services, e.g. their names, and the name/type of their input and output. This is due to the fact that "names" for web-services and their input/output are not even necessarily mnemonic and/or using any common standards. On the contrary, these names are usually selected and assigned by different software developers and usually represent only their personal preferences. (b) Beside the naming challenges, also the semantics of the web-services and each of their input and output elements are not uniformly provided. There is a need for common ontological definitions to clarify the actual intention of the software developer behind these elements. (c) Furthermore, for the purpose of developing a new integrated web-service, through composition of other existing web-services, although SME-S1 (as the developer of this new integrated service) does not need to know and fully understand the exact code and how each of the existing component services are implemented, SME-S1 must in fact have a very good understanding of the functionality and interaction (namely the behavior) of each component service, in order to integrate it with the others. In some cases in fact SME-S1 needs to adapt the behavior of some of these services in order to make them match the others and become compatible. But considering the real practice, it should be first noted that the SMEs in the VBE are fully independent and autonomous, therefore unlike the case of software service integration within one large enterprise, or through outsourcing, in the case of SMEs in service industry, there are no common base for definition of service syntax and semantics, and no standards is observed when developing their software services. Therefore, as a first step to support collaboration among such service providing SMEs in a VBE, it is necessary to establish a framework for their service interoperability. This interoperability framework shall create the common understanding about the existing services in the VBE and thus requires a common frame and meta-data to formally express the syntax, semantics, and behavior of software services. The structure of this paper is as follows. Section 2, address the application of SOA to the collaborative networks. In Section 4 we address the implemented architecture for the approach and introduce its 4 aspects of service modeling, service registering, service discovery, and service integration. Finally in Section 4, some conclusive remarks are drawn.

Applying SOA to Collaborative Networks

From the ICT perspective of a CN, supporting its agility, cost-effectiveness, and adaptability need designing more advanced infrastructures. The SOA and service utility paradigms [START_REF]Framing the future of the Service Oriented Economy[END_REF] as prominent ICT approaches provide the strong required architecture for a system in which there are components interacting with each other, while their functionalities are viewed as software modules called services [START_REF] Singh | Service Oriented Computing[END_REF]. In service industry, software service accessibility by each enterprise in the collaborative network, in support of service interoperability, results in reinforcing its collaboration with others and decreasing its service development and hosting costs. In the SOA context, SaaS (Software-as-a-Service) [START_REF]Software as a Service: Strategic Backgrounder[END_REF] is a powerful model that can benefit the CNs. As clients, remote access to services can be supported for CN members, who can for instance pay per use, based on the contractual rules specified in SLAs (Service Level Agreement) [START_REF]Web Service Level Agreement (WSLA) Language Specification[END_REF]. As such, it does not matter where the services providers are located, and how the services have been deployed [START_REF]The Business Model of Software-As-A-Service[END_REF].

Using SaaS, CN members (as clients) can search among existing services, build and register their own new services, compose existing services, or adapt the accessed services according to their needs. In this sense, both common representation of software services as well as formal modeling and coordination of their interactions are fundamental issues which assist flexible and better service discovery and service composition. We focus and discuss these two aspects in the following paragraphs.

Currently there are several notations and graphical modeling tools used for modeling of business processes, such as the Business Process Modeling Notation (BPMN) and the Unified Modeling Language (UML) Activity Diagram, the Eventdriven Process Chains (EPC), and the Role Activity Diagrams (RADs) [START_REF] Ko | Business process management (BPM) standards: a survey[END_REF]. BPMN and UML Activity Diagrams are currently considered as the two most suitable and popular ones. While these standards are largely overlapping, BPMN is slightly stronger and more expressive [START_REF] Wohed | On the Suitability of BPMN for Business Process Modelling[END_REF], so we have choose BPMN as the basic notation for modeling business processes in the proposed platform. Despite its popularity, the BPMN notation is too abstract to convey sufficient details required to represent the syntax, semantics, and operational behavior properties of software services, necessary for service composition/integration. Interface, data types and structures of each service are represented by its syntax. Web Service Definition Language (WSDL) is the most popular language for syntactical representation of software services [START_REF]Web Service Description Language[END_REF].

Most web service models and languages such as Simple Object Access Protocol (SOAP) [START_REF]Simple Object Access Protocol[END_REF], and Universal Description Discovery Integration (UDDI) [15] are also used at the syntactic level. These technologies support interoperability between different services through common standards, but human interaction is still needed to search for appropriate services and for composing them in a reasonable manner. The intervention of human is however in contrast to the strategic goals of SOA, such as the scalability, agility, etc. [START_REF] Thomas | SOA Principles of Service Design[END_REF]. Therefore, it is necessary to automate main tasks of SOA such as service discovery, composition and adaptation to the extent possible. To achieve this goal, besides the syntax, we should also consider more conceptual properties of services that are known as semantics. The semantics represent conceptual aspects of services, using explicit and machine-interpretable descriptions.

Further to syntax and semantics, behavioral properties of a service must also be formally defined. These properties address the set of operations involved in a service and indicate the order of invocations of these operations. Composition and integration of web services lie at the heart of our framework and they cannot be successful without behavioral specification of software services. BPMN may also be used to define the behavior of a service, but, there are some drawbacks and ambiguities in this aspect of BPMN [START_REF] Kokash | Formal Behavioral Modeling and Compliance Analysis for Service-Oriented Systems[END_REF]. Therefore, developing service ontology is required to specify service semantics and disambiguate current BPMN process specification of services. We propose a new SOA based platform for a CN, as shown in Figure 1. This architecture is composed of four layers including business modeling space, meta data space, service composition space and IT infrastructure space. As Figure 1 illustrates, members/stakeholders of a CN share their software services according to their contracts in business modeling space. These services shall be represented as extended BPMN diagrams, from which Meta Data (as represented in meta data space) is extracted, to derive their syntactical, semantics and behavioral descriptions. Software Services are designed to support interoperable machine-to-machine interaction over a network using two basic standards including WSDL which describes the interface in a machine-interpretable format, and SOAP [START_REF]Web Service Description Language[END_REF] which is used to format the exchanged messages. For documenting syntactical information of software services, we need to parse the XML-based documents generated by WSDL and Soap, to extract the syntax of operations and messages of web services. We also use the formal notation of constraint automaton [START_REF] Christel | Modeling Component Connectors in Reo by Constraint Automata[END_REF] for specification of the (external) behavior of a service. In this formalism, a web service is represented as a sequence of operations in which there are some constraints defined on operations' invocation order [START_REF] Jongmans1 | Automatic Code Generation for the Orchestration of Web Services with Reo[END_REF]. In the next section, we discuss requirements and the needed architecture to implement this platform, considering the mentioned Meta Data.

Implementation Architecture and Requirements

Our proposed framework for implementation of composition of software services within collaborative networks consists of four components, which are implemented as modules, to address: (i) modeling business processes and obtaining their formal meta-data (on syntax, semantics, and behavior), (ii) registering the extracted metadata in corresponding repositories, (iii) discovering, matching and adapting appropriate services (needed for their composition into a new integrated service), and (iv) coordinating, integrating, and executing composed services. Thus, the complete implementation architecture includes four modules, labeled as: modeling, registering, discovery, and integration.

Modeling of Services

This module supports the formal definition of the software services to be shared with the community of enterprises at the CN. See Figure 2 that represents the general architecture for service provision with two of its modules, modeling and registering. From the end users point of view at each enterprise, their shared business services are required be defined. At first, user presents the complete flow of his every business process as a BPMN diagram or BPD (Business Process Diagram) using the BPMN editor. Each diagram should be further extended to define the syntax, semantic and behavior of its corresponding software service. Such enrichments, which is represented in the box labeled as "BPMN Extender", consist of three parts: adding new descriptions, refining ambiguities, and annotating to facilitate extraction of these metadata. The task of extracting elements needed to register the behavior and semantics metadata of the service in appropriate repositories has been presented with the box labeled "Metadata Extractor". To obtain Syntactical metadata, besides some basic syntactical meta-data derived from the primary BPMN diagram, we need to load and parse WSDL documents of web services, which are represented in the boxes labeled as "WSDL Loader" and "WSDL Parser". These steps are shown within the Business Modeling Space and Meta Data Space in Figure 1.

Registering of Services

As mentioned in Section 3.1, we formalize the externally observable behavior of the software services in terms of constraint automata. There is therefore, a constraint automaton generated for each service which should be captured within the behavior registry. The data structure of this registry is formed of state tables which store current state, next state, ports (operation names) and data constraints of constraint automaton [START_REF] Jongmans1 | Automatic Code Generation for the Orchestration of Web Services with Reo[END_REF]. Behavior registry of services is needed to generate final executable code for integrated services, as described in the next subsections. Also the syntactical metadata for services need to be captured in syntax registry. Most activities in the framework e.g. discovery, integration and execution of services, refer to this registry.

The services meta-data is improved by using OWL-S, a rich description language for representing semantics. Service semantics are then captured within the ontology registry, which describes "individual" services, together with the set of their "property assertions" relating individual services to each other [START_REF] Sirin | Bringing Semantics to Web Services with OWL-S[END_REF].

Obviously beside the three metadata registries addressed above, the framework also needs a service registry, such as UDDI which contains all shared services with their syntactic metadata. But in addition to syntactic information, we also keep the ontological and behavioral metadata associated with each published service synchronized in the service registry. Figure 2 illustrates the required operations for registering new services by the service provider in the platform. This task uses the BPMN for modeling the behavior and semantic of the services and the WSDL for specification of their syntax. We will describe in the next section how we use these registries to compose existing services into an integrated service. All mentioned registries are considered as Service Repository within the ICT Service Infrastructure Space in Figure 1.

Discovery of Services

Figure 3 represents the general architecture for service composition in our framework, where its four different aspects of modeling, registering, discovery, and integration are also indicated. We will of course in this subsection focus on describing the Discovery aspects of this architecture. Let us consider the example provided in Section 1, where the user in SME-S1 intends to create a new integrated tourism service composed of a number of other services (i.e. reservation of flight ticket, reservation of accommodation, etc.). This user will then need to first specify this integrated business process and its components through the BPMN editor. The task of decomposing the integrated service into its component services is represented in the box labeled as "Decomposer". The step after this decomposition is the performed by the service search engine, which starts to match as much as possible the description of the component services defined by the user against the services existing the service registry, to be offered as alternatives to the user. As such, the role of Service search engine is the discovery of potential required services among the existing shared services. The Service search engine has to search the syntax and ontology service registries simultaneously, for matching the syntactic and semantic aspects of the registered services against the decomposed components. The report of all the partially matched services, as well as those that are not found will be sent to the user, where he can apply his/her preferences in selecting among the alternatives.

Nevertheless standardizing the service definitions does not remove the need for service adaptation. Usually the discovered services, do not fully, but only partially match the requirements and context of the desired service component (decomposed tasks). In this case, in case such a service is selected by the user, the service adapter modifies it in order to make it compatible with the user's desired service. This adaptation provides semi-automated support for identification and resolution of interface-level mismatch between the intended and the discovered services [START_REF] Motahari Nezhad | Semiautomated adaptation of service interactions[END_REF]. As Figure 1 shows, the dashed lines connecting the Composed Services to the Service Repository indicate the process of service discovery.

Integration of Services

We apply the Reo [START_REF] Christel | Modeling Component Connectors in Reo by Constraint Automata[END_REF] circuits to model the coordination aspects related to the interactions among software services. As such, the user at SME-S1 will use the Extensible Coordination Tools (ECT) [START_REF] Arbab | Modeling, Testing and Executing Reo Connectors with the Eclipse Coordination Tools[END_REF], which is a collection of Eclipse plug-ins, to design these interaction circuits, using a drag-and-drop graphical interface. But, some essential activities like communication between web services and the Reo circuits, and generating executable code from a circuit diagram cannot be done by ECT. Therefore, we need a wrapper to connect web services to the boundary nodes of Reo circuits as Reo components, to communicate with web services and exchange data via SOAP message, and also translate Reo circuits to java code [START_REF] Jongmans1 | Automatic Code Generation for the Orchestration of Web Services with Reo[END_REF]. Using wrapper provides interaction among the running software services in a way coordinated by the Reo circuits and also dynamic and automatic service invocation. For these purposes, the Reo compiler produces the glue-code among the individual services involved in the integrated service, and the Proxy generator produces the proxies for each involved service. Furthermore, to generate final executable code for a composed service, we need its syntactic metadata and behavioral properties of selected services. We have described more details about the design and the current implementation of this wrapper in another paper [START_REF] Jongmans1 | Automatic Code Generation for the Orchestration of Web Services with Reo[END_REF]. As shown in Figure 1, the Selected Services would be integrated by Reo Coordination Tools within the Collaborative Service Composition Space.

Conclusion

This paper addresses the design of a framework to assist service providers in a collaborative network, e.g. the SMEs involved in a tourism or insurance VBE, to uniformly create the formal definition of their services, so that they be understood and shared with others. For this purpose, the paper proposes a novel SOA-based Collaborative Business ICT framework to support CNs in service provision industry with their effective collaboration through sharing and composition of their web services. This approach supports the organizations involved in a service industry CN with a platform-independent, easy-to-use, on-demand, and pay-per-use ICT service interoperability infrastructure. From the technical point of view, this is a web-based integrated platform devoted to the CNs, for providing value-added business services, via service composition. The platform improves software service discovery and service integration using variant metadata, as well as concrete formal machine readable definitions. Moreover, it uses Reo circuits as coordination models, used to coordinate the complex interaction protocols among enterprise business processes, which is one of the most challenging issues in modeling and executing business processes in CNs.

Fig. 1 :

 1 Fig. 1: A new SOA-based platform for a CN

Fig. 2 :

 2 Fig. 2: Architecture of Service Provision in the platform

Fig. 3 .

 3 Fig. 3. Architecture of Service Composition in the platform

Acknowledgements

The work on this paper is partially supported by the FP7 project GLONET, funded by the European Commission.