Den Status quo der App-Modernisierung festhalten

Für den Start hat es sich bewährt, sich an zwei zentralen Einflussfaktoren zu orientieren und die bestehende Applikationslandschaft Schritt für Schritt anhand dieser zu bewerten.

1. Die absehbare Komplexität einer Migration spielt bei der Entscheidung des Modernisierungs- und Migrationszeitpunkts die erste wichtige Rolle. Diese kann beispielsweise anhand vieler technischer Faktoren wie der Anzahl und Art der Abhängigkeiten abgeschätzt werden. Ebenso wichtig ist die Art der bisher eingesetzten Technologien sowie die Eingliederung in die unternehmensweite Architektur.
2. Darüber hinaus ist die Relevanz der Applikation für die Fachbereiche Zentrale Applikationen werden oft vereinfacht als Business-kritisch bezeichnet. Zu einer fundierten Einschätzung kommen IT-Entscheider bestenfalls über den direkten Austausch mit den Fachbereichen. Detaillierte Interviews haben sich dafür als vielversprechend erwiesen. Gleichzeitig räumt man damit den Fachbereichen die Möglichkeit ein, sich aktiv in den Change-Prozess einzubringen und diesen mitzugestalten. Ein positiver Nebeneffekt: aus Betroffenen werden Beteiligte.

Die Ergebnisse dieser Analysen und Experteninterviews können durch Abhängigkeiten technologischer, organisatorischer oder wirtschaftlicher Natur schnell sehr komplex und unübersichtlich werden. Die nun zu lösende Aufgabe besteht darin, eine Priorisierung vorzunehmen, um den Projekterfolg sicherzustellen. Dies erfolgt häufig anhand der einfachen Zuordnung der Applikationen wie in der folgenden Abbildung beispielhaft zu sehen ist:

Angelehnt an das Eisenhower-Prinzip kann man anschließend diese Liste in eine Matrix mit vier Quadranten überführen. Anhand dieser kann nun entschieden werden, mit welchem Quadranten begonnen werden soll. In diesem sehr einfachen Beispiel mit vier Applikationen ergibt sich folgende Matrix:

Der Einfachheit halber passen die Applikationsnamen zur empfohlenen Reihenfolge der Migration. Der Sinn hinter dieser Reihenfolge ist einfach erklärt: Man muss davon ausgehen, dass im Zuge der Modernisierung Fehler passieren, denn das ist menschlich und absolut normal. An diesem Punkt ist es wichtig, das potenzielle negative Ausmaß bereits vorab zu bemessen. Werden zu Beginn der Modernisierungen noch viele Fehler gemacht, wird sich die Anzahl dieser mit zunehmender Erfahrung reduzieren. Dementsprechend sollten Unternehmen mit Applikationen beginnen, bei welchen der negative Einfluss von Fehlern möglichst gering ist, sprich mit Applikationen, die nicht Business-kritisch sind. Gleichzeitig lernt man am besten mit einfachen Problemen, die Schritt für Schritt komplexer werden, weshalb mit einfach zu migrierenden Applikationen begonnen werden sollte. Mit diesem Vorgehen können Unternehmen mit einem möglichst optimalen Ertrags-Risiko-Verhältnis schrittweise an die Modernisierung und Migration ihrer Applikationslandschaft herangehen.

Doch wie könnte ein mögliches Zielbild aussehen? Eine häufige Ausgangsbasis für Modernisierungs- und Migrationsprojekte sind monolithische Anwendungslandschaften. Bei der Modernisierung dieser wird häufig eine Microservices-Architektur angestrebt. Für den Betrieb von Cloud-Native-Anwendungen hat sich Kubernetes als Standard etabliert, welcher von der Cloud Native Computing Foundation (CNCF) weiterentwickelt wird. In diesem Umfeld haben sich viele Anbieter darauf konzentriert, die Entwicklung und den Betrieb von Cloud-Native Anwendungen für Enterprise Workloads zu optimieren. Red Hat OpenShift ist dabei eine sehr verbreitete Lösung, welche die Komplexität reduziert, den Betrieb vereinfacht und Unternehmen dabei unterstützt, ihre Business-kritischen Anwendungen sicher und compliant auf Kubernetes zu betreiben – On-Prem, in der Cloud oder auch hybrid.

Um die Vorteile von Cloud-nativen Architekturen auch realisieren zu können, ist die Cloud meist ein zentraler Enabler. Mit Azure Red Hat OpenShift (ARO) haben Microsoft und Red Hat nach jahrelanger Zusammenarbeit auch dafür eine gemeinsame Lösung. ARO ist ein Managed-PaaS-Dienst für Red Hat OpenShift in der Azure Cloud, der gemeinsam von beiden Technologieanbietern entwickelt und für Kunden betrieben wird. Der Support wird ebenfalls gemeinsam übernommen. Für Hybridszenarien kann beispielsweise auch Azure ARC mit Red Hat OpenShift zusammen genutzt werden.

Die letzte zentrale Frage, die sich Unternehmen stellen müssen, ist, ob sie diesen Weg aus eigenen Mitteln bewerkstelligen können oder ob sie sich externe Expertise einkaufen wollen. Bei fehlender Kapazität oder Wissen empfiehlt sich sicherlich die Zusammenarbeit mit externen Experten, die auch schon früh im Projekt eine Orientierungshilfe sein können. Den Kontakt zu diesen Partnern stellen Red Hat oder Microsoft gerne her!

* Dominik Bergmann ist Partner Development Manager bei Microsoft, Patrick Melchner ist Technology Strategist bei Microsoft