Public-Private Partnership in e-Government: a Case Implementation

Alain Sandoz Jean-René Eudes Raphaëlle Prévot Vauban Technologies & Université de Neuchâtel

Centre des technologies de l’information, Etat de Genève

Centre des technologies de l’information, Etat de Genève

info@vaubantechnologies.com jean-rene.eudes@etat.ge.ch raphaelle.prevot@etat.ge.ch

Abstract

Public-private partnerships (PPP) are used by

governments as a means to finance infrastructure services such as roads, bridges or hospitals. In e-government, public services are provided and delivered to citizens and businesses through the internet. The end user should be able to measure a difference in terms of service quality and comfort, or necessary effort, delay, and cost, between acquiring the service over the net vs. using traditional channels. This paper presents a case implementation of PPP in e-government in Geneva, Switzerland. In this scheme, a private third party is introduced aside the public administration and the end-user in order to maximize the added value to the user. In comparison to the traditional client-server model of internet transaction, several new problems are encountered at the organizational, process and technical levels. The paper describes the solutions and underlying architectures. 1. Introduction

This paper is an attempt to describe the principles that have lead to the design and construction in Geneva, Switzerland, of a generic platform for the execution of e-government processes under the constraints of public-private partnerships. The issues leading to the design and to the implementation arise from different levels: 1) regulation and organization of society; 2) process engineering; and 3) technical realization and operations of internet applications. Therefore, the considerations proposed in the paper vertically cross these levels, each of which would deserve a thorough scientific examination before any conclusion can be drawn. This is not our intention since we proceed experimentally in collaboration with different partners having sometimes diverging interests.

E-Government is the domain of providing public services with added value to citizens and businesses, and delivering them through the internet. “Added value” means that the end user can measure a difference in terms of service quality and comfort, or necessary effort, delay, and cost, between acquiring the service over the net vs. using traditional channels. The main difficulty in e-government relies in public-sector processes which are often tangled up in a maze of regulation and organizational constraints. If this is the case, e-government can become a way to transfer the administration’s workload to the end-user over the internet, with little or no added value to the latter.

The paper presents a case implementation of e-government service delivery we are currently testing in Geneva. In this scheme, a private third party is introduced aside the public administration and the end-user. The private partner produces and technically delivers a service to an eligible end user who has made a claim. The public actor retains legal responsibility for service delivery, has total control over sensitive information, and is given an option to block the claim during a fixed delay. If the claim is not blocked, service is delivered by the private partner who will ultimately be paid for it. A contract between public and private partners establishes conditions, remuneration and penalties (in case service is not delivered or blocking is abusive).

The advantage of the scheme is that the end-user must not wait for the public actor to work completely through the fabrication and control processes before receiving the service. This is possible because, in many cases, this process is only slightly concerned with authorization in its first few steps, and then heavily burdened with internal notification, accounting and medium breaks inside the administration, whereas the end-user’s legal right to receive service has already been established.

The time interval during which the public actor is allowed to block the claim is sufficient to check

2008 International MCETECH Conference on e-Technologies

0-7695-3082-6/08 $25.00 © 2008 IEEEDOI 10.1109/MCETECH.2008.14

203

2008 International MCETECH Conference on e-Technologies

0-7695-3082-6/08 $25.00 © 2008 IEEEDOI 10.1109/MCETECH.2008.14

203

2008 International MCETECH Conference on e-Technologies

0-7695-3082-6/08 $25.00 © 2008 IEEEDOI 10.1109/MCETECH.2008.14

203

authorization. This means that part of the chain of command inside the public organization must be notified of the claim in order to be able to block it if necessary. However it does not imply that the administration’s processes, particularly the implementation of workflows in back-end information systems, must be reengineered. The last point is important because the scheme can thus be applied and tested on a subset of poorly efficient processes or even business cases, before doing any process reengineering. Learning from these preliminary steps, the administration can then go on to reorganize internally. There is also a business interest for the private partner to accompany this ongoing transformation for other processes and services where the scheme can be applied.

