Digital Future Meetup #2: Effizientes Applikations-Upgrade

Christoph Kofler

Herzlich willkommen zum zweiten Digital Future Meetup mit dem Schwerpunkt Software-Modernisierung. Wir haben dem Ganzen einen ganz komplizierten Titel gegeben – auf den kommen wir später noch zurück.

Mein Name ist Christoph Kofler. Ich bezeichne mich gern als Bergführer für Software-Modernisierung und bin dementsprechend auch ausgerüstet. Ich bin heute dafür zuständig, den roten Faden durch das gesamte Meetup zu führen und ein wenig Kontext zu geben: Was verstehen wir unter Software-Modernisierung, wo stehen wir gerade und was erwartet euch heute.

Der erste Talk kommt von Claudia Maderthaner. Sie ist Senior Developerin bei Gepardec und wird darüber sprechen, wie man mit Individualsoftware dauerhaft „up to date“ bleibt.

Danach begrüßen wir Klaus Klammer von SCCH, unserem Forschungspartner im Rahmen der Software-Modernisierung. Er wird uns zeigen, wie KI bei der Testerstellung unterstützen kann. Das ist ein extrem spannendes Thema, weil wir alle Software kennen, die keine oder kaum Tests hat – und das ist ein echtes Problem, wenn man modernisieren will. Wir hoffen heute auf Lösungsansätze.

Nach diesen beiden Talks gibt es eine 15-minütige Pause, in der wir die Verpflegung eröffnen. Danach geht es mit voller Energie weiter mit Bea.
Bea ist Agile-Trainerin und Katalysatorin – oder wie sie sich selbst nennt: Dramaaufdeckerin, Musterbrecherin, Papiertigerjägerin und Strukturzauberin. Ich arbeite schon lange mit ihr zusammen. Sie ist von der Firma Well Projects, und ihr werdet dann aktiv eingebunden sein – das wird der interaktive Teil des Meetups.

Jetzt starte ich mit unserer Digital-Future-Reise. Wo wollen wir hin, wo stehen wir gerade – geistig und praktisch – beim Thema Software-Modernisierung? Ich nehme euch kurz mit auf diese Reise.

(Musik)

Letztes Jahr haben wir ein Forschungsprojekt zum Thema Software-Modernisierung gestartet und parallel dazu bei Gepardec einen Innovationsprozess angestoßen. Die erste Frage war: Was sind eigentlich die echten Probleme am Markt in diesem riesigen Themenfeld Software-Modernisierung? Man kann fast von Gesundheitsproblemen von Software sprechen.

Wir haben sehr viele Interviews geführt, uns Marktangebote angesehen – absichtlich so, dass man sie nicht einfach lesen kann –, Whitepaper analysiert, Literatur und Videos recherchiert. Kurz gesagt: Wir haben extrem viele Informationen zu diesem Problem gesammelt.

Im nächsten Schritt haben wir diese Erkenntnisse synthetisiert. Dazwischen gab es bereits das erste Digital Future Meetup. Wer war damals schon dabei?
Beim ersten Meetup haben wir Interviewpartner eingeladen, mit ihnen diskutiert und uns reale Herausforderungen, Lösungsansätze und Strategien aus der Praxis schildern lassen.

Danach haben wir die Erkenntnisse weiter verdichtet, verschiedene Frameworks in unserem Innovationsprozess angewendet und sind schließlich bei einer sogenannten „How-might-we“-Frage gelandet. Das ist ein sehr konkretes Problem innerhalb des großen Problemraums Software-Modernisierung.

Uns war klar: Das Thema ist riesig, man muss sich ein konkretes Problem herauspicken, das man wirklich lösen kann. Daraus ist der Titel des heutigen Meetups entstanden:

Wie können wir Architekt:innen und Entwickler:innen das Upgrade von Applikationen abnehmen, damit sie mehr Zeit für fachliche Entwicklung haben, die Applikationen up to date bleiben und Security-Patches schneller integriert werden können?

Security ist dabei einer der großen Treiber.

Heute setzen wir diese Reise fort – mit diesem Digital Future Meetup – und wir freuen uns, dass ihr uns auf dieser Reise begleitet.

(Musik)

Jetzt geht es weiter mit dem ersten Talk.

(Mikrofonwechsel, kurze technische Pause)

Claudia Maderthaner

Herzlich willkommen auch von meiner Seite an alle.

