Mythos Nr. 1: Wenn es nicht kaputt ist, sollte man es nicht reparieren
Wenn Sie ein ISV(Softwareunternehmen) sind, der eine Legacy-Anwendung anbietet, dann kommt Ihnen das folgende Szenario vielleicht bekannt vor:
- Ihre Legacy-Anwendung funktioniert gut und erfüllt den vorgesehenen Zweck
- Ihr Produkt ist nach wie vor ein Kassenschlager und generiert stetige Einnahmen!!
Wenn eines oder beide der oben genannten Szenarien zutreffen, was spricht dann für eine Modernisierung Ihrer Legacy-Anwendung?
Die Realität: Ich habe gesehen, wie viele Softwareunternehmen diesem Mythos anhängen, nur um später ihre Kurzsichtigkeit zu bereuen. Selbst wenn Ihre Anwendung nicht kaputt ist, müssen Sie aus den folgenden Gründen eine Modernisierung in Betracht ziehen:
- Ihre Legacy-Anwendung könnte leicht durch einen flinken Konkurrenten mit einer überlegenen, hochmodernen Anwendung ersetzt werden
- Die Modernisierung dient nicht nur der Nachrüstung, sondern auch dazu, Ihre Anwendungen zukunftsfähig zu machen
- Legacy-Anwendungen sind nicht so skalierbar oder flexibel wie moderne Anwendungen und können neue Technologien nicht nutzen, was für die Integration mit anderen Anwendungen in einer Plattformlandschaft unerlässlich ist.
- Die Modernisierung ist die einzige Möglichkeit, Ihre Altinvestitionen zu schützen und den inneren Wert Ihres Produkts zu erschließen!
Mythos Nr. 2: Meine Kunden beschweren sich nicht
Die Realität: Wenn Kunden sich nicht beschweren, bedeutet das nicht unbedingt, dass sie zufrieden und glücklich sind!
- Legacy-Anwendungen erfüllen vielleicht die aktuellen Geschäftsanforderungen Ihrer Kunden, aber sie sind nicht in der Lage, deren zukünftige Geschäftsanforderungen zu erfüllen, insbesondere in einer sich schnell verändernden Technologie- und Geschäftslandschaft.
- Sie können vielleicht Ihre derzeitigen Kunden mit einem alten Angebot halten, aber Sie werden nicht in der Lage sein, neue Kunden zu gewinnen oder Ihr Angebot auf angrenzende Märkte auszuweiten.
- Legacy-Technologien werden zu einem Stolperstein, der Sie daran hindert, das angesammelte, funktionale und fachliche Know-how zu nutzen.
- Ihre Kunden sind sich möglicherweise nicht der Gefahren einer Technologie-/Geschäftsmodellstörung oder der Wettbewerbskräfte, die im Spiel sind, und der Kosten bewusst , die entstehen, wenn Sie nicht modernisieren.
Mythos Nr. 3: Mein Monolith ist felsenfest
Die meisten Legacy-Anwendungen wurden mit einer monolithischen und eng gekoppelten Architektur unter Verwendung herkömmlicher 2/3-Tier-Muster entwickelt. Diese Anwendungen sind in der Regel so konzipiert, dass sie entweder als Systems of Record(SoR, zur Automatisierung von Kerngeschäftsprozessen) oder als Systems of Differentiation(SoD, zur Bereitstellung von Integrations- und Orchestrierungsfunktionen) dienen. Aus dieser Perspektive sindLegacy-Anwendungen stabil und felsenfest. Rechts ?
Die Realität: Nichts könnte weiter von der Wahrheit entfernt sein. Dies ist bestenfalls ein sich selbst aufrechterhaltender Mythos und die Realität ist viel komplexer:
- In großen Unternehmensanwendungen hat die explosionsartige Zunahme der Anzahl von Modulen mit voneinander abhängiger Geschäfts- und Datenlogik zu Spaghetti-Code mit enormer Komplexität geführt .
- Ältere Anwendungen haben oft eine nicht reagierende Benutzeroberfläche, so dass sie auf der neuen Klasse von Geräten nicht dargestellt werden können.
- Monolithische Architekturen und fehlende Trennung von Belangen machen es sehr schwierig, Legacy-Anwendungen zu skalieren
- Monolithische Codebasen sind schwer zu pflegen, und es ist ein Albtraum, inkrementelle Änderungen vorzunehmen und häufige Implementierungen zu unterstützen.
- Fehlende Modularität ist ein großes Hindernis für die Einführung neuerer Technologien
Mythos Nr. 4: Rehosting macht meine Anwendung modern
Rehosting ist eine häufig verwendete Lift-and-Shift-Strategie, die eine schnelle Umstellung von Legacy-Anwendungen auf eine moderne Infrastruktur ermöglicht. Wird durch Rehosting eine Legacy-Anwendung modernisiert?
Die Realität: Mit dem Rehosting wird nur eine teilweise Modernisierung der Infrastruktur erreicht.
- Beseitigt keine der zugrundeliegenden Einschränkungen der Altanwendung in Bezug auf technologische Veralterung, architektonische Einschränkungen und Codekomplexität
- Ohne eine architektonische und technologische Modernisierung kann die Anwendung durch ein einfaches Rehosting nicht die vollen Möglichkeiten einer modernen Infrastruktur und einer Cloud-Bereitstellung nutzen.
Mythos Nr. 5: Eine neue Benutzeroberfläche ist dasselbe wie eine Anwendungsmodernisierung
Ein gängiger Modernisierungsansatz besteht darin, an der Benutzeroberfläche herumzubasteln und ältere Anwendungen für den Web- oder mobilen Zugriff zu aktivieren. Ist ein UI-Facelifting mit einer Anwendungsmodernisierung gleichzusetzen?
Die Realität: Die Modernisierung der Benutzeroberfläche kann der erste Schritt auf dem Weg zur Modernisierung der Anwendung sein und ist somit ein Mittel, aber kein Ziel. Ein UI-Facelift ist nur eine schnelle Lösung, um eine Legacy-Anwendung webfähig zu machen und/oder sie modern aussehen zu lassen.
- Eine wirklich moderne Anwendung benötigt ein responsives UI-Framework, das nur dann gut funktioniert, wenn auch die zugrunde liegenden Technologien und die Architektur modernisiert werden.
- Ein UI-Facelifting ändert das Verhalten der alten Anwendung nicht und trägt nicht dazu bei, sie skalierbar oder erweiterbar zu machen.
- Eine neue Benutzeroberfläche beseitigt nicht die Komplexität des Codes oder die technologischen Beschränkungen einer älteren Anwendung.
Mythos Nr. 6: Durch das Hinzufügen eines Wrappers wird mein Produkt offen
Die Verwendung eines Wrappers zur Erstellung einer Schnittstelle und zur Bereitstellung von Legacy-Anwendungen als Webdienste oder APIs ist ein weiterer beliebter Ansatz zur Modernisierung. Kann man damit wirklich eine alte Anwendung öffnen?
Die Realität: Es hilft nur dabei, den Lebenszyklus der Legacy-Anwendung zu verlängern, beseitigt aber nicht die zugrunde liegenden Zwänge.
- Im besten Fall legt ein Wrapper nur eine bestimmte Schicht offen und erfasst nicht die ganzheitliche Funktionalität der Legacy-Anwendung
- Das grundlegende Verhalten einer Legacy-Anwendung wird weder verändert noch modernisiert
Mythos Nr. 7: Automatisierte Code-Migration löst alle meine Legacy-Probleme
Neben dem Rehosting ist die automatisierte Codemigration eine beliebte Strategie zur Anwendungsmodernisierung. Es gibt viele proprietäre Tools und Dienstleister, die die Migration von Legacy-Code in eine modernere Programmiersprache ermöglichen. Bedeutet das, dass der migrierte Code eine moderne Anwendung ist?
Die Realität: Diese Strategie wird nur zu einer teilweisen Modernisierung des Legacy-Codes führen und nicht zur Modernisierung der gesamten Anwendung.
- Ohne architektonische Modernisierung bleiben die Beschränkungen des alten Codes bestehen
- Ein Monolith wird in einer neuen Technologie neu erstellt, mit all den Komplexitäten der alten Anwendung
- Dies funktioniert oft besser, wenn die Migration von einer früheren Version zu einer modernen Version derselben Programmiersprache oder innerhalb desselben Technologie-Stacks erfolgt.
- Es ist schwer vorherzusehen, wie der migrierte Code funktionieren wird, und man merkt erst, wenn er versagt.
Mythos Nr. 8: Anwendungsmodernisierung ist eine einmalige Angelegenheit
Die Realität: Die Modernisierung ist ein kontinuierlicher Prozess und sicherlich keine einmalige Angelegenheit.
- Das Aufkommen disruptiver Technologieparadigmen ist schwer vorherzusehen
- In einem von Natur aus disruptiven Umfeld sind die geschäftlichen Anforderungen von Unternehmen selten statisch und entwickeln sich ständig weiter.
- Man kann zukunftsfähig sein, aber niemals zukunftssicher.
Abschließende Gedanken
Die Herausforderungen von Legacy-Anwendungen und die technologischen und geschäftlichen Gründe für eine Modernisierung sind hinlänglich bekannt. Dennoch gibt es kein Patentrezept für die Modernisierung von Anwendungen. Es ist wichtig, die Vor- und Nachteile der verschiedenen Modernisierungsansätze zu verstehen, zwischen Mythen und der Realität zu unterscheiden und eine ganzheitliche Strategie für die Schaffung zukunftsfähiger Anwendungen zu formulieren. Modernisierung darf nicht blindlings mit der Beseitigung von Altlasten gleichgesetzt werden, sondern muss als Ansatz zur Nutzung des angesammelten Geschäftswerts und des Fachwissens gesehen werden, um die Anwendung zuverlässig, skalierbar und offen zu machen.
Verfasst von
Kiran Madhunapantula, COO
Kiran Madhunapantula is passionate about radical trends in software development using techniques like Lean Software Development and Scrum, building high-performance teams, and organizing distributed innovation.
Unsere Ideen
Weitere Blogs
Contact



