Cloud Transitions richtig gemacht!

Es ist nicht mehr die Frage, ob Ihr Unternehmen Anwendungen in die Cloud verlagern wird, sondern nur noch, wann und wie dies geschehen muss. In diesem Artikel teilen wir unsere Erkenntnisse darüber, was erforderlich ist, um diesen Übergang erfolgreich zu gestalten. Wir beleuchten verschiedene Perspektiven, die Sie bei einer Cloud-Migration berücksichtigen sollten, und erklären, wie Sie die richtige Strategie festlegen können.

Haben Sie einen Business Case für die Migration in die Cloud?

Wenn wir mit Unternehmen über die Umstellung auf die Cloud sprechen, stellen wir fest, dass viele unterschiedliche Ansätze gewählt werden. Der Grund dafür ist, dass der gewählte Ansatz und die zu ergreifenden Schritte in hohem Maße davon abhängen, wer im Unternehmen mit der Leitung der Umstellung betraut wird.

Wenn Sie die Entwickler fragen, wie sie ihre Anwendung in die Cloud verlagern können, werden sie mit großartigen Plänen aufwarten, wie sie die Architektur ihrer Anwendung auf Microservices umstellen und wie sie das neueste .NET Core-Framework verwenden können, da es für Cloud-Workloads optimiert wurde. Dies wird zu hohen Investitionen führen, bevor die Dinge verschoben werden können, denn die grundlegenden Unterschiede dieser Art von Architektur erfordern, dass die Anwendung neu geschrieben wird.

Wenn Sie die IT-Betriebsabteilung fragen, wie sie den Übergang bewerkstelligen soll, wird sie sich eine neue Methode zur Bereitstellung der Infrastruktur ausdenken und einen Servicekatalog einrichten, aus dem Kunden neue virtuelle Maschinen anfordern können, die nun in der Cloud bereitgestellt werden. Außerdem werden Sie umfangreiche Netzwerkarchitekturen und eine Menge Komplexität sehen, weil sie versuchen, ihre aktuellen Systeme mit Hilfe der Cloud-Infrastruktur zu implementieren, was ganz anders ist, wenn man den maximalen Nutzen aus der Cloud ziehen will.

Dies sind zwei Beispiele von vielen anderen Perspektiven. Sind sie falsch? Das glauben wir nicht. Wir sind jedoch der Meinung, dass diese Ansätze suboptimal sind und hohe Kosten und eine geringe Kapitalrendite verursachen werden. Um dies zu verhindern, sollte eine Antwort auf die Frage gegeben werden: Welche Migrationsstrategie trägt zu den Geschäfts- und IT-Zielen Ihres Unternehmens bei? Mit anderen Worten: Was ist der Business Case für die Migration einer Anwendung in die Cloud?

Von CAPEX zu OPEX

Die Cloud ist ein echter Game Changer. Nicht nur aus technischer Sicht, sondern vor allem auch aus wirtschaftlicher Sicht. In der Vergangenheit musste ein Unternehmen erhebliche Summen ausgeben, um einen wettbewerbsfähigen Online-Dienst zu starten. Diese Kapitalkosten (CAPEX) sind jedoch größtenteils weggefallen, und alle Kosten verlagern sich auf die Betriebskosten (OPEX). Das liegt daran, dass Sie nicht in Hardware investieren müssen, sondern stattdessen den Cloud-Anbieter für die von Ihnen genutzten Ressourcen bezahlen. Das ist der On-Demand- und Pay-As-You-Go-Charakter der Cloud. Aus diesem Wandel lassen sich zwei Kräfte ableiten, die von unseren Kunden verlangen, dass sie die Art und Weise, wie Software bereitgestellt wird, ändern. Die erste Kraft betrifft die unabhängigen Softwareanbieter (ISVs), die jetzt aufgefordert werden, ihre Software-as-a-Service anzubieten, weil ihre Kunden das gleiche Modell für die Software wünschen, die sie kaufen, wie sie es jetzt mit der Hardware in der Cloud tun. Die zweite Kraft betrifft Unternehmen, die ihre Betriebskosten senken wollen, und eine Möglichkeit, dies zu erreichen, ist die Nutzung der Cloud. Viele Unternehmen geben in ihren Plänen an, vollständig in die Cloud zu wechseln und ihre eigenen Rechenzentren abzuschaffen. Das hört sich zunächst sehr lukrativ an, aber manchmal vergisst man, dass es wirtschaftlich überhaupt nicht vorteilhaft ist, einfach nur Ihre vorhandenen Maschinen auf Maschinen in der Cloud zu verlagern. Ihre Gesamtkosten werden wahrscheinlich viel höher sein.

