DDC hakt nach: Wie baust Du eine Softwarearchitektur ohne Schuldenfalle auf?

Cloud hier, KI da – und dann auch noch Clean Architecture! Wer heute Software entwirft, braucht mehr als Diagramme und Buzzword-Bingo. David Tielke weiß: Die eigentliche Herausforderung liegt nicht in fancy Patterns, sondern im Alltag. Wie genau das zu erreichen ist, erfährst Du in seinem Workshop auf der .NET Developer Conference 2025. Hier verrät er, wie Architektur wirklich zukunftsfähig wird – nämlich, indem sie in der Gegenwart nicht schon kollabiert.

Du redest von Flexibilität als DEM Qualitätsmerkmal moderner Architekturen. Wo liegt denn der Sweet Spot zwischen "flexibel für die Zukunft" und "funktioniert heute ohne Kopfschmerzen"?

David: Der Spagat, den wir in der Softwarearchitektur jeden Tag haben, ist weniger zwischen Gegenwart und Zukunft. Die Realität ist, dass Projekte zu großen Teilen sehr funktionsgetrieben entwickelt werden. Das heißt: Über Jahre oder gar Jahrzehnte wurde die Entwicklungszeit überwiegend für die Entwicklung von Funktionen investiert und weniger für die Qualität der Software.

Dadurch sind in der Gegenwart die Projekte oft durch sehr viele Schulden belastet – meist strukturelle Schulden, technische Schulden etc. Diese Situation erzeugt bereits in der Gegenwart erhebliche Probleme und lässt natürlich auch wenig Handlungsspielraum für die Zukunft zu.

Ich denke, bei dem angesprochenen Sweet Spot geht es weniger darum, wie man eine Architektur so entwirft, dass sie in Zukunft flexibel ist (das ist vergleichsweise einfach), als vielmehr darum, eine einfache und flexible Architektur in der Gegenwart zu haben, die mit wenig Schulden implementiert ist. Dann ist der Gestaltungsspielraum für die Zukunft recht groß und mit wenig zusätzlichem Aufwand zu bewerkstelligen.

Anzeige

🛠 Training: Architektur meistern in .NET-Projekten

Du entwickelst mit .NET und trägst gleichzeitig die Verantwortung für die Architektur? David Tielke zeigt Dir in diesem intensiven DWX-Academy-Training, wie du tragfähige, wartbare und zukunftssichere Architekturen entwirfst – ganz ohne Framework-Overkill, aber mit jeder Menge Praxisnutzen.

Themen: OO-Prinzipien & Metriken, Komponentenbasierte Strukturierung, Inversion of Control, Multi-Layer & Multi-Tier, Referenzarchitektur entwickeln

📅 17. bis 19.11.2025 (remote, öffentlich)

🔗 Gleich anmelden: Nur wenige Plätze verfügbar!

Neue Technologien wie Weiterentwicklungen in Cloud und KI verändern die Spielregeln ständig. Wenn du eine Architektur für die nächsten fünf Jahre planst - auf welche Trends setzt du?

David: Für die Antwort muss man etwas ausholen. Vorab: Aus meiner Sicht sind die Themen Cloud und auch KI in der Softwareentwicklung in Teilen komplett overhyped und die Berichterstattung entspricht nicht der tatsächlichen Situation in den Projekten.

Eine ordentliche On-Premise-Architektur ist meistens ohne Weiteres für die Cloud geeignet – auch wenn es keine der gehypten Cloud-Native-Architekturen mit Microservices oder FaaS-Implementierungen ist.

Eine Architektur richtet sich immer nach den Anforderungen an ein Produkt. Wenn ich also ein Produkt beispielsweise für 100 Nutzer in der Stunde für ein On-Premise-Szenario entwickle, erstellt man dazu eine passende Systemarchitektur, beispielsweise eine 2-Tier-Architektur – wobei ein Tier eine SPA (beispielsweise Blazor) und der zweite Tier das Backend ist.

Diese Architektur kann ich ohne Weiteres in die Cloud migrieren – und zwar ohne viel Aufwand. Dieser Ansatz wird oft als Lift-and-Shift-Variante belächelt mit dem Hinweis: „Das ist so keine richtige Cloud-Anwendung.“

Aus meiner Sicht ist es als Architekt und Architektin jedoch wichtig, die Bedürfnisse des Unternehmens, der Anwendung und der Kunden zu adressieren, anstatt irgendwelchen Begriffsdefinitionen von Cloud-Herstellern hinterherzulaufen. Niemandem (außer den Cloud-Betreibern) ist damit gedient, eine eigentlich funktionierende Architektur mit viel Aufwand für die Cloud neu zu entwickeln – wenn am Ende das Ergebnis nicht besser (meist schlechter) als vorher ist, man aber eine vermeintlich zukunftssichere Cloud-Architektur hat.

Zukunftssicherheit wird nicht durch eine Plattform wie die Cloud bestimmt, sondern einzig und allein durch die Anforderungen – und die kommen am Ende vom Kunden, dem Unternehmen und dem Projekt selbst.

Ändert sich jedoch die Anforderung und das System muss plötzlich mandantenfähig sein und anstatt der 100 10.000 Nutzer in der Stunde bedienen können, ist das natürlich ein anderes Szenario. Solche Anforderungen kommen aber meist nicht von heute auf morgen, sondern kündigen sich über einen längeren Zeitraum an. Hier ist wieder der Architekt gefragt: Diese Rolle ist dafür verantwortlich, solche Informationen und Anforderungen so früh wie möglich einzusammeln und entsprechend in der Architektur zu verarbeiten.

