// HEISE ONLINE — HARDWARE & GADGET
Kontext bei Architekturentscheidungen: „It Depends reicht nicht“
Im Interview erläutert Neal Ford, warum Architekten mehr überprüfen und weniger diskutieren sollten. Außerdem spricht er über KI in der Softwarearchitektur.
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.