Warum diese Phase unterschätzt wird

Design hat in der Softwareentwicklung ein eigenartiges Doppelleben. Auf der einen Seite gilt es als die kreative, attraktive Disziplin, in der Architekturdiagramme entstehen, Mockups gemalt werden und elegante Strukturen Gestalt annehmen. Auf der anderen Seite wird genau diese Phase im Projektalltag oft als der Schritt behandelt, den man am ehesten verkürzen kann. Schließlich ist „der Plan klar", die „Anforderungen stehen" und Code schreibt sich nicht von allein. Also wird gestartet.

Das Ergebnis ist berechenbar: Was im Design nicht entschieden wird, entscheidet später der Code. Und Code trifft Entscheidungen lokal, situativ und ohne Blick aufs Ganze. Eine Architektur, die nie bewusst gewählt wurde, ist trotzdem da, sie ist nur aus Zufall entstanden. Ein Datenmodell, das nie durchdacht wurde, existiert trotzdem, es spiegelt nur die erste implementierte Tabelle wider.

Die Designphase hat ein paradoxes Imageproblem. Sie wirkt entweder zu künstlerisch oder zu akademisch. Zu künstlerisch, wenn man sie mit UI-Mockups gleichsetzt und für „Optik" hält. Zu akademisch, wenn sie als Abfolge von UML-Diagrammen erscheint, die niemand mehr aktualisiert, sobald die Entwicklung beginnt. Beide Verkürzungen verfehlen den Kern. Design im SDLC ist weder Schmuck noch Bürokratie. Design ist die bewusste Entscheidung, wie etwas gebaut wird, bevor es gebaut wird.

Ein Muster, das sich wiederholt: Ein Team hat eine saubere Analyse vorliegen, klare Anforderungen, priorisiertes Backlog. Statt nun zwei oder drei Wochen in das Design zu investieren, beginnt die Entwicklung sofort. „Wir designen iterativ, im Code." Das klingt agil, modern, pragmatisch. Sechs Monate später hat das System eine gewachsene Struktur, in der niemand mehr genau sagen kann, warum ein bestimmter Service genau diese Zuständigkeit hat oder warum die Authentifizierung an drei Stellen unterschiedlich implementiert ist. Es gibt keine schlechte Architektur, es gibt schlicht keine. Refactoring-Bedarf entsteht nicht erst nach Jahren, er ist von Anfang an eingebaut, nur sieht man ihn nicht.

Was diese Phase wirklich ist

Die Designphase übersetzt validierte Anforderungen in eine technische Form, mit der die Entwicklung tatsächlich arbeiten kann. Was die Analyse als „was und für wen" geliefert hat, wird hier zu „wie". Aus Anforderungen werden Komponenten, aus Nutzerbedürfnissen Oberflächen, aus Systemgrenzen Schnittstellen. Der entscheidende Schritt dabei ist nicht das Zeichnen von Diagrammen, sondern das Treffen von Entscheidungen, die anschließend nicht mehr ohne Aufwand zurückgenommen werden können.

Im Kern beantwortet die Designphase drei Fragen:

• Welche Struktur soll das System haben?

• Wie interagieren seine Teile miteinander?

• Wie begegnet es seinen Nutzern?

Diese drei Ebenen gehören untrennbar zusammen. Eine schöne Oberfläche auf einer instabilen Architektur ist eine Frage der Zeit. Eine elegante Architektur ohne Rücksicht auf den Nutzerkontext ist eine Lösung für ein anderes Problem.

Design lässt sich grob in zwei Stoßrichtungen denken, die in jedem Projekt vorkommen, auch wenn die Gewichtung variiert. High-Level-Design beantwortet die strukturellen Fragen: Welche Komponenten gibt es, wie sind sie geschnitten, wie kommunizieren sie, wo verlaufen die Grenzen zwischen ihnen? Low-Level-Design beantwortet die konkreten: Wie sieht das Datenmodell aus, welche Algorithmen kommen zum Einsatz, wie sind die internen Module einer Komponente aufgebaut? Beide brauchen einander. High-Level ohne Low-Level bleibt unverbindlich, Low-Level ohne High-Level wird zu einer Sammlung lokaler Optima ohne gemeinsame Linie.

