Risiken bei der Modernisierung von Altsystemen minimieren
Die Modernisierung einer geschäftskritischen Anwendung bietet große Chancen, ist aber immer mit Risiken verbunden. Über viele Jahre gewachsene Systeme enthalten komplexe Abhängigkeiten, umfangreiche Datenbestände und Geschäftsregeln, die häufig nur teilweise dokumentiert sind.
Das größte Risiko besteht deshalb oft nicht darin, eine neue Technologie einzuführen. Schwieriger ist es, sicherzustellen, dass bei der Veränderung des bestehenden Systems keine wichtigen Funktionen, Daten oder Geschäftsregeln verloren gehen.
Eine erfolgreiche Modernisierung versucht daher nicht, jedes Risiko vollständig auszuschließen. Sie schafft ein Vorgehen, bei dem Risiken früh erkannt, begrenzt und kontrolliert werden können.
Je größer und geschäftskritischer ein Altsystem ist, desto wichtiger ist es, die Modernisierung in überschaubare und überprüfbare Schritte zu zerlegen.
Warum sind Altsysteme besonders schwierig zu modernisieren?
Ein über viele Jahre betriebenes Softwaresystem ist normalerweise wesentlich komplexer, als es auf den ersten Blick erscheint.
Ursprüngliche Entwickler haben das Unternehmen möglicherweise längst verlassen. Dokumentationen entsprechen nicht mehr vollständig dem aktuellen Stand. Neue Funktionen wurden ergänzt, Schnittstellen verändert und Sonderlösungen für einzelne Geschäftsprozesse geschaffen.
Dabei entstehen Abhängigkeiten, die selbst erfahrenen Mitarbeitern nicht immer vollständig bekannt sind.
Ein bestimmtes Datenfeld wird beispielsweise nicht nur von der eigentlichen Anwendung verwendet, sondern auch von einem nächtlichen Prozess oder einem externen System. Eine scheinbar überflüssige Funktion bildet möglicherweise einen seltenen, aber wichtigen Geschäftsfall ab.
Genau diese versteckten Zusammenhänge machen die Modernisierung anspruchsvoll.
Das Risiko des Wissensverlusts
In vielen Altsystemen befindet sich wichtiges Wissen nicht in Dokumentationen, sondern in den Köpfen einzelner Mitarbeiter.
Langjährige Entwickler kennen technische Besonderheiten und wissen, welche Komponenten voneinander abhängig sind. Erfahrene Anwender kennen wiederum fachliche Sonderfälle, die aus dem Programmcode allein nur schwer erkennbar sind.
Dieses Wissen sollte möglichst früh in eine Modernisierung einbezogen werden.
Besonders kritisch wird die Situation, wenn zentrale Wissensträger kurz vor dem Ruhestand stehen oder das Unternehmen verlassen. Eine Modernisierung erst nach deren Ausscheiden zu beginnen, kann erheblich aufwendiger werden.
Modernisierung bedeutet deshalb auch Wissenssicherung. Architektur, Geschäftsregeln und kritische Prozesse sollten dort dokumentiert werden, wo sie für die zukünftige Anwendung relevant sind.
Versteckte Abhängigkeiten erkennen
Eine häufige Ursache für Probleme sind unbekannte technische Abhängigkeiten.
Über viele Jahre entstehen Verbindungen zwischen Anwendungen, Datenbanken, Dateien, Batch-Prozessen und externen Systemen. Manche davon wurden ursprünglich nur als Übergangslösung geschaffen und sind später zu einem festen Bestandteil der Systemlandschaft geworden.
Wird eine solche Verbindung bei der Modernisierung übersehen, kann eine scheinbar lokale Änderung unerwartete Auswirkungen auf andere Prozesse haben.
Vor größeren Eingriffen sollte deshalb untersucht werden, welche Komponenten miteinander kommunizieren, wo Daten gelesen oder verändert werden und welche externen Systeme von bestimmten Funktionen abhängig sind.
Dabei muss nicht das gesamte Altsystem vollständig analysiert werden. Entscheidend ist, die Abhängigkeiten zu verstehen, die für den jeweils nächsten Modernisierungsschritt relevant sind.
Geschäftslogik darf nicht unbemerkt verloren gehen
Eines der größten Risiken einer Neuentwicklung oder Migration ist der Verlust von Geschäftslogik.
In einer langjährig betriebenen Anwendung befinden sich häufig Regeln, die ursprünglich aus konkreten Anforderungen entstanden sind. Einige davon werden täglich benötigt, andere nur in seltenen Sonderfällen.
Gerade diese seltenen Fälle sind problematisch. Sie werden bei einer neuen Anforderungsanalyse möglicherweise nicht erwähnt, sind im produktiven Betrieb aber dennoch notwendig.
Deshalb sollte bestehende Software nicht ausschließlich als technischer Altbestand betrachtet werden.
Der vorhandene Programmcode ist häufig auch eine Form von Unternehmenswissen.
Vor der Ablösung einer Funktion muss deshalb verstanden werden, welche fachlichen Regeln sie tatsächlich abbildet.
Datenmigration ist mehr als das Kopieren von Daten
Ein weiterer kritischer Bereich ist die Datenmigration.
Historische Datenbestände sind häufig über viele Jahre gewachsen. Datenmodelle wurden erweitert, Formate verändert und unterschiedliche Generationen von Datensätzen befinden sich in derselben Datenbank.
Eine Migration kann deshalb nicht immer darin bestehen, Tabellen aus einem alten in ein neues System zu kopieren.
Zunächst muss geklärt werden, welche Daten weiterhin benötigt werden, wie ihre Qualität ist und wie sie in das zukünftige Datenmodell übertragen werden können.
Dabei kann sich auch herausstellen, dass nicht alle historischen Daten migriert werden müssen. Bestimmte Informationen können beispielsweise in einem Archiv verbleiben, während nur aktiv benötigte Daten in die neue Umgebung übernommen werden.
Eine gute Modernisierungsstrategie trennt deshalb Datenmigration, Datenbereinigung und Datenarchivierung bewusst voneinander.
Warum ein Big-Bang-Ansatz das Risiko erhöhen kann
Bei einem vollständigen Systemwechsel konzentrieren sich viele Risiken auf einen einzigen Zeitpunkt.
Die neue Anwendung muss funktionieren, die Datenmigration muss abgeschlossen sein, alle relevanten Schnittstellen müssen verfügbar sein und die Anwender müssen mit dem neuen System arbeiten können.
Treten mehrere Probleme gleichzeitig auf, wird eine Rückkehr zum bisherigen Zustand schwierig.
Bei einer schrittweisen Modernisierung lassen sich diese Risiken verteilen. Einzelne Funktionen können zunächst parallel betrieben und überprüft werden. Erst wenn die neue Lösung zuverlässig funktioniert, wird die bisherige Komponente stillgelegt.
Damit wird aus einer großen Umstellung eine Folge kleinerer Entscheidungen.
Mit einem Pilotprojekt beginnen
Ein Pilotprojekt ist eine gute Möglichkeit, die geplante Modernisierungsstrategie unter realen Bedingungen zu überprüfen.
Dafür sollte ein Bereich gewählt werden, der fachlich relevant, aber ausreichend abgegrenzt ist. Ein völlig unbedeutendes Modul liefert zwar ein geringes Projektrisiko, aber auch wenig Erkenntnisse für die weitere Modernisierung.
Der Pilot sollte zeigen, ob die geplante Architektur funktioniert, ob sich bestehende Systeme zuverlässig integrieren lassen und ob die gewählten Technologien für das Unternehmen geeignet sind.
Gleichzeitig entstehen erste Erfahrungen mit Entwicklung, Tests, Deployment und Betrieb der neuen Komponenten.
Erst danach werden weitere Bereiche übertragen.
Automatisierte Tests schaffen Sicherheit
Bei bestehenden Anwendungen ist häufig nicht vollständig dokumentiert, wie sich das System in jeder Situation verhalten soll.
Tests gewinnen deshalb bei einer Modernisierung besondere Bedeutung.
Bevor eine wichtige Funktion ersetzt wird, sollte ihr heutiges Verhalten nachvollziehbar sein. Automatisierte Tests können anschließend überprüfen, ob die modernisierte Komponente dieselben fachlichen Ergebnisse liefert.
Besonders wertvoll sind Tests für Geschäftsregeln, Berechnungen und Schnittstellen. Sie schaffen eine technische Absicherung für weitere Veränderungen.
Dadurch können Entwickler die Anwendung schrittweise verändern, ohne bei jeder Anpassung ausschließlich auf manuelle Prüfungen angewiesen zu sein.
Alt und Neu kontrolliert parallel betreiben
Während einer Modernisierung kann es sinnvoll sein, alte und neue Komponenten zeitweise parallel zu betreiben.
So können beispielsweise Ergebnisse des neuen Systems zunächst mit denen der bestehenden Anwendung verglichen werden. Abweichungen werden sichtbar, bevor die neue Komponente vollständig die Verantwortung übernimmt.
Auch neue Benutzeroberflächen oder Prozesse können zunächst mit einer begrenzten Gruppe von Anwendern eingesetzt werden.
Der Parallelbetrieb sollte allerdings nicht zum Dauerzustand werden. Für jede Übergangslösung muss klar sein, wann die alte Komponente abgeschaltet werden kann.
Andernfalls entsteht zusätzliche Komplexität statt einer einfacheren Systemlandschaft.
Rückfallmöglichkeiten einplanen
Nicht jede Veränderung funktioniert im ersten Anlauf wie erwartet.
Eine gute Modernisierungsstrategie berücksichtigt deshalb bereits vor einer Produktivsetzung, was passiert, wenn eine neue Komponente Probleme verursacht.
Wenn möglich, sollte ein Modernisierungsschritt so gestaltet sein, dass vorübergehend auf die bisherige Lösung zurückgegriffen werden kann. Das reduziert den Druck bei der Einführung erheblich.
Mit zunehmender Stabilität der neuen Komponente kann diese Rückfallmöglichkeit später entfernt und das alte Modul endgültig stillgelegt werden.
Kostenrisiken entstehen häufig durch einen unklaren Umfang
Modernisierungsprojekte können teuer werden, wenn zu Beginn versucht wird, das gesamte Altsystem vollständig zu analysieren und gleichzeitig eine perfekte zukünftige Architektur zu definieren.
Das andere Extrem ist ebenso problematisch: Ohne ausreichende Analyse wird mit der Entwicklung begonnen und wichtige Abhängigkeiten werden erst während des Projekts entdeckt.
Sinnvoll ist deshalb ein gestuftes Vorgehen.
Zunächst wird genügend analysiert, um die grundsätzliche Modernisierungsstrategie und einen geeigneten ersten Schritt festzulegen. Für diesen Bereich erfolgt anschließend eine detailliertere Analyse.
Danach kann auf Basis der gewonnenen Erkenntnisse der nächste Abschnitt geplant werden.
So verbessert sich die Planungssicherheit mit jedem Modernisierungsschritt.
Die Zielarchitektur muss klar sein
Schrittweise Modernisierung darf nicht mit planloser Einzeloptimierung verwechselt werden.
Wer lediglich Komponenten ersetzt, sobald sie Probleme verursachen, kann am Ende eine Systemlandschaft erhalten, die zwar modernere Technologien verwendet, aber weiterhin komplex und schwer wartbar ist.
Deshalb braucht die Modernisierung ein technisches Zielbild.
Es sollte beispielsweise festlegen, wie Systeme zukünftig miteinander kommunizieren, wo Geschäftslogik liegen soll, welche Rolle APIs spielen und wie neue Komponenten integriert werden.
Nicht jedes technische Detail muss von Anfang an feststehen. Die grundsätzliche Richtung sollte jedoch klar sein.
Jeder Modernisierungsschritt sollte nicht nur ein aktuelles Problem lösen, sondern das System gleichzeitig näher an die gewünschte Zielarchitektur bringen.
Auch organisatorische Risiken berücksichtigen
Modernisierung ist nicht ausschließlich ein IT-Projekt.
Anwender müssen mit neuen Funktionen arbeiten, Fachbereiche müssen Anforderungen erklären und bestehende Prozesse möglicherweise anpassen. Gleichzeitig müssen Entwickler häufig sowohl das bestehende als auch das neue System betreuen.
Wird dieser zusätzliche Aufwand unterschätzt, kann die Modernisierung das Tagesgeschäft erheblich belasten.
Deshalb sollten Fachbereiche, Anwender und technische Wissensträger früh einbezogen werden. Besonders wertvoll sind Mitarbeiter, die sowohl die Software als auch die dahinterliegenden Geschäftsprozesse gut verstehen.
Sie helfen dabei, zwischen historisch gewachsenen Besonderheiten und tatsächlich notwendigen Anforderungen zu unterscheiden.
Risiken lassen sich nicht vollständig vermeiden – aber kontrollieren
Eine geschäftskritische Anwendung zu verändern, wird niemals vollkommen risikofrei sein.
Auch das Nichtstun ist jedoch mit Risiken verbunden. Technologien altern weiter, Know-how geht verloren und notwendige Veränderungen werden zunehmend schwieriger.
Die eigentliche Entscheidung lautet deshalb nicht:
„Modernisierung mit Risiko oder Weiterbetrieb ohne Risiko?“
Sondern:
„Welche Risiken entstehen durch die Modernisierung – und welche Risiken entstehen, wenn wir nicht modernisieren?“
Eine gute Strategie betrachtet beide Seiten.
Fazit: Kleine, überprüfbare Schritte reduzieren das Modernisierungsrisiko
Die größten Risiken einer Software-Modernisierung entstehen häufig durch unbekannte Abhängigkeiten, verlorenes Wissen, unvollständig verstandene Geschäftslogik und komplexe Datenmigrationen.
Diese Risiken lassen sich deutlich reduzieren, wenn ein Unternehmen nicht versucht, das gesamte System auf einmal zu ersetzen.
Eine strukturierte Bestandsaufnahme schafft zunächst Transparenz. Eine Zielarchitektur definiert die Richtung. Ein Pilot überprüft die wesentlichen Annahmen. Tests sichern bestehende Geschäftsregeln ab. Anschließend können Funktionen und Daten schrittweise übertragen werden.
So wird aus einem schwer kalkulierbaren Großprojekt eine Folge überschaubarer und überprüfbarer Modernisierungsschritte.
Modernisierungsrisiken frühzeitig erkennen
hm informatik ag unterstützt Unternehmen und Softwarehersteller dabei, bestehende Anwendungen zu analysieren, technische und fachliche Risiken sichtbar zu machen und daraus eine schrittweise Modernisierungsstrategie abzuleiten.
Dabei steht nicht die möglichst schnelle Ablösung des bestehenden Systems im Vordergrund, sondern ein kontrollierter Übergang zu einer zukunftsfähigen Architektur.