Ich muss gleich vorausschicken: Ich bin kurzfristig eingesprungen. Eigentlich hätte Ludwig diesen Talk halten sollen – falls ihr das so in der Ankündigung gelesen habt. Ich bin heute also der „Ersatz-Ludwig“, hoffe aber, dass ich euch das Thema genauso gut näherbringen kann.

Es geht um die Frage, die wir aus unserer How-might-we-Frage entwickelt haben:
Wie können wir Software dauerhaft aktuell halten?

Dass wir das machen sollen, ist grundsätzlich allen klar – darüber müssen wir nicht diskutieren. Die eigentliche Frage ist das Wie. Denn trotz dieses grundsätzlichen Konsenses gibt es viele Probleme und Hindernisse, warum Updates in der Praxis oft nicht oder nur zögerlich umgesetzt werden.

Der zentrale Konflikt ist immer derselbe:
Updates bringen selten unmittelbar sichtbare Features oder neue Usability. Gleichzeitig konkurrieren sie mit der Feature-Entwicklung – und Features sind das, was man verkaufen und vermarkten kann.

Meine Motivation für dieses Thema kommt stark aus dem Bereich Security. Ich unterrichte unter anderem sichere Informationssysteme, Software-Security ist mir ein großes Anliegen. Genau deshalb ist es so wichtig, Updates nicht aufzuschieben.

Warum brauchen wir Unterstützung bei Upgrades?

Ein zentraler Punkt ist Automatisierung. Wir wollen weg davon, Updates manuell zu analysieren: Welche Änderungen sind nötig? Welche Refactorings müssen gemacht werden? Stattdessen wollen wir möglichst viele Schritte automatisieren und in kleine, regelmäßige Updates zerlegen. Je kleiner und regelmäßiger die Schritte, desto einfacher wird es. Je länger man wartet, desto aufwendiger wird das Update.

Oft kommen bei Updates unerwartete Probleme dazu. Ein klassisches Beispiel ist die Umstellung von Java EE auf Java 17 mit dem Wechsel zu Jakarta. Das bedeutet nicht nur Namespace-Änderungen, sondern viele Library-Updates, API-Brüche und Abhängigkeiten, die nicht mehr weiterentwickelt werden. Das fühlt sich an, als würde man an einem Faden ziehen – und plötzlich löst sich der ganze Pullover auf.

Zusätzlich spielt die Systemarchitektur eine Rolle:
Habe ich einen Monolithen oder viele Microservices? Beides hat unterschiedliche Herausforderungen, aber in beiden Fällen wiederholen sich viele Arbeitsschritte.

Ein weiterer großer Punkt ist die Kultur. Modernisierung braucht Commitment – Zeit, Ressourcen und Unterstützung durch das Management. Lippenbekenntnisse reichen nicht. Man sieht das auch bei großen Playern wie Microsoft, die nach mehreren Sicherheitsvorfällen öffentlich ihre Security-Strategie überdenken mussten.

Unsere Überlegung war: Wie können wir es besser machen?

Wir wollen weg von Big-Bang-Updates – riesige Modernisierungsprojekte – hin zu einem kontinuierlichen Prozess, der parallel zur Entwicklung läuft. Updates sollen kein gefürchtetes Ereignis sein, sondern nebenbei passieren.

Dafür braucht es gute Testqualität. Nur wenn ich mich auf meine Tests verlassen kann, habe ich die Sicherheit, dass Updates nichts kaputt machen. Automatisierung ist hier entscheidend: Alles, was automatisiert läuft, passiert einfach. Man kümmert sich nur noch um Sonderfälle.

In klassischen Entwicklungsprozessen gibt es einen Hauptstrang für Releases und Feature-Branches. Wenn ein kritisches Update kommt, gibt es oft zwei Varianten:
Entweder Feature-Stop und Update-Fokus – oder ein separates Update-Team. Beide Varianten haben Nachteile: Entwicklungsstopps oder Merge-Konflikte.

Unsere Idee ist ein dritter Weg:
Updates werden als Update-Skripte umgesetzt, die laufend auf den aktuellen Entwicklungsstand angewendet werden können. So kann die Feature-Entwicklung weiterlaufen, während die Update-Skripte kontinuierlich getestet und angepasst werden.

Wenn das Update fertig ist, werden die Skripte auf den aktuellen Code angewendet – und das Update ist integriert. Danach läuft der Prozess weiter, weil Software nie „fertig modernisiert“ ist.

Die Vorteile:

• Kein Entwicklungsstopp

• Höhere Effizienz durch Spezialisierung

• Lernen aus jedem Update

• Updates werden Teil des Tagesgeschäfts

