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:
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:
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.
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!
