Wolkig mit Aussichten auf Diamanten

Damit eine Anwendung erfolgreich in die Cloud transportiert werden kann, sind nicht nur ihre technischen Parameter und eine funktionierende Infrastruktur entscheidend. Viel entscheidender ist die Berücksichtigung aller Facetten der Software und die Ausrichtung an der Unternehmensstrategie. Durch den adesso-Analyseansatz entsteht ein technisches und fachliches Gesamtbild, das eine nachhaltig erfolgreiche Cloud-Nutzung erst möglich macht.

Im Blog-Beitrag „Wolkig mit Aussichten auf Apps “ wurde das adesso-Vorgehen für die Adaption der Cloud vorgestellt. Bei dieser Vorgehensweise werden Anwendungen analysiert und anschließend in die Cloud migriert oder auch modernisiert. Um zu prüfen, welche Möglichkeiten bestehen, wird im Rahmen der Analyse ein technisches und fachliches Assessment durchgeführt.

Das technische Assessment ist toolbasiert und misst unter anderem Aspekte wie CPU, RAM, Auslastung oder Betriebssystemversion. Viel entscheidender ist das fachliche Assessment, da es zusätzlich die Aufgabe der Software, die Konformität mit den Unternehmensstandards, Kriterien und Pain Points untersucht und die Unternehmensstrategie berücksichtigt.

Für diese fachliche Bewertung wurde das folgende Analyseverfahren entwickelt:

Wie in der Grafik zu erkennen ist, werden sechs verschiedene Facetten der Software von der Unternehmensstrategie beeinflusst (siehe Mitte). Es ist nicht nur entscheidend, wo die Anwendung läuft, sondern auch, wie die Betriebsprozesse aussehen. Es ist nicht nur entscheidend, um welche Software es sich handelt, sondern auch, welche konkrete Aufgabe sie erfüllt. Es ist nicht nur entscheidend, was die Pain Points der Anwendung sind, sondern dass die genutzten Möglichkeiten auch Compliance-konform sind. Nur wenn alle Facetten gleichberechtigt Einfluss nehmen, ergibt sich ein konsistentes Gesamtbild der Anwendung.

Unternehmensstrategie

In der Mitte der Grafik ist die Unternehmensstrategie dargestellt, da sie alle Facetten der Analyse beeinflusst. Sie definiert den Grund für die Cloud, das heißt, welche Ziele mit der Cloud-Adaption verfolgt werden sollen. Die Anwendungen müssen sich diesen Zielen unterordnen bzw. zu ihnen beitragen, auch wenn dies ihren eigenen Anforderungen zuwiderläuft.

Ist es das Ziel, das Betriebsteam zu entlasten und damit höherwertige Dienste und viel Automatisierung zu nutzen, muss dies entsprechend in der Analyse berücksichtigt werden. Kann eine Anwendung keine höherwertigen Dienste nutzen oder nicht von Automatisierung profitieren, sollte sie nicht in die Cloud verlagert werden. Denn sie verursacht bestenfalls die gleichen Betriebskosten wie zuvor und trägt somit nicht zum Geschäftsziel bei, da keine Verbesserung eintritt.

Ist das Ziel, die Kundenbindung zu stärken, kann dies beispielsweise durch einen verbesserten und stabileren Betrieb, eine schnellere Skalierung und auch häufigere Updates mit neuen Features erreicht werden. All diese Punkte lassen sich durch moderne Cloud-Architekturen realisieren. Kann die Software jedoch nicht entsprechend angepasst werden, sollte sie ausgetauscht oder neu entwickelt werden, um besser zur Strategie zu passen.

Zweck der Software

Der Zweck der Software hilft zu beurteilen, warum diese Anwendung benötigt wird, das heißt, welches Problem sie löst. Diese Information ist in Zeiten von vielen Alternativen und SaaS-Diensten wichtig, weil dadurch ein Austausch der Software oft attraktiver wird als eine Migration.

Hat der Kunde beispielsweise eine Backup-Lösung on-premises, so muss diese in der Regel nicht in die Cloud migriert werden, da es dort Backup-Lösungen der Hyperscaler gibt. Handelt es sich um ein angepasstes SAP-System, so gibt es spezielle Migrationspfade und Landing Zones, die genutzt werden sollten. Ist die Anwendung für die Sammlung und Analyse von Daten zuständig, sollte über einen modernen Ansatz nachgedacht werden. So gibt es für die Datenanalyse spezielle Data Mesh-Architekturen und mit Microsoft Fabric oder Purview spezialisierte Tools für Azure. In diesem Fall müssen nur die Daten migriert werden, nicht aber die Anwendung.

