Seite wählen

Die geschäftlichen Aspekte der Softwaremodernisierung

Never touch a running system.

Das ist eine uralte Prämisse in der IT-Welt, welche oft aus Angst vor Änderungen und Fehlern bis zum heutigen Tage immer noch gelebt wird und das wird sich zukünftig vermutlich nur schwer ändern.

Diese Herangehensweise ist jedoch häufig nicht zielführend, da sie zwar auf das Mikrosegment angewendet werden kann, jedoch beim übergreifenden, großen Bild nicht alltagstauglich erscheint. Dies ist vor allem dann der Fall, wenn bestimmte wirtschaftliche Komponente dazukommen und ein Zwang besteht auf äußere Veränderungen zu reagieren.

Daher gibt es eine zentrale Frage, die man sich im Rahmen der Softwaremodernisierung stellen muss: „Warum sollte man modernisieren?“

Natürlich gibt es auch extreme Konstellationen, in denen eine Modernisierung aus technischer oder wirtschaftlicher Sicht keinen Sinn ergibt. Dies gilt es zu erkennen und nur wer Experte in diesem Bereich ist, kann zuverlässig beurteilen, wann die Risiken zu hoch für den eventuellen Nutzen sind. In diesem Fall ist es die Pflicht eines jeden verantwortlichen Dienstleisters darauf hinzuweisen.

Bereits in unserem Whitepaper beschreiben wir ausführlich, warum und wann man modernisieren sollte. Dort gehen wir jedoch überwiegend auf die technischen Aspekte ein und vernachlässigen etwas die wirtschaftliche und organisatorische Komponente.
Wir nutzen, wenn es um Modernisierungen geht auch gerne den Vergleich zum Nash Gleichgewicht – Wenn alle Faktoren eines Spieles permanent gleichbleiben, bleibt es auch das Ergebnis. Doch in dem Moment, in welchem ein Spieler einen Faktor ändert, müssen auch die anderen Mitspieler auf Änderung reagieren. – Und genau so ähnlich verhält es sich mit der Modernisierung von Systemen im Wettbewerbskontext.

Ein gutes Beispiel ist das Erscheinen der ersten innovativen Smartphones. Bis zu diesem Zeitpunkt waren einige wenige Unternehmen wie beispielsweise Nokia, Sony und Siemens Marktführer in jenem Bereich. Doch dann erschien das erste iPhone, welches den Verbrauchern ein komplett neues Erlebnis versprach. Nokia und Co. passten weder ihre Technologie noch ihre Produktion an und verloren dadurch sehr schnell Ihre Vorreiterposition. Auch wenn dieses Beispiel viele Details auslässt, so zeigt es doch auf eine radikale Weise welche Auswirkungen ein solches -nicht reagieren- haben kann.

Und genauso wie Nokia und andere Hersteller nicht wissen konnten, was der neue Trend der Smartphones bedeutet, können Verantwortliche nicht immer absehen, welche Auswirkungen es hat zu lange auf Legacy-Sprachen oder Legacy-Systeme zu setzen.

In der Industrie sind diese Auswirkungen nicht immer sofort absehbar, daher werden Legacy Systeme auch viel zu lange eingesetzt.

Die Gründe für eine Modernisierung sind fast immer wirtschaftliche, denn niemand modernisiert nur aus Prestige-Gründen oder für das eigene Ego. Diese wirtschaftlichen Gründe sind oft indirekt und spiegeln sich oft nicht im Umsatz wider, aber selbst der Arbeitskraftmangel in bestimmten Technologie-Gebieten hat einen direkten Einfluss auf den Umsatz den ein Unternehmen erzielen kann.

Doch nun erstmal zurück zur ursprünglichen Frage – Warum aber sollte man nun modernisieren?

Eine Modernisierung kann aus vielerlei Gründen sinnvoll oder gar notwendig sein:

1.
Ein Grund für eine Modernisierung ist das Fehlen qualifizierter Arbeitskräfte in gewissen Technologien. So ist es mittlerweile unglaublich schwierig COBOL, PL/I, Mainframe, AS400 Programmierer/Experten zu finden und diese abzuwerben. Setzt man dagegen z.B. auf Industriestandards wie Java, C# oder Python ist das Besetzen von Positionen viel einfacher.
2.
Anpassungen an einem System werden schwerfällig, zu aufwendig oder sogar komplett unmöglich. Dies ist immer dann kritisch, wenn eine Anwendung oder Infrastruktur aus rechtlichen Gründen schnell und unkompliziert angepasst werden muss. Hierzu zählen gesetzliche Vorgaben, wie z.B. Anpassungen der Steuersätze oder Anpassungen von Bilanzierungspflichten, oder das Speichern der Daten nach entsprechenden Standards, o.ä.
3.
Architektonische Komponenten, wie z.B. Datenbanken oder Anwendungsserver sind veraltet und müssten ausgewechselt werden. In solchen Fällen ist die Applikation oft der Bottleneck. Kosten für Mainframe und Co. mit einer nicht optimierten Codebasis kosten mehr als Programme und Anwendungen, die in einer modernen Cloudumgebung und Architektur laufen. Das Gleiche gilt für die Migration von Datenbanken. Viele unserer Projekte haben den einfachen Hintergrund Datenbanken von Informix oder DB2 nach Oracle zu migrieren. In diesen Fällen wäre eine veraltete Legacy-Anwendung wieder ein extremer Bottleneck, welcher eine Migration komplett unmöglich macht.
4.
Nicht nur führen veraltete Anwendungsarchitekturen dazu, dass sich jüngere Kandidaten weigern an einem System zu arbeiten, sondern sie führt auch dazu, dass die Performance darunter leidet. Mit alten, monolithischen Architekturen der Legacy-Sprachen lassen sich oft SOA oder Microservice-Architekturen nicht durchsetzen. Diesen Faktor darf man vor allem dann nicht unterschätzen, wenn eine Kunden-Userbasis existiert, welche ebenfalls die Anwendung nutzt (z.B. Online-Versicherungskalkulatoren für den Endverbraucher oder Ratenkalkulatoren für Banken).
5.
Legacy-Sprachen und Legacy-Anwendungen sind oft ein Grund, warum der Umzug in die Cloud unmöglich wird. Dieser Umzug ist jedoch meist ein nützlicher und kosteneffektiver Prozess. Viele große Unternehmen versuchen von Mainframe und Co. und den damit verbundenen hohen MIPS-Kosten wegzukommen. Eine alte Legacy-Anwendung macht aber genau dieses Ziel unerreichbar.

