Digital Future Meetup – Softwaremodernisierung
Christoph Kofler:
Wenn du an Digital Future denkst – was hat das eigentlich mit Softwaremodernisierung zu tun?
Also wie entsteht Digitalisierung, Digital Future? Das klingt oft nach dem „neuen heißen Scheiß“, aber eigentlich ist der heiße Scheiß nach einem Jahr auch schon wieder Geschichte. Und genau in dem Moment fängt es wieder an: Software wird modernisiert.
Und das bringt mich zur Frage: Worüber reden wir hier eigentlich, wenn wir von Softwaremodernisierung sprechen?
Wir bezeichnen damit die Modernisierung von Individualsoftware. Und Individualsoftware ist heutzutage Teil von fast allen Produkten – egal ob es Steuerungssoftware ist oder das Produkt selbst.
Modernisierung kann vieles sein: ein kleines Framework-Upgrade, eine Architekturänderung oder gleich die komplette Software in die Cloud. Das ist eine riesige Spannbreite.
Und genau mit diesem Thema wollen wir uns im Digital Future Meetup beschäftigen – in einer Serie über das ganze Jahr hinweg.
Mein Name ist Christoph Kofler. Ich nenne mich Cloud Native Evangelist und Innovation Manager bei Gepardec.
Ja, ich meine die Lederhose ernst – das ist kein Scherz. Wer beim letzten Meetup dabei war, weiß das.
Bei Gepardec unterstützen wir Unternehmen dabei, Cloud-native Technologien zu nutzen. Anders gesagt: Wir helfen bei der Modernisierung von Software.
Bevor wir losstarten, möchte ich kurz das Organisationsteam des Digital Future Meetups vorstellen.
Das ist insofern bemerkenswert, weil wir sehr breit aufgestellt sind:
Einerseits zwei technische Organisationen – Gepardec und das Software Competence Center Hagenberg – und andererseits Agilistas und Viable Projects, die für die organisatorischen Aspekte der Softwaremodernisierung stehen.
Und diese organisatorischen Aspekte sind mindestens genauso wichtig wie die technischen – das haben wir auch in unseren Interviews immer wieder gehört. Genau diese Themen werden wir in den kommenden Meetups näher beleuchten.
Heute geht es darum, euch Erkenntnisse aus einem gemeinsamen Forschungsprojekt mit dem SCCH zum Thema Softwaremodernisierung zu präsentieren.
Ich bitte jetzt kurz die Mitorganisator:innen, sich vorzustellen.
Beatrix (Agilistas):
Hallo, ich bin Beatrix. Meine Heimat ist Software Engineering in Hagenberg.
Ich war über zehn Jahre technisch unterwegs – Projektleitung, Programmleitung – für sehr große Projekte in skalierten Scrum-Umfeldern.
Mittlerweile bin ich selbstständig als Agile Trainerin, Consultant und Coach, mit Schwerpunkt auf SAFe.
Wir bauen hier oft die Brücke zwischen Kanban, Scrum und anderen agilen Methoden. Es macht riesigen Spaß, gemeinsam an diesen Themen zu arbeiten.
Rudolf (SCCH):
Mein Name ist Rudolf … ich bin vom Software Competence Center Hagenberg. Mein Titel ist Research Manager, auch wenn das nicht ganz so cool klingt.
Ich komme ursprünglich aus der Forschung, bin aber seit rund 20 Jahren im SCCH tätig.
Mein Schwerpunkt war lange Softwaretesten und Softwarequalität, später wurde es breiter – heute unterstütze ich Teams strategisch bei Projekten, Architekturfragen und Qualität.
Was mir an Forschung besonders gefällt, ist, Erkenntnisse zu gewinnen und sie in funktionierende Produkte zu übersetzen. Genau das versuchen wir hier.
Christoph Kofler:
Danke euch.
Warum Softwaremodernisierung? Warum ist das für jede einzelne Person hier relevant?
Softwaremodernisierung betrifft fast jede Firma. Software ist Teil fast jedes Produkts. Spätestens ein Jahr nach einem Greenfield-Projekt beginnt eigentlich schon wieder das Refactoring.
Das betrifft wirklich jede und jeden.
Damit es interaktiver wird: Ihr habt sicher die Plakate gesehen.
Die Frage lautet: Was sind eure größten Pains und Gains bei der Softwaremodernisierung?
Pains sind die Schmerzen – was tut weh?
Gains sind die Gewinne – was wird besser, wenn wir modernisieren?
Bitte steht auf, sucht euch ein Plakat aus und ordnet euch zu.
(Publikum bewegt sich, Gelächter)
Christoph Kofler:
Wie gehen wir bei Gepardec das Thema Softwaremodernisierung an?
Wir sind sehr vorsichtig, nicht sofort mit Tools zu starten. Die Gefahr ist groß, dass man glaubt, ein Tool sei die Lösung – ohne das Problem wirklich verstanden zu haben.
Wir arbeiten daher mit einem kundenzentrierten Innovationsprozess, dem Double Diamond aus dem Design Thinking.
Links steht der Problemraum:
Wie modernisiere ich Software?
Wie kann ich schneller modernisieren?
Was gehört überhaupt alles zu diesem Problem?
In diesem Problemraum befinden wir uns aktuell. Erst wenn das Problem wirklich verstanden ist, formuliert man sogenannte How-might-we-Fragen und geht in den Lösungsraum.
Dort entstehen Prototypen, Experimente und am Ende validierte Lösungen – also Lösungen, die der Markt wirklich braucht.
Wir haben Mitte Jänner 2024 definiert, was wir herausfinden wollen:
Ist Softwaremodernisierung ein marktrelevantes Thema für uns?
Wir wollten Kundeninterviews führen, Marktbegleiter analysieren, Whitepaper lesen, Literatur und Videos sichten.
Insgesamt haben wir 18 Interviews geführt. Die Erkenntnisse waren enorm.
Wir haben Angebote analysiert, Studien gelesen – zum Beispiel die Aussage, dass rund 45 % der Softwarefunktionen nicht genutzt werden.
Das wirft die Frage auf: Muss man wirklich alles modernisieren – oder kann man auch Dinge bewusst weglassen?
Ende Jänner, Anfang Februar haben wir einen intensiven Synthese-Workshop gemacht und mit verschiedenen Frameworks gearbeitet – Clusterings, Value Proposition Canvas, „Tal des Elends“.
Dabei ging es immer um die Frage:
Welche Schmerzen treiben Modernisierung?
Welchen Mehrwert bringt sie – technisch und fürs Business?
Christoph Kofler:
Und damit übergebe ich an Ludwig Steindl.
Ludwig Steindl:
Danke.
Ich beschäftige mich seit vielen Jahren mit Software und Softwaremodernisierung. Und ich stelle gern unbequeme Fragen.
Was bedeutet Softwaremodernisierung eigentlich?
Es gibt unterschiedliche Antworten – abhängig vom Stakeholder.
Aus Sicht der Business-Entscheider:innen geht es um Wettbewerbsfähigkeit, Umsatzsteigerung, Kostenoptimierung und User Experience.
Ein klassisches Beispiel ist Mobile Banking:
Früher musste man zur Bank gehen. Heute erledigt man alles am Handy. Das verändert Kundenerwartungen massiv.
Aus Sicht der Entwickler:innen geht es um Developer Experience.
Frameworks sterben nicht nur, weil sie technisch schlecht sind, sondern weil niemand mehr damit arbeiten will.
Wenn ich keine Entwickler:innen mehr finde, muss ich modernisieren – egal wie stabil das System ist.
Architekt:innen wollen Flexibilität, kurze Time-to-Market, Skalierbarkeit.
Doch hier entstehen Spannungsfelder:
Flexibel vs. stabil, schnell vs. sicher – das widerspricht sich oft.
Dann gibt es Compliance und Security.
Diese Gruppe denkt in Konformität, Risiko, Datenverlust und Herstellersupport.
Das ist nicht sexy für Entwickler:innen, aber existenziell für Unternehmen.
Ludwig Steindl:
Modernisierung ist also stakeholderabhängig und baut aufeinander auf.
Fachliche Modernisierung braucht moderne Architektur.
Moderne Architektur braucht technische Aktualität.
Je weiter man nach unten kommt, desto schwieriger wird es, den Nutzen zu argumentieren.
Oben sehe ich den Gewinn.
Unten sehe ich vor allem vermiedene Risiken.
Und Risiken lassen sich schwer verkaufen – bis es knallt.
Ein Beispiel:
Ein Datenbank-Upgrade für 200.000 € wirkt teuer.
Aber wenn es keinen Support mehr gibt und ein Hardwaredefekt alle Daten zerstören kann, werden daraus plötzlich 10 Millionen Schaden.
Softwaremodernisierung ist wie Zähneputzen:
Es macht keinen Spaß.
Aber wenn man es nicht regelmäßig macht, wird es später richtig unangenehm – und teuer.
Christoph Kofler:
Danke.
Jetzt kommen wir zur Podiumsdiskussion mit:
(Vorstellungsrunde folgt – alle berichten aus ihren Rollen und Erfahrungen mit Modernisierung, Migration, Personal, Technologie, Organisation und Change Management.)
Diskussion – Kernaussagen (wortgetreu verschriftlicht):
-
Softwaremodernisierung ist fast immer Change Management
-
Technik ist lösbar – Menschen nicht automatisch
-
Wissensträger müssen mitgenommen werden
-
Agilität und Kultur sind entscheidend
-
Standardisierung hilft, zukünftige Migrationen zu erleichtern
-
Ohne laufende Pflege wird jede Modernisierung extrem teuer
-
Messbarkeit (Dead Code, Nutzung) hilft beim Weglassen
Christoph Kofler (Abschluss):
Zum Abschluss bitten wir euch um Feedback:
Was nehmt ihr heute mit?
Welche Themen sollen wir in den nächsten Meetups vertiefen?
(Mentimeter-Auswertung, Begriffe wie „Dead Code“, „Faktor Mensch“, „Nachhaltige Software“, „Architektur“, „Cloud Migration“ erscheinen.)
Das nächste Meetup findet am 16. Mai 2024 statt.
Thema:
Wie können wir Architekt:innen und Entwickler:innen Upgrades abnehmen, damit sie sich auf fachliche Entwicklung konzentrieren können?
Vielen Dank für eure Aufmerksamkeit.
Pizza und Getränke stehen bereit – genießt den Abend und das Networking.