• Leichtere Kommunikation nach außen

Wichtig sind:

• Automatisierter Build-Prozess

• Gute Testabdeckung

• Eine gelebte Modernisierungskultur

• Management-Commitment

(anschließende Diskussion, Fragen aus dem Publikum, Erfahrungsberichte zu Release-Zyklen, Update-Strategien und Testautomatisierung)

Publikumsbeitrag:
„Ich finde, aus Entwicklersicht ist es sehr wichtig, dass man möglichst regelmäßig updatet. Es gibt nichts Blöderes, als wenn man irgendetwas einsetzen muss, das schon fünf Jahre alt ist – und man sich dann durch Changelogs wühlt und sieht, was für coole Features es in den neuen Versionen gibt. Das ist irgendwie … persönlich nervig.“

Moderator (Christoph):
„Danke – also es geht auch um Mitarbeiterzufriedenheit auf der Entwicklerseite. Gut, dann kommen wir zum zweiten Teil. Oder – hättest du noch etwas zu sagen?“

Moderator (Christoph):
„Ich stelle kurz vor, weil wir das vorher ganz bewusst auf die Folien geschrieben haben: Die Hauptarbeit macht der Klaus, aber jetzt übernimmt zuerst Mario.“

Mario Winterer

Mario Winterer:
„Ich bin Mario Winterer und im Software Kompetenzzentrum Hagenberg für den Schwerpunkt Engineering Future Systems zuständig. Da geht es im Wesentlichen darum: Wie wollen wir in Zukunft Software entwickeln? Oder: Wie wird Softwareentwicklung – beziehungsweise die Entwicklung softwarelastiger Systeme – aussehen? Und das ist, aus unserer Sicht zumindest, glücklicherweise fast alles, was wir in Zukunft entwickeln.“

„Bevor wir jetzt im Detail darauf eingehen, wie KI bei der Testerstellung unterstützen kann, möchte ich euch kurz auf einen kleinen ‚Landausflug‘ mitnehmen: Wir beleuchten KI in der Softwareentwicklung allgemein und steigen dann etwas detaillierter ins KI-Thema ein.“

„Zur kurzen Agenda: Ich gebe einen groben Überblick über KI in der Softwareentwicklung – und danach übernimmt, wie versprochen, Claus Klammer. Bei ihm geht es dann im Detail um Softwaretesten. Ich glaube, du hast sogar eine Live-Demo geplant – das wird hoffentlich spannend.“

„Die allgemeine Frage ist: Was heißt KI in der Softwareentwicklung? Das KI-Thema ist gerade ein riesiger Hype – alle sprechen darüber, alle stürzen sich drauf. KI bedeutet im Prinzip künstliche Intelligenz. Der Begriff wurde schon in der letzten Jahrhundertmitte geprägt. Und was man damals schon erkannt hat: Maschinelles Lernen ist der Kern – wie bringt man einen Computer dazu, Wissen zu erwerben, statt alles als Algorithmus ‚hart‘ runterzuprogrammieren?“

„Im Bereich Machine Learning gibt es unzählige Methoden – hunderte, wahrscheinlich tausende. Ein kleiner Bereich davon ist das, was wir aktuell besonders stark wahrnehmen: Large Language Models und Generative AI. Also: Wie kann ich auf Basis von Input textuelles Output erzeugen, das wie von einem Menschen wirkt? Und wie kann ich einen Chatbot bauen, der so wirkt, als ob ein Mensch dahintersteckt?“

„Wenn man sich das anschaut, sieht man eine relativ kurze Zeitleiste der wichtigsten Modelle – kurz vor der Pandemie geht’s richtig los. Da ist irgendwo GPT, dann GPT-4, dann viele Open-Source-Modelle und kommerzielle Modelle: GPT, Gemini von Google, Llama von Meta und so weiter.“

„Und man kann sich fragen: Ist das nur ein Hype, den man ignorieren kann – und in ein paar Jahren ist wieder alles wie vorher? Wenn man sieht, wie stark alle großen Player investieren – ganze Entwicklungsteams, riesige Budgets – dann wird klar: Ganz ignorieren kann man das wahrscheinlich nicht.“

„Ein zweites Indiz: Wie lange hat es gedauert, bis eine Technologie 100 Millionen Nutzer erreicht? Bei Uber, Twitter, Spotify sprechen wir von mehreren Jahren. Instagram und TikTok waren schon deutlich schneller. ChatGPT hat diese Marke in rund zwei Monaten erreicht. Das zeigt: Das ist nicht nur eine Nischen-Community.“

