Kontext bei Architekturentscheidungen: „It Depends reicht nicht“

Neal Ford ist unabhängiger Softwareberater, Bestsellerautor und Referent. Er gilt als international anerkannter Experte für Softwareentwicklung und -bereitstellung, insbesondere an der Schnittstelle zwischen agilen Entwicklungsmethoden und Softwarearchitektur. Neal hat Zeitschriftenartikel, neun Bücher und Dutzende von Videopräsentationen verfasst sowie auf Hunderten von Entwicklerkonferenzen weltweit Vorträge gehalten.

Zu seinen Themen gehören Softwarearchitektur, Continuous Delivery, funktionale Programmierung und moderne Softwareentwicklung. Er ist ein Vorreiter bei der Entwicklung konkreter Verifizierungsmechanismen für Softwarearchitekturen, sowohl für Menschen als auch für Agenten.

Auf dem Software Architecure Gathering 2026 ist Neal Ford mit dem Vortrag „Software Architecture Trade-off Analysis“ und dem Workshop „How To Teach Your Agents About Architecture“ vertreten.

iX: Ihren Vortrag „Software Architecture Trade-off Analysis“ auf dem Software Architecture Gathering 2026 beginnen Sie mit einer Aussage, die viele Architekten nur zu gut kennen: „It depends.“ Welchen entscheidenden Faktor übersehen Softwarearchitekten Ihrer Erfahrung nach noch immer häufig, wenn sie architektonische Trade-offs bewerten?

Neal Ford: Den Kontext. „It depends“ ist die richtige Antwort auf jede Frage in der Softwarearchitektur. Das Problem ist, dass Architektinnen und Architekten an diesem Punkt aufhören, statt die entscheidende Anschlussfrage zu stellen: Wovon hängt es ab?

Der häufigste Fehler, den ich beobachte, ist, dass Architekten Trade-off-Analysen auf einer allgemeinen Ebene durchführen. Sie lesen darüber, wie ein bekanntes Unternehmen ein Problem gelöst hat, und gehen davon aus, dass für sie dieselben Trade-offs gelten – obwohl die Rahmenbedingungen, die Größenordnung und die Geschäftsziele des anderen Unternehmens mit ihren eigenen kaum etwas gemeinsam haben. Nehmen Sie niemals Architekturratschläge von jemandem an, der Ihren Kontext nicht kennt.

Ein zweiter Punkt wird häufig übersehen: Trade-offs sind nicht statisch. Die Analyse, die Sie vor zwei Jahren durchgeführt haben, war damals richtig. Aber das Ökosystem, das Team und das Business haben sich seitdem verändert. Deshalb muss eine Trade-off-Analyse iterativ erfolgen und darf keine einmalige Angelegenheit sein.

iX: Bei Trade-offs muss man technische Aspekte häufig gegen geschäftliche Prioritäten abwägen. Welche Architekturentscheidung sieht isoliert betrachtet oft „falsch“ aus, ist aber sinnvoll, sobald man den größeren Businesskontext berücksichtigt?

Ford: Duplizierung statt Wiederverwendung. Jede Architektin und jeder Architekt bekommt DRY (Don’t Repeat Yourself) schon im ersten Programmierkurs eingetrichtert. Code oder Daten bewusst zu duplizieren, sieht isoliert betrachtet daher fast wie ein Kunstfehler aus.

Aber Wiederverwendung erzeugt Kopplung. Jedes Team, das dieselbe Library oder denselben Service nutzt, ist nun mit den anderen Teams aneinandergekettet, und eine Änderung für ein Team wird für alle zu einer Koordinationsaufgabe.

Liegt die geschäftliche Priorität auf unabhängiger Teamgeschwindigkeit und einer kurzen Time-to-Market – was in einer Microservices-Welt normalerweise der Fall ist –, ist es häufig besser, etwas Kleines und Stabiles zu duplizieren, statt es gemeinsam zu nutzen.

Wiederverwendung ist eine großartige Idee – bis zu dem Moment, an dem sie es nicht mehr ist. Und nur der Businesskontext zeigt, wo diese Grenze verläuft.

iX: In Ihrem Vortrag stellen Sie moderne Techniken für Trade-off-Analysen als Alternative zu eher bürokratischen Ansätzen vor. Worüber sollten Softwarearchitektinnen und -architekten heute Ihrer Meinung nach weniger diskutieren und was sollten sie stattdessen häufiger verifizieren?

Ford: Über fast alles worüber sie derzeit in Konferenzräumen diskutieren. So viele Architekturdiskussionen wie „Wird das die Performance beeinträchtigen?“, „Wird das unsere Modularität zerstören?“ oder „Kann das skalieren?“ sind empirische Fragen im philosophischen Gewand. Wenn zwei Architekten Anekdoten über Elastizität austauschen, handelt es sich letztlich um einen Austausch von Erfahrungsberichten. Eine Fitnessfunktion, die Elastizität am tatsächlichen System misst, dient dagegen der Verifizierung.

Die bürokratischen Ansätze scheitern, weil sie mit einem enormen Analyseaufwand von Dokumenten verbunden sind, den anschließend niemand mit der Realität abgleicht. Der moderne Ansatz besteht darin, die kleinste verantwortbare Entscheidung zu treffen, den betreffenden Aspekt in etwas Ausführbares zu überführen und sich vom laufenden System bestätigen zu lassen, ob die Entscheidung richtig war.