CAPEX = Capital Expenditures, Investitionskosten für die Entwicklung eines Systems

OPEX = Operational Expenditures, die wiederkehrenden Kosten bei der Nutzung eines Systems

Wie gehen Sie richtig mit der Cloud um?

Zunächst einmal müssen Sie verstehen, dass der Wechsel in die Cloud keine Einheitsgröße für alle ist. Wenn Sie beispielsweise der im vorigen Absatz erwähnte ISV sind, müssen Sie sich Ihre aktuelle Software ansehen und die Kosten ermitteln, die entstehen, wenn Sie diese Software jetzt selbst hosten. Sie werden nun mit den Kosten konfrontiert, die Ihren Kunden entstanden sind. Diese Kosten sollten Sie für jeden Kunden, den Sie haben, nachvollziehen. Sie müssen sich ansehen, in welchem Zustand sich die Software befindet und in welchem Teil des Lebenszyklus sie sich befindet. Wurde sie gerade erst entwickelt, ist sie schon lange auf dem Markt und muss bereits erheblich überarbeitet werden, oder handelt es sich um ein Produkt, das sich am Ende seines Lebenszyklus befindet und für das Sie eine Möglichkeit benötigen, SaaS anzubieten, aber nicht investieren wollen?

Je nach Lebenszyklusphase Ihrer Anwendung können Sie diese auf ein Cloud-Migrationsstrategie-Modell wie das Gartner 5-R-Modell(Rehost, Refactor, Revise, Rebuild, Replace), das Azure 5-R-Modell oder das AWS 6-R-Modell projizieren. Diese "R"-Modelle besagen, dass Sie sich für eine dieser Strategien entscheiden müssen, und zwar auf der Grundlage der Cloud-Migrationsziele Ihres Unternehmens sowie der Anforderungen und Beschränkungen der jeweiligen Anwendung.

Um die Optionen, aus denen Sie wählen können, zu entmystifizieren, werden die Strategien der verschiedenen "R"-Modelle in der folgenden Tabelle kombiniert und erläutert.

Nachdem Sie sich für eine der Strategien entschieden haben, müssen Sie sich zwei Faktoren ansehen. Der erste Faktor sind die Investitionskosten, wenn Sie sich für Rehost, Refactor, Rebuild oder Replace entscheiden. Bei all diesen Strategien müssen Sie in Ihre Lösung investieren, bevor Sie sie in der Cloud betreiben können. Als nächstes müssen Sie die Betriebskosten für den Betrieb dieser Anwendung in der Cloud über die nächsten 5 Jahre betrachten. Daraus ergibt sich ein Diagramm, das Ihnen den Gesamtbetrag zeigt, den Sie in den nächsten 5 Jahren ausgeben werden, wenn Sie eine bestimmte Strategie wählen.

Um Ihnen eine Vorstellung vom Ergebnis dieses Ansatzes zu geben, geben wir Ihnen ein Beispiel für einen der Fälle, die wir in der Praxis gesehen haben. Das folgende Diagramm zeigt eine 5-Jahres-Darstellung der Kapital- und Betriebskosten eines Produkts, das in die Cloud verlagert werden sollte. Die Problemstellung, die es in diesem Fall zu beantworten galt, lautete: Wie können wir unser Produkt so schnell wie möglich in die Cloud verlagern und dabei die Kapitalkosten so gering wie möglich halten und gleichzeitig die Betriebskosten für den Betrieb des Produkts für unsere Kunden auf lange Sicht kosteneffizient halten.