Art der Software

Die Art der Software bestimmt den Grad der Anpassungsmöglichkeiten. Bei selbst entwickelter Software sind wesentlich mehr Änderungen möglich als bei gekaufter Software.

Bei selbst entwickelter Software sollte eine kurze Potenzialanalyse durchgeführt werden, ob Cloud-Vorteile genutzt werden können. Wenn die Modernisierung Vorteile für die Cloud bringt und strategisch gewünscht ist, kann ein Modernisierungskonzept erstellt werden. Dieses beschreibt in der Regel verschiedene Anpassungsschritte mit den jeweiligen Kosten und Potenzialen. Dies ermöglicht es dem Kunden, das gewünschte Zielbild genau auszuwählen. Diese Konzepte erfordern einen erheblichen Analyseaufwand, da Interviews mit den beteiligten Teams geführt werden müssen und die Software durch einen Re-Architekten neu geschnitten wird. Auch wenn diese Analyse zeit- und kostenintensiver ist, ist der Mehrwert enorm. Gerade bei Anwendungen, die direkt die Wertschöpfung des Unternehmens beeinflussen, lohnt sich ein solcher Schritt oft.

Bei gekaufter Software sind die Möglichkeiten deutlich eingeschränkter. Oft sind automatische Skalierungen und Verbesserungen im laufenden Betrieb möglich, aber meist keine Umstellung auf Microservices oder Serverless-Technologien. Höherwertige Dienste von Hyperscalern lassen sich jedoch häufig einbinden und durch einfache Konfiguration integrieren. Dieser Schritt spart Infrastruktur und Betriebsaufwand. Zudem kann bei gekaufter Software gut mit Analyse- und Migrationswerkzeugen gearbeitet werden, was den Prozess beschleunigt.

Kriterien

Kriterien sind nicht-funktionale Anforderungen, die die Qualitätsmerkmale der Software bestimmen. Sie können sich im Laufe der Zeit geändert haben und sollten daher neu erfasst oder geprüft werden. Einige Kriterien haben wenig Einfluss auf die Architektur, beispielsweise die Benutzbarkeit, und werden daher nur in Ausnahmefällen geprüft. Andere Kriterien bestimmen die zukünftige Lösung sehr stark, zum Beispiel Effizienz oder Wartbarkeit.

Das Kriterium Effizienz beschreibt das Verhalten des Systems bei Laständerungen. So sollen oft nur so viele Ressourcen wie nötig in Anspruch genommen werden. Trotzdem muss bei vielen Anfragen eine schnelle Reaktion erfolgen und entsprechend automatisch neue Ressourcen bereitgestellt werden.

Zuverlässigkeit fasst die Anforderungen an einen stabilen Betrieb zusammen. Die Software soll eine entsprechend hohe Verfügbarkeit bieten und auch bei Ausfall von Teilkomponenten problemlos weiterarbeiten beziehungsweise neu starten können.

Sicherheitsaspekte zielen unter anderem darauf ab, den Zugriff zu verbessern, indem beispielsweise eine Legacy-Anwendung mit einer MFA-Authentifizierung versehen wird oder der Datenverkehr zusätzlich verschlüsselt wird. Auch die Nachvollziehbarkeit von Änderungen, zum Beispiel für Audits, gehört dazu.

Ein häufiger Grund für die Migration in die Cloud ist die bessere Wartbarkeit. Diese kann durch das Aufbrechen eines Monolithen oder auch durch den Umstieg auf höherwertige Dienste erreicht werden, die eine entsprechende Entlastung bei der Wartung bieten. Auch ein höherer Automatisierungsgrad kann zu einer besseren Wartbarkeit beitragen.

Für viele Kunden ist eine hohe Portabilität wichtig. Sie wollen einen Vendor Lock-in vermeiden und in kurzer Zeit von einem Hyperscaler zu einem anderen oder zu on-premises wechseln. Höherwertige Services werden dann kaum genutzt, sondern eher Container und die entsprechenden Managed Kubernetes Services der Cloud-Dienstleister.

Compliance

