Bestehende Software: wann sich Weiterentwicklung lohnt.

An beobachtbaren Problemen ansetzen.

Änderungen berühren unerwartet viele Bereiche, wichtige Abläufe lassen sich kaum prüfen oder Wissen liegt nur bei einzelnen Personen. Solche Beobachtungen sind konkreter als das allgemeine Urteil, eine Anwendung sei „veraltet“.

Technische Schulden beschreiben Entscheidungen und aufgeschobene Arbeiten, die spätere Änderungen erschweren können. Nicht jede davon ist sofort problematisch. Relevant wird, welche Bereiche tatsächlich verändert werden müssen und welche Risiken dabei entstehen.

Den tatsächlichen Zustand sichtbar machen.

Quellcode, vorhandene Tests, Dokumentation und Betriebsbedingungen liefern unterschiedliche Teile des Bildes. Dazu kommt das Prozesswissen der Menschen, die die Anwendung nutzen oder betreuen.

Fehlende Informationen sind selbst ein Ergebnis der Bestandsaufnahme. Sie sollten nicht durch eine scheinbar sichere Aufwandsschätzung verdeckt werden. Zunächst kann es sinnvoll sein, einen besonders relevanten Ablauf nachvollziehbar zu dokumentieren oder prüfbar zu machen.

Mehr als zwei Optionen vergleichen.

Zwischen „alles lassen“ und „alles neu bauen“ liegen Erweiterung, Integration und Teilersatz. Ein klar abgegrenzter Bereich kann überarbeitet werden, während andere Funktionen zunächst bestehen bleiben.

Auch ein Neubau hat Übergangsaufwand: Daten, Nutzer und abhängige Systeme müssen berücksichtigt werden. Umgekehrt kann ein Bestand so eingeschränkt sein, dass eine Erweiterung nicht mehr sinnvoll ist. Beides lässt sich nur am konkreten System beurteilen.

Als illustrative Entscheidungssituation dient eine Auftragsverwaltung, die zuverlässig arbeitet, deren Daten aber zusätzlich in Excel gepflegt werden. Ist der betreffende Bereich gut änderbar und prüfbar, kann eine Erweiterung im Bestand sinnvoll sein. Liegt das Problem vor allem im Datenaustausch und gibt es eine geeignete Schnittstelle, kommt eine Integration infrage. Ist nur die schwer wartbare Eingabemaske das Hindernis, kann ein abgegrenzter Teilersatz geprüft werden, während die bestehende Auftragsverarbeitung erhalten bleibt.

Entscheidend sind jeweils Änderbarkeit, verfügbare Schnittstellen, Datenverantwortung und der Übergang im laufenden Betrieb. Vor einer Entscheidung sollte derselbe Beispielauftrag durch den heutigen und den vorgesehenen Ablauf verfolgt werden: Wer darf welche Angaben ändern, welches System ist führend und wie werden Fehler oder doppelte Übertragungen erkannt? Ohne diese Klärung ist auch eine kleine Schnittstelle keine automatisch risikoarme Lösung.

Veränderungen am Ziel priorisieren.

Beginnen Sie bei den Bereichen, die für das nächste Vorhaben wichtig sind. Definieren Sie, was nach der Änderung besser prüfbar, erweiterbar oder nutzbar sein soll. So wird Modernisierung zu einer begründeten Entscheidung statt zu einem Selbstzweck.