Im SDLC steht die Designphase an einer Schlüsselstelle: Sie ist der letzte Moment, in dem fundamentale Strukturentscheidungen mit überschaubarem Aufwand getroffen werden können. Was hier festgelegt wird, prägt nicht nur die Entwicklung, sondern auch das Testing, das Deployment und die Wartung über Jahre hinweg. Eine schwer testbare Architektur produziert teure Testphasen. Ein nicht deploybares Design produziert komplizierte Releases. Eine unverständliche Struktur produziert teure Wartung. Design ist deshalb keine Phase neben den anderen, sondern eine, die in alle nachfolgenden Phasen hineinwirkt.

Das Verhältnis zu den angrenzenden Phasen:

Menschen, nicht nur Prozesse

Design wirkt von außen wie eine technische Disziplin. In Wirklichkeit ist auch das Design ein sozialer Prozess, nur ist die Sozialdynamik hier subtiler als in der Planung oder der Analyse. Sie spielt sich nicht zwischen Fachbereich und IT ab, sondern innerhalb des Entwicklungsteams. Und sie ist deshalb für Außenstehende oft unsichtbar.

Formell sind in der Designphase Software-Architekten, Senior Developer, UX-Designer, Datenmodellierer und je nach Domäne Sicherheits- oder Infrastruktur-Verantwortliche beteiligt. Informell entscheidet etwas anderes: Wessen Architekturpräferenz hat sich in den letzten Projekten durchgesetzt? Welcher Architekt wird häufiger gefragt, weil er Diskussionen offener führt? Wer hat das Standing, eine vorgeschlagene Lösung kritisch zu hinterfragen, und wer schweigt lieber, weil der Widerspruch sozial teuer wäre? Diese Dynamiken bestimmen mit, welches Design am Ende gewählt wird, und nicht immer ist das die technisch beste Variante.

Besonders kritisch ist das Verhältnis zwischen erfahrenen und weniger erfahrenen Teammitgliedern. Senior Developer und Architekten haben Muster im Kopf, die sich in vielen Projekten bewährt haben. Das ist wertvoll, kann aber auch dazu führen, dass Lösungen aus Gewohnheit gewählt werden, nicht weil sie zum konkreten Problem , sondern zur eigenen Erfahrung passen. Wer Microservices in den letzten fünf Projekten gemacht hat, sieht in jedem neuen Projekt Microservices. Wer immer Event-getrieben gearbeitet hat, sieht überall Events. Diese Pfadabhängigkeit ist nicht falsch, aber sie braucht einen Gegenpol. Jüngere Teammitglieder, externe Perspektiven oder einfach die ehrliche Frage, ob ein bekanntes Muster wirklich das passende ist.

Eine weitere Spannung entsteht zwischen Design und Entwicklung, wenn diese organisatorisch getrennt sind. Wer Design macht, sieht oft nicht, was im Code passiert. Wer Code schreibt, sieht oft nicht, warum eine bestimmte Designentscheidung getroffen wurde. Das Ergebnis: Designdokumente, die in der Realität nicht halten, und Code, der von der ursprünglichen Idee zunehmend abweicht. Ein gutes Design ist nicht das Design, das auf dem Papier am elegantesten aussieht, sondern das Design, das im Code überlebt.

Typische Reibungspunkte in dieser Phase:

• Over-Engineering aus Gewohnheit: Lösungen werden komplexer entworfen, als das Problem es erfordert, weil Komplexität als Zeichen von Sorgfalt missverstanden wird. Eine einfache Anwendung bekommt eine Microservice-Architektur, obwohl ein Monolith das gleiche Problem mit deutlich weniger Aufwand löst.

• Premature Optimization: Designentscheidungen werden für Lasten und Anforderungen getroffen, die noch gar nicht existieren. Das System wird für eine Skalierung gebaut, die es vielleicht nie braucht, und ist dafür im Alltag schwerer zu bedienen.

• Lösungsverliebtheit: Eine bestimmte Technologie oder ein bestimmtes Muster wird zur Voraussetzung gemacht, bevor das Problem überhaupt vollständig verstanden ist. Aus „wir nutzen Event Sourcing" wird die Frage, welches Problem damit gelöst wird, zur Nebensache.

• Unsichtbare Annahmen: Designer treffen Entscheidungen auf Basis von Annahmen über Last, Datenvolumen oder Nutzerverhalten, die nirgendwo dokumentiert sind. Wenn sich später herausstellt, dass die Annahmen nicht stimmen, ist die Architektur bereits gebaut.