Für diesen speziellen Fall wurde eine Schätzung der Anzahl der Nutzer des Produkts in jedem Jahr und der erforderlichen Änderungen am Produkt für jede Strategie vorgenommen.

Wenn Sie sich dieses Diagramm ansehen, sehen Sie, dass eine Rehost-Strategie im Falle dieses Produkts eine geringe Anfangsinvestition (Capex) hat, aber die Betriebskosten lassen die Gesamtkosten linear ansteigen. Das liegt an den Kosten für die benötigten virtuellen Maschinen, die jedes Jahr genutzt werden.

Die Refactor-Strategie konzentriert sich auf die Änderung des Produkts, um es mandantenfähig zu machen, was ressourcenschonender ist als eine Rehost-Strategie. Dies ist ressourceneffizienter als eine Rehost-Strategie, da das Produkt nicht mehr für jeden Kunden eigene Ressourcen benötigt.

Die Rebuild-Strategie wird die höchsten Anfangskosten verursachen, da die erforderlichen Änderungen am Produkt zu berücksichtigen sind. Andererseits sind die jährlichen Betriebskosten aufgrund der optimalen Nutzung nativer Cloud-Dienste relativ gering, so dass keine Serverwartung anfällt.

Bei der Replace-Strategie wird das Produkt durch eine Software-as-a-Service-Lösung ersetzt. Dies ist ein interessantes Szenario aus der Kostenperspektive. Das Abonnement für das Produkt wird jede Periode bezahlt. Die wichtige Frage ist hier, ob das Produkt ein strategisches Unterscheidungsmerkmal ist. Mit anderen Worten: Trägt das Produkt zur Innovation und Differenzierung des Produkts gegenüber der Konkurrenz bei.

Mit Blick auf die Problemstellung stellt sich die Frage: Wann ist es wirtschaftlich sinnvoll, die Investition in die Veränderung des Produkts zu tätigen, so dass sich die Investition langfristig amortisiert.

Sie sehen, dass die Rebuild-Strategie das beste Betriebskostenmodell hat. Nach der Anfangsinvestition steigt die Kostenlinie im Vergleich zu den anderen Kostenlinien kaum noch an. Letztendlich wird sie die billigste sein, aber die Kapitalrendite wird aufgrund der hohen Anfangskosten einige Jahre dauern. Ein weiterer Nachteil ist, dass die Zeit bis zur Markteinführung des Produkts im Vergleich zu Strategien, die weniger bedeutende Änderungen erfordern, länger ist. Wenn Sie nur das Lift-and-Shift-Verfahren anwenden, werden Sie feststellen, dass es innerhalb eines Jahres teurer wird als die Umgestaltung der Anwendung zur Unterstützung der Mandantenfähigkeit. Das letztere Szenario ist billiger, weil eine Instanz der Anwendung mehreren Kunden zur Verfügung steht, während eine dedizierte Anwendung nur einen einzigen Kunden bedient.

Anhand dieses Diagramms könnten Sie eine Strategie ableiten, bei der Sie zunächst mit einem Lift-and-Shift beginnen, dann die Investition für Multi-Tenancy (Refactor) starten und dann auf Cloud-Native umstellen. Da es wahrscheinlich nicht sehr sinnvoll ist, Refactor und Rebuild gleichzeitig durchzuführen, sollten Sie ein Szenario wählen, bei dem Sie nach Optionen für eine schrittweise Umstellung auf ein vollständig cloud-natives Produkt suchen.

Der Hauptvorteil dieses Beispiels ist, dass diese Art der Bewertung von Anwendungen eine Reihe möglicher Szenarien ergibt und Ihnen einen Einblick in einen harten Business Case gibt, um die Investition zu tätigen und die beste Strategie zu bestimmen.

Die Perspektive eines Unternehmens

