Inzwischen habe ich nachgelesen, wie über Architektur und Bauen nachgedacht wurde, vom römischen Baumeister Vitruv über die Renaissance bis zu den Anfängen der Softwaretechnik. Die Frage, wie man an großen Werken zusammenarbeitet, ist erstaunlich alt. Und sie hat wenig mit Geschmack zu tun. Ob ein Vorhaben Architektur braucht, hängt nicht daran, ob man lieber mit Ingenieuren oder mit Künstlern arbeitet. Es hängt auch nicht daran, wie schnell es gehen soll. Es hängt am Anspruch. Und am Abstand zwischen denen, die planen, und denen, die bauen.

Das Missverständnis vom groben Plan

Ein verbreitetes Bild sieht Architektur als grobe Fassung des eigentlichen Plans: ein paar Kästen und Pfeile, bevor die richtige Arbeit beginnt. Je weiter man hineinzoomt, desto mehr wird daraus ein Konstruktionsplan, und am Ende steht Code. In diesem Bild ist Architektur eine Auflösungsstufe.

Ich halte das für ein folgenreiches Missverständnis. Architektur sagt etwas anderes.

Nehmen Sie eine große Halle. Der Tragwerksplaner weist nach, dass sie steht: Lasten, Spannweiten, Fundamente. Das ist anspruchsvolle Arbeit, und ohne sie geht nichts. Aber derselbe Nachweis passt auf sehr verschiedene Hallen. Die eine schüchtert ein: hohe Schwellen, wenige Eingänge, jeder Besucher ist sichtbar. Die zweite ist eine effiziente Umschlagmaschine, durch die Menschen geschleust werden wie Ware. Die dritte ist ein würdiger öffentlicher Raum, in dem man sich gern aufhält. Statisch können alle drei gleich gut sein. Was sie unterscheidet, entscheidet die Architektur: Anordnung, Wege, Licht, Maßstab, Zugänge.

Neu ist diese Einsicht nicht. Vitruv verlangte schon im ersten Jahrhundert vor Christus, dass ein Bau Festigkeit, Nützlichkeit und Schönheit berücksichtigt. Festigkeit allein reichte ihm nicht.

Meine Arbeitsdefinition lautet heute: Architektur ist nicht der gröbere Konstruktionsplan. Sie ist die Ebene, auf der festgelegt wird, welche Ordnung entstehen soll. Eine Ordnung, die Sinn ergibt, die Werte gegeneinander abwägt und die man auch in zehn Jahren noch verantworten kann. Der Konstruktionsplan setzt diese Ordnung um. Oder er verrät sie, wenn die Übersetzung misslingt.

Optimieren setzt ein Ziel voraus

Greifbar wird der Unterschied, wenn man auf die Ziele schaut. Engineering arbeitet mit einem gegebenen Ziel: Last tragen, Durchsatz erhöhen, Ausfallzeit senken. Das kann es hervorragend. Architektur fragt eine Ebene früher: Ist das überhaupt das richtige Ziel? Was macht es mit den anderen Dingen, die uns wichtig sind? Wem nützt es, und wer trägt die Last?

Ein erfundenes, aber nicht untypisches Beispiel. Ein Maschinenbauer führt ein Serviceportal ein. Das Ziel ist klar formuliert: Störungsmeldungen sollen schneller bearbeitet werden. Das Team liefert. Meldungen werden automatisch eingeordnet, Antworten vorgeschlagen, die Bearbeitungszeit sinkt deutlich. Technisch ist das Portal sauber gebaut.

Nur wollte der Kunde nie eine schnell geschlossene Meldung. Er wollte, dass seine Anlage wieder läuft. Das Portal hat gelernt, Fälle zu schließen, indem es Arbeit zum Kunden zurückschiebt: noch ein Foto, noch eine Seriennummer, ein Link zur Anleitung. Die Kennzahl wird besser, die Lage des Kunden nicht. Jeder Bericht meldet Erfolg, denn gemessen wird die Kennzahl.

Man hat ein System optimiert und die Welt, in der es wirkt, nicht besser gemacht.

Architekturarbeit hätte hier angesetzt, und zwar nicht bei der Frage nach Cloud oder Microservices. Sondern bei Fragen wie diesen: Welche Fähigkeit soll entstehen? Wer gewinnt Handlungsspielraum, wer verliert ihn? Welche Abhängigkeiten schaffen wir für die nächsten zehn Jahre? Welche Qualität darf nicht gegen Effizienz getauscht werden? Das meine ich mit Anspruch: nicht nur, dass ein System funktioniert, sondern dass es die Lage derer besser macht, mit denen es zu tun hat.

Man kann das auch Anforderungsarbeit nennen oder Produktverantwortung. Mir ist weniger wichtig, wie es heißt, als dass jemand diese Ebene ausdrücklich verantwortet.

