Mehr Beinfreiheit in der Private Cloud Und sie bewegen sich doch!

Anbieter zum Thema

Cronon GmbH

Arvato Systems

OutSystems

Information Services Group (ISG) Germany GmbH

Kann man Hyperscaler zu mehr Flexibilität bringen? In der Produktion sicherlich kaum. In der operativen Zusammenarbeit dann aber sehr wohl. Wer wissen will, was jenseits der Standards machbar ist, braucht jedoch eine belastbare Sourcing-Strategie.

Die Public Cloud wechselt auf die Überholspur. Mittlerweile auch hierzulande. Nach Jahren des Abwartens entschließt sich eine stetig steigende Zahl von Unternehmen, die Angebote der Hyperscaler nun auch im Kerngeschäft zu nutzen. Nicht wenige sprechen sich bereits für den kompletten Umzug all ihrer Applikationen aus.

Doch Vorsicht! Um das Licht seines Rechenzentrums tatsächlich einmal endgültig ausschalten zu können, sind erhebliche strategische Vorarbeiten nötig. Denn nur wer Applikation für Applikation den Nutzen, die Risiken, die Machbarkeit und den Zeitplan der angestrebten Migration klärt, geht mit wirklich belastbarem Wissen ins vertragliche Sparring mit den Hyperscalern. Nicht zuletzt entwickeln Unternehmen dann auch eine wesentlich genauere Vorstellung davon, wann es sich lohnt, Public-Cloud-Anbieter auch auf spezifischere Formen der Zusammenarbeit anzusprechen.

Erwartungen und Möglichkeiten abwägen

Zuvor sollte man sich jedoch eines grundlegend klarmachen: Hyperscaler haben ein extrem standardisiertes Geschäftsmodell, das vor allem produktionsseitig keine nennenswerten Spielräume für unternehmensspezifische Anpassungen bietet. Vor diesem Hintergrund ist es aus Kundensicht ratsam, erst einmal gehörigen Abstand zu all jenen Erwartungen zu nehmen, die man im Managed-Service-Umfeld an seine IT-Dienstleister zu stellen gewohnt ist.

Sicherlich, auch Letztere haben ein nicht eben geringes Interesse daran, möglichst viele Standards zu verkaufen. Doch signalisieren sie immer auch die Bereitschaft, auf weiterführende Kundenanforderungen einzugehen. Insbesondere dann, wenn dies zu Branchenlösungen führt, mit denen man sich am Markt differenzieren kann.

Das Mindsetting eines Hyperscalers ist ein grundlegend anderes. Hier geht es zuallererst darum, die Kapazitäten der vorhandenen Standards bestmöglich auszulasten. Kaufmännische Themen wie die Dimensionierung der Mengen-abnahmen oder der Zuschnitt der Rabattstaffeln stehen deshalb im Vordergrund jeder Vertragsverhandlung. Eine fachliche Diskussion spezifischer Kundenanforderungen findet zumeist nur am Rande statt. Zumal der Vertrieb des Hyperscalers keinen vergleichbaren Durchgriff auf das Solution-Design und die Delivery hat, wie dies zum Beispiel im Managed-Services-Umfeld der Fall ist.

Vor diesem Hintergrund sollten sich auch die Kundenunternehmen darüber im Klaren sein, dass ihnen ohne weitere Zusatzregelung keine zentrale Serviceorganisation gegenüberstehen wird, auf die die Anwender in der Betriebsphase direkt zugreifen könnten. Bevor man in einer solchen Ausgangslage Tatsachen schafft, sollte man deshalb so präzise wie möglich festlegen, welche Ziele sich mit der Cloud-Migration realistischerweise verbinden lassen und wie die Roadmap dorthin aussieht.

Anteil des cloud-fähigen Workloads feststellen

Kernthema einer solchen Sourcing-Strategie ist die Migrationsfähigkeit der bestehenden Anwendungslandschaft. Hierbei gehen die Überlegungen weit darüber hinaus, einfach nur die Mehrwerte zu beschreiben, die mit dem Wechsel auf eine Public-Cloud-Infrastruktur verknüpft werden.

Mindestens genauso wichtig ist es, die applikationsseitigen Voraussetzungen zu klären, die gegeben sein müssen, damit sich die Workloads auch weiterhin in ausreichender Qualität ausführen lassen. Reicht die erzielbare Cloud-Performance, um die Service Level Agreements in einer Form aufrechtzuerhalten, dass Kunden, Mitarbeiter und Geschäftspartner sie in der Praxis akzeptieren werden? Bei möglichen Abweichungen ist präzise zu ermitteln, inwieweit die daraus resultierenden Business-Risiken den Nutzen der Cloudifizierung gleich wieder aufzehren.