„Natürlich ist das Internet voll mit Leuten, die behaupten, man könne in fünf Minuten drei Spiele entwickeln und damit Geld verdienen. Das sind oft Märchen – mit einem Körnchen Wahrheit, aber man darf es nicht zu sehr für bare Münze nehmen. Deshalb schauen wir uns lieber die professionellere Seite an.“

„Das ist nur ein Auszug an Tools, die für KI-basierte Entwicklung verwendet werden. Ganz oben GitHub Copilot. Wer hat damit schon gearbeitet? Wer hat überhaupt schon mal KI eingesetzt – ChatGPT zum Beispiel? (Viele Hände.) Genau – fast alle haben KI schon genutzt, um Code zu generieren.“

„Und das ist wirklich nur eine kleine Liste: Wir haben recherchiert, da gibt es über 30 oder 40 Tools, und die Liste ändert sich fast wöchentlich. Amazon hat CodeWhisperer, es gibt Codium, Tabnine, und viele mehr.“

„Aber KI betrifft nicht nur Coding. Das ist zwar der größte und naheliegendste Bereich – weil LLMs sehr gut programmieren können und auch sehr viel Code als Trainingsdaten hatten. Aber es gibt viele weitere Bereiche im Software Engineering:“

• „Testing und Testcode-Generierung – dazu sagt Claus gleich mehr.“
• „Requirement Engineering: unstrukturierte Anforderungen in ein strukturiertes Requirements-Dokument bringen.“
• „Projektmanagement: Backlogs generieren, User Stories ausformulieren.“
• „Design: Wireframes aus Prosa-Beschreibungen ableiten – nicht perfekt, aber ein Startpunkt.“
• „Systemarchitektur: schwieriger, weil der Kontext bei großen Systemen oft fehlt.“
• „Deployment: CI/CD-Pipelines, Infrastructure-as-Code, Konfigurationen generieren.“
• „Operations: Diagnose, Root-Cause-Analyse auf Basis von Logs und Fehlermeldungen.“

„Das soll nur ein Überblick sein – damit klar wird: Es geht nicht nur um Codegenerierung. Es gibt viele Felder, in denen sich KI langsam hineinentwickelt.“

„Und damit übergebe ich an Claus Klammer, der euch über das eigentliche Thema Software Testing mehr erzählen wird. Danke.“

Claus Klammer

Claus Klammer:
„Danke Mario. Wie wir schon bei der Einleitung gesehen haben, haben wir Large Language Models gewählt, weil sie allgegenwärtig sind und weil KI damit in der Allgemeinheit angekommen ist.“

„Ich möchte zuerst einen Schritt zurückgehen: Was hat sich in der Historie der Softwareentwicklung – speziell beim Testen – getan? Wenn Software früher klein war, wurde klassisch am Ende getestet (Wasserfall). Irgendwann wurde das zu mühsam, also hat man begonnen, zu automatisieren. Dann kamen die Webapplikationen, UI-Automatisierung, Browser-Frameworks.“

„Inzwischen werden Systeme immer komplexer, der Funktionsumfang explodiert – und gleichzeitig kommt der Druck: schneller liefern, häufiger releasen. Ein wichtiger Schritt war deshalb Continuous Testing: Tests laufen in der CI-Pipeline direkt bei jedem Commit.“

„Das ist auch notwendig – nicht, weil wir das aus Spaß machen, sondern weil man die Abhängigkeiten in vernetzten Systemen sonst nicht mehr beherrscht. Gleichzeitig hinkt Testen gefühlt immer hinterher. Oft nicht, weil Entwickler nicht wollen – sondern weil bei Zeitdruck Testen als erstes gekürzt wird. Auf diese Frage sollte es eigentlich nie hinauslaufen.“

„KI ist als Begriff nicht neu – ungefähr um 1950 hat man erstmals beschrieben, dass Maschinen lernen könnten: durch Beobachtung, durch Daten, durch Ableitungen. Im Testing gab es in der Forschung schon lange KI-Methoden – und jetzt springen wir auf den aktuellen ‚Hype-Zug‘ mit LLMs.“

„Grundsätzlich läuft Testing parallel zum Softwareentwicklungszyklus: Testplanung, Testfallentwicklung, Testumgebungen, Ausführung, Reporting, Rückkopplung. Idealerweise passiert das kontinuierlich – in der Realität klappt das nicht immer.“

„Die Vision, die viele heute zeichnen, ist autonomes Testen – ähnlich wie autonomes Fahren: ‚Test-AI, hier ist mein System, bitte teste.‘ Oder: ‚Sag mir, wie ich testen soll.‘“