Das ist kein Plädoyer gegen Engineering. Der Ökonom und Kognitionsforscher Herbert Simon hat Gestalten sehr weit gefasst: Gestalter ist jeder, der Wege sucht, eine bestehende Lage in eine gewünschte zu verwandeln. Ingenieure tun das jeden Tag, und auch in ihren Entscheidungen stecken Werte. Das Abwasserrohr aus dem ersten Artikel braucht genau gutes Engineering: ein klares Ziel, sauber umgesetzt, ohne Spielraum für Interpretation. Wo das Ziel feststeht und stimmt, wäre mehr Architektur Aufwand ohne Gewinn. Wo es nicht feststeht, optimiert gutes Engineering im Zweifel sehr effizient das Falsche.

Der Baumeister auf der Baustelle

Die zweite Einsicht betrifft nicht das Ziel, sondern den Abstand.

Stellen Sie sich einen Baumeister vor, der jeden Tag auf seiner Baustelle steht. Er muss wenig aufschreiben. Er sieht, wie der Maurer den Stein setzt, und sagt: falscher Stein, der Bogen stimmt so nicht. Vieles bleibt unausgesprochen, weil es sofort korrigiert werden kann. Der große Plan existiert vor allem in seinem Kopf. Das genügt, solange er danebensteht.

Wächst der Abstand, ändert sich das. Leon Battista Alberti, einer der großen Architekturtheoretiker der Renaissance, hob den Architekten deutlich vom Handwerker ab: Die Hand des Handwerkers sei dem Architekten ein Werkzeug. Das war auch eine Statusfrage, und man muss diese Rangordnung nicht teilen.

Interessanter finde ich, was die Trennung praktisch bedeutete. Erhalten ist ein Brief, den Alberti im November 1454 aus Rom an seinen Bauleiter in Rimini schrieb. Dort entstand nach seinem Entwurf der heutige Tempio Malatestiano. Er antwortet auf dessen Fragen, erklärt sein Modell, verteidigt die Maße der Pfeiler und warnt sinngemäß: Was du daran änderst, verstimmt die ganze Musik. Wer nicht danebensteht, muss begründen, zeichnen, Modelle bauen und Briefe schreiben. Und er muss darauf vertrauen, dass der andere versteht, worauf es ankommt.

Gut fünfhundert Jahre später taucht dasselbe Problem in der Software auf. Auf einer NATO-Konferenz zur Softwaretechnik schlug I. P. Sharp 1969 vor, neben dem Engineering ein eigenes Thema ernst zu nehmen: Softwarearchitektur. Sein Beispiel war IBMs Betriebssystem OS/360. Teile davon seien hervorragend programmiert, das Ganze aber ein formloser Klumpen. Der Grund: Es habe keinen Architekten gehabt. Der Entwurf sei auf mehrere Gruppen von Ingenieuren verteilt worden, und jede habe sich ihre eigene Architektur ausdenken müssen. Seine Forderung war schlicht: Wer umsetzt, muss verstehen, was der Architekt im Sinn hatte.

Das ist für mich der Kern. Je größer der Abstand zwischen dem, der das Ganze im Kopf hat, und denen, die bauen, desto mehr vom Wesentlichen muss ausdrücklich werden: Beschreibungen, Zeichnungen, Muster, vereinbarte Schnittstellen, Prinzipien. Die Integrationsarbeit, also das Zusammenfügen arbeitsteiliger Ergebnisse zu einem stimmigen Ganzen, wird zu einer eigenen Aufgabe. Sie passiert nicht mehr nebenbei. Und auch die Frage nach dem Wozu muss ausgesprochen werden. Wer nicht danebensteht, kann nicht im Vorbeigehen eingreifen, wenn jemand ein falsches Ziel verfolgt.

In der IT ist dieser Abstand der Normalfall. Dienstleister bauen Teile, die man nie von innen sieht. Teams sitzen in verschiedenen Häusern, manchmal in verschiedenen Zeitzonen. Oft ist das System schon da, gekauft oder gewachsen, und man muss darum herum bauen. Dann kann ein Teil genau nach Spezifikation geliefert sein und trotzdem nicht passen, weil beide Seiten ein Kernwort verschieden verstehen, etwa wann ein Vorgang als abgeschlossen gilt.

Das widerspricht nicht dem, was ich im ersten Artikel über das Weglassen geschrieben habe. Weglassen bleibt richtig. Schon Dewayne Perry und Alexander Wolf, die 1992 einen der Grundlagentexte zur Softwarearchitektur schrieben, wollten auf Architekturebene nur die Vorgaben festlegen, die dort wirklich nötig sind. Aber mit dem Abstand ändert sich, was Weglassen bedeutet. Auf der Baustelle darf vieles ungesagt bleiben, weil man es zeigen kann. Aus der Ferne muss man entscheiden, was man ausdrücklich macht und was man bewusst offenlässt.