Wie bei den Kriterien können sich auch die Compliance-Anforderungen geändert haben. Bei dieser Facette geht es nicht nur darum, die bisherige Compliance zu verstehen und zu prüfen, ob diese weiterhin eingehalten werden muss. Es geht auch darum, die Anwendung an die neuen Compliance-Anforderungen anzupassen, die durch die Cloud-Adaption entstanden sind.

Wie muss beispielsweise das neue SLA für die Applikation in Kombination mit den Cloud Landing Zones und den SLAs der Cloud Services aussehen? Welche Richtlinien gelten für die Anwendungen in der Cloud, zum Beispiel kein öffentlicher Zugriff und nur Regionen in Europa? Welche Anforderungen werden an das Disaster Recovery gestellt? Die Anforderungen sind für jeden Kunden sehr unterschiedlich und können aus den verschiedensten Bereichen kommen, etwa Security, Fachbereich, Betrieb etc. Auch wenn es in der Regel nicht so viele maßgebliche Anforderungen gibt, muss die Anwendung diese in jedem Fall erfüllen, wodurch sie einen großen Einfluss auf den Lösungsraum haben.

Umgebung

Beim Thema Umgebung wird sowohl die bestehende als auch die zukünftige Umgebung analysiert. Soll die Anwendung zukünftig in der Azure Cloud laufen, können entsprechende Services des Hyperscalers Microsoft genutzt werden. Häufig wird auch die Nutzbarkeit von Cloud-nativen Diensten wie Functions und App Service in Azure geprüft. Ist die Zielumgebung ein OpenShift Cluster, wird die Nutzbarkeit von Tools wie Red Hat Advanced Cluster Security oder Argo CD geprüft. Auch die bestehenden Rahmenbedingungen durch die Landing Zones, beispielsweise die Bandbreite bei der on-premises Anbindung, haben Einfluss auf die Lösungsbausteine.

Die vorhandene Umgebung ist vor allem für die Toolauswahl relevant. Je nach Umgebung können Tools der Hyperscaler oder von Drittanbietern sinnvoll eingesetzt werden. Sie helfen bei der Analyse und können später auch Migrationen durchführen. Beispielsweise kann die Analyse von VMWare-Umgebungen direkt mit Tools von AWS und Azure durchgeführt werden. Weitere Tools, zum Beispiel speziell für die Analyse von Datenbanken, sind häufig sogar automatisch integriert oder können zusätzlich eingesetzt werden.

Infrastruktur und Betrieb

Auch hier lohnt sich ein analytischer Blick, ob die bisherigen Betriebsabläufe und die Infrastruktur übernommen oder angepasst werden können. Einerseits sollen bewährte Konzepte beibehalten werden, andererseits kann eine Anpassung notwendig sein.

Oft wird bei der Migration nur auf die technische Machbarkeit geachtet, nicht aber auf den Betrieb. Hier geht es zum einen um das Betriebsteam und deren Möglichkeiten, d.h. ob alle Services eines Hyperscalers genutzt werden können oder ob noch ein entsprechendes Onboarding notwendig ist. Zum anderen sind damit die Prozesse im Betrieb gemeint, die über die On-Premise-Welt hinaus in die Cloud ausgedehnt werden müssen. Hier können Kooperationen mit anderen Dienstleistern oder anderen Betriebsteams notwendig sein.

Die Infrastruktur betrachtet den eigentlichen Aufbau der Anwendung. Hat die Software einen Datenbank-Cluster? Hat sie mehrere Front-End-Server, die hinter einem Load-Balancer stehen? Die technische Analyse kann dazu Details liefern, aber oft nicht, warum die Infrastruktur so aufgebaut wurde, wie die Kommunikationsflüsse und Verantwortlichkeiten sind und welche Pain Points es mit dem aktuellen Aufbau gibt. Diese Punkte gilt es zu hinterfragen und bei einer möglichen Transformation in die Cloud entsprechend zu verbessern oder ggf. auch sinnvoll wiederzuverwenden.

Fazit

Um eine Anwendung erfolgreich in die Cloud zu bringen, ist eine ganzheitliche Analyse erforderlich. Sie muss sowohl die technischen und prozessualen Details der Anwendung selbst, die Vorgaben des Unternehmens als auch die zukünftige Umgebung berücksichtigen. Die Unternehmensstrategie sollte dabei immer oberstes Ziel sein und alle betrachteten Facetten beeinflussen. Denn nur wenn die Unternehmensstrategie und alle Facetten der Anwendung berücksichtigt werden, kann ein sehr gutes Zielbild abgeleitet werden.