„Was erwarten wir uns davon? Weg von repetitiver Arbeit, hin zu explorativem Testen. Realistischere Simulationen. Bessere Diagnose. Selbstheilende Systeme. Tests, die sich mit dem System weiterentwickeln. Und vor allem: mehr Automatisierung.“

„Ein spannender Punkt ist die Testgenerierung: Reinforcement Learning kann zum Beispiel Navigation über UIs lernen. Und LLMs sind besonders gut bei Text-Input – sie können aus dem Kontext ableiten, ob ein Feld eher Name oder Telefonnummer ist, was man sonst mühsam händisch programmieren müsste.“

„Außerdem ist es interessant, weil Systemtester:innen häufig keine Programmierer:innen sind. Wenn KI natürliche Sprache in Automatisierung übersetzen kann – etwa: ‚Navigiere zum Warenkorb und bezahle‘ – dann wäre das ein echter Hebel.“

„Es gibt aber klare Herausforderungen: Datenverfügbarkeit, Toolintegration, Kosten, Ethik, und vor allem: Wie testet man das Testing-Tool selbst?“

„Wir arbeiten an einem Prototypen, der Systemtests mit LLMs unterstützt. Wir verwenden dafür Gherkin-ähnliche Testskripte (Given/When/Then) und lassen Agenten daraus automatisierte Playwright-Tests erzeugen und ausführen. Das ist ein Prototyp – die Ergebnisse sind probabilistisch, nicht so deterministisch wie handgeschriebene Tests. Aber: Wenn man das mehrfach ausführt und es stabil funktioniert, kann es trotzdem ein nützliches Signal liefern.“

„Und eine wichtige Erkenntnis bleibt: Das größte Problem ist oft nicht das Tool – sondern dass Systeme grundsätzlich schlecht testbar sind. Beobachtbarkeit ist ein Schlüsselfaktor (z. B. OpenTelemetry).“

„Autonomes Testing ist visionär, aber wir bewegen uns Schritt für Schritt in diese Richtung. Unsere Aufgabe ist es, Firmen dabei zu unterstützen, die Grundlagen zu schaffen.“

„Danke – und sorry für die Holprigkeiten.“

Moderator (Christoph):
„Danke! Nutzt die Pause, geht auf Claus zu und stellt Fragen. Wir machen jetzt 15 Minuten Pause, dann geht’s weiter.“

 

Dieter Strasser

Also was … Wahnsinn, oder? Der Mario zeigt uns da etwas von 2018, der Klaus sagt: „Die sind jetzt auf Stufe 2, Stufe 5 ist dann die große Offenbarung.“
Ich glaube, man muss immer schauen, ob nicht der Terminator irgendwann hinten daherkommt, mit den Maschinen die Menschheit übernimmt und alles dominiert.

Ja, weil du da, Chris, unser Bergführer, hast am Anfang so schön von Strategie und Execution und Plan und so weiter gesprochen – so schöne Datenstrukturen, das unterrichtest du, das zeigst du. Und ich habe letztens in einem Training mit meinen Teilnehmern den Zweck einer Übung durch KI erstellen lassen. Die haben geschaut: „Das passt ziemlich gut.“ Das kann man schon viel im Alltag verwenden – aber man muss halt aufpassen, hat uns der Klaus gesagt.

Ja, mit Testen bist du fertig … das ist schon Wahnsinn. Technik überall.

Und dann die Claudia, die uns gesagt hat, wie wichtig diese Kontinuität ist: welche Fallstricke es gibt, und dass man so vieles automatisieren sollte. Ich bin total voll – Prozesse hat sie erzählt, Technik hat sie erzählt.
Und ich hab mir gedacht: „Boah, bist du fertig – wo sind eigentlich die Menschen?“

PowerPoint – das steht nicht für PowerPoint, sondern für People, Process and Technology. Und gerade wenn es um Software-Modernisierung geht, konzentrieren wir uns immer auf den Process- und Technology-Teil. Aber genauso wichtig ist der People-Teil.

Bei der Claudia ist das ein bisschen angeschwungen, wie hat sie das genannt … Update-Kultur oder Modernisierungskultur? Management-Commitment. Sie hat Management gesagt, ein paar Sachen sind angeschwungen – aber die werden immer nur gestreift. Stiefmütterlich fast.