The following section defines the context and the organizational constraints necessary to operate the scheme. Section 3 presents the case study in terms of processes, researched benefits and tradeoff between gain of time (the end-user’s added value) and risk (the cost for the administration). Section 4 describes the key articulations of the implementation. Section 5 briefly describes several applications. 2. Public-private partnership in e-government

While ranking among the top nations regarding its capability in the information society [1, 2], Switzerland has been very slow to develop e-government [3]. The reasons invoked in the country are a complex structure of authority with three levels (federal, cantonal and communal) of government all enjoying and jealously defending sovereignty on broad sectors of regulation; and also some degree of mistrust towards the administration on behalf of citizens and businesses.

Nevertheless the Canton of Geneva has had some success in the development of e-democracy, notably the act of voting through the internet [4]. It is currently working on the development of an e-government platform [5] and has been considering the opportunity to implicate private partners in the management of certain specific public services in e-government based on public-private partnership agreements [6, 7].

In a PPP, a public entity delegates the construction of an infrastructure to a private contractor who finances the asset and manages it over a predefined interval of time. During this period, the private contractor delivers a service to a population using the asset and receives payment in order to make a profit. The asset is usually very concrete: a school, a road, a bridge or a hospital. Services include functional maintenance of the asset, but not for example teaching

in schools or providing medical care in hospitals. In this sense, the contractor is responsible towards the government for functional capability, but the government is responsible towards the end-user for delivery of the service and conformity with regulation. In Geneva, we are testing this model in a domain where assets are information systems and public services are provided to citizens over the internet.

We first remark that the kind of PPP we are looking in for e-government is not related to outsourcing computer and network infrastructures to private contractors for the benefit of public administrations. We consider the situation where a private third party delivers a public service to an end-user (citizen or business) on behalf of a public agency, and under the following conditions:

• the private partner is responsible towards the public agency for service production and delivery (functional capability), whereas the public agency is responsible towards the end-user for effective delivery (conformity);

• the public agency retains control of all sensitive information concerning the end-user and is responsible for the enforcement of privacy protection;

• the end-user retains the choice to acquire the service through the internet or through traditional channels. In the latter case, the public agency generally delivers the service itself. This last point is necessary because of the poor penetration of e-government in day to day life in terms of number of services available and of citizens concerned. As long as the benefits of e-government are not clearly established, traditional channels must be maintained.

These constraints define four domains where the actors implicated in a PPP for e-government have, or share, a responsibility (illustrated by the round-cornered boxes in Figure 1).

The government has exclusive access to sensitive citizen-related data and is responsible for privacy, enforcement, and conformity. The service provider is responsible for the production and the maintenance of the service. Both actors share a responsibility regarding service delivery to the citizen: this is the domain of shared risk. The end-user and beneficiary of the service has responsibilities of his own which are defined by the legal context of the considered service. All three participants entertain point to point relationships that are regulated using an agreement, which is a fundament of the partnership.

204204204

Figure 1. Domains of responsibility for PPP actors in

e-government 3. Process re-engineering

We consider the situation where an end-user is entitled to a benefit or a service from a public administration. In order to receive this service the user posts a claim (see Figure 2) and waits for an answer. The answer can be a rejection (e.g. because the request is incomplete in the view of the administration) or an acknowledgement of the request, or the awaited result.

There are many examples in the field of public administration: attaining legal majority entitles a citizen to vote and in some countries registration on electoral lists is a service that the administration provides only if it is requested. Delivering goods or services entitles a supplier to receive payment after an invoice has been posted to the administration. Diverse conditions can entitle a person to receive social benefits, and in many cases this service has to be asked for. Being an academic, a physician, a lawyer, etc. or a company registered by the government in a specific sector of activity, can open up access to some types of classified information, which has to be formally requested. Etc.