Für die Mehrzahl der bislang umgesetzten Migrationsprojekte lässt sich konstatieren, dass rund 80 Prozent der Workloads ausreichend geeignet sind, um sie in gut planbarer Form in eine Public Cloud zu bringen. Beim Rest – und dieser Rest wird in nicht eben wenigen Unternehmen auch deutlich über 20 Prozent liegen – stellt sich die Ausgangslage wesentlich anspruchsvoller dar. Bis hin zu dem Punkt, da man feststellt, dass Lösungen von Grund auf neu zu entwickeln sind, um zu lauffähigen Lösungen zu kommen.

Gerade in Unternehmen mit langer IT-Historie werden Zwischenlösungen und eine genaue Priorisierung der unterschiedlichen Einzelvorhaben zwingend erforderlich sein. Mitunter gilt es dann auch einzelne Applikationen aus der Planung herauszunehmen. So etwa Anwendungen, deren Lebenszyklus zu weit fortgeschritten ist, als dass sich der Entwicklungsaufwand einer Cloudifizierung nach dem aktuellen Stand der Technik noch rechnen könnte.

Aus all diesen Vorüberlegungen ergibt sich eine Roadmap, die sämtliche Einzelvorhaben in eine verbindliche Reihenfolge stellt und die sich daraus ergebenden Timelines konsistent aufschlüsselt. Teil dieser Roadmap sind auch all diejenigen Vorhaben, die bis auf Weiteres ausgeklammert werden. Gerade hier gilt es, die weiteren Zuständigkeiten festzulegen: Für welchen Teil dieser Applikationen soll der Hyperscaler Zwischenlösungen erarbeiten? Worum kümmert sich die IT-Organisation in ihrem bisherigen Partnernetzwerk vorerst besser noch selbst? Und: Bei welchen Applikationen soll das Unternehmen auf SaaS-Lösungen wechseln, die einen akzeptablen Ersatz bieten?

Auf diese Weise entsteht ein gesamthaftes Bild, aus dem sich schlüssige Ziel-szenarien für sämtliche Teilprojekte ableiten lassen. Ob der Migrationsplan weit und genau genug gefasst ist, zeigt sich dann gerade auch in den Vertrags-verhandlungen: Kann man konkrete Teilfragen zum Kapazitätsbedarf und den erforderlichen Lieferterminen auf Basis der vorhandenen Leitlinien beantworten? Oder beginnt man konzeptionell immer wieder von vorn, da die Roadmap noch Lücken aufweist?

Den Kundenbedürfnissen entgegenkommen

Nun zurück zur Ausgangsfrage: Wo in der Werschöpfungskette können Hyperscaler-Kunden eine flexiblere Unterstützung erreichen? Über welche Themen lohnt es sich zu verhandeln, wenn es doch produktionsseitig kaum Einflussmöglichkeiten gibt? Ein wichtiges Teilgebiet wurde bereits kurz angesprochen: Der Umgang mit Applikationen, deren Cloudifizierung bis auf Weiteres nicht wirtschaftlich ist. Die Mehrzahl der Anwenderunternehmen organisiert die daraus resultierenden Teilprojekte derzeit noch in Eigenregie und greift dabei auf das eigene Partnernetzwerk zurück.

Um die Komplexität einer Cloud-Migration im eigenen Unternehmen zu reduzieren, kann es jedoch sinnvoll sein, den Hyperscaler damit zu beauftragen. Dieser unterhält ohnehin Geschäftsbeziehungen zu vielen Managed-Services-Providern und Colocation-Anbietern, so dass er sämtliche Services aus einer Hand anbieten kann.

Doch der Change-Bedarf einer Cloud-Migration geht noch sehr viel weiter. In besonderem Maße gilt dies für Unternehmen, die eine eigene Entwicklungs-organisation haben und die dort eingesetzten Mitarbeiter darin fortbilden müssen, cloud-fähige Applikationen zu entwickeln. Hier lohnt es sich, frühestmöglich Vereinbarungen darüber zu treffen, wie sich die Public-Cloud-Anbieter an den erforderlichen Qualifizierungs- und Zertifizierungsmaßnahmen beteiligen sollten.

Ansatzpunkte für eine tiefere Zusammenarbeit mit dem Hyperscaler ergeben sich auch ganz generell im Organizational Change Management (OCM). So zum Beispiel bei Aufbau und Übernahme der passenden Steuerungsfunktionen. Bislang haben Hyperscaler zwar keine größeren OCM-Lieferkapazitäten geschaffen. Doch können sie eine wichtige Quelle für Expertengespräche sein, zu denen der Cloud-Kunde dann eigene Fachleute und gegebenenfalls weitere Dienstleister hinzuzieht.

* Der Autor Friedrich Löer ist Partner bei der Information Services Group (ISG).

(ID:47849026)