Über unsMediaKontaktImpressum
Christian Robert 07. Juni 2014

Aus alt mach neu - Software-Migrationen erfolgreich gestalten

Nicht jede Anwendung, die heutzutage entwickelt wird, startet auf der grünen Wiese. Häufig treffen wir in der Praxis auf Altanwendungen, die Jahre oder bereits Jahrzehnte im Einsatz sind, jedoch den Anforderungen, die an sie gestellt werden, nicht mehr länger gewachsen sind.

In solchen Fällen geht es darum, eine Altanwendung möglichst ohne große Reibungsverluste zu migrieren und softwaretechnisch auf neue Beine zu stellen. Dieser Artikel soll einen Einstieg in die Herausforderungen geben und mögliche Lösungswege aufzeigen, wie eine solche Migration einfacher und für alle Seiten zufriedenstellend erreicht werden kann.

Nicht wenige Softwareprojekte, die aktuell in Angriff genommen werden, beschäftigen sich nicht mit der Umsetzung von trendigen neuen Ideen, die Aufmerksamkeit in den diversen Social Media Kanälen erzeugen, sondern mit der Migration von Altsystemen, das bedeutet der Neuimplementierung bestehender – und teilweise seit Jahren, wenn nicht sogar Jahrzehnten laufender – Anwendungen. Wie in vielen Bereichen der Softwareentwicklung so hat auch die Umsetzung von Migrationsprojekten eigene Herausforderungen und eigene best practices.

In diesem Artikel wollen wir uns diese Herausforderungen im Detail ansehen und herausarbeiten, wie ein Migrationsprojekt effizient und für alle Beteiligten zufriedenstellend umgesetzt werden kann.

Vorüberlegungen

Bevor überhaupt mit der eigentlichen Migration gestartet werden kann, sollte zunächst die Frage beantwortet werden: Warum überhaupt eine Migration? Was spricht gegen eine evolutionäre Weiterentwicklung und für einen revolutionären Neustart?

Nicht selten ist die erste Antwort der Projektbeteiligten ein schnelles "Um alle Probleme der Vergangenheit hinter uns zu lassen und mit neuer und besserer Funktionalität aufwarten zu können". Dies ist jedoch leichter gesagt als getan, da die unterschiedlichen Stakeholder (oftmals unausgesprochene) abweichende und durchaus sich gegenseitig widersprechende Motivationen haben können. Es gilt also, das Motto "Alles neu" feingranular zu betrachten und die einzelnen Teilmotivationen genauer herauszuarbeiten.

So möchte die Entwicklungsabteilung oftmals das System von Grund auf neu implementieren um technische Schulden, die im Laufe des bisherigen Anwendungslebens aufgelaufen sind, beseitigen zu können und moderne Technologien zum Einsatz bringen. Auch der Austausch von nicht mehr unterstützen externen Hard- und Softwarekomponenten kann eine Motivation sein.

Den Kunden wiederum interessieren die Interna der verwendeten Technologien in der Regel nicht oder nur am Rande – für ihn zählen Dinge wie die Geschwindigkeit, eine leichte Benutzbarkeit und das Vorhandensein eines möglichst optimal auf die eigenen Bedürfnisse passenden Satzes an Funktionalitäten.

Der Vertrieb des Anbieters wiederum ist darauf bedacht, eine möglichst hohe Marge bei der Umsetzung des Projektes zu erzielen, wogegen der Einkauf des Kunden genau das Gegenteil, nämlich eine möglichst günstige Lösung erwerben möchte. Dies sind nur einige Beispiele, an denen bereits Konfliktszenarien zu erkennen sind.

Der erste Schritt vor der eigentlichen Planung und Durchführung einer Migration sollte daher immer sein, sich dieser potentiellen Konflikte bewusst zu sein und eine klare "Marschrichtung" vorzugeben, wieso eine Migration durchgeführt werden soll. Auch die Rahmenbedingungen – wie zu liefernder Umfang, Budget und verfügbare Zeit – müssen abgesteckt und für alle transparent gemacht werden.

Vorbereitungen

Auch wenn die Entscheidung für eine Migration gefallen ist, so muss dies noch lange nicht bedeuten, dass eine bestehende Anwendung komplett neu geplant und entwickelt werden muss. Je nach Szenario kann es durchaus sinnvoll und gewünscht sein, bestimmte Bestandteile der Anwendung zu isolieren und separat und/oder phasenweise zu migrieren.

