Die agile Migration von Applikationen

In unserer dynamischen und komplexen Welt lassen sich Software-Entwicklungsprojekte nur bedingt planen, denn oftmals verändern sich Anforderungen, neue kommen hinzu und bestehende verlieren an Bedeutung. Es ergibt also viel Sinn, Anwendungen iterativ zu entwickeln und in Betrieb zu nehmen. Bei der Entwicklung einer neuen Software funktioniert das in vielen Unternehmen sehr gut, aber wie funktioniert es bei der Ablösung einer vorhandenen Software? Was ist das sogenannte Minimal Viable Product bei der Ablösung einer Applikation und wie gelingt das agile Migrieren einer solchen Applikation?

Das MVP bei der Ablösung einer Applikation

Die agile Software-Entwicklung geht generell in Schritten vor. Als erstes wird das Minimum Viable Product (MVP) realisiert. Es stellt ein kleines, bereits funktionsfähiges Set der zu entwickelnden Software dar. Davon ausgehend wird die Software iterativ weiterentwickelt, stets mit dem Gedanken, dass sie voll lauffähig und produktiv einsetzbar sein soll. Durch dieses schrittweise Vorgehen kann die Software sehr zielgerichtet anhand der aktuellen Kundenanforderungen entwickelt werden und so entsteht frühzeitig echter Nutzen für die Kunden.

Bei der Ablösung einer vorhandenen Applikation ist die Situation jedoch eine andere: Die Anwendung wurde bereits entwickelt und Kundenbedürfnisse bzw. -anforderungen müssen nicht erst erhoben werden. Da aber die meisten Applikationen aktiver Bestandteil einer Applikationslandschaft sind, ist es sehr schwierig, mit einem Minimal Viable Product anzufangen und dieses iterativ zu erweitern. Darüber hinaus müssen Sie bei der Ablösung einer Applikation darauf achten, dass die vorhandenen Funktionalitäten auch mit der neuen Applikation wieder zur Verfügung stehen. Und auch die Schnittstellen zu umliegenden Systemen sind für das Funktionieren der Gesamtprozesse oft unverzichtbar.

Ist also ein iteratives Vorgehen bei der Ablösung einer vorhandenen Applikation unangebracht? Wäre vielleicht sogar eine klassische Ablösung mit der Wasserfallmethode besser geeignet? Tatsächlich eignet sich ein klassischer Projektmanagement-Ansatz bei der Ablösung einer vorhandenen Lösung, denn viele Anforderungen stehen bereits vor Projektbeginn fest. Wie lässt sich aber nun der Nutzen der neuen Applikation frühzeitig und nicht erst zum Projektende realisieren? Um bei einem Migrationsprojekt iterativ vorzugehen, müssen Sie Funktionsblöcke identifizieren, die für sich lauffähig sind und aufeinander aufbauend entwickelt werden können. Hierin liegt die intellektuelle Herausforderung bei der agilen Migration.

Das agile Migrieren

Bei einem agilen Migrationsprojekt verfolgen Sie die Idee, die ersten Versionen der neuen Applikation parallel zur vorhandenen Applikation zu betreiben. Anwendungsfälle, die sich mit den ersten Blöcken von Funktionalitäten realisieren lassen, laufen auf der neuen Applikation anstatt auf der vorhandenen. Kompliziertere Anwendungsfälle verbleiben solange auf der Bestandsapplikation, bis die hierfür nötigen Funktionalitäten in der neuen Applikation vorhanden sind. Diese entwickeln Sie entsprechend den Funktionsblöcken iterativ und setzen sie kontinuierlich produktiv. Auf diese Weise können Sie iterativ Anwendungsfälle migrieren und profitieren frühzeitig vom Nutzen der neuen Applikation.

Natürlich erfordert dieses Vorgehen, dass Sie sich Gedanken über den Parallelbetrieb der alten und neuen Applikation machen. Sich müssen sich bspw. überlegen, was passiert, wenn ein ehemals einfacher Anwendungsfall migriert wurde, dann aber unerwartet zu einem komplizierteren wird, der noch nicht umgesetzt ist. Und was passiert bei Abhängigkeiten von Daten in der neuen und der alten Applikation? Wie Sie solche Herausforderungen lösen, lässt sich nur im konkreten Einzelfall klären.

Ein Beispiel für eine agile Migration

Gerne möchte ich Ihnen von einem konkreten Beispiel aus meiner Arbeit bei idealo, Deutschlands großem Preisvergleich und Shoppingportal, berichten. idealo importiert täglich rund eine Milliarde Angebotsdaten von Online-Händlern. Da die Datenmengen jedes Jahr kontinuierlich steigen, wurde absehbar, dass die verwendete Datenbank einer Import-Applikation sich bald nicht mehr sinnvoll skalieren lassen würde. Die Datenbank war am Rande ihrer Leistungsfähigkeit angelangt und die Entwicklung einer neuen Applikation mit einer optimierten Importlogik wurde unausweichlich. Als besondere Herausforderung mussten wir unzählige, komplizierte Funktionalitäten für individuelle Händler realisieren, die zusätzlich noch in vielfältige Prozesse eingebettet waren. Uns war nicht klar, wann die überlastete Datenbank ihren Geist aufgeben würde, aber dieses Katastrophen-Szenario galt es auf jeden Fall zu vermeiden.