Die wirksamste Gegenmaßnahme ist nicht ein strengerer Designprozess, sondern eine andere Haltung. Design ist kein Statement darüber, wer recht hat, sondern ein Aushandeln dessen, was unter den gegebenen Bedingungen tragfähig ist. Die entscheidende Frage ist nicht „Wie würden wir es ideal lösen?", sondern „Welche Lösung passt zu diesem Problem, in diesem Team, mit diesen Ressourcen, in diesem Zeitrahmen?". Wer diese Frage konsequent stellt, landet bei Designs, die nicht nur elegant sind, sondern auch gebaut, betrieben und verändert werden können.

Woran du erkennst, ob es läuft

Gutes Design erkennt man daran, dass die Entwicklung nicht ständig zurückfragt. Man erkennt es daran, dass neue Teammitglieder das System nach einer Woche in Grundzügen erklären können. Man erkennt es daran, dass eine neue Anforderung sich in die bestehende Struktur einfügen lässt, statt sie zu sprengen. Schlechtes Design erkennt man zuverlässig erst Monate später, wenn die Refactoring-Backlogs wachsen und jede Änderung an einer Stelle drei andere Stellen aufschlägt.

Messbar wird Qualität im Design dort, wo Entscheidungen nicht nur getroffen, sondern auch nachvollziehbar sind:

• Verständlich: Ein neues Teammitglied kann die Architektur in einem Gespräch erklärt bekommen und die wichtigsten Entscheidungen anhand der Dokumentation rekonstruieren.

• Begründet: Jede zentrale Designentscheidung hat eine Begründung, die über „so machen wir das immer" hinausgeht. Trade-offs sind benannt, Alternativen wurden in Erwägung gezogen.

• Konsistent: Ähnliche Probleme werden im System ähnlich gelöst. Wer einen Teil verstanden hat, kann den nächsten Teil zumindest plausibel erraten.

• Testbar: Komponenten sind so geschnitten, dass sie isoliert geprüft werden können. Was sich nur als Ganzes testen lässt, lässt sich später auch nur als Ganzes ändern.

• Veränderbar: Das Design hält nicht nur die heutige Anforderung aus, sondern auch eine, die in sechs Monaten noch nicht formuliert ist. Erweiterung ist möglich, ohne die Grundstruktur anzufassen.

Die weichen Warnsignale sind hier besonders aufschlussreich. Wenn im Designreview niemand widerspricht, war entweder die Lösung wirklich überzeugend oder das Team hat aufgegeben, sich einzubringen. Wenn Entwickler beginnen, Designentscheidungen im Code „etwas anders" umzusetzen, weil das Original „in der Praxis nicht passt", war das Design entweder unrealistisch oder unverstanden. Und wenn die Architekturdokumentation nach drei Monaten keiner mehr findet, war sie nie Teil der Arbeit, sondern nur Begleitmaterial.

Die Übergabe in die Entwicklungsphase ist der nächste Belastungstest. Was diese Phase konkret liefern sollte:

Die Architecture Decision Records sind dabei das am häufigsten unterschätzte Artefakt. Ein Diagramm zeigt, wie etwas aussieht, ein ADR zeigt, warum es so aussieht. Wer in zwei Jahren überlegt, eine Designentscheidung zu ändern, braucht nicht die Form, sondern die Begründung dahinter. Ohne sie wird jede ältere Entscheidung zur willkürlichen Altlast.

Entscheidungen, die morgen noch gelten

Das Besondere an Designentscheidungen ist ihre Halbwertszeit. Ein schlecht geschriebener Code-Block lässt sich in einer Stunde refactorn, eine unglücklich gewählte Architektur begleitet ein Projekt manchmal über Jahre. Wer in der Designphase ungenau arbeitet, kauft sich keine Zeit, sondern verschuldet sich auf eine Weise, die später schwer zurückzuzahlen ist. Diese „technische Schuld" ist keine Metapher für schlampige Arbeit, sondern eine sehr konkrete Form von Kosten, die das Team über die gesamte Lebensdauer des Systems begleichen muss.

Nachhaltige Designarbeit bedeutet nicht, jede zukünftige Anforderung vorwegzunehmen. Das wäre nicht nur unmöglich, sondern aktiv schädlich, weil es zu Over-Engineering führt. Nachhaltige Designarbeit bedeutet, die heutigen Entscheidungen so zu treffen, dass sie morgen noch sinnvoll sind, und gleichzeitig so wenig wie möglich vorwegzunehmen, was sich noch ändern könnte. Konkret heißt das:

