|
13.10.2026 09:05 Uhr |
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.
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.
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.
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.
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.
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.
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.
(rme)