![\"\"](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Tecan-Introspect-KeyVisual-1365x1024.webp\")
<\/p>\nWenn gewachsene Software kaum noch wartbar ist, entsteht schnell der Wunsch nach einem radikalen Neustart: alles weg, alles neu, diesmal sauber. Im ersten Teil dieser Reihe hat Thomas Immich das Bild eines KI-Agenten skizziert, der \u00fcberholte Altsysteme in moderne, gut wartbare Anwendungen mit \u00fcberzeugender User Experience \u00fcberf\u00fchrt. Der entscheidende Punkt dabei: Auch problematische Altsysteme enthalten etwas Wertvolles: Sie enthalten bereits umgesetzte Anforderungen. Wie man diese Anforderungen strukturiert aus dem Bestand zur\u00fcckgewinnt und daraus einen KI-gest\u00fctzten, nutzerzentrierten Modernisierungsprozess ableitet, zeige ich in diesem zweiten Teil.<\/p>\n
<\/p>\n
Wenn sich Funktionserweiterungen und Fehlerbehebungen in der eigenen Software wie Jenga anf\u00fchlen, wenn im Planning immer wieder die sprichw\u00f6rtliche Bombe auftaucht und selbst kleine \u00c4nderungen Multi-Sprint-Kettenreaktionen ausl\u00f6sen, ist klar: Das System steht unter Druck. Die naheliegende Frage lautet dann nicht nur, wie man es stabilisiert. Sondern auch, ob man \u00fcberhaupt noch in dieses System investieren sollte. W\u00e4re ein kompletter Neubau nicht konsequenter?<\/p>\n
Die Antwort ist unspektakul\u00e4r, aber wichtig: Es kommt darauf an.<\/p>\n
Bei einer kleinen Nutzerbasis k\u00f6nnen die Risiken eines radikalen Schnitts \u00fcberschaubar sein. Ist die Nutzerbasis jedoch gro\u00df, steigt das Risiko deutlich. Selbst kleine \u00c4nderungen fallen besonders Power-User*innen auf, weil sie etablierte Routinen, Abk\u00fcrzungen und mentale Modelle ber\u00fchren. Wer diese Menschen nicht ausreichend einbindet, riskiert Akzeptanzprobleme genau dort, wo das System im Alltag am intensivsten genutzt wird.<\/p>\n
Hinzu kommt: Software-Entwicklung ist teuer. Eine Modernisierung bietet die M\u00f6glichkeit, Risiken und Kosten bewusst zu steuern, weil nicht alles auf einmal ersetzt werden muss. Stattdessen lassen sich funktionale Bereiche priorisieren, validieren und schrittweise erneuern.<\/p>\n
So k\u00f6nnen Nutzende fr\u00fchzeitig mitgenommen werden. Gleichzeitig sinkt das Risiko, \u00fcber lange Zeit ein neues System zu entwickeln, das am Ende zwar modern aussieht, aber an realen Nutzungsanforderungen vorbeigeht.<\/p>\n
Das st\u00e4rkste Argument f\u00fcr Modernisierung liegt jedoch in den langfristig sinkenden Kosten f\u00fcr Weiterentwicklung und Wartung. Positive Effekte f\u00fcr Marketing und Sales durch eine sichtbar moderne Anwendung kommen hinzu, sollten aber nicht der alleinige Treiber sein.<\/p>\n
<\/p>\n
Abbildung 1 \u2013 Ein gutes UI Design tr\u00e4gt viel zu UX bei, wie das von Centigrade f\u00fcr Tecan Introspect (https:\/\/links.centigrade.de\/en\/references\/intuitive-data-visualisation-laboratory-software)<\/a>. F\u00fcr gute UX sind aber weitere Faktoren entscheidend.<\/em><\/p>\n Entscheidend ist, im gesamten Prozess von der Anforderungsanalyse bis zum Shipment der modernisierten Softwareteile sauber zu arbeiten. Gutes Anforderungsmanagement hilft, sinnvolle Pakete zu schn\u00fcren und den Fokus richtig zu setzen. Prototyping und Usability Testing helfen, nicht nur etwas Neues, sondern das Richtige zu entwickeln. Und eine Design-Spezifikation, die \u201eAI-ready\u201c ist, sorgt daf\u00fcr, dass aktuelle KI-Tools effizient unterst\u00fctzen k\u00f6nnen, ohne dass Qualit\u00e4t und Nachvollziehbarkeit verloren gehen.<\/p>\n Allein dadurch ist aber noch nicht sichergestellt, dass die Anwendung diesmal nicht wieder zu einem schwer wartbaren Frankenstein-System wird. Gerade mit Werkzeugen wie Mistral, Claude, Copilot, Codex & Co. ist ein Feature schnell generiert, ein Pull Request schnell erstellt und der n\u00e4chste Entwicklungsschritt schnell angesto\u00dfen. Wer diesen Geschwindigkeitsgewinn ohne klare Architektur- und Qualit\u00e4tsleitplanken nutzt, arbeitet m\u00f6glicherweise direkt auf die n\u00e4chste Modernisierung zu.<\/p>\n Moderne Sprachmodelle sollten deshalb nicht als Abk\u00fcrzung um den Prozess herum verstanden werden, sondern als Beschleuniger innerhalb eines guten Prozesses. Daf\u00fcr sind bewusste Architektur- und Technologieentscheidungen zentral. Ein moderner Techstack, der aktiv weiterentwickelt wird und austauschbare Einzelteile erlaubt, ist eine Grundlage f\u00fcr Wartbarkeit. Passende Frameworks, Bibliotheken und Standards wie k\u00f6nnen schnelle Feature-Entwicklung unterst\u00fctzen, ohne die Architektur zu verw\u00e4ssern. Visuelle Anpassungen werden etwa durch Tailwind CSS<\/a> oder Framer Motion<\/a> leichter. Und auch k\u00fcnftige KI-gest\u00fctzte Konzepte f\u00fcr Onboarding, Hilfe oder dedizierte Workflows mit KI-Agenten und MCPs lassen sich schneller integrieren, wenn die Architektur darauf vorbereitet ist.<\/p>\n Modernisierung bleibt komplex. Aber mit einem strukturierten, schrittweisen Vorgehen l\u00e4sst sich diese Komplexit\u00e4t steuerbar machen: nutzerzentriert, technisch fundiert und mit einem klaren Blick auf Risiken.<\/p>\n <\/p>\n Bei der strukturierten Modernisierung eines Altsystems sollte der Fokus, wie bei einer Neuentwicklung, auf den Anforderungen der Nutzenden liegen. Sie zeigen, welche Bereiche der Software aus Nutzungsperspektive wirklich wichtig sind. Diese Perspektive sollte ma\u00dfgeblich bestimmen, wo Funktionen erg\u00e4nzt, verbessert oder bewusst unver\u00e4ndert gelassen werden. Denn der Nutzwert einer Software entsteht nicht aus der Menge ihrer Funktionen, sondern daraus, wie gut sie reale Aufgaben unterst\u00fctzt. Genau deshalb ist diese Perspektive auch entscheidend f\u00fcr den ROI von UX auf Basis professioneller mensch-zentrierter Arbeit<\/a>.<\/p>\n Nat\u00fcrlich ist es ebenfalls relevant zu verstehen, wo die gr\u00f6\u00dfte technische Schuld liegt. Aber technische Schuld allein beantwortet noch nicht die Priorisierungsfrage. Warum sollte man zuerst einen Bereich refaktorieren, der nur einmal im Monat genutzt wird, wenn ein anderer Bereich t\u00e4glich Arbeit verlangsamt oder Fehler erzeugt?<\/p>\n Gesucht ist also mindestens der 80-Prozent-Fall: die Bereiche, in denen die t\u00e4gliche Arbeit tats\u00e4chlich stattfindet. Dort hat Modernisierung den gr\u00f6\u00dften Einfluss auf Nutzende, Produktivit\u00e4t und Akzeptanz. Dieses Wissen macht Priorisierungsentscheidungen belastbarer und hilft, Investitionen dort zu platzieren, wo sie Wirkung entfalten.<\/p>\n Wie finden wir heraus, welche Teile der Software wie h\u00e4ufig genutzt werden? \u00dcber Nutzungsdatenanalyse. Sie zeigt, welche Funktionen besonders relevant sind, wo Probleme auftreten und wo Ver\u00e4nderung besonders sensibel ist. In der Praxis setzen wir daf\u00fcr etablierte Tools wie ein, damit Modernisierungsentscheidungen nicht nur auf Bauchgef\u00fchl, sondern auf belastbaren Daten basieren.<\/p>\n Gleichzeitig entsteht ein Bild, das auch f\u00fcr die \u00dcberarbeitung und Neugestaltung der UI-Konzepte zentral ist: Welche Nutzenden verwenden welche Funktionen in welchem Kontext und mit welchem Ziel? Diese Verbindung aus Verhalten, Kontext und Ziel bildet die Grundlage f\u00fcr gute UI-Gestaltung.<\/p>\n <\/p>\n Wenn die relevanten Nutzungsdaten vorliegen, wirkt der n\u00e4chste Schritt verlockend einfach: Kontext sauber aufbereiten, KI-Werkzeuge mit Anforderungen und Architekturhinweisen f\u00fcttern und daraus m\u00f6glichst schnell einen Implementierungsplan generieren lassen. Mit gutem Context Engineering entstehen tats\u00e4chlich erstaunlich schnell Vorschl\u00e4ge, die zun\u00e4chst plausibel klingen.<\/p>\n Genau hier liegt jedoch die entscheidende Grenze. Die risikominimierenden Effekte einer Modernisierung treten nur dann zuverl\u00e4ssig ein, wenn nach dem \u201eReverse Engineering\u201c der Anforderungen auch das \u201eForward Engineering\u201c sauber betrieben wird. Nutzende m\u00fcssen gezielt eingebunden werden, und UX darf nicht nur wie ein Oberfl\u00e4chenversprechen wirken. Sie muss in den Anforderungen, im Konzept, in der Interaktion und in der Umsetzung tats\u00e4chlich angelegt sein.<\/p>\n Ein sauberer Forward-Engineering-Prozess schafft au\u00dferdem die M\u00f6glichkeit, auf Marktver\u00e4nderungen, technologische Weiterentwicklungen und ver\u00e4nderte Erwartungshaltungen von Nutzenden zu reagieren. Diese Erkenntnisse k\u00f6nnen dann bewusst in die modernisierten Teile einflie\u00dfen. Technologie- und Architekturentscheidungen sollten dabei auf einer validierten Gestaltung beruhen, die wiederum aus validierten Anforderungen hervorgeht.<\/p>\n Erst wenn menschliche Intervention, fachliche Bewertung und Qualit\u00e4tssicherung in diesen Prozess eingebettet sind, kann KI den Gesamtprozess sinnvoll beschleunigen.<\/p>\nWie lassen sich Anforderungen aus Altsystemen gewinnen?<\/h3>\n
Warum Vibe Coding allein nicht reicht<\/h3>\n
![\"\"](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/02-NutzerzentrierteSoftwaremodernisierug-1500x694.webp\")
<\/p>\n
![\"\"](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/03-AutomatisierteScreenerstellung-1500x422.webp\")
<\/p>\n![\"\"](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/04-PlanEinfuehrungKiUnterstuetzung-1500x773.webp\")
<\/p>\n