13th European Conference on eGovernment – ECEG 2013 1 | Page 558

Konrad Walser and Olivier Brian
clients( administrative units and also third parties). Central from an organisational perspective is to establish who the " contact person " is within the community cloud for the external service recipient( SR), and the institutional framework that the community cloud must have in order to provide an effective and efficient service to the public administration.
1.3 Methodical procedure
The methodical procedure for compiling the findings from this article is based on a qualitative process for developing possible organisational variants of a community cloud for authorities / public administration.
Expert interviews, based on key words / results, were conducted and some of them were held with the same people several times. Interviews were conducted with the organisation that commissioned the work that underlies this article( IT steering unit at the Federal Department of Finance, Architecture Division) and with organisational and e‐Government experts. The interviews for this study are based on a very widely supported cloud strategy for Switzerland which is currently in the consultation process( ISB 2011). This research shows possible organisational measures for implementation that complement( ISB 2011). The intention is to use the results presented here as the starting point for a possible pilot project for a community cloud for the Swiss authorities. From the commissioning entity ' s perspective and based on a definition of the concept, the method aimed to gather the requirements for creating a community cloud, and then use these to define organisational models for implementing the community cloud for public authorities. Further research investigated the question of how the community organises itself. This was based, among other things, on the results from a research project that looked at sourcing options from Swiss parishes( Csoka 2006), which were partially used as the basis for this development of proprietary community cloud models. Additional considerations were based on Carr ' s publication which describes how infrastructures can be used to generate and distribute electricity.( Cloud models from other domains: electricity, transport infrastructures etc.( Carr 2008)). The corresponding broker model is based on an idea of a spin‐off from the ETH Zurich( cloud force). The aforementioned bases were used to define models that, in interviews with the commissioning entity, were tested and validated in terms of their completeness and usability for public authorities. This showed that the results were valid and reliable. The effective implementation / use of the relevant models for public authorities was also tested. For reasons of space, this will be discussed in a subsequent article.
2. Introduction to the subject matter
2.1 Definition of cloud computing This article is based on the NIST Cloud definition:
“ Cloud computing is a model for enabling ubiquitous, convenient, on‐demand network access to a shared pool of configurable computing resources( e. g. networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.”( NIST 2011)
This definition comes closest to the concept of cloud computing and is often cited in literature and in practice. Cloud computing can thus be described as a special form of outsourcing( Motahari‐Nezhad et al. 2009). It has specific features and characteristics that each have their own advantages and disadvantages. Only when a service exhibits all of the properties listed in the following table can it be referred to as an integrated cloud offering as per the NIST definition.
Table 1: characteristics of cloud computing Characteristics
Description
On‐demand self‐service IT is used as a service and be called up easily without any form of manual interaction.
Broad network access The service is available via a network, independent from the end device. The connection must be available and high‐performing as per the service.
Resource pooling The required resources are made available by the provider for different clients. This is made possible by technologies such as virtualisation and multi‐client capability( multi‐tenancy).
Rapid elasticity The resources required are made spontaneously available as needed and, in the event of non‐use, released without any manual intervention.
536