Hallo Herr Ehmke, Anwendungsmodernisierung ist ein wichtiges Themenfeld der ITGAIN. Was macht es aus Ihrer Sicht so wichtig?
Ja, tatsächlich ist Anwendungsmodernisierung ein aus meiner Sicht sehr wichtiges und häufig ein nicht hinreichend beachtetes Thema mit vielen Facetten. In der Praxis begegnen uns häufig gewachsene Anwendungslandschaften, die durch sich wandelnde und neue Anforderungen im Gesamtbild kein ordentliches IT-Systemdesign mehr erkennen lassen. Hier sprechen wir auch von technischen Schulden. Parallel dazu hat sich die Welt weiterentwickelt und Techniken oder Technologien sind verfügbar, die es zum Zeitpunkt des Entwurfs und der Implementierung noch nicht gab.
Betrachten wir zunächst die „technischen Schulden“. Die Beseitigung kostet doch erstmal nur Geld, ohne funktionale Erweiterungen, also ohne erkennbaren Mehrwert, oder?
Natürlich kostet die Beseitigung von „technischen Schulden“ zunächst auch Geld. Nicht umsonst sprechen wir von „Schulden“. Diese Investition wurde in der Vergangenheit bei der Weiterentwicklung – zum Beispiel wegen Termin- oder Kostendruck – eingespart. Dabei geht es aber nicht, wie man so schön sagt, um „Schmuck am Nachthemd“. Wenn wir hier nicht tätig werden, entsteht eine Anwendungslandschaft, die zukünftig kaum noch wartbar ist, dafür aber fehleranfällig und schlimmstenfalls unzugänglich im Hinblick auf die Umsetzung neuer Anforderungen ist.
Aber es ist schon richtig, dass oft die verkürzte Sicht entsteht: Warum Geld für „nichts“ ausgeben? Eine Argumentationshilfe kann hier eine Modernisierung unter Nutzung neuer technologischer Möglichkeiten sein.
Sie kombinieren also das Notwendige mit dem Nützlichen?
Ja, genau. Dadurch ergeben sich zwar immer noch nicht zwingend neue Funktionen, aber zumindest kann man hinterher von einer Anwendung sprechen, die „up to date“ ist. Und nicht zuletzt in der Pflege auch Geld spart.
Soweit die Theorie, können Sie uns dazu ein praktisches Beispiel geben?
Aktuell modernisieren wir eine über Jahrzehnte gewachsene Mainframe - oder auch Großrechner genannte - Anwendung in Cobol. Diese Anwendung wird in einem Rechenzentrum betrieben und von mehreren verschiedenen Mandanten genutzt. Die verschiedenen Mandanten haben dabei über die Jahre mitunter uneinheitliche sowie unterschiedliche fachliche Anforderungen eingebracht.
Das hört sich nach einer komplexen Struktur an. Und Cobol klingt auch wie vorgestern.
Eine gewisse Komplexität wird die Anwendung immer behalten. Aber sie soll nicht komplexer sein als nötig. Die Probleme, die sich daraus ergeben haben, haben auch bei unserem Kunden zu der Einsicht geführt, dass wir hier tätig werden müssen.
Cobol ist allerdings nicht der Grund für die Probleme und gehört auf dem Großrechner unseres Erachtens aus gutem Grund zu einer viel verwendeten Programmiersprache. Wenn auch nicht mehr für alle Aufgaben. So gibt es auch in dem Umfeld den Wunsch, Aufgaben wo möglich auf eine dezentrale Java-Plattform zu verlagern.
Also ein Musterbeispiel für Anwendungsmodernisierung?
In gewisser Weise: Ja. Sicherlich würden wir uns manchmal mehr Tempo wünschen. Aber die Bereitschaft das Thema anzugehen ist da und so gehen wir Schritt für Schritt voran.
Wie können wir uns das vorstellen?
Bevor wir mit dem Thema gestartet sind, gab es schon Vorüberlegungen, was getan werden müsste. Dabei hat ein Projektmitarbeiter etwas flapsig formuliert: „Alles wegwerfen und neu machen.“ Das ist aus unserer Sicht im Allgemeinen weder notwendig noch sinnvoll. Zum einen sind damit erhebliche Kosten verbunden und zum anderen vielleicht sogar noch größere Risiken.
Wir versuchen daher ausgehend von bestehenden Problemen handhabbare Blöcke zu identifizieren und hier Verbesserungen zu erreichen.
Ein einfaches Beispiel: Für jeden Mandanten mussten zu einem festgelegten Zeitpunkt bestimmte Buchungssätze erzeugt werden. Dafür gab es einen Batchjob, in dem für jeden Mandaten geprüft wurde, ob Daten vorliegen, daraus wurde dann ein Dataset erzeugt, über mehrere Schritte verarbeitet und letztlich gebucht. Das bringt zum einen mit sich, dass die Aufnahme eines neuen Mandanten die Erweiterung des Jobs erforderlich macht. Zum anderen ist der Job so aber praktisch nur schwer testbar, da die konkrete Situation so eben nur in der produktiven Umgebung vorliegt.
Wir haben die Abläufe nun so angepasst, dass ein einheitlicher Job unabhängig vom Mandanten läuft und prüft, ob Daten für einen Mandaten vorliegen. Ist dies der Fall, werden in dem Job die Daten für diesen Mandaten weiterverarbeitet. Der Ablauf ist damit getrennt vom konkreten Mandanten und auch in der Testumgebung ohne Mühen und Anpassungen lauffähig.
Eine sehr lokale Anpassung, gut zu testen mit relativ geringem Risiko und Aufwand.
Dabei kommen aber keine neuen Technologien zum Einsatz.
Nehmen wir ein anderes Beispiel: Die Anwendung ist für die verschiedenen Mandaten auch über mehrere Systeme verteilt, die sich jedoch einige Daten teilen. Bisher wurden die Daten über verschiedene File-Transfer-Strecken verteilt. Dazu mussten sie aus den Datenbanken in Dateien entladen, zusammengefasst, übertragen, ggf. aufgeteilt und im Zielsystem dann geladen werden. Was besonders im Zusammenhang mit Erweiterungen und Formatwechseln zu Problemen geführt hat.
Hier haben wir eine neue zentrale Datenbanktabelle eingeführt, die für den Datentransfer genutzt wird. Damit gibt es nur noch zwei Jobs. Ein Job, der die Daten in die zentrale Tabelle „sendet“ und ein Job, der die Daten aus der zentralen Tabelle „empfängt“. Fertig.
Außerdem konnten wir durch den Verzicht auf den Dateitransfer auf die neue Java-Plattform umstellen.
Sie sind bei ITGAIN für das Team Banken und Versicherungen verantwortlich. Wird bei der Anwendungsmodernisierung auch fachliches Know-How benötigt?
Zunächst einmal sind die meisten Fragestellungen eher technischer Natur. Es gibt jedoch auch immer wieder Themen, bei denen man den fachlichen Hintergrund beleuchten muss, um zu verstehen, warum die Dinge so sind, wie sie sind. Da hilft es ungemein, wenn man im Team jemanden hat, der nicht nur die technische Seite beleuchten kann. So können wir sicherstellen, dass die Anwendung hinterher nicht nur technisch modern ist, sondern auch nach wie vor den fachlichen Anforderungen genügt. Falls wir den Eindruck haben, dass die fachliche Anforderung möglicherweise gar nicht mehr bestehen, können wir direkt die notwendigen Abstimmungen durchführen und das System an der Stelle vereinfachen. Mit ausschließlich technischem Blick hätten wir unnötige Komplexität in das neue System gebracht. Daher wird fachliches Know-How durchaus benötigt.
Anwendungsmodernisierung ist also sowohl technisch als auch fachlich anspruchsvoll?
Auf jeden Fall. Aber aus unserer Sicht unabdingbar. Insbesondere wenn man im Sinne von Risikominimierung und Budgetverträglichkeit eine schrittweise Umstellung vornehmen möchte, sollte man besser heute als morgen damit beginnen.
Also führt am Ende kein Weg an einer Anwendungsmodernisierung vorbei?
Sie lohnt sich! Komplexe Anwendungssystemen altern im Grunde ähnlich wie eine Immobilie. Die Welt dreht sich weiter. Das führt auch bei Anwendungssystemen im übertragenen Sinn zu einem Verfall. Wenn man also nicht irgendwann eine „Bruchbude“ haben möchte, muss man regelmäßig in die Instandhaltung investieren. Langfristig ist das günstiger!