Architekten mauern keine Wände, 2009 und 2026

Im Mai 2009 habe ich hier aufgeschrieben, warum ein Softwarearchitekt programmieren können muss. Siebzehn Jahre später schreiben Agenten den Code. Zeit, den alten Text noch einmal zu lesen.

Das Argument von 2009

Der Beitrag begann mit einem Vergleich aus dem Bauwesen. Niemand erwartet, dass der Architekt eines Einfamilienhauses das Fundament gießt und die Wände mauert. Warum also sollte ein Softwarearchitekt programmieren?

Meine Antwort damals: Weil Software sich nicht verhält wie ein Gebäude. Das Deployment muss wegen der Performanz geändert werden, ein Protokoll erzeugt zu viel Last, ein Teil des Systems verträgt keine parallele Nutzung. Nichts davon steht im ursprünglichen Entwurf, und kaum etwas davon wird hinterher nachgetragen. Der Kernsatz:

Die endgültige Architektur findet sich nur in der Software selbst wieder.„Architekten mauern keine Wände und Softwarearchitekten programmieren nicht“, Mai 2009 (im Archiv)

Daraus folgte: Der Architekt muss Code lesen, die Entwicklungsumgebung beherrschen und das laufende System anhand von Logfiles und Heapdumps verstehen. Und er braucht die Programmierkenntnisse für seine Rolle im Team, als Mentor, als jemand, der fremden Code beurteilen kann, und als Autorität, mit der Entwickler das Gespräch suchen, wenn sie vom Entwurf abweichen wollen. Nur so bleibt nach mehreren Versionen noch ein Entwurf erkennbar.

Als Gegenbild hatte ich damals den Architekten skizziert, der seinen Entwurf als Powerpoint dem Management vorstellt und den Code mit einem MDA-Werkzeug generieren lässt. Das war 2009 als Karikatur gemeint.

Was 2026 daraus wird

Heute ist die Karikatur fast Wirklichkeit geworden, nur mit anderen Werkzeugen. Man beschreibt, was man will, in natürlicher Sprache, und ein Agent erzeugt den Code. Ist das Argument von 2009 damit erledigt?

Ich glaube, das Gegenteil ist der Fall. Der Kernsatz gilt unverändert: Die endgültige Architektur steckt in der Software, nicht im Entwurf und erst recht nicht im Prompt. Neu ist, dass immer weniger Menschen diese Software Zeile für Zeile geschrieben haben. Die Lücke zwischen dem, was wir beabsichtigt haben, und dem, was tatsächlich gebaut wurde, war nie größer.

Und ein MDA-Generator war wenigstens deterministisch. Aus demselben Modell kam derselbe Code. Ein Agent liefert aus derselben Spezifikation bei jedem Lauf etwas anderes, im Zweifel unterschiedlich korrekt. Die Prüfung lässt sich nicht mehr an einen verlässlichen Übersetzungsschritt delegieren. Sie muss jedes Mal neu stattfinden.

Spannend ist auch, welche Rolle die Spezifikation am Ende spielt. Wird sie einmal erstellt, und wir landen wieder bei einem wasserfallartigen Vorgehen, oder wird sie fortlaufend überarbeitet? Wie finden Änderungen aus einem Review Widerhall in der Spezifikation?

Was bleibt, was sich verschiebt

Von den Anforderungen aus 2009 bleibt erstaunlich viel:

• Code lesen können wird wichtiger, nicht unwichtiger. Wer Agenten-Code beurteilen soll, muss tiefer lesen als bei menschlichem Code, weil dieser Code so plausibel aussieht.
• Das laufende System verstehen bleibt. Logfiles und Heapdumps lügen nicht, egal wer den Code geschrieben hat.
• Fremden Code beurteilen ist jetzt die Hauptaufgabe. Nur ist der „Fremde“ oft ein Modell.

Was sich verschiebt, ist die Rolle im Team. 2009 war der Architekt die Autorität, an die sich Entwickler wenden, wenn sie vom Entwurf abweichen wollen. Ein Agent fragt nicht. Er weicht einfach ab, wenn nichts ihn daran hindert. Deshalb muss der Entwurf heute in Prüfungen gegossen werden, die automatisch anschlagen. Mehr dazu in Vom Code-Design zum Harness-Design.

Mit etwas Abstand lese ich den Text von 2009 auch anders. Ich habe damals für das Programmieren argumentiert, aber gemeint war etwas anderes: das Verstehen. Der Architekt sollte programmieren können, weil er nur so die Theorie des Systems im Sinne von Peter Naur aufbauen und mit dem Team teilen konnte. Programmieren war das Mittel, Verstehen der Zweck. Mehr dazu in Programmieren war nie der Punkt.

Die Frage von 2009, ob ein Architekt selbst programmieren muss, stellt sich damit neu. Er muss nicht mehr jeden Tag selbst schreiben, aber er muss den Code jederzeit lesen und beurteilen können. Ein Architekt mauert keine Wände. Aber er muss erkennen, ob eine Wand trägt.

Daraus ergibt sich dann die nächste spannende Frage, die bei uns in der Firma immer häufiger hochkommt: Wie bilden wir Junioren auf Dauer zu Architekten aus? Ein reines Architektur-Studium als Ausbildungsweg habe ich schon vor Jahren abgelehnt, weil ihm die Erfahrung fehlt. Auch wie wir das notwendige Lernen in unsere Kundenprojekte einbauen ist noch nicht geklärt. Ich werde darüber berichten.