Lift-and-Reshape-Strategie Vom Business-Case zum erfolgreichen Replatforming

Anbieter zum Thema

Hyland Software Germany GmbH

Flexera Software GmbH

STACKIT - Schwarz Digits Cloud GmbH & Co. KG

Veraltete IT-Infrastrukturen bergen häufig Risiken hinsichtlich Stabilität und Sicherheit. Die Gefahr: ein Totalausfall. Um dies zu verhindern, sollten Unternehmen ihre Plattformen regelmäßig überprüfen, hinterfragen und unter Umständen ersetzen.

Für moderne, funktionale und sichere IT-Lösungen müssen nicht direkt ganze Infrastrukturen neu geschaffen werden. Mit bestehenden Tools und Technologien lässt sich schon viel bewirken. Gleichzeitig kann die Integration und der Einsatz einzelner zusätzlicher Services große Wirkung zeigen.

Ab einem bestimmten Punkt werden trotzdem einschneidende Veränderungen notwendig, um die gewünschten Effekte zu erzielen – ganz gleich ob nun mehr Leistungsfähigkeit, Stabilität oder Sicherheit. Bei solchen umfassenden Replatforming-Prozessen sollten Entwicklerinnen und Entwickler daher auf folgende Punkte achten:

Schrittweise Umsetzung für besseres Troubleshooting

Eine Systemlandschaft besteht aus diversen Komponenten: zentrale Backoffice-Komponenten, wie z.B. ERP- und PIM-Systeme, die jeweilige Plattform selbst mit all ihren Komponenten und zusätzlich angeschlossene Drittsysteme.

Steht ein Replatforming-Prozess an, wird dieser oft aus dem Business-Operations-Bereich getrieben. Dahinter steht meist der Wunsch, direkt weitere Systeme auszutauschen oder neue Funktionen hinzuzufügen. So wäre gleich alles auf einmal erledigt.

Doch gerade bei komplexen Veränderungen kann es zu Problemen bei der Integration kommen. Zu viele „Moving Targets“ erhöhen die Komplexität des Projekts. So werden die Fehleranalyse und die Antizipation von Problemen bei der Integration noch schwieriger. Durch eine schrittweise Implementierung können Entwickler und Entwicklerinnen eventuelle Fehler schneller lokalisieren und beheben.

Realistische Ziele setzen

Natürlich spiegelt das perfekte Replatforming selten den Business-Alltag wider. Sorgfältiges, schrittweises Vorgehen kostet mehr Zeit und kollidiert so mit ambitionierten Go-to-Market-Vorstellungen. Trotzdem sollte hier priorisiert und systematisch vorgegangen werden. Dazu müssen zunächst kritische Problempunkte der Infrastruktur identifiziert werden.

Sind keine Updates von Komponenten zur Sicherstellung des reibungsfreien Betriebs mehr möglich bzw. erfordern zu viel Aufwand oder ist das System aus technologischer Sicht nicht mehr zu verantworten, muss gehandelt werden. Darauf folgt eine Evaluation der technischen Optionen, um die bestehende Infrastruktur sinnvoll zu modernisieren und erweitern. Hier sollte neben den definierten Business-Anforderungen auf einen stabilen und sicheren Betrieb geachtet werden.

Gleichzeitig spielen auch die Kosten eine Rolle. Bestimmte Kernkomponenten wie ERP-Systeme sind in der Regel kostspielig und basieren auf Lizenzmodellen mit entsprechenden Laufzeiten, weshalb es sich üblicherweise nicht rechnet, mehrere davon gleichzeitig im Einsatz zu haben, um denselben Funktionsbereich abzudecken.

Auf einfache Implementierung achten

Ist die Entscheidung hinsichtlich der zu adaptierenden Komponenten gefallen, geht es an die Umsetzung. Im günstigsten Fall handelt es sich um eine API-Integration. Hier muss ausschließlich gewährleistet sein, dass die alte Komponente ab- und die neue zugeschaltet werden kann.

Dieser Fall betrifft jedoch auch nur Anwendungen, die keine umfassende Datengrundlage benötigen, sonst muss zusätzlich die Datenmigration vorbereitet werden, um die Datenkonsistenz sicherzustellen und Datenstrukturen anzupassen. Als möglicher Fallback-Plan empfiehlt sich hier häufig ein Parallelbetrieb der neuen und alten Komponente.

Fallback-Strategien schaffen

Mit Blick auf das Deployment im Zuge eines Replatforming empfiehlt sich ebenfalls ein behutsames Vorgehen. In den letzten Jahren – getrieben durch Best Practices in Continuous Integration und Continuous Deployment (CI/CD) – ist ein Ansatz dafür das „Blue/Green-Deployment“.

Auf einem skalierbaren System wird dabei die neue Komponente erst nur für einen kleinen prozentualen Anteil der Benutzer ausgerollt. So lässt sie sich auf das Auftreten möglicher Fehler prüfen. Ist das der Fall, geht man zurück zum alten System. Bei einem reibungslosen Ablauf wird die Verteilung sukzessive ausgeweitet, bis die neue Komponente vollständig ausgerollt ist.

Dieser Ansatz ist jedoch nur in bestimmten Szenarien nutzbar, denn er erfordert spezifische Infrastrukturkapazitäten und Applikationen, die ein entsprechendes Vorgehen erlauben. Alternativ dazu können die Fachkräfte zu Rolling Deployments oder Phased Rollouts greifen.

Wichtig ist dafür, dass der verwendete Load Balancer Benutzerpersistenz unterstützt, damit der dedizierte Nutzer-Traffic stets an denselben Container/Server kommuniziert wird. Nun gibt es Szenarien, in denen kein Parallelbetrieb möglich ist.

Um hier ein möglichst reibungsfreies Replatforming umzusetzen, ist ein klassisches „Staging“ notwendig. Dabei sollte auf eine gute Testabdeckung mit durchdachten Testszenarien und möglichst hoher Testautomatisierung geachtet werden. Die zwei geläufigsten Ansätze für das Testing sind hier „Test Driven Development“ (TDD) und „Test After Development“ (TAD).

Nachdem das Replatforming häufig mit neuen Features einhergeht, müssen zudem Tests auf unterschiedlichen Ebenen durchgeführt werden, etwa Unit-Tests, Integrationstests oder auch End-to-End-Tests. Der Erfolg sämtlicher Tools, auch zur automatischen Aktualisierung von Komponenten, basiert auf einem soliden Testkonzept.

Veränderung als Chance

Beim Replatforming gilt es, den Status quo zu hinterfragen. Dazu gehört es, alle bestehenden Prozesse und Funktionen auf den Prüfstand zu stellen. So riskant solche IT-Projekte sein können – ein Replatforming ist in erster Linie eine immense Chance, festgefahrene Strukturen aufzubrechen und neuen Anforderungen gerecht zu werden.

Wichtig ist eine gute Priorisierung und kritische Analyse, um technologische Verantwortung übernehmen zu können. Hier sind Developer gefragt, ihren Arbeitgebern mögliche Lösungen aufzuzeigen und IT-Strukturen zu schaffen, die ein erfolgreiches, sicheres und störungsfreies Arbeiten ermöglichen.

* Bernd Alter ist Technical Director bei Turbine Kreuzberg. Seit über 15 Jahren beschäftigt er sich bei der Technologieagentur mit der Konzeption und technischen Leitung von Softwareprojekten. Seine Spezialität ist PHP, begleitet von Infrastruktur-Themen (Docker/Kubernetes und Cloud) sowie der Entwicklung von Software- und Systemarchitekturen.

(ID:48156055)