• Reversible vor irreversiblen Entscheidungen: Nicht jede Entscheidung muss früh getroffen werden. Was sich später leicht ändern lässt, sollte später entschieden werden. Was sich nur schwer ändern lässt, gehört in die Designphase. Diese Unterscheidung ist entscheidender als die Frage, ob etwas „wichtig" ist.

• Einfachheit als Default: Komplexität rechtfertigt sich, sie ist nicht der Ausgangspunkt. Ein Design, das eine einfache Lösung erst nach ernsthafter Prüfung verworfen hat, ist robuster als eines, das gleich mit der komplizierten Variante beginnt. Komplexität, die sich nicht durch ein konkretes Problem begründen lässt, ist Belastung, kein Wert.

• Annahmen explizit machen: Jedes Design basiert auf Annahmen über Last, Daten, Nutzungsverhalten und Veränderungsraten. Wer diese Annahmen festhält, gibt dem Team ein Frühwarnsystem an die Hand: Wenn sich eine Annahme als falsch erweist, ist sofort klar, welcher Teil des Designs unter Druck gerät.

• Trade-offs benennen, nicht verstecken: Jede Designentscheidung ist ein Kompromiss. Performance vs. Lesbarkeit, Flexibilität vs. Einfachheit, Konsistenz vs. Verfügbarkeit. Wer den Trade-off nicht benennt, baut die Konsequenz trotzdem ein, nur ohne dass das Team es weiß.

Das häufigste nachhaltige Problem der Designphase ist keines der spektakulären, sondern eines, das sich langsam aufbaut: die unbemerkte Erosion der ursprünglichen Idee. Ein Design wird sorgfältig entworfen, dann beginnt die Entwicklung. Eine kleine Abweichung hier, eine pragmatische Lösung dort, eine schnelle Anpassung wegen Termindruck. Jede einzelne Veränderung ist nachvollziehbar. In Summe ist das System nach einem Jahr kein Ergebnis des Designs mehr, sondern eines unzähliger kleiner Korrekturen. Design ist deshalb keine einmalige Phase, sondern eine Haltung, die durch die Entwicklung getragen werden muss, sonst verliert sie sich.

Am Ende der Designphase lohnt sich deshalb eine ehrliche Rückfrage:

Wenn in zwei Jahren jemand fragt, warum dieses System genau so aufgebaut ist, hätten wir dann eine Antwort, die mehr ist als ‚historisch gewachsen'?

Wenn die Antwort zögerlich ist, ist das Design noch nicht fertig.

Weiterdenken

Design ist die Phase im SDLC, in der die Differenz zwischen kurzfristig schnell und langfristig tragfähig am deutlichsten spürbar wird. Hier zeigt sich, ob ein Team bereit ist, Aufwand in etwas zu investieren, das erst Monate später seine Wirkung entfaltet. Hier zeigt sich auch, ob Erfahrung als Werkzeug genutzt wird oder als Abkürzung. Wer im Design wirklich nachdenkt, verzichtet bewusst auf ein paar Tage scheinbarer Produktivität, um Wochen späterer Korrektur zu vermeiden. Wer im Design abkürzt, gewinnt scheinbar Zeit, die das Projekt sich am Ende doppelt zurückholt.

Vielleicht ist das die wichtigste Erkenntnis dieser Phase: Design ist nicht das Gegenteil von Pragmatismus, sondern seine reifere Form. Pragmatisch ist nicht, sofort loszulegen, sondern lange genug innezuhalten, um das Richtige zu bauen.

Nimm dir etwas Zeit und reflektiere die folgenden Fragen:

• Werden in deinem Team Designentscheidungen wirklich getroffen oder ergeben sie sich aus dem Code, sobald die ersten Pull Requests entstehen?

• Welche der zentralen Architekturentscheidungen eures aktuellen Systems könnte heute noch jemand begründen, der vor zwei Jahren nicht dabei war?

• Wie viel Komplexität in eurer Software ist durch ein konkretes Problem gerechtfertigt und wie viel ist Gewohnheit, Trend oder vorweggenommene Skalierung?

• Wann habt ihr zuletzt eine einfache Lösung bewusst gewählt, obwohl eine elegantere möglich gewesen wäre?

Die nächste Phase, die Entwicklung, baut direkt auf dem auf, was das Design geliefert hat. Dort werden aus Architekturen Code, aus Schnittstellenverträgen Implementierungen, aus UI-Prototypen klickbare Realität. Wie gradlinig diese Umsetzung verläuft, hängt unmittelbar davon ab, wie tragfähig das Design war.