Alle reden immer nur über private oder öffentliche Ressourcen oder gar hybride Szenarien. Community Clouds sind irgendwie in der Mitte: Sie verbinden die Mehrmandantenumgebung einer Public Cloud mit der Exklusivität einer Private Cloud. Denn in den Nutzerkreis werden nur ausgewählte Teilnehmer zugelassen. Typische Beispiele sind hier Konzern-IT-Abteilungen oder Zweckverbände: Sie sind alle Trusted Cloud Service Provider. Egal, ob sich 10, 100 oder 1.000 rechtlich selbständige Unternehmen zusammentun, die "Economics of Scale" ziehen immer: Größere Umgebungen lassen sich effizienter betreiben, Einkaufsvorteile nutzen und die Skalierung ist einfach abzubilden.

Für den Betreiber ist es eine gute Möglichkeit, sich mit Mehrwerten gegenüber den Public-Cloud-Anbietern durchzusetzen. Somit werden Community-Clouds in Deutschland geplant, die mit Branchenwissen oder speziellen regionalen Services Rechenleistung zentralisieren und Kompetenzen bündeln sollen (wie Energy Clouds oder Logistic Clouds).

Das ist alles gut und richtig, dafür gibt es auch technisch ausgereifte Lösungen verschiedener Hersteller, mit deren Konfiguration und Administration der Betreiber vertraut gemacht werden muss.

Gewisse Standards sind unabdingbar

Spannender ist die Frage, was eigentlich angeboten werden soll, wenn doch beabsichtigt ist, alles einfacher, schneller und vielleicht auch kostengünstiger laufen zu lassen. Denn viele unterschiedliche Service-Kataloge für die "Mitglieder" der Community Cloud oder gar eine Cloud pro Mandant macht alle Konsolidierungsgedanken zunichte. Es geht also wie so häufig bei Cloud-Projekten um die Standardisierung. Das kann ein langer oder gar unmöglicher Weg sein. Neben den Kosten der Standardisierung durch den Lizenzbedarf gibt es noch die Benutzer und die Administratoren, die trotz der Veränderung des Betriebsmodells auf Cloud Computing am liebsten nichts ändern möchten und in ihrer Komfortzone verharren.

Doch die Situation ist alternativlos: Ohne Standardisierung keine wirtschaftlich sinnvolle und nachhaltige Cloud.

Der Community-Cloud-Betreiber hat es mit der Abstimmung der IT-Verantwortlichen der jeweiligen Mandanten zu tun - mit eigenen Erfahrungen und Meinungen.

Nachdem man sich auf eine Version von Infrastruktur-Komponenten wie Exchange oder SharePoint geeinigt hat, kommen die scheinbar trivialen, aber sehr emotionalen Themen wie Bildbetrachter oder PDF-Erzeuger dran. Welches Tool wird allen Ansprüchen gerecht? Man wünscht sich den Konsens in dem alle Beteiligten gewinnen. Häufig genug reicht es aber nur zum Kompromiss (keiner gewinnt und die Wahl fällt auf das kleinste Übel). Wenn die Diskussion jedoch verfahrener wird, kann die Auseinandersetzung so stark sein, dass etwas aus dem Service-Katalog gestrichen wird. Dabei behält jeder sein Gesicht und dennoch verliert auch jeder. Keine Optimierungspotentiale und keine Flexibilitätssteigerung kommen mehr zustande.

Eine Community Cloud geht in der Regel viel weiter, als nur eine einfache IaaS-Umgebung wie bei Amazon. Die Community stellt Plattformen und Applikationen als Service bereit, denn nur so kann sie eine Attraktivität erhalten und ist nicht beliebig austauschbar. Wenn nun aber die eine Applikation aus der Cloud kommt, eine andere aus einer anderen Cloud und die dritte im alten Umfeld verbleibt, wird die Interoperabilität und auch die Bedienbarkeit dauerhaft geschwächt. Davon hat auch niemand etwas.

Aus den Erfahrungen vieler Projekte gibt es die folgenden Empfehlungen:

• Nicht nur die Technologen sind gefragt. Die Einführung der Community Cloud sollte auch von Experten begleitet werden, die eine Software Asset Management-Kompetenz haben, um die beste skalierbare Lizenzform auswählen zu können.

• Der Service-Katalog ist so zu beschreiben, dass alle Parteien (Anbieter wie Abnehmer) sich wiederfinden. Manche standardisierten Applikationen können in unterschiedlichen Ausprägungen oder Servicelevel angeboten werden.

• Einen Konsens zwischen allen Beteiligten zu erreichen, ist anstrengend, aber unter dem Gesichtspunkt der Vernunft die nachhaltigste Lösung. Dabei ist ein offenes Diskussionsklima zu berücksichtigen und auch der Weg zur gemeinsamen Lösung (wie Trainings oder Migrationspfade).

• Ein Projektmarketing hilft, die Verantwortlichen und Benutzer der Community Cloud richtig zu informieren und Widerstände zu vermeiden. Eine einfache Vorgabe funktioniert nicht, weil sonst Lücken gefunden oder Stellvertreterkriege geführt werden. Das Projektmarketing stellt die Vorteile der standardisierten Umgebung im empfängergerechten Umfang und der entsprechenden Tiefe heraus.

• Interatives Verbesserungsmanagement in der Community?

• Klärung der Betriebsverantwortlichkeiten für die Community Cloud: Wer betreibt, wer entwickelt weiter?

So kann das Vorhaben erfolgreich enden, eine standardisierte, flexible und kostenoptimierte Umgebung zwischen Gleichgesinnten zu etablieren, bei der alle gewinnen. Und das Vertrauen ist viel höher als in eine Public Cloud, weil man die Mitnutzer kennt und alle an einem Strang ziehen. (bw)