Ich bin mir ein bisschen vorgekommen wie … Softwarefirma geht’s, und immer geht’s um Implementation, und da waren so lästige Menschen, die dann doch was tun müssen. Menschen sind tatsächlich ein Problem.

Beatrix Gottanka

In der Organisation – weil viele … ach so: Menschen kennen Widerstand. Wenn ich jetzt hergehe und sage: „Wir wollen modernisieren“ – die Claudia hat sogar gesagt: „Da gibt’s Widerstand.“ Wirklich. Da ist Widerstand.

Wir als Menschen streben nach Stabilität, nach Sicherheit. Wenn wir morgen in die Arbeit gehen, übermorgen in die Arbeit gehen und nächste Woche in die Arbeit gehen, wollen wir, dass alles gleich ausschaut, dass man die gleichen Leute trifft. Das ist so wie, wenn ich vom Bahnhof daher immer den gleichen Weg gehe, damit ich zur richtigen Zeit ankomme.

Natürlich: Warum haben wir Widerstand? Kontrollverlust.

Gerade bei der Software-Modernisierung wissen wir ja gar nicht, wie groß das Risiko ist, wenn wir irgendwas ändern. Da draußen hängt irgendwas dran, was man nicht kennt – das muss man jedenfalls wissen.

Sobald wir was ändern wollen – und Software-Modernisierung ist Veränderung – wird’s Widerstand geben. Das ist im Menschen so drin.

Warum ist das so? Das Verlassen der Komfortzone und der Kontrollverlust tun ein bisschen weh. Manche finden das Neue cool zum Spielen – manche haben einen kleineren oder größeren Widerstand.

Was Organisationen verstehen müssen: Wir haben sehr viel mit Menschen zu tun. Und Menschen sind eben keine Maschinen.

Ich hab da … Maschine: Ticketmaschine. Input und Output sind ziemlich klar. Ich schmeiß oben eine Münze rein, ich suche mein Ticket aus, Ticket kommt raus, Rest kommt raus. Je nach Maschine kann das kompliziert werden – aber nicht komplex. Ursache-Wirkungsbeziehung ist klar.

Beim Menschen nicht. Ein Mensch ist ein komplexes Wesen – das heißt, wir haben sehr viele Einflussfaktoren. Und der Output ist nicht vorhersehbar.

Jeder Mensch ist kompliziert – und komplex.

(Zwischenruf / Korrektur aus dem Raum)
Entschuldigung – das war falsch, danke fürs Aufpassen.

Aber der Klaus hat noch was dazu gesagt: Internet of Things – das macht auch Komplexität.

Was ist Komplexität? Komplexität ist, wenn wir es mit verschiedenen Einflussfaktoren zu tun haben, wo wir nicht wissen, wie groß deren Einfluss auf unser System ist. Und wir kennen auch nicht mehr alle Einflussfaktoren.

Bei Menschen sind Einflussfaktoren zum Beispiel: Genetik, wie wir aufgewachsen sind, Religiosität, Erfahrungen, kognitive Fähigkeiten, emotionale Intelligenz – und sogar banale Dinge wie: Wie haben wir geschlafen? Das hat Einfluss auf unseren Output.

Das bringt mich auf die Idee … ich habe für Christopher Everett so ein Responsibility-Process … und der sagt immer: „Teamsport ist Individualsport.“ Wir müssen bei uns selbst anfangen, uns klar zu werden, was da los ist. Und das ist nicht immer das Gleiche.

Änderung fängt bei uns selber an.

Jetzt haben wir dieses komplexe System „Mensch“ – und jetzt können wir uns ganz viel Spaß daraus machen und ein paar von diesen komplexen Wesen in ein Team stecken. Und der Chris zieht uns rauf mit seinem Seil als Bergführer – und trotzdem: Wir müssen es selber machen. Blöd, wenn man über Änderungen redet, über Software-Modernisierung redet, und vor allem über Architekturänderungen.

Und in dem Zusammenhang darf man Conway’s Law nicht vergessen. Die meisten von euch kennen es, aber ich sag’s trotzdem kurz:
„Any organization that designs a system (in our Fall: Softwareprodukt) will produce a design whose structure is a copy of the organization’s communication structure.“

Was immer wir bauen, wird unsere Unternehmensorganisation widerspiegeln. Die Grafik haben wir von Martin Fowler geklaut: „Designs reflect communication.“ Da sieht man Teams, zum Beispiel Ostküste/Westküste USA, Zeitunterschied, wenig Verbindung – und so schaut dann auch die Kopplung im System aus.