Figure 2 depicts the different steps of the fabrication process the government agency sets up to answer to the request. First, depending on the medium used to post the request, it can take some time before the right actor in the administration receives it. Acknowledgement of the request is also optional. The first concrete step is then usually the verification that the request is justified. This is the authorization sub-process which leads to a decision. A fully automated authorization sub-process would enable the user posting a claim through the internet to be immediately informed of the outcome. However, human intervention remains the rule in many applications. If the decision is not to reject, the process goes on to two different kinds of activities: tasks concerned with producing the service, and tasks concerned with internal controls and accounting. In addition to the amazing fertility of imagination public administrations can show in this domain, these activities are often fragmented, time-consuming, poorly coordinated and

loosely related to the service requested by the end-user. They might implicate several different computer applications scattered through different platforms, and exhibit discontinuities and medium breaks in the flow of information and control.

.

Figure 2. Initial service fabrication process

Once the service is ready for delivery it is sent off

to the user who will receive it after an undetermined delay. It will be difficult to estimate the time that was actually necessary to produce the awaited result, which has an impact on planning further requests (in turn this leads end-users to build up reserves with regards to the service, e.g. by posting the claim earlier than necessary, and has a global slow-down effect on the way the administration and the society interact).

The possibility to deposit requests electronically is an improvement. However, compared to the duration of the complete procedure, the gain is small. More worthy is the fact that the user automatically receives an acknowledgement of the request.

A second improvement for the end-user would be brought along by serializing first the production tasks and then the control and accounting tasks. This is shown in Figure 3. In general this is not possible without fully re-engineering the fabrication process.

Figure 3. Serializing production and control tasks

This is the real bottleneck of e-government,

strangling public administrations harder by the deployment of electronic services the lower their level of authority and the more they lack resources: the economies of scale are vital in e-government, since an electronic service costs the same to develop and maintain for 10’000 users as for 1’000’000.

At this stage we introduce a new paradigm: a controlled-risk light authorization process inside the government agency with a time-out, accompanied by

205205205

the fabrication of the service in parallel outside the administration.

The principle is illustrated in Figure 4.

Figure 4. External fabrication of the service

As soon as the claim is posted, the actors

responsible for authorization and control inside the agency are alerted. During a fixed interval of time, these people, organizational units or computer systems can call an option and block service delivery. The time interval is long enough so that the necessary controls related to authorization can be executed. If delivery has not been blocked, a timeout locks the blocking option and the service must be delivered to the end-user.

This manner to proceed has several advantages. The main benefit to the user is a much shorter, fixed, maximal delay between the moment the claim is posted and the reception of the service (or the notification of rejection). In the case implementation we are working on in Geneva, this gain can be tenfold, which is considerable given the financial implications at hand. Also, if the request is blocked, the end-user is informed of the situation and its origins, and can take corrective action immediately, which is also very important.

Another advantage is that the scheme can be applied to a chosen subset of business cases, while the administration is still running the old process on the remaining cases, but without requiring that employees manage two or more processes at the same time (which could lead to resistance against this new way to proceed). In the first stage of re-engineering, business cases must be chosen so that the interface between the new process and the old legacy applications can be run without human intervention.

This also has a cost. On one side, the trade off for shorter end-user delays is the risk the administration runs if it is unable to block a request that should have been rejected. Overly reacting to this risk perception, the public-sector actor might block requests unduly. If blocking comes after the fabrication process has begun, this implies a loss. Moreover, if the time necessary to check authorization is actually shorter than the fabrication process, then the latter must start as soon as

the request is posted if the goal is to minimize answer time. This means that any call of the blocking option (justified or not) implies a loss. Who pays? The actor responsible for the loss should pay, and this can only be the end user (e.g. in the case of an unjustified request) or the government agency (unjustified blocking of a justified request).

On the other hand, the private partner wants to make a profit out of the business and has to be remunerated for providing the service. In this sense, the production process is outsourced according to some prior examination and agreement, and a portion of the profit the end-user and the administration make out of the scheme is returned to the private partner.