Daher sollte gelten: Die Messwerte entscheiden und nicht die Meinungen.

iX: Ihr Workshop „How To Teach Your Agents About Architecture“ beschäftigt sich damit, wie Architekten sowohl Menschen als auch KI-Agenten beibringen können, architektonische Vorgaben zu befolgen. Welche Aspekte der Softwarearchitektur lassen sich überraschend einfach einem Agenten vermitteln und welche sind weiterhin stark von menschlichem Urteilsvermögen abhängig?

Ford: Die strukturellen Dinge sind überraschend einfach – alles, worauf es eine deterministische Antwort gibt. Abhängigkeiten zwischen Layern, Regeln zur Kopplung von Komponenten, Namenskonventionen oder Vorgaben wie „Nichts in der Domänenebene greift direkt auf die Datenbank zu“. Genau solche Kontrollmechanismen implementieren wir seit einem Jahrzehnt als Fitnessfunktionen. Agenten sind gut darin, diese Regeln zu befolgen, und tun dies unermüdlich, anders als manche Menschen.

Menschliches Urteilsvermögen braucht es weiterhin für alles, was vor der Regel liegt: warum die Regel existiert, wann sich der Businesskontext so stark verändert hat, dass eine Regeländerung erfolgen sollte, und wie man konkurrierende Trade-offs gegeneinander abwägt, für die es keine objektiv richtige Antwort gibt.

Ein Agent kann den architektonischen Ansatz den ganzen Tag lang durchsetzen, er kann aber noch nicht entscheiden, wie dieser Ansatz aussehen sollte. Diese Entscheidung entsteht an der Schnittstelle zwischen technischen Rahmenbedingungen und Geschäftsstrategie – und niemand hat die Geschäftsstrategie in die Trainingsdaten geschrieben.

iX: In Ihrem Workshop betonen Sie, wie wichtig es ist, Architekturregeln in Spezifikationen einzubetten und deterministische Guardrails zu erzeugen. Wie stellen wir sicher, dass diese Guardrails gutes Engineering fördern, statt lediglich starre Compliance durchzusetzen?

Ford: Jede Guardrail muss ihr Warum mitliefern. Eine Regel ohne Begründung ist nichts anderes als Bürokratie, die nur dazu dient, Vorschriften anzuhäufen. Menschen und Agenten werden den Wortlaut der Regel befolgen und dabei fröhlich den eigentlichen Zweck missachten.

Deshalb verbinden wir jede Regel mit der Begründung dahinter, so wie es ein guter Architecture Decision Record (ADR) macht. Dadurch können sowohl Menschen als auch Agenten erkennen, wann sie auf eine legitime Ausnahme gestoßen sind und wann sie lediglich versuchen, ein Hindernis zu umgehen.

Der zweite Schutzmechanismus besteht darin, Guardrails wie Code zu behandeln: Sie werden versioniert, überprüft und gelöscht, sobald der Kontext, der sie ursprünglich gerechtfertigt hat, nicht mehr existiert. Eine veraltete Guardrail ist schlimmer als gar keine, denn sie vermittelt den Menschen, die sie lesen, dass Regeln willkürlich sind.

Stellen Sie sich Guardrails wie Leitplanken auf einer Bergstraße vor: Sie lenken das Auto nicht, sondern verhindern lediglich, dass Fehler tödlich enden. In dem Moment, in dem Ihre Guardrails anfangen zu lenken, haben Sie eine Bürokratie geschaffen statt einer Architektur.

iX: Da KI zu einem festen Bestandteil der Softwareentwicklung wird: Glauben Sie, dass sich die Rolle von Softwarearchitekten allmählich vom Entwerfen von Systemen hin zum Entwerfen der Regeln und Guardrails verschieben wird, anhand derer sowohl Menschen als auch KI-Agenten diese Systeme entwickeln?

Ford: Teilweise – aber ich würde es eher so formulieren, dass dadurch klar wird, was schon immer unsere Aufgabe war. Architekten haben Systeme nie wirklich selbst gebaut. Sie haben die Rahmenbedingungen und Strukturen definiert, innerhalb derer Systeme entstehen, und sich dann auf Code Reviews, Gespräche auf dem Flur und die Hoffnung verlassen, dass die architektonische Absicht (Architectural Intent) den Kontakt mit der tatsächlichen Implementierung überlebt.

KI zwingt uns dazu, diese Absicht explizit, präzise und ausführbar zu machen – durch Spezifikationen, Fitnessfunktionen und Guardrails. Denn Agenten können die architektonische Absicht nicht einfach zwischen den Zeilen herauslesen. Und offen gesagt waren Menschen darin auch nie besonders gut.

Ja, ein größerer Teil der Arbeit der Architekten wird damit darin bestehen, Absichten zu formulieren, statt Diagramme zu erstellen. Aber der Kern der Rolle verändert sich nicht: Jemand muss weiterhin die Trade-off-Analyse durchführen, die Geschäftsziele verstehen und Entscheidungen treffen, wenn Menschen unterschiedlicher Meinung sind.

Das Medium verändert sich. Das „It depends“ bleibt.

Das Interview führte Richard Wallintin von WPS [–-] Workplace Solutions.