Wofür ist das gut? Wenn ich eine Architekturänderung vornehmen muss, muss ich schauen: Passt das überhaupt zu meiner Teamstruktur? Oder behindert meine Teamstruktur sogar das, was ich vorhabe? Wie leicht ist das für Teams anzunehmen? Und ist uns das bewusst? Ist uns das klar? Ich glaube nicht – aber man kann es sich bewusst machen.

So. Das müssen wir wissen: Widerstand. Wie Menschen ticken. Conway. Und … es gibt auch sowas wie Unternehmenskultur.

Nicht schon wieder ein Gebiet – aber das hat einen wahnsinnigen Einfluss darauf, wie leicht wir Software-Modernisierung schaffen.

Unternehmenskultur sind Werte, Normen und Verhaltensweisen in einer Organisation. Und es ist nicht das, was HR auf Hochglanzposter druckt, sondern das, was tatsächlich beobachtbar ist: Wie die Leute wirklich handeln.

Als Consultant in vielen verschiedenen Firmen kann ich sagen: … naja.

Firmen haben auch einen Rucksack: Wer sind die Gründer? Wie alt ist die Firma? Altersstruktur? Diversität? Wie kommuniziert man? Sind alle colocated oder verteilt?

Und das hat Einfluss auf Agilität. Agilität im weitesten Sinn: Die Fähigkeit einer Organisation, sich anzupassen und auf sich ändernde Umstände zu reagieren.

Die Unternehmenskultur hat Einfluss auf diese Fähigkeit – und diese Fähigkeit wiederum beeinflusst die Unternehmenskultur. Jetzt muss man nachdenken … mir kommt es vor wie dicke Tanker.

Manche Firmen sind dicke Tanker, manche sind Schnellboote. Titanic … dann kommt der Eisberg und dann gibt’s nichts mehr zu modernisieren.

Was ist besser, was ist schlechter? Schnellboote kommen nicht über den Ozean. Es braucht ein bisschen beides: Stabilität, aber auch Anpassungsfähigkeit.

Und meistens entstehen dadurch Konflikte und Spannungen. Das ist nicht automatisch schlecht, aber es reibt. Reibung ergibt Wärme. Darum habe ich das mit einer Flamme dargestellt. Je mehr Reibung, desto größer die Flamme. In manchen Firmen ist es eine riesige Flamme, in manchen klein. Die Flamme ist immer da.

Wie kommen wir raus aus diesem Tanker-Ding? Wie kommen wir dahin, dass wir auch Schnellboote können?

Bevor wir das beantworten, schauen wir kurz: Was verursacht große Flammen?

Ich habe ein paar Zitate für euch – die kennt ihr vielleicht:

• Projektleitung: „Modernisierung gehört nicht zum Umfang dieses Projekts.“

• IT-Leitung: „Ich habe Angst vor den Risiken.“

• Produktmanagement: „Wir können uns das nicht leisten, die Roadmap ist für die nächsten drei Jahre fix.“

• Entwicklungsleitung: „Unsere Systeme funktionieren gut – warum reparieren, was nicht kaputt ist?“

Never change a running system.

(Gelächter / Kommentare aus dem Raum)

Okay. Blöd das hinzunehmen. Wir überlegen uns lieber, wie es anders gehen kann.

Wie kommen wir über diese Widerstände drüber? Wir wollen dahin, was Claudia gesagt hat: dieses kontinuierliche Mitdenken von Software-Updates.

Und jetzt: Viele Gehirne denken besser als meins – das gerade mit Bier geflutet wird.

(Gelächter)

Wir finden das gemeinsam heraus in einer Gruppenarbeit.

Ich habe vier Personas vorbereitet: Produktmanager, Entwicklungsleiter, Softwareentwickler:innen und Entscheidungsträger:innen. Jede Gruppe überlegt, wie man diese Person davon überzeugt, Software-Modernisierung Priorität einzuräumen.

Jede Gruppe bekommt ein Handout mit Unterfragen, Flipchart ist vorbereitet. Bitte nominiert eine:n Sprecher:in, um die Ergebnisse vorzustellen. Ihr habt 12 bis 15 Minuten Zeit. Wenn es gar nicht geht, dann fünf – länger nicht.

Gruppenpräsentationen

(Unklarer Übergang / Zwischenrufe und Gesprächsfetzen, teils unverständlich im Ausgangsmaterial)

Publikum / Gruppe (teilweise unverständlich):
… real scenario … Firma hat schon Vergangenheit … Entwickler fangen gar nicht bei mir mehr an … „mit dem veralteten Zeug fang ich nicht an“ … wir wollen eine flashy Webseite …

