2.5 Community cloud organisational models
Konrad Walser and Olivier Brian
Various models with different operational and organisational structures can be used for organising a community cloud. The design options are described below by means of ideal types including advantages and disadvantages. Depending on the scenario, a combination of organisational forms may also be selected. Successful control, communication and co‐ordination between the stakeholders are critical for the correct organisational form. These activities will turn out differently depending on the model used.
Analysis has shown that the characteristics of the IT service providing can be described as follows: " Characteristics of the IT service providing: here it is about analysing whether outsourcing parts of the IT belongs to an existing strategic scenario in an administration. The following can be asked here: is the IT outsourced completely or in parts? Yes or no? An investigation of the institutional form of the service provider to which the IT is outsourced: here it is essentially about clarifying the institutional form i. e. whether the service provider was institutionalised as having internal, overall or external administration and the nature of possible current or future developments“( Walser and Breidung 2010).
ITIL( Bon et al. 2009) distinguishes three different types of service providers. Type I is described as functionally integrated SP, Type II is defined as a shared service center, and Type III means total outsourcing.
Starting from these three different service providers, possible ideal community cloud organisational forms are described in table 4( Brian 2012). These are ideal solutions that only reveal the relationship between the SP and the SR. A combination of the different organisational forms is possible and partly even necessary.
Table 4: Ideal community cloud organisational forms
Type / Description |
Advantages |
Disadvantages |
|
The broker acts as a central contact |
|
|
point, which simplifies communication |
|
|
( reduction in transaction costs). |
|
|
All coordination is done via the broker |
|
|
. Simple to achieve a market overview |
|
|
through limited number of providers |
|
|
( brokers). |
|
Broker model: SR obtains services via a central broker who coordinates with the SP. It could also be possible to have several brokers who offer different services.
Open community model: Anyone who complies with the rules defined by the community can get involved. Rules are created by the community and can be influenced by the members.
Different providers can easily become involved in the community. Providers can enhance communities through their key competencies. Solutions are available to the whole community.
SR dependent on broker. Neutrality of the broker must be ensured. Clarification of broker ' s liability. Broker as intermediary. Limited number of brokers. Low level of competition within the community.
Communication / co‐ordination complicated by loose organisation. Individual solution users have little influence on the community. Continuity dependent on members. Impact of innovative ideas complicated by community rules. From the members ' perspective, the community may develop an unfamiliar momentum of its own. Legal form of the community not clarified.
Consortial cloud organisation: Consortium of providers / users makes a community cloud available. Synergies( e. g. redundant data centres) can be exploited. Services provided by the consortium are defined / offered.
Cloud master provider: Consists of a main provider supported by other providers( sub‐contractors); wide support / consideration of other providers. In contrast with brokers, the main provider can itself contribute certain functionalities to the service.
Shareholdings in the consortium clearly defined. Wider support possible through involvement of different parties. Communication / coordination. Occurs within the consortium.
Clear contact person for communication / co‐ordination / control. Main provider can pass on risk to subcontractor. Additional offerings through sub‐contractors that the main provider cannot provide.
Decisions and advances must be made via the consortium or within the context of the rules agreed in the community. Disadvantageous for providers who do not belong to the consortium. Possible price fixing within the consortium. Parties involved represent wishes of their organisation, not very objective. Strong dependence on the main provider. Clarification of liability of main provider for sub‐contractors. Main provider has an effective monopoly and can strongly influence the sub‐contractors.
539