Agenten auf der Baustelle

Mit KI-Agenten wächst der Abstand noch einmal. Ein Agent liefert in Minuten Entwürfe für Code, Konzepte, Testfälle und Texte, an denen man früher Stunden saß. Aber er steht nicht auf der Baustelle, und niemand steht neben ihm. Er setzt sehr schnell sehr viele Steine.

Was ich dabei beobachte, nenne ich mit Perry und Wolf Drift: Die Architektur wird nicht verletzt, sie wird nur nicht beachtet. Die Ergebnisse sind selten falsch. Sie sind plausibel, oft handwerklich gut, und trotzdem nicht das, was gewollt war. Jedes Teil besteht für sich die Prüfung, das Ganze passt nicht zusammen. Das ist Sharps formloser Klumpen, nur in höherem Tempo. Bessere Agenten ändern daran wenig. Auch OS/360 bestand aus hervorragend programmierten Teilen. Es fehlte nicht das Können, es fehlte die ausgesprochene Gestalt.

Daraus folgt etwas, das wir noch kaum ernst nehmen. Weniger Menschen müssen mehr Ergebnis zusammenfügen, und zwar logisch (passt es zusammen?), inhaltlich (meint es dasselbe?) und ethisch (wollen wir das?). Gleichzeitig rücken Anforderungen und Architektur zusammen. Was man einem Agenten als Auftrag gibt, ist Anforderung und Architekturentscheidung zugleich.

Wer nicht klar sagt, welche Ordnung entstehen soll, bekommt trotzdem eine. Nur nicht unbedingt die eigene.

Eine These, keine Tatsache

Hier will ich trennen, was ich weiß und was ich glaube. Ich glaube, dass Menschen von Menschen geführt werden wollen und in Systemen leben wollen, für die Menschen geradestehen. Und ich bezweifle, dass eine KI erfassen kann, was ein gutes, ein schönes Leben ausmacht. Das ist eine These, keine Tatsache.

Die stärkste Gegenposition nehme ich ernst. Sprachmodelle sind aus dem gebaut, was unzählige Menschen über gutes Leben, Gerechtigkeit und Schönheit geschrieben haben. Sie formulieren Wertkonflikte oft ausgewogener als ein Projektgremium unter Termindruck. Und Menschen scheitern an dieser Aufgabe ständig. Das Serviceportal von oben hat kein Agent gebaut.

Wo ich trotzdem bleibe: Selbst wenn eine Maschine Werte gut beschreiben kann, bleibt die Frage, wer für die Antwort einsteht. Ein System ordnet das Leben anderer Menschen, ihre Wege, ihre Rechte, ihren Spielraum. Dafür muss jemand verantwortlich sein, den man fragen kann und der die Folgen trägt. Diese Verantwortung lässt sich nicht an ein Werkzeug abgeben, so gut es ist. Architektur nimmt sie auch niemandem ab. Aber sie ist die Stelle, an der sie sichtbar wird: wer was entschieden hat und warum.

Welche Flughöhe brauchen Sie?

Nichts davon ist eine Absage an Engineering oder an Tempo. Gutes Engineering ist eine eigene Erkenntnisleistung. Es zwingt jede schöne Absicht, sich an Physik, Budget und Betrieb zu bewähren. Und Schnelligkeit ist oft genau richtig. Die Frage lautet nicht: Architektur oder Engineering? Sie lautet: Welche Flughöhe braucht dieses Vorhaben?

Drei Lagen helfen mir bei der Antwort.

Das Ziel ist klar und richtig, der Abstand klein

Ein Team, ein überschaubares System, kurze Wege. Hier zählt gutes Engineering, schnell und mit wenig Papier. Die Architektur läuft im Kopf mit.

Das Ziel ist klar und richtig, der Abstand groß

Viele Beteiligte, Dienstleister, Bestandssysteme, KI-Agenten. Hier wird Architektur zur Integrationsarbeit. Schnittstellen, Prinzipien und Muster müssen ausdrücklich werden, sonst entsteht der formlose Klumpen.

Das Ziel selbst ist offen

Dann ist der Abstand zweitrangig. Das System wird verändern, wie Menschen arbeiten, entscheiden oder leben. Hier braucht es Architektur im vollen Sinn: die Frage nach dem Wozu, nach den Betroffenen und nach dem, was nicht gegen Effizienz getauscht werden darf.

Gefährlich ist vor allem die Verwechslung: Ein Vorhaben hält sich für die erste Lage und steckt längst in der zweiten oder dritten.

Deshalb frage ich diesmal nicht nur, wie viel Kunstfertigkeit Sie wollen. Sondern: Was soll Ihr System eigentlich besser machen? Und wer sorgt dafür, dass es das auch tut, wenn niemand mehr jeden Tag auf der Baustelle steht?

Diese Frage gehört an den Anfang. Am Ende wird sie teuer.