Wenn Sie in einem Unternehmen tätig sind, können Sie diese Art von Bewertung ebenfalls vornehmen. Der Unterschied besteht jedoch darin, dass Sie sich mit einem Portfolio von Anwendungen befassen müssen. In diesem Fall ist es am besten, wenn Sie die Anwendungen zunächst grob in drei Kategorien unterteilen.

• Sonderanfertigungen
• Von einem Partner maßgefertigt
• Standardmäßig und vor Ort gehostet

 

Die Kategorie Custom-built umfasst Software, die entwickelt wurde, um für das Unternehmen etwas zu bewirken. Gartner bezeichnet diese Systeme als "Systems of Innovation". Diese Systeme können genau so bewertet werden, wie wir es für den ISV beschrieben haben, und Sie können daraus die besten Szenarien auswählen.

Die Kategorie Von einem Partner maßgeschneidert umfasst die Systeme der Differenzierung, bei denen Sie oft eine Teillösung von der Stange kaufen, diese aber vollständig an die Bedürfnisse des Unternehmens anpassen. Diese Systeme können auch in die Cloud verlagert werden. In diesem Fall bitten Sie oft den Partner, der das Produkt entwickelt hat, sich darum zu kümmern.

Die Kategorie "von der Stange" bedeutet normalerweise "Systems of Record". Das sind die Systeme, die Sie brauchen, aber jeder hat die gleichen und sie sind nur dazu da, um sicherzustellen, dass Sie Ihr Geschäft betreiben können. Es gibt keine Möglichkeit, sich einen Vorteil zu verschaffen, indem Sie dies anders machen als Ihr Konkurrent. In dieser Kategorie können Sie oft einfach auf die Software-as-a-Service-Lösung des Anbieters umsteigen.

Wie beurteilen Sie die Anwendungen, die Sie verschieben werden?

Bei der Bewertung von Anwendungen, die in die Cloud verlagert werden sollen, müssen diese auf mehreren Ebenen bewertet werden. Wie bereits erwähnt, ist es wichtig, die aktuelle Phase im Lebenszyklus der Anwendung zu bestimmen. Die nächste Frage lautet: Wohin wollen wir mit diesem Produkt gehen? Früher war es vielleicht ein "System der Innovation", aber inzwischen hat es jeder Konkurrent auch. Das ist der Moment, in dem Sie sich entscheiden, es durch eine SaaS-Lösung zu ersetzen. Wenn das System immer noch differenzierend oder innovativ sein wird, ist es sinnvoll, die Szenarien Rehost, Refactor und Rebuild zu betrachten. In der Praxis bedeutet dies, dass die Initiative zur Cloud-Transformation es Ihnen ermöglicht, die strategische Bedeutung der Anwendungen im Portfolio zu überdenken und schrittweise in die Cloud zu migrieren. Die folgende Abbildung zeigt den Ablauf der Bewertung.

 

Cloud-Übergänge richtig gemacht

Bei der Betrachtung von Cloud-Migrationsstrategien gibt es keine einzelne Strategie, die für alle Anwendungen im Portfolio eines ISV oder eines Unternehmens geeignet ist. Es ist eine Mischung aus verschiedenen Ansätzen erforderlich, die auf dem Wert, den eine Anwendung liefert, und den Kosten (Investitionen und Betriebskosten) der gewählten Strategie basieren. Da diese Strategien in hohem Maße von der jeweiligen Situation, der Anwendung und der Art der Kosten abhängen, gibt es keine Einheitslösung für alle.

In diesem Artikel haben wir einen Ansatz beschrieben, wie Sie einen Business Case für Ihre Anwendungen erstellen, wenn Sie diese in die Cloud verlagern. Wenn Sie Ihr Entwicklungsteam fragen, werden Sie eine andere Lösung erhalten als wenn Sie Ihr Betriebsteam fragen. Der Hauptunterschied besteht darin, dass wir die wirtschaftliche Perspektive hinzugefügt haben. Dies ermöglicht es Ihnen, eine ausgewogene Sichtweise für die Umstellung zu erstellen und die Kosten und Vorteile vorherzusagen.