In our experience, the end-user is ready to do this to some extent when the subject considered is, for example, shortening the delay of payments made by the administration. We come back to these considerations in section 5 dedicated to applications.

Independently from service provision, a third party application (see the description of system C in the following section) must be built, deployed, and run. To avoid falling back into the usual pitfalls akin to administrations and burden the new platform with unnecessary controls, this task can also be entrusted to an external private partner under another type of PPP contract.

Being neutral and essentially an information production facility, the platform can be used to provide service to several public entities running the same production process (this is often the case when regulation is defined at an upper legislative level and applied at the local executive level). Or else, the generic scheme can be used to optimize other services, and the resulting processes run on the same platform. We also come back to these considerations in section 5. 4. Implementation

Figure 4 depicts how communication between partners must be implemented:

• when an end user posts a claim, this defines a new business case and signals the beginning of a transaction. Both the third party and the government agency must be notified;

• during the time interval when the blocking option is open, the government agency must be able to deliver a blocking message to the third party. If blocking occurs, the end-user must be notified;

• at the end of the fabrication process and if no blocking message has been received, the third party must deliver the service to the end user. The

206206206

government agency is notified and receives accounting information related to the transaction.

This scheme can be enriched in several manners: • the production process can be extended to more

complex transactions where any participant can be solicited to deliver complementary information (more communication exchanged during the production process);

• any one of the three participants (i.e. not only the government agency) can block the transaction at any time as long as the blocking option is open (in particular, this gives the end-user an option to back out of the request as long as the service has not been delivered, but maybe at a cost);

• depending on the type of process, more than three partners could be implicated in a business case and in the execution of the corresponding transaction (e.g. an end-user who posts a request for social benefits could designate a family doctor to assist in the process).

To reflect these constraints and the conditions described in section 2, we have designed the distributed system along the following lines:

• the shared risk domain is implemented on an autonomous system called the central system C (see Figure 5). For any business case, this system is the state repository and execution management unit of a unique reference transaction;

Figure 5. Mapping the PPP-architecture on the

distributed system’s architecture

• each participant (end-user, third party and government agency) runs its own technological infrastructure and information system on which the business cases and the transactions it is concerned with are reflected. For a given business case, these peripheral systems are called Pu, Pa and Ps, (resp. for the user’s, the administration’s and the service provider’s systems). For a given administrative process in e-government, many business cases can be managed, each one possibly corresponding to a different end-user. This implies that there are multiple Pu systems which are heterogeneous and possibly very simple;

whereas the government agency and the third party manage a set of business cases for each process, meaning that both Pa and Ps are powerful computer systems integrated in a complex information system infrastructure;

• human end-users, or employees of the end-user, of the government agency and of the third party, can access system C using a browser. The peripheral systems can also communicate with C using the network (in the first implementation in Geneva, we use web-services, but an interface using sockets will be added in the next version);

• each one of Pu, Pa and Ps, maintains a local projection of every business case it is concerned with (for the end-user, usually one at a time). This local representation of the business case might be very simple, like a set of printouts for an end-user accessing the system with a browser. For the public agency, however, it is more likely to be a complex object reflecting requirements of some of the control and accounting procedures that will have to be conducted inside the administration on the reflected business case because of its own internal rules;

• system C maintains its own image of the business case with the following implementation constraint: any information concerning the business case and residing on C must be shared by at least two partners. In particular, C does not reflect any organizational characteristic which is proper to only one participant.

Under these conditions, a business case can be considered as the instance of a workflow, where each state transition is originated by one participant and concerns at least one other participant. System C can be built as a workflow engine providing services to a set of participants on a set of open business cases.

The services C provides are: • security and access control. Each business case

has a defined set of participants. Only an authorized participant is allowed to access a business case. Each state transition can be triggered by a participant only according to a role-based description of the corresponding workflow dynamics, where each role has a one to one relationship to a unique participant of the business case. Participants are identified and authenticated before accessing any information or functions related to individual business cases. Basically, systems security is implemented along the same lines as in the e-voting system [4];