Soll beispielsweise für eine Enterprise-Anwendung, die bereits nach dem Client-Server-Modell strukturiert ist, die Benutzerschnittstelle angepasst werden (von einem Fat Client hin zu einem Thin Client, bei dem die Anwendung direkt vom Browser aus benutzbar ist), so könnte es ausreichen, nur die Benutzerschnittstelle, also genau den Teil der Anwendung der für die Darstellung zuständig ist, zu migrieren. Die eigentliche Geschäftslogik kann hierbei unverändert weitergenutzt werden.

Die Vorteile liegen auf der Hand: Es müssen nur die Anwendungsbestandteile angefasst und neu implementiert werden, die sich auch tatsächlich ändern. Die bewährte und bereits im Einsatz befindliche Geschäftslogik braucht weder neu implementiert, noch sich aufwendigen Qualitätssicherungs- und Regressionstests zu unterziehen. Nicht immer jedoch ist dies eine gangbare Lösung: Lässt sich die Geschäftslogik nicht sauber von der Darstellungslogik trennen, so bleibt nur die Alternative einer Migration aller Anwendungsbestandteile in einem Schritt.

Migrationsplanung

Ist also die Entscheidung gefallen, dass die Anwendung migriert werden soll, so gibt es eine Reihe an Voraussetzungen, die abgesteckt werden sollten, um einen möglichst sauberen Übergang von der Altanwendung zur Neuimplementierung zu gewährleisten. Gerade hierbei gilt es, alle Projektbeteiligten, besonders aber die Endbenutzer, die später tagtäglich mit der Anwendung arbeiten, frühzeitig und umfangreich mit einzubinden. Eine überraschende Erkenntnis ist nämlich, dass eine Anwendung oftmals nicht in der Art und Weise verwendet wird, wie es in der ursprünglichen Planung angedacht war.

Die Gründe hierfür sind so unterschiedlich wie interessant. Ein Beispiel, dass in der Praxis regelmäßig angetroffen wird, ist der Erfindungs- und Ideenreichtum der Benutzer. Um die Aufgaben des Tagesgeschäftes möglichst effizient zu lösen, werden Wege durch die Anwendung beschritten und Techniken eingesetzt, die weder vorgesehen noch in der Planung der Anwendung berücksichtigt wurden. Nicht selten werden nicht dokumentierte Funktionen oder sogar Bugs innerhalb der Anwendung genutzt, um das gewünschte Ergebnis zu erreichen.

Dem Autor ist ein solches Beispiel selbst in der Praxis begegnet: In einer Produktverwaltung fehlte für bestimmte Benutzergruppen die Möglichkeit, ein neues Produkt anzulegen. Anstatt jedoch diesen Fehler zu bemängeln und seine Abschaffung einzufordern, hatten die Benutzer einen alternativen Weg entwickelt. Zur Neuanlage wurde ein bereits bestehender Artikel (samt aller referenzierten Informationen) kopiert und die Kopie anschließend mit den neuen Produktdaten überschrieben. Die Anforderung einen neuen Artikel einzustellen, wurden somit aus Benutzersicht erfüllt. Eine Dokumentation des Prozesses fand jedoch – außer in den Köpfen der entsprechenden Mitarbeiter – nirgendwo statt. Dies führte dazu, dass eben jene implizite Anforderung an das System nicht mit in die Planung der zu migrierenden Funktionalitäten aufgenommen wurde. Während der Testphase der migrierten Anwendung schließlich wurde von den Benutzern mehrheitlich das Fehlen dieser Funktionalität bemängelt. Der Workaround war für sie kein Workaround, sondern ein essentieller Bestandteil der Anwendung.

Aus diesem Beispiel lässt sich ableiten, dass für eine erfolgreiche Migration nicht nur die klassischen Anforderungen, die für die ursprüngliche Anwendung definiert wurden, berücksichtigt werden müssen – kombiniert mit den Änderungswünschen für die neue Version – sondern auch versteckte Funktionalität klar erkannt und dokumentiert werden muss.

Hierfür ist es nahezu unerlässlich, sich nicht nur mit der Spezifikation der abzulösenden Anwendung zu beschäftigen, sondern den direkten Kontakt zu den Anwendern zu suchen, die tagtäglich mit der Software in Kontakt kommen. Als hilfreich und effizient hat sich erwiesen, hierzu aus allen Anwendern eine überschaubare Gruppe zu bilden, die die Aufgabe hat, im Auftrag der Gruppe die Anwenderinteressen sowohl in der Planungsphase als auch später während der Umsetzungsphase zu vertreten.

