Agentic Engineering (Teil 5): Architektur ist zurück!

Peter Pedross, CEO & Gründer, PEDCO AG – SAFe Fellow

Agentic Engineering verändert die Rolle der Architektur grundlegend. Was traditionell als technische Entwurfsdisziplin galt, wird zunehmend zu einer organisatorischen Fähigkeit, die es autonomen Systemen ermöglicht, konsistente und qualitativ hochwertige Entscheidungen zu treffen. Da autonome Agenten zu Akteuren in Ingenieursorganisationen werden, entwickelt sich die Architektur zu einer Navigationsinfrastruktur, die Orientierung bietet, Grenzen definiert und den Rahmen für eine effektive Zusammenarbeit zwischen Menschen und KI-Systemen schafft.

Software-/Systemarchitektur war schon immer essenziell, ihre wahrgenommene Bedeutung hat sich jedoch im Laufe der Zeit verändert.

In den frühen Jahren der Enterprise-Softwareentwicklung wurde Architektur häufig als das Fundament betrachtet, auf dem jedes erfolgreiche System aufbaut. Mit dem Aufkommen agiler Methoden wurden Organisationen später dazu ermutigt, umfangreiche Vorabplanung zu vermeiden und stattdessen evolutionäre Architekturansätze zu verfolgen. DevOps verlagerte den Fokus auf schnelle Lieferung, Automatisierung und kontinuierliches Feedback, während Cloud-native Plattformen zunehmend viele Infrastrukturthemen abstrahierten. Keine dieser Entwicklungen hat die Bedeutung von Architektur verringert. Sie haben lediglich verändert, worauf Engineering-Organisationen ihre Aufmerksamkeit richten.

Agentic Engineering verschiebt dieses Gleichgewicht erneut. Während autonome Systeme zunehmend an der Softwareentwicklung teilnehmen, entwickelt sich Architektur von einer Design-Disziplin zu einer organisatorischen Fähigkeit. Dieser Unterschied ist subtil, aber bedeutend. Erfahrene Ingenieure kompensieren architektonische Schwächen häufig beinahe intuitiv. Sie verstehen historische Entscheidungen, erkennen fragile Schnittstellen, wissen, welche Komponenten voneinander isoliert bleiben sollten, und erinnern sich an die Gründe für Kompromisse, die möglicherweise bereits vor Jahren eingegangen wurden. Ein großer Teil dieses Wissens wird niemals formal dokumentiert. Es existiert innerhalb der Engineering-Teams. Autonome Agenten verfügen über diese Erfahrung nicht.

• Jedes Architekturprinzip, dem sie folgen sollen, muss explizit gemacht werden.
• Jede Integrationsgrenze muss beschrieben werden.
• Jede Abhängigkeit muss verständlich sein.
• Jede Einschränkung muss als Teil des Engineering-Kontexts repräsentiert werden.

Architektur wird damit zu deutlich mehr als einer Sammlung von Modellen und Diagrammen. Sie wird zur Struktur, die es autonomen Systemen ermöglicht, konsistent zu argumentieren und Entscheidungen zu treffen. Dies hat eine wichtige Konsequenz:

• Autonome Agenten skalieren nicht nur die Produktivität im Engineering.
• Sie skalieren auch die Qualität der Architektur.

Organisationen mit einer klar definierten Architektur werden häufig beobachten, dass autonome Agenten bestehende Engineering-Praktiken verstärken, konsistentere Implementierungen erzeugen und bessere technische Entscheidungen treffen. Organisationen mit fragmentierten Architekturen erleben hingegen den gegenteiligen Effekt. Inkonsistente Systemgrenzen, undokumentierte Abhängigkeiten und widersprüchliche Designprinzipien werden verstärkt anstatt verborgen. Das Ergebnis ist nicht eine langsamere Softwareentwicklung. Es ist eine schnellere architektonische Erosion. Diese Beobachtung lässt sich relativ einfach zusammenfassen:

Gute Architektur wird besser. Schlechte Architektur verschlechtert sich schneller.

Die Auswirkungen reichen jedoch weit über die reine Softwarestruktur hinaus. Architektur definiert zunehmend die Umgebung, innerhalb derer autonome Entscheidungen überhaupt stattfinden dürfen. Anstatt ausschließlich technische Systeme zu beschreiben, beginnt Architektur zunehmend auch das Verhalten von Engineering-Systemen zu beschreiben.

• Welche Systeme dürfen miteinander interagieren?
• Welche Schnittstellen gelten als stabil?
• Welche Technologien werden bevorzugt?
• Welche Abhängigkeiten benötigen eine Freigabe?
• Welche Qualitätsmerkmale sind verpflichtend?

Diese Fragen werden nicht länger ausschließlich für menschliche Engineers beantwortet. Sie definieren die operativen Grenzen, innerhalb derer autonome Systeme arbeiten sollen. Die Architecture Runway verdeutlicht diese Entwicklung besonders gut. Traditionell repräsentierte sie die technische Grundlage, die zukünftige Geschäftsfunktionalität ohne unnötige Neugestaltung ermöglicht. Im Kontext des Agentic Engineering erhält die Architecture Runway jedoch eine zusätzliche Rolle. Sie wird zu einer navigativen Infrastruktur. Anstatt ausschließlich zukünftige Softwarefähigkeiten vorzubereiten, bereitet sie zukünftige autonome Entscheidungsfindung vor.

• Sie erklärt, wo Veränderungen zu erwarten sind.
• Sie identifiziert stabile Schnittstellen.
• Sie macht architektonische Einschränkungen sichtbar.
• Sie bietet Orientierung.

Autonome Agenten benötigen nicht lediglich Implementierungsaufgaben. Sie benötigen eine Karte. Auch dies verändert eine weitere langjährige Annahme. Über viele Jahre wurde Architektur primär anhand der Qualität der Systeme bewertet, die sie hervorbringt. Im Zeitalter des Agentic Engineering wird Architektur zunehmend anhand eines weiteren Kriteriums bewertet werden:

Wie effektiv ermöglicht sie autonomen Systemen, qualitativ hochwertige Engineering-Entscheidungen zu treffen?

Diese Perspektive verändert Architektur von einer unterstützenden Engineering-Disziplin zu einem der wichtigsten Wettbewerbsvorteile moderner Softwareorganisationen.

Das nächste Kapitel untersucht, warum Architektur allein dennoch nicht ausreicht. Sobald Organisationen ihr Architekturwissen explizit machen, müssen sie auch Governance von statischer Dokumentation zu einem aktiven Bestandteil des Engineering-Systems selbst weiterentwickeln.

Vorheriges Kapitel  Nächstes