• transaction control. The transactions we consider are not traditional distributed transactions where the evolution of a distributed state is coordinated

207207207

through a central control system and the transaction terminates with a 2PC protocol establishing consistency. In our case, each participant acts through a heterogeneous peripheral system on which there is a priori no external control. Each participant has different legal responsibilities regarding the transaction and any operation on C must set a business case into a consistent partial state that has the same meaning at each instant for all the participants. System C implements theses conditions by serializing all requests issued along the (US)-(CO) axis (see below and Figure 6);

• persistency. With respect to the heavy legal responsibility linked to the delivery of the service, system C, which implements the shared risk domain, is built in a way to guarantee persistency of business case contents and state, as well as logs of all operations;

• notification. System C notifies every business case participant of state transitions using the chosen notification mechanism of the corresponding peripheral system. This will usually be SMTP for end-users. The much harder conditions set on the public agency to react within a set delay (blocking option) weighs in favor of more robust communication mechanisms between C and Pa, for the central system’s manager (who can prove the efforts made to reach Pa) as well as for the administration’s system manager (who does not want to carry responsibility for late blockings due to carelessness at executive level in the public agency). One of the positive side effects of the scheme is thus to clarify responsibility between actors in the administration.

The technological architecture of system C is described in Figure 6. The system runs in a J2EE environment and is composed of four off-the-shelf technological components and four macro-functional modules. Component (1) is the interactive web-interface programmed in JSP; (2) is a MySQL relational database management unit; (3) is the persistency unit (Hybernate) and (4) the web-service component (of JBoss).

Module (BC) manages business cases and comprises the workflow engine; (AD) contains all administrative data and functions, in particular identity management of participants in business cases and in transactions, for access control and role assignment; (US) is the programmed user interface (i.e. web pages and technical connections to the heart of the system on the (BC)-(AD) axis); and (CO) is a message driven communication unit which implements communication

with peripheral systems between functional peers at the (BC)-(AD) level.

(2)

(3)

(4)

(CO)

(1)

(US)

(BC) (AD)

Figure 6. Central system’s architecture

Several considerations led to the design in Figure 6.

The main reason is its generic nature which enables to build system Pa as a functional copy of C running a secondary workflow engine inside the administration’s network. In this manner, the simple workflows executed on C can be replicated in Pa and coupled with more complicated workflows connected to the legacy systems running the older processes and their reference databases inside a protected domain. This is illustrated in Figure 7. Security issues are at stake, but also the capability to extend the platform to new processes and services synchronously with the developments on new services conducted by the private partner.

The generic workflows, and the command protocols used at the (BC)-(AD) level (i.e. to notify from C outwards and to request to C inwards from the peripheral systems) are described in XML files and published. These design issues, and in particular the design of the replicated workflow engine with primary and secondary business case copies respectively on C and Pa, are however out of the scope of this paper.

Generally, a business case managed on C will go through eight states: created, published, activated, locked, delivered, received, terminated. The first two states created, published reflect the need to correctly define the context of a business case and transfer necessary arguments to the participants. For example, the choice of the private partner by the end-user (just as a customer chooses which credit card he wants to use to pay a service in a mall) is a deterministic step when more than one provider is available. When the business case enters the published state, the corresponding transaction can start and every participant is notified. When the end-user posts the claim, the business case transits to state activated and

208208208

the timeout on the blocking option begins to run. The locked state means that the blocking option has elapsed and system Ps is free to deliver the service. As long as the business case is not in the locked state it can be blocked by any participant, which defines a ninth possible state.

Figure 7. Global distributed system architecture

Abusive blocking of business cases can annihilate

the researched benefits of the system. In this case, the participants must refer to the fundamental agreement (see Figure 1) to sort out what’s going wrong.

Once the service has been produced and sent to the end-user, the third party triggers the transition to state delivered. In turn the end-user can trigger the transition into state received leading the system to archive the business case and terminate it. If the end-user doesn’t acknowledge reception once the business case has entered the delivered state, a timeout can raise an exception for appropriate treatment.

