0:00
„Willkommen zum Vortrag über das Thema, warum Softwaremodernisierung oft unterschätzt wird. Wir kommen auf das Thema, indem wir den Startpunkt eines Innovationsprozesses vorstellen, den wir in der gepardec ins Leben gerufen haben. Ich möchte euch für ein paar Minuten in diesen Prozess mitnehmen – dann starten wir mit dem eigentlichen Inhalt. “
0:42
„Unser Innovationsprozess orientiert sich an der bekannten Vorlage des Double Diamond aus dem Design Thinking. Der Kernpunkt: Wir setzen uns intensiv mit dem Problem der Softwaremodernisierung auseinander. Über zwei Monate hinweg haben wir den ‚Problem Space‘ genau analysiert – wo drückt der Schuh am Markt? Wo spüren Unternehmen echten Handlungsbedarf?
Dazu haben wir zahlreiche Interviews geführt, Marktrecherchen betrieben, Wettbewerber analysiert, YouTube-Tutorials studiert und Literatur recherchiert. All diese Erkenntnisse wurden in einem Syntheseprozess verdichtet. Das heutige ‚Kondensat‘ liefert euch die wesentlichen Erkenntnisse, von denen ihr direkt profitieren könnt.“
2:10
„Mit diesen Worten übergebe ich kurz an Ludwig (Kurze Pause: Ludwig meldet sich.)
So, wenn ihr Fragen habt, könnt ihr diese gern im Chat posten. Dann starten wir direkt weiter.“
2:47
„Ich werde heute darüber sprechen, warum Softwaremodernisierungsprojekte scheitern – und zwar in aller Kürze für diejenigen, die wenig Zeit haben. Basierend auf unseren Workshops, Interviews mit Kunden und eigener Erfahrung habe ich drei Hauptgründe identifiziert.
Der wichtigste Punkt: Es fehlt das Bewusstsein und die Kultur für Modernisierung. Wir modernisieren oft erst, wenn wir den Effekt spüren – wenn etwa unsere Applikation gealtert ist und nicht mehr flexibel reagiert. Das führt zu komplexen und teuren Projekten.
Die Punkte zwei und drei leiten sich direkt von dieser Grundursache ab: Modernisierung ist eine aktive, explizite Tätigkeit und kein selbstlaufender Prozess innerhalb unseres Handwerks.“
3:50
„Ein interessanter Aspekt: ‚Komplexer ist komplexer als er hofft‘ – das ist bewusst gewählt. Häufig zeigen sich bei Modernisierungsprojekten erst in der Umsetzung die tatsächlichen Hürden und die daraus resultierende Komplexität. Wenn ich mir vornehme, meine seit Jahren vernachlässigte Software zu modernisieren, plane ich beispielsweise drei Monate und ein bestimmtes Budget ein – doch die tatsächlichen Herausforderungen zeigen sich oft erst während der Umsetzung.“
4:25
„Wir sehen Softwaremodernisierung als eine Pyramide mit drei Ebenen:
- Inhaltliche Modernisierung: Hier geht es um neue Features, etwa um Endnutzer auch über eine App anzusprechen. Diese Ebene spricht Business-Entscheider direkt an, da sie oft einen positiven Einfluss (z. B. mehr Umsatz) haben.
- Architekturmodernisierung: Eine moderne, flexible Architektur ermöglicht es, neue Features effizient und schnell zu entwickeln. Hier müssen Kennzahlen (wie Time-to-Market oder Fehlerquoten) definiert werden, um den Mehrwert auch dem Business aufzuzeigen.
- Technische Modernisierung: Darunter fallen Aktualisierungen der Technologien, Frameworks und Infrastruktur. Ohne eine solide technische Basis fällt auch die Architektur zusammen – vergleichbar mit einem Haus, dessen Fundament stabil sein muss.“
5:42
„Viele fragen sich: ‚Modernisierung klingt toll, aber wie bekomme ich dafür Geld?‘
Ein wesentliches Problem, das wir mit unseren Kunden sehen: Modernisierungen gelten oft als teuer und komplex, weshalb sie extra budgetiert werden müssen.
Bei inhaltlichen Modernisierungen ist der Nutzen unmittelbar spürbar – neue Features, die direkt positive Effekte im Business bewirken. Bei Architektur- und technischer Modernisierung ist das weniger offensichtlich, da die Vorteile erst indirekt über Kennzahlen wie schnellere Markteinführung oder geringere Ausfallzeiten sichtbar werden.
Hier spielt auch das Risiko eine Rolle: Wenn ich beispielsweise keinen Support mehr für meine Plattform habe, kann ein Fehler schnell zu gravierenden Schäden führen. Deshalb muss man das Risiko sowohl in der Tiefe (Schadenhöhe) als auch in der Breite (Wahrscheinlichkeit) messen und kommunizieren.“
11:41
„Ein wesentlicher Punkt: Fehlendes Bewusstsein. Oft wird die Weiterentwicklung von Features höher gewichtet als technische oder architektonische Modernisierungen – bis der momentane Zustand des Systems zu einem echten Problem wird.
Dies führt zu einem fehlenden Commitment und Budget seitens der Entscheider, was wiederum dazu führt, dass bei einer nachträglichen Modernisierung die Kosten-Nutzen-Darstellung schwierig wird.
Zudem sind hohe Aufwände für Tests, Abnahmen und die manuelle Modernisierung häufige Hemmnisse. Viele Kunden modernisieren händisch, was den Prozess langwierig und fehleranfällig macht.“
15:40
„Ein weiterer Begriff, der in unseren Interviews häufig fiel, ist die ‚Spirale der Softwaremodernisierung‘. Dabei fängt man an, an einem kleinen Teil etwas zu ändern, und plötzlich wird das ganze System, bedingt durch zahlreiche Abhängigkeiten, in Mitleidenschaft gezogen. Ein Beispiel: Bei einem JBoss-Upgrade taucht oft auch eine neue Hibernate-Version auf, die sich anders verhält als vor vier Jahren – was zusätzlichen Aufwand bedeutet.
Diese Abhängigkeiten können sich sogar quadratisch vergrößern, weshalb wir unseren Kunden empfehlen, regelmäßig zu prüfen, ob neue Abhängigkeiten wirklich einen wesentlichen Benefit liefern.“
17:30
„Typische Erfolgsfaktoren sind eine schrittweise – idealerweise kontinuierliche – Modernisierung. Anstatt in einem riesigen Schritt von einem veralteten Stand auf den aktuellen Stand zu wechseln, sollten die Schritte klein gehalten werden.
Das hat den Vorteil, dass es leichter in den laufenden Betrieb integriert werden kann und sich auch besser budgetieren lässt.
Ein weiterer kritischer Punkt ist die Testqualität: Je besser die automatisierten Tests (sowohl Unit- als auch Integrationstests) sind, desto reibungsloser verläuft die Modernisierung. Eine saubere Codebasis ist hierbei von zentraler Bedeutung, denn ungenutzte oder veraltete Features belasten langfristig das System.“
20:14
„Ein wesentlicher Erfolgsfaktor ist zudem die Unternehmenskultur: Eine Organisation, die offen für Veränderungen ist und das Bewusstsein für die Notwendigkeit von Modernisierung lebt.
Das bedeutet, dass Modernisierung als fester Bestandteil der täglichen Arbeit etabliert wird – ähnlich wie das regelmäßige Schreiben automatisierter Tests oder das Einhalten von Coding-Standards.
Erfolgreiche Teams haben kurze Entscheidungswege, Vertrauen in die Kompetenz der Mitarbeitenden und geben Verantwortung ab. Ein Zitat aus unseren Interviews verdeutlicht das: ‚Wenn wir blind auf unsere Endkunden hören würden, hätten wir heute kein System – der Kunde hätte nicht, was er braucht.‘
Dabei muss auch die Marktbeobachtung eine Rolle spielen: Architekten sollten aktiv den Puls der Zeit wahrnehmen, um frühzeitig auf künftige Anforderungen reagieren zu können.“
23:04
„Die wesentliche Eigenschaft moderner Architektur ist Flexibilität – sie muss in der Lage sein, sich den sich ändernden Marktanforderungen anzupassen.
Dabei steht Fachlichkeit vor Technologie: Ein neuer Technologie-Stack ist erst dann sinnvoll, wenn er den fachlichen Anforderungen gerecht wird.
In der Praxis bedeutet das, dass Architekten nicht nur den neuesten S*eiß einbauen, sondern eine Lösung entwickeln, die die aktuellen und zukünftigen fachlichen Bedürfnisse – und damit auch die der Business-Entscheider – erfüllt.“
24:03
„Neben der technischen Modernisierung ist es essenziell, Prozesse so zu gestalten, dass Modernisierung und Featureentwicklung Hand in Hand gehen.
Es darf nicht die Wahl zwischen beidem bestehen. Ebenso wichtig ist eine Organisation, die das entsprechende Mindset besitzt.
Wenn diese drei Faktoren – technische Infrastruktur, agile Prozesse und ein modernes, offenes Mindset – zusammenwirken, dann ist die Basis für nachhaltige Modernisierung gelegt.“
25:06
„Damit bin ich mit meinen Punkten für heute durch. Ich lade euch herzlich ein, Fragen zu stellen und Feedback zu geben – auch, wenn ihr Aspekte seht, die ich vielleicht nicht ausreichend berücksichtigt habe.
Im Chat wurden bereits einige Kommentare und Anregungen gepostet. Beispielsweise wurde angemerkt, dass Product Owner lernen müssen, auch einmal ‚Nein‘ zu sagen.
Ein weiterer interessanter Punkt betraf den Einsatz von Feature Flags: Während einige meinen, Feature Flags seien ein Mehrwert zum schrittweisen Ausbau, gibt es auch Stimmen, die sagen, dass deren Implementierung mehr Arbeit bedeutet.
Ebenfalls wurde betont, wie wichtig es ist, Messpunkte in der Software zu implementieren, um zu wissen, welche Features tatsächlich genutzt werden – so kann man sich bei der Modernisierung auf das Wesentliche fokussieren.“
29:05
„Einige Teilnehmer haben zudem darauf hingewiesen, dass Investitionen in Modernisierung langfristig immer auch von der Verfügbarkeit der Ressourcen abhängen.
Manche Kommentare beziehen sich auf die Frage, ob es sinnvoll sei, einmal alle zwei Jahre ein neues Frontend zu entwickeln – wobei hier betont wird, dass moderne Technologien auch die Automatisierung und damit die laufende Aktualisierung unterstützen können.
Letztlich wurde immer wieder deutlich, dass Architekturmodernisierung ein zentraler Hebel für Entwicklungsgeschwindigkeit und Marktreaktionsfähigkeit ist – jedoch nur, wenn auch die technische Basis stimmt.“
31:03
„Zum Schluss möchte ich betonen: Jede Investition in Modernisierung – sei es technisch, architektonisch oder inhaltlich – ist eine bewusste Entscheidung, die klar dokumentiert und nachvollziehbar sein muss. Nur so kann man auch in Zukunft die getroffenen Entscheidungen hinterfragen und gegebenenfalls anpassen.
Ein weiterer wichtiger Aspekt ist der finanzielle Impact von unterlassener Modernisierung. Wir müssen messbar machen, wie sich verkürzte Time-to-Market, geringere Fehlerquoten und verbesserte Betriebsstabilität positiv auf das Business auswirken.“
32:04
„In Gesprächen mit Auftraggebern diskutieren wir oft, wie viel Entwicklungsressourcen eingespart werden können, wenn Modernisierungen durchgeführt werden – etwa eine Einsparung von 20 % über fünf Jahre.
Natürlich ist dies für den Auftraggeber schwer zu verifizieren, wenn er nicht weiß, was ohne die Investition passiert wäre. Deshalb ist es wichtig, alle Metriken – von Time-to-Market über Defektquoten bis hin zu Kosteneinsparungen – transparent zu machen.“
33:04
„Ein sinnvoller Ansatz könnte auch sein, dass Teams kontinuierlich Kapazitäten für Modernisierungsaufgaben reservieren – idealerweise unterstützt durch automatisierte Prozesse.
Ein Kommentar von Michael verdeutlicht, dass zwar Technologien für Upgrades vorhanden sind, aber oft die Prioritäten im Team anders liegen. Sobald ein Feature wichtiger wird als ein Upgrade, rutscht das Modernisierungsprojekt in den Hintergrund.
Dies unterstreicht, wie wichtig es ist, klare Ziele zu definieren und auch unter Zeitdruck die Modernisierung nicht zu vernachlässigen.“
35:43
„Zum Abschluss möchte ich nochmals betonen: Fachlichkeit muss immer vor Technologie stehen.
Unsere Architektur ist dazu da, die fachlichen Anforderungen der Business-Entscheider umzusetzen. Das bedeutet, wir treffen unsere Technologieentscheidungen nicht nur, weil es gerade modern ist, sondern weil sie den tatsächlichen Bedarf erfüllen.
Nur so können wir sicherstellen, dass unsere Systeme auch in 20 Jahren noch effektiv und flexibel sind – und nicht irgendwann in einem Zyklus von Technologieschulden stecken bleiben.“
36:29
„Zum Schluss noch eine Frage: Kann der Einsatz von KI dazu beitragen, den Modernisierungsprozess zu beschleunigen und produktiver zu gestalten?
Meine Antwort: KI kann gewisse Aufgaben unterstützen – allerdings ist das ein eigenes ‚Rabbit Hole‘. Es gibt viele Aspekte, die noch weiter untersucht werden müssen. Danke an Ludwig für die Einsichten aus unserem Innovationsprozess!“
37:23
„Wir kehren nun kurz zum Innovationsprozess zurück. Aufgrund der Erkenntnis, dass die fachlichen Anforderungen immer im Vordergrund stehen und die technische Modernisierung oft hinten bleibt, haben wir uns eine Frage gestellt: Wie können wir Architekten und Entwicklern das Upgrade von Applikationen abnehmen, damit sie mehr Zeit für die fachliche Entwicklung haben?
In diesem Kontext haben wir bei GePathek mehrere Prototypen entwickelt. Wer Interesse hat, Feedback zu geben und von den neuesten Erkenntnissen zu profitieren, dem werde ich nach diesem Webinar eine Aufzeichnung und meine Kontaktdaten per E‑Mail zukommen lassen.“
39:01
„Ich schließe mit einer kurzen Ankündigung: Am 16. Mai findet in Linz das Digital Future Meetup unter dem Motto ‚Softwaremodernisierung‘ statt. Dort nehmen wir euch weiter mit auf diese Reise im Innovationsprozess. Wer Lust und Zeit hat – ich freue mich auf eure Teilnahme!