… vulnerabilities … Security-Karten, rote Karten … Unterstützung von anderen Stellen in der Firma … menschlich vielleicht auch Stolz, cooles Entwicklungsteam …

Gruppe „Produktmanager“ (Sprecher:in unklar – wirkt wie Christoph Kofler oder jemand aus der Gruppe)

Produktmanager überzeugen: Wenn wir Modernisierung durchziehen, können wir in Zukunft Features schneller entwickeln, weil wir kürzere Zyklen realisieren können.

Die Qualität wird besser, weil wir Testautomatisierung haben, weil wir Coding-Standards automatisiert prüfen – dadurch weniger Fehler. Und wenn weniger Fehler da sind, bleibt wieder mehr Zeit für Feature-Entwicklung.

Wir bekommen früheres Feedback, weil wir schneller releasen. Dadurch sind auch Experimente möglich: unterschiedliche Feature-Varianten ausrollen und mit A/B-Testing prüfen, was besser funktioniert. Mit Feature-Flags Dinge vorbereiten und schrittweise freischalten – und wenn’s nicht gut ist, deaktivieren und wieder rausnehmen.

Durch all diese Maßnahmen sollten auch die Betriebskosten sinken. Weil: Mit Automatisierung brauche ich nicht mehr ständig manuell nachkontrollieren. Ich habe Monitoring, das mich automatisch informiert, wenn Dinge im Betrieb in die falsche Richtung gehen.

Vielleicht ist es die KI, die sagt: „Hallo, die Performance entwickelt sich in eine Art, die wir nicht wollen.“

Und man muss es natürlich auch bringen: Compliance-Anforderungen – sei es durch Gesetzgeber oder andere Vorgaben – müssen erfüllt werden.

Danke.

Gruppe „Softwareentwickler:innen“ (Sprecher:in unklar)

Wir haben als Softwareentwickler:innen viel mit Learning Experience zu tun: neue Tools, neue Frameworks, Neues ausprobieren. Ich behaupte: Die meisten Softwareentwickler haben einen starken Entdeckertrieb.

Das motiviert auch schnellere Feature-Entwicklung. Man muss nicht zwei Wochen gegen ein veraltetes Framework kämpfen, bis ein Button richtig funktioniert.

Man kann Mitspracherecht beim Tooling einräumen: Framework A oder B – wer Erfahrung hat, kann empfehlen oder abraten. Man greift institutionelles Wissen ab.

Mit neuen Tools kann man leichter updaten – alte Tools sind meistens sperriger und schwieriger zu handhaben.

Das spielt auch in Learning hinein: neue Frameworks, neue Architekturen, Sachen ausprobieren.

Und zu guter Letzt: Wir haben viel Zuckerbrot, aber wir brauchen auch ein bisschen Peitsche. Wer keine neuen Sachen verwenden will, muss die alten verwenden.

(Zwischenrufe / Gelächter)

Gruppe „Entscheidungsträger:innen“ (Sprecher:in unklar, Abschnitt teilweise schwer verständlich)

Entscheidungsträger überzeugen: Wir haben diskutiert, dass es teilweise zwar „brennt“, aber nicht immer sichtbar ist.

Es gibt das Thema: Bibliotheken aktualisieren, Software auf den Stand bringen, vor allem was Security betrifft.

Ein Argument ist die Personalsituation: In den nächsten Jahren gehen Leute in Pension. Systeme bleiben. Wir hatten Praktikanten oder neue Leute von der Uni – und wenn das System veraltet ist, fangen die gar nicht erst an oder sagen: „Mit dem alten Zeug interessiert mich das nicht.“

Das wirkt auf Mitarbeiterzufriedenheit und Recruiting.

Dann natürlich Security: Wenn wegen fehlender Updates Daten geklaut werden – das will man nicht. Heute gibt es fertige Bausteine, Technologien, Bibliotheken, die weiterentwickelt werden. Wenn man das nicht nutzt, belastet man sich selbst.

Compliance: Anpassung an Gesetze und Vorgaben.

Und: Es kommen neue Anforderungen von Kunden. Man glaubt, man ist fertig – aber rundherum entwickelt sich alles weiter. Es ist wie ein Fluss, man bleibt sonst hinten nach.

Risiko war auch ein Punkt: Modernisierung kostet kurzfristig und ist riskobehaftet. Der Vorschlag war: Evolution statt Revolution – iterativ vorgehen. Wir wollen nicht alles auf einmal, sondern schrittweise.

Danke.