State transitions can be executed interactively by a user acting on a browser and accessing component (BC) through components (1) and (US); or alternatively requested through the network using messages delivered to (CO). Any state transition provokes a notification which is sent by C to every participant concerned with the business case. 5. Applications 5.1. Speeding up payment of invoices

The system described above was initially designed to speed up payment to furnishers of invoices sent to government agencies in specific domains where the control and accounting processes can be unduly and unpredictably long. This is often the case in complex projects like construction or software development, depending on how internal controls are organized parallel to project controls. Prolonged payment delays can provoke balance and liquidity problems for furnishers, as well as delays and disruption in the projects themselves. The first version of the system was built to guarantee a 10-day payment delay as soon as 1) a service delivered to a project was formally

accepted by the project organization, and 2) the related invoice was sent to the government agency by the furnisher.

This application responds to the difficulty of conducting projects (processes driven by time, resources and results) in administrations where controls are driven by static abstract constraints established in regulation.

Furnishers were ready to remunerate a third party through a fair discount on the original invoice payment in order to be paid in a fixed guaranteed delay. The third party is a credit institution which buys invoices back from the furnisher under specific contract conditions establishing the discount, on one side, and conditions for full repayment from the public actor on the other.

Reengineering the flawed process in the public agency is planned in three steps: 1) setting up the scheme described above; 2) transferring the service from the private third party inside the government’s treasury department; 3) reengineering the control and payment process. As discussed below, the private actor can have several public customers, which prevents it from going out of business after step 2). 5.2. Distributed transactions in e-government

The scheme presented above has generic characteristics which enable reuse in other application domains.

It makes it possible for several actors to interact across institutional barriers inside a distributed transactional context in a deterministic and controlled manner, without delegating or weakening their position relatively to legal responsibility (i.e. implicitly accepting more responsibility than they would like through the use of a common software platform they do not control).

For a given (repetitive) transaction, a workflow is defined, published and installed on a platform C which is publicly and centrally made available. The workflow does not reflect internal organizational characteristics of any of the potential actors. This enables each participant to reflect the workflow inside its organization along its own constraints, without impairing functionality of other partners.

There is no limit on the number of participants of a given workflow.

Execution is asynchronous, though delays can be assigned to a participant for the execution of some action, as in the case described above.

Moreover, there is no need for any partner to be a government agency in the role of the public sector, a private service provider, or even a citizen or a private

209209209

business in the role of the end-user. For example, a local government agency can play the role of service provider for neighboring local governments if it has proceeded to reengineer a costly process the others have not yet come to, or if it is assigned the executive role for a new procedure issued from higher legislative authorities (without implying that other partners lose sovereignty or responsibility). 5.3. Other types of services

Currently we are designing workflows for two new applications: provisioning of digital identities to end users of e-government services and harmonizing digital registers among government agencies.

The first problem is concerned with giving electronic credentials to end users across the internet without the latter having to sign a physical contract or to use a certificate from a PKI. These two options remain open for end-users who want to use them, but are considered too time costly, respectively too complicated, for the common user of e-government services.

For most e-government services, the conditions necessary to achieve a sufficient level of security are 1) guarantee that the designated user has made a request for e-credentials and has acknowledged the conditions of use; 2) guarantee that the designated user receives the credentials (and not someone else).

In this case the third party is an actor which has a relationship with both the end-user and the government agency (the relationship can be either contractual or regulatory) and already provides e-services to the end-user at the same level of sensitivity as defined by the considered e-government context (an example is the user’s bank providing e-banking services which are usually considered by users as sensitive services).

The second problem concerns harmonizing digital registers across agencies inside a local government, as well as across local government boundaries (local registers often have to be consolidated at higher levels of authority). This task is complex. It first requires the deployment of a quality insurance process ensuring that the perception of datasets converges at each end of a harmonization procedure. We have found that the generic scheme presented above is well suited to the implementation of such a QI process. 5.4. Application to PPP and e-government