Warum nun aber trauen sich CIO, CTO und C-Level Manager nicht, diese Systeme und Architekturen anzugehen?

Dazu muss man verstehen welche Agenda ein C-Level-Executive hat. Auf dieser Ebene haben Manager einen befristeten Vertrag zwischen 2-5 Jahren und sie tragen nicht selten die Gesamtverantwortung für die IT und den reibungslosen Betrieb dieser. Geht man nun eine Modernisierung an, ändern sich bestehende Systeme und ein Risiko entsteht.
Oft werden auch neue Systeme und die damit verbundenen neuen GUIs von der Userbasis nicht willkommen geheißen. Diese Risiken sind viele Manager nicht bereit einzugehen.

Jetzt jedoch zum Interessanten an der ganzen Sache…

Legacy-/und Softwaremodernisierungen können praktisch risikolos und
ohne Downtimes operativer Systeme durchgeführt werden. Dazu kommt, dass es bei einer Modernisierung immer einen Proof of Concept inklusive Pilotphase gibt, was im Grunde nichts anderes als eine Spiegelung des Gesamtprojektes ist.

Viele Unternehmen bedenken nicht den monetären Schaden, den sie verursachen können, indem alte Systeme nicht modernisiert werden.

Unsere Folgenden Basis-Ansätze haben sich bereits in vielen Situation bewiesen:

1.
Man kann eine Modernisierung niemandem aufzwingen!
Nicht nur das Management muss mitziehen. Auch die Userbasis und Stakeholder müssen mit eingebunden werden. Wenn man die dafürsprechenden Faktoren nicht berücksichtigen will, hat es keinen Sinn eine Transformation anzugehen. Denn eine Modernisierung ohne Zusammenarbeit mit dem Kunden ist unmöglich.
2.
Ängste und Sorgen müssen ernst genommen werden.
Es dürfen keine Fragen offenbleiben. Das Konzept und die Ansätze müssen vollständig und verständlich sein. Der Kunde muss dabei verstehen, wie und mit welchen Mitteln die Analyse und später die Transformation seiner Systeme durchgeführt wird.

Ein zentrales Element unserer Modernisierungs- und Transformationsansatzes ist es, dass sich die Geschäftslogik der Systeme nicht verändert. Sämtliche bestehende Prozesse des Unternehmens müssen und sollten nicht angepasst werden.

Dabei werden auch keine Mittel verwendet, welche die Komplexität beeinflussen. Ebenso dürfen keine Runtime-Environments entstehen. Der Output muss echt sein, denn nur so entsteht nach erfolgreicher Transformation in ein neues System -> beispielsweise „Real Java“.

Zwischen Cobol und Java gibt es vielerlei Unterschiede. Beide Sprachen nutzen Daten und Ressourcen unterschiedlich und auch die Kommunikation weicht stark ab. Dies bedeutet im Umkehrschluss, dass Cobol-Methoden nicht direkt nach Java transformiert werden können, was die Migration des Quellcodes sofort ausschließt.

Und hier haben wir bereits das Problem, welches bei der Nutzung von vielen Konvertern auftritt, denn diese nehmen den kompletten Quellcode und transformieren alles in einen neuen Code.

Warum aber nehme ich Teile eines Codes, die in der neuen Umgebung nicht benötigt werden mit in eine neue Umgebung?

Versteht und verinnerlicht man diese Gegebenheiten, kann eine Transformation mit sehr hoher Selbstsicherheit angegangen werden.
Entscheidend sind dabei das Know-How und die Erfahrung mit Modernisierungen.

Mit diesem fundierten und bereits vielfach bewährten Ansatz hoffen wir unseren Kunden diese Angst nehmen zu können. Denn fehlt diese Expertise bei einem Dienstleister, hätten auch wir Angst vor einer Transformation.

Mit unserem Wissen und praktischen Erfahrungen, sind Modernisierungsprojekte jedoch kein Grund zur Sorge!

Sie haben Fragen?

Unsere Experten aus allen Bereichen unterstützen Sie und stehen Ihnen bei allen Fragen mit Rat und Tat zur Seite.

Oder werfen Sie einen Blick auf unsere Referenzen.