In die Jahre gekommene geschäftskritische Applikationen verhindern oft eine schnelle digitale Transformation. Die komplette Neuentwicklung ist nicht nur teuer und langwierig, sie birgt auch Risiken. Lesen Sie in diesem Whitepaper, wie Sie mit Standardsoftware und Replatforming schneller, kostengünstiger und effizienter zum Ziel kommen.
Inhalt:
In vielen Unternehmen behindern geschäftskritische Legacy-Applikationen die schnelle und gründliche Transformation. Sie lassen sich weder mit Cloud-Ressourcen verbinden, noch in moderne Konzepte wie DevOps oder Container integrieren. IT-Verantwortliche sehen daher oft keinen anderen Weg, als die Anwendungen von Grund auf neu zu entwickeln.
Dieser Ansatz birgt jedoch erheblich wirtschaftliche und technische Risiken. Komplexe Geschäftsprozesse, die sich über Jahre oder womöglich Jahrzehnte hinweg entwickelt haben, in einer komplett neuen Lösung abzubilden, ist eine Mammutaufgabe, die Mannjahre verschlingt und ewig dauert. Am Ende steht womöglich eine Applikationen, die bereits wieder überholt ist.
Dieses Whitepaper schlägt einen anderen, klügeren Weg vor: Eine Kombination aus Standardsoftware und Replatforming mittels Container und Microservices.
Lesen Sie unter anderem:
- Wie Sie Standardsoftware zukunftssicher erweitern.
- Welche Vorteile der Replatforming-Ansatz mit Containern und Microservices bietet.
- Welche Standardsoftware als Basis für das Replatforming geeignet ist.
Originalauszug aus dem Dokument:
Die Grundidee, eine Standardsoftware um individuelle Funktionen zu erweitern, könnte man natürlich auch ohne Microservices realisieren und sich so einen Teil des Aufwands ersparen. Moderne Standardsoftware bietet dem Endanwender die Möglichkeit der individuellen Erweiterung durch spezielle Programmierschnittstellen.
Die Erfahrung zeigt aber, dass das Aufblähen der Standardsoftware durch Customizing, langfristig zum Problem werden kann. Erweitert man die Standardsoftware um die entscheidenden Features, unterliegen diese sofort denselben Restriktionen wie die monolithische Standardsoftware selbst und genau das will man ja vermeiden.
Übertriebenes Customizing kann darüber hinaus sogar die Update-Fähigkeit des Produkts zu gefährden, was sich dann im Betrieb veralteter Versionen mit entsprechenden Release-Staus widerspiegelt.
Der wahrscheinlich schwerwiegendste Customizing-Nachteil ist aber die starke Bindung an den Hersteller der Standardsoftware. Denn anders als bei der Lösung über eine Microservice-Architektur genügt es hier meist nicht, beim Wechsel der Standardsoftware die Schnittstellenschicht neu zu schreiben.
Wird ein Umstieg unumgänglich, verliert man mit dem alten Produkt auch alle dort durchgeführten Erweiterungen und damit genau die Features, auf die es ankommt.
Das lässt man lieber sein und bleibt beim Hersteller, auch wenn es eine bessere Softwarealternative gäbe.