Mit dieser Gruppe von Anwendern ("Schlüsselnutzer") sollten die typischen Anwendungsfälle, die sowohl die alte als auch die neue Software abdecken sollen, aufgenommen und analysiert werden. Hierbei ist besonders darauf zu achten, die tatsächlichen Anforderungen ("eigentlich wollen wir X erreichen") von den tatsächlich eingesetzten Schritten ("was wir aber machen ist Y") zu separieren, um klar erkennen zu können, wo die Schwachstellen der Altanwendung liegen und welche dieser Punkte bei einer Migration separat betrachtet werden müssen.

Last but not least sollte während der Migrationsplanung auch die eigentliche Umstellung mit geplant werden. Ist eine Koexistenz der beiden Systeme möglich? Kann im Falle des Falles die Altanwendung länger als geplant in Betrieb gehalten werden? Welche neue Hardware wird für den Betrieb der neuen Software benötigt? Alles dies sind Fragen zu denen bereits vor der eigentlichen Umsetzung eine Antwort vorliegen sollte.

Migrationsdurchführung

Nachdem die Vorüberlegungen und die konkrete Migrationsplanung abgeschlossen sind, kann mit der eigentlichen Migration, also der Umstellung auf technischer Ebene, begonnen werden.

Auch hier ist frühes Feedback von Anwenderseite der Schlüssel zu einer erfolgreichen Umsetzung. Idealerweise verläuft die Migration nach einem agilen Verfahren, was es den Anwendern (entweder als ganzes oder den Schlüsselnutzern) ermöglicht, frühzeitig Korrekturen einzubringen. Oft treten dabei durchaus Fehlerquellen und Hindernisse auf, die in der Planung nicht als solche erkannt wurden.

Ein Szenario, dass dem Autor selbst in einem Migrationsprojekt begegnet ist, kann hier als Beispiel dienen. Die zu migrierende Anwendung bestand aus einem in COBOL geschriebenen Terminalprogramm. Rein zeichenbasiert wurde der Benutzer nach und nach durch die einzelnen Eingabefelder geführt. Die neue Anwendung hingegen bestand aus einer modernen Rich-Client-Anwendung. In dieser war es nun möglich, die Eingabefelder nicht nur in der ursprünglichen Reihenfolge auszufüllen, sondern beliebig zwischen den einzelnen Feldern hin und her zu springen. Durch diese Möglichkeit ergaben sich allerdings widersprüchliche Validierungsfehlermeldungen, da die Validierung nur für eine sequentielle Bearbeitung klar definiert war.

Dadurch, dass dies zu einem frühen Zeitpunkt bereits von den Anwendern bemerkt und bemängelt wurde, konnte das gesamte Validierungskonzept überarbeitet und für entsprechende Szenarien angepasst werden.

Mehr oder weniger nebenbei wurden hierbei auch die Ängste der Anwender gemindert, die – teils offen ausgesprochen, teils versteckt – befürchteten, dass die Migration an ihnen vorbei laufen, sie vor vollendete Tatsachen stellen und keinen Einfluss auf die Abwicklung ihres zukünftigen Tagesgeschäftes haben würde.

Als sie hier erkannten, dass ihr Feedback schnell in die zu entwickelnde Neuanwendung integriert wurde, waren diese deutlich eher bereit, sich auch mit weiteren Änderungs- und Anpassungswünschen an das Entwicklungsteam zu wenden.

Ein weiterer Vorteil von frühzeitiger und intensiver Einbindung der Endbenutzer in die Migrationsphase ist der sinkende Schulungsaufwand bzw. die Möglichkeit diese auch von den Anwendern durchführen zu lassen. Eine Schulung durch Schlüsselnutzer hat sich als deutlich effekiver erwiesen als eine Schulung durch das Entwicklungsteam oder eine dezidierte Schulungsabteilung.

Nicht nur werden die Schlüsselnutzer von ihren Kollegen viel eher als Wissensvermittler akzeptiert, sie sind auch viel eher in der Lage, auf spezifische Fragen fachlich korrekte Antworten geben zu können.

Zusammenfassung

Die hier aufgezeigten Punkte geben eine erste Einführung in die Herausforderungen und Hürden, die sich während einer Migration ergeben. Jedes Projekt hat mit einer unterschiedlichen Historie und damit auch mit anderen Schwierigkeiten zu kämpfen.

Nichtsdestotrotz lässt sich mit einigen der hier vorgestellten Grundprinzipien manch ein potentieller Eisberg ein wenig leichter umschiffen.

Autor
Das könnte Sie auch interessieren

Neuen Kommentar schreiben

Kommentare (0)