Wie sind wir nun bei der agilen Migration vorgegangen? Wir begannen, Funktionalitäten der Anwendung in Blöcke zu schneiden. Dies war für uns die größte Herausforderung. Wir entschieden uns dafür, die Funktionalitäten entsprechend ihrer Nutzung durch unterschiedliche Händlergruppen zu trennen. Beispielsweise gibt es deutsche Händler, die ihre Waren auch nach Österreich versenden, so dass deren Angebote inklusive der entsprechenden Lieferbedingungen und der geltenden Mehrwertsteuer sowohl auf der deutschen also auch auf der österreichischen idealo-Seite verfügbar sein mussten. Die Realisierung dieser Funktionalität wurde für einen späteren Funktionsblock eingeplant. Im Gegenzug konnten wir bereits die deutschen Händler auf die neue Applikation migrieren, die ihre Waren innerhalb Deutschlands, aber nicht nach Österreich versenden.

Ein weiterer Funktionsblock drehte sich um Varianten von Angeboten, also beispielsweise Handys, die optional in verschiedenen Farben und mit unterschiedlichen Speicherausstattungen verkauft werden. Auch das Importieren von Varianten wurde für einen späteren Block von Funktionalitäten eingeplant. Zuvor konnten wir bereits Händler importieren, die keine Varianten in ihren Angeboten verwendeten.

Die Test-Automatisierung

Bei ca. 560.000 Händlern ist es in der Praxis gar nicht so einfach, die benötigten Funktionsblöcke einzelner Händler zu identifizieren. Was würde passieren, wenn ein Händler, der bis dato ohne Angebotsvarianten gearbeitet hatte, nun doch welche verwenden wollte? Möglicherweise hätten wir seine Daten bereits auf die neue Applikation migriert, die aber den Umgang mit Varianten noch nicht umgehen konnte. Um solche Herausforderungen zu meistern, haben wir ungefähr ein Drittel unserer Gesamtaufwände in Tests und deren Automatisierung investiert.

Der eigentliche Prozess der Migration wurde vollautomatisiert durchgeführt. Dabei umfasste unser Setup zwei Teststrecken: die alte und die neue Importstrecke. Jeder Händler wurde parallel über den alten und den neuen Import bearbeitet und die Ergebnisse beider Importe wurden miteinander verglichen. Gab es keine unerklärbaren Abweichungen, wurde der Händler automatisch auf die neue Import-Applikation umgestellt. Auf diese Weise wurde jeder Händler automatisiert migriert, sobald die für ihn nötigen Funktionalitäten implementiert waren.

Fazit

Hat sich dieses iterative Vorgehen mit dem umfangreichen Testaufwand gelohnt? Ja, auf jeden Fall. Durch die frühestmögliche Migration von Händlern, konnten wir die bestehende, unternehmenskritische Datenbank entlasten und so unser Betriebsrisiko signifikant senken. Darüber hinaus konnten wir frühzeitig auch neue Features, wie bspw. die individuelle Steuerung der Importfrequenz pro Händler in Betrieb nehmen. Und wir konnten sogar fachliche Fehler in der alten Applikation identifizieren, so dass auch die Qualität der Angebotsdaten frühzeitig gesteigert wurde.

Nach meiner Meinung und Erfahrung lohnt es sich bei der Migration von komplizierten Applikationen über einen agilen, iterativen Ansatz nachzudenken. Die geeigneten Schnitte für die Iterationen zu finden, ist eine Herausforderung, denn viele Funktionalitäten und Schnittstellen müssen gleich zu Beginn vorhanden sein. Die Kunst liegt darin, die Anwendungsfälle nach der Komplexität ihrer funktionalen Anforderungen zu unterteilen. So lassen sich Funktionsblöcke finden, die in Iterationen nacheinander realisiert werden können und jeweils schon die Migration einer Teilmenge der Daten und Anwendungsfälle ermöglichen.

Natürlich ist der Parallelbetrieb der beiden Applikationen eine zusätzliche Herausforderung, doch mit einer guten Test-Automatisierung können Sie diese bewältigen. Ob der Gesamtaufwand bei einem Vorgehen per Wasserfall-Migrationen geringer gewesen wäre, kann ich nicht exakt sagen. Jedoch spricht der wesentlich früher realisierte Nutzen und das signifikant reduzierte Risiko im Vergleich zu einer Big-Bang-Migration deutlich für eine agile Migration.

Hinweise:

Jan Hegewald bloggt unter https://www.agil-gefuehrt.de über moderne Führung und Agilität. Und auf https://www.jan-hegewald.de finden Sie weitere Inhalten zu Themen rund um digitale Produktentwicklung. Auf LinkedIn können Sie leicht mit ihm Kontakt aufnehmen.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Jan Hegewald hat zwei weitere Beiträge im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick und Sie wissen es.