Dasselbe gilt für KI, auch wenn es zwei Aspekte hat: Der einzige Grund, KI in eine Anwendung funktional einzubauen, ist, wenn es dazu Anforderungen seitens der Stakeholder gibt. Kommt eine solche funktionale Anforderung, ist das für die Architektur nicht weiter relevant – da wir in der Architektur für die nicht-funktionalen Anforderungen zuständig sind. Ob eine architekturelle Komponente am Ende durch menschlich geschriebenen Quellcode eine Funktion ausführt oder diese Aufgabe durch eine KI gelöst wird, ist aus architektureller Sicht nicht relevant.

Der zweite Aspekt ist der Einsatz von KI bei der Entwicklung. Hier ist aus meiner Sicht für die Zukunft Vorsicht geboten: Derzeit sind LLMs unglaublich stark bei der Entwicklung von Quellcode, der funktionale Anforderungen umsetzt, allerdings erschreckend schwach bei der Umsetzung der Struktur der Implementierung. Das heißt: Nur weil ein Stück Quellcode, der von Copilot generiert wurde, die gewünschte Funktionalität liefert, heißt das nicht, dass er von der Struktur her (Aufteilung der Klassen und Methoden, Entkopplung von Schnittstellen, Einhaltung von Codierungsvorgaben etc.) in die tatsächliche Anwendung passt.

Deshalb finde ich den Namen Co-Pilot so passend: Solche Tools sind eine echte Waffe – aber nur in den Händen von guten Entwicklerinnen und Entwicklern, die Kenntnisse von Architektur und Design haben. Gibt man sie in die Hände von Entwicklerinnen und Entwicklern, die solche Grundlagen nicht beherrschen, ist es ebenfalls eine Waffe, aber eher eine kontraproduktive.

Ein schlechter Entwickler, der früher pro Tag eine Stunde technische Schulden mit seinem Quellcode erzeugt hat, erzeugt heute mit LLM plötzlich fünf Stunden technische Schulden oder mehr. Daher stellt der unkontrollierte Einsatz von Tools wie Copilot durch unerfahrene Entwicklerinnen und Entwickler für meine Architektur eine reale Gefahr dar, die ich unbedingt entsprechend adressieren muss.

Deshalb ist es auch hier wichtig, sowohl auf die richtige Ausbildung zu achten als auch auf die richtigen Anforderungen in Form von Richtlinien. Habe ich eine gute Ausbildungs- und Anforderungssituation, kann die Produktivität und die Qualität von Entwicklerinnen und Entwicklern auf ein vollkommen neues Niveau gehoben werden. Habe ich diese Situation nicht, stellt sie eine Gefahr für meine Architektur dar. Da sowohl für die architekturelle Ausbildung als auch für Vorgaben durch Richtlinien zu großen Teilen der Architekt beziehungsweise die Architektin verantwortlich ist, sehe ich hier die wahre Herausforderung und Aufgabe der Architekten im Zusammenhang mit der KI.

Diese lange Antwort kurz zusammengefasst: Keiner der aktuellen und zukünftigen Trends in der Softwareentwicklung kommt ohne entsprechende Anforderungen in ein Projekt. Daher ist es aus architektureller Sicht immer wichtig, für eine gute und vollständige Anforderungslage in Projekten zu sorgen. Kommt dann so ein Trend, geht es für Architekten darum, diesen in das System „Softwareentwicklung“ zu integrieren und mögliche Risiken schnell zu identifizieren und entsprechend durch Maßnahmen zu adressieren.

In deinem Workshop geht es um zukünftige Einsatzszenarien - aber mal konkret: Was ist das wildeste Szenario, das du schon mal architektonisch abfedern musstest?

David: Wirklich reale und wilde Szenarien gibt es in der Architektur eigentlich gar nicht – meistens reden wir von Standardprojekten. Beispielsweise riesige Monolithen auf eine moderne Architektur umbauen, eine Anwendung skalierbar und ausfallsicher machen und so weiter. Die wildesten Projekte sind meist die, bei denen versucht wird, ein komplett verhunztes Projekt mit architekturellen Mitteln wieder in Ordnung zu bringen.

Beispielsweise hatte ich vor einigen Wochen ein Projekt, bei dem versucht wurde, jede nur erdenkliche Kundenanforderung in ein Standardprodukt zu integrieren. Das heißt: Auch wenn es ein Produkt war, das für 2000 verschiedene Kunden geeignet sein sollte, wurde bei entsprechendem Geld seitens des Kunden jede mögliche Zusatzfunktion eingebaut, die nur von diesem Kunden genutzt wurde. Das Ende war natürlich, dass im Projekt insgesamt über 10.000 Einstellungsmöglichkeiten enthalten waren und dadurch kaum noch qualitative Ziele wie Wiederverwendbarkeit, Austauschbarkeit, Testbarkeit etc. erfüllt werden konnten.

Wirklich wild sind solche Projekte deshalb, weil an allen möglichen Stellen im Projekt eklatante Fehler gemacht werden (hier beispielsweise in der Vision und der Anforderungsanalyse), aber am Ende versucht wird, diese Fehler mit einer Architektur auszugleichen, die damit gar nichts zu tun hat. Das ist gleichzeitig auch eines der größten Probleme in der Softwareentwicklung allgemein: Zu oft kaschieren und kompensieren Entwickler und Architektinnen die Fehler von Kollegen und Kolleginnen innerhalb des Projektes – wodurch sich leider auch nie wirklich Besserung einstellt.

Die .NET Developer Conference 2025 (DDC) findet vom 24. bis 27. November 2025 in Köln statt. Hier erfährst Du alles rund um Microsoft .NET. Davids Workshop „Moderne Softwarearchitekturen“ findet am Montag, dem 24. November 2025, ab 9.00 Uhr statt. 

Noch kein Ticket? Dann gleich eines holen.