Sie sind hier: HomeTelekommunikation

Legacy Software: Modernisierungskandidaten identifizieren

In die Jahre gekommene Anwendungen sind in vielen Unternehmen noch im Einsatz. Wie sich diese Fälle finden lassen, dazu hat der auf Software Revival spezialisierte IT-Dienstleister Avision einen Fragenkatalog entwickelt.

Testen Bildquelle: © Vasin Leenanuruksa - 123RF

Legacy Software muss kein Problem darstellen – dennoch birgt sie oftmals betriebliche Risiken in sich. Der Schnellcheck von Avision will helfen, potenzielle Modernisierungskandidaten zu identifizieren. Dazu sollten sich Unternehmen die unten stehenden Fragen stellen. „Lautet die Antwort auf diese Fragen öfter als dreimal Nein, sollten sich die Verantwortlichen die betreffende Anwendung genauer ansehen und in eine tiefere Analyse einsteigen“, so Nadine Riederer, CEO bei Avision.

Haben noch mehr als zwei Mitarbeiter Know-how für die aktuelle Anwendung?
Ist das nicht der Fall, besteht laut Avision zum einen die Möglichkeit, dass die Anwendung dann irgendwann nicht mehr gewartet werden kann. Zum anderen droht ein Know-how-Verlust, wenn die wenigen Mitarbeiter, die sich mit der Anwendung auskennen, das Unternehmen verlassen.

Ist das letzte Update vor weniger als zwölf Monaten erfolgt?
Häufige Updates sind ein Hinweis darauf, dass das nötige Know-how noch im Unternehmen ist, ein vernünftiger Pflegestatus der Software erhalten wurde, der Source Code vorhanden ist und aktuelle Sicherheitsanforderungen berücksichtigt werden. Liegt das letzte Update über ein Jahr zurück, kann das heißen, dass der Source Code fehlt beziehungsweise kein Dienstleister mehr vorhanden ist, der Updates durchführen kann.

Können Komponenten wie Betriebssystem, Datenbanken und Java upgedatet werden?
Auch die Umgebung der Software muss Update-fähig sein. Das kann aber aus zwei Gründen nicht gegeben sein: Zum einen, weil Versionen von Betriebssystemen, Datenbanken oder Programmiersprachen verwendet werden, die am Ende ihres Lebenszyklus angelangt sind und von ihren Anbietern nicht mehr mit Updates oder Sicherheits-Patches versorgt werden. Zum anderen besteht bei Individualsoftware die Möglichkeit, dass sie durch das Update einer solchen Komponente gar nicht mehr funktionsfähig ist.

Gibt es mehr als ein fachliches Release pro Jahr?
Selbst wenn die zweite und dritte Frage mit Ja beantwortet werden, heißt das nur, dass ein technisches Release möglich ist. Trotzdem kann eine Anwendung aber so komplex geworden sein, dass sich nicht mehr als ein fachliches Release pro Jahr umsetzen lässt. Selbst kleinste Anpassungen erfordern dann einen horrenden Testaufwand. Dadurch häufen sich die fachlichen Anforderungen an und das Backlog wird immer größer.

Enthält das Release mehr als 70 Prozent fachliche Anpassungen?
Ist das nicht der Fall, bedeutet das, dass ein Release hauptsächlich der Anpassung technischer und kaum mehr fachlicher Anforderungen dient. Der Aktualisierungsbedarf der Anwendung ist dann so hoch, dass er nicht mehr innerhalb der Releases abgearbeitet werden sollte.

Sind die Kosten jedes Release gleichbleibend oder sinkend bei identischem Anteil von fachlichen Änderungen?
Lautet die Antwort Nein werden die Anpassungen der Software immer teurer und das Kosten-Nutzen-Verhältnis verschlechtert sich immer mehr. Eine Gegenüberstellung der laufenden Kosten und der Kosten für eine Modernisierung kann das Potenzial für Kosteneinsparungen aufdecken.

Die IT-Verantwortlichen haben keine Bedenken, wenn die Anwendung angepasst werden soll?
Äußern die IT-Verantwortlichen bei jedem Release einer bestimmten Anwendung Bedenken und würden sie am liebsten gar nicht mehr verändern, sollten die Verantwortlichen hellhörig werden. Diese Bedenken sind ein eindeutiges Indiz dafür, dass bei der Anwendung etwas im Argen liegt und Modernisierungsbedarf bestehen könnte.

Nutzt die Anwendung aktuelle Sicherheitsfeatures?
Sicherheitsfeatures wie verschlüsselte Zertifizierungen und regelmäßige Sicherheits-Patches sind eine absolute Notwendigkeit. Sind diese nicht vorhanden beziehungsweise können nicht eingespielt werden, stellt die Anwendung ein Sicherheitsrisiko für das Unternehmen dar.