In the development above, we have considered two different kinds of intervention of the private sector as partner in e-government.

The first is the provision of a service in place of the government: the service provider has some property (efficiency, relationship, knowledge, etc.) that makes it worthwhile to delegate the fabrication process while still keeping full control and responsibility on the finality of the procedure. The PPP is then of the service contract type: the government contracts with a private entity to provide services the government previously performed [8].

The second is the construction, operation and maintenance of the central platform C. Clearly, this platform must be positioned outside the direct reach of the public agencies running transactions on it. This argues in favor of a DBOM- (design build operate maintain) type of PPP contract.

If the contractor is remunerated according to the number of participants in transactions, the number of workflows operated and the number of business cases actually executed, and if different levels of quality of service can be proposed to different users (for example, a logging facility where requests and official decisions can be backed up for individual end-users working from home on their PC), then there is an interest for the private partner operating the platform to participate in the development of new transactions for government agencies, with contributions at the high end of the value chain.

Speeding up the development of e-government in this way could in turn be of great benefit to the administration, especially for public services used by businesses. 6. Conclusion

The greatest difficulty in the deployment of e-government is the re-engineering of production processes inside public administrations. The problem is not only technical, but has much to do with resistance to change. When there are multiple levels of authority (federal, county and local, as in Switzerland for example) the problem is even greater because e-government services cannot reach optimal efficiency if their deployment is not at least grossly synchronized transversally at each level to lower costs.

In the scheme we present in this paper, a private entity works alongside the public administration and the end-user. The private partner executes the fabrication processes of a public service without having to handle sensitive personal data. Based on its own access to potentially, but otherwise undisclosed, sensitive data, the public partner can block the process.

Where it applies, the scheme furnishes a solution to both the problems above: specific organizational constraints are not visible to the end-user, and for this

210210210

reason reusability throughout a given level of authority is high. Also the public administration can proceed incrementally to the migration of services and business cases according to different criteria, and thus better organize, control, and finance the reengineering process.

At the technical level, the scheme requires no adaptation of the end-users’ platform, i.e. generally a browser. For the public and private partners, some web-technology is necessary for batch operations and automatic treatment of notifications. A primitive workflow engine is used to implement multi-party state-based serialized transactions. In this way a consistent view from all parties is guaranteed at any time, which is necessary to enforce conformity and accountability between all the participants. 7. References [1] The Economist Intelligence Unit, IBM Institute for Business Value, “The 2007 e-Readiness Rankings”, http://www.eiu.com, 2007 [2] S. Dutta, A. Lopez-Carlos, I. Mia, World Economic Forum Global Information Technology Report 2005-2006, Palgrave Macmillan, March 2006

[3] EU i2010, Capgemini, “Online Availability of Public Services: How Is Europe Progressing? Web Based Survey on Electronic Public Services”, Report of the 6th Measurement, http://ec.europa.eu/information_society/eeurope/i2010/docs/benchmarking/online_availability_2006.pdf, June 2006 [4] M. Chevallier, M. Warynski, A. Sandoz, “Success Factors of Geneva’s e-Voting System”, Electronic Journal on e-Government, http://www.ejep.com, Volume 4, Issue 2, 2006. [5] A. Sandoz, N. Haenni, J.-R. Eudes, “Addressing and protecting distributed resources in e-Government architectures using multiple digital identities”, 5th European Conference on e-Government, Antwerp, Belgium, June 2005 [6] http://www.pppcouncil.ca/resources_legislation.asp [7] US Dept. of Transportation, Federal Highway Administration, “Case Studies of Transportation Public-Private Partnerships around the World” http://www.fhwa.dot.gov/ppp/int_ppp_case_studies_final_report_7-7-07.pdf, July 2007 [8] Deloitte Research, “Closing the Infrastructure Gap, the Role of Public-Private Partnerships” http://www.deloitte.com/dtt/cda/doc/content/closeinfgap(2).pdf, 2006

211211211