Enterprise Architecture: Von Automatisierung zu Autonomie

Eine gewagte Frage: Warum brauchen wir überhaupt noch Applikationen, wenn wir direkt mit intelligenten, personalisierten Agenten interagieren können? Diese Agenten erledigen jede benötigte Aufgabe – sie benötigen lediglich Daten, Wissen und Unterstützung durch andere spezialisierte Agenten.

Betrachten wir, was heutige Applikationen tatsächlich sind: eine Benutzeroberfläche, Business-Logik, Datenzugriff und Integrationspunkte – gebündelt zu einem Paket. Und was macht ein Agent? Er kommuniziert in natürlicher Sprache, schlussfolgert dynamisch über Business-Logik, greift über Tools und APIs auf Daten zu und orchestriert systemübergreifend.

Das ist jedoch eine Zukunftsrichtung – nicht unsere heutige Realität. Legacy-Systeme werden noch Jahrzehnte bestehen bleiben. Neue Applikationen werden weiterhin gebaut. Und für Aufgaben, die effizient, in grossem Umfang und konsistent erledigt werden müssen, könnten Applikationen weiterhin ihre Berechtigung haben. Dennoch verschiebt sich der architektonische Fokus: weg von Applikationen als primäre Ausführungsschicht hin zu Agenten als primärer Orchestrierungsschicht.

Deshalb haben wir beides in einer Domäne zusammengeführt: Agents & Applications. Heute unterscheiden sich Agenten und Applikationen noch darin, wie sie gebaut, integriert und gemanagt werden. Gleichzeitig rufen Agenten Applikationen bereits auf und betten sie ein und beginnen, eigene Applikationslogik zu generieren. Bald könnten die beiden nicht mehr unterscheidbar sein. 

Daten haben sich von einer unterstützenden Rolle zu einem zentralen Thema entwickelt. Über Jahre hinweg waren sie lediglich ein Bestandteil von Applikationen – in Datenbanken gespeichert, durch Applikationslogik geprägt und von Applikationsteams verwaltet. Dass Daten als eigenständige architektonische Domäne aufgestiegen sind, war eine bedeutende Entwicklung: von Data Warehousing über Master Data Management bis hin zu Data Mesh und Data Products.

Agenten transformieren diese Landschaft weiter: Denn sie fragen nicht nur Datenbanken ab – sie konsumieren unstrukturierte Informationen und Wissen, um zu schlussfolgern, zu planen und zu handeln. Ein Policy-Dokument, ein E-Mail-Thread, eine Prozessbeschreibung – all das wird zu direktem Input für das Verhalten von Agenten. Es reicht nicht mehr aus, Wissen in Dokumenten nur für Menschen verfügbar zu machen. Wir müssen es explizit managen, kuratieren und strukturieren, damit Agenten es lesen, finden und korrekt interpretieren können – für RAG (Retrieval-Augmented Generation), für Kontext und für autonome Entscheidungen.

Das erfordert neue Architekturkonzepte:

• Knowledge Graphs und Ontologien, die Agenten ein semantisches Verständnis ermöglichen.
• RAG-Architekturen (Retrieval-Augmented Generation), die Agentenantworten in organisationalem Wissen verankern.
• Agent Memory und Context Stores, damit Agenten Zustände über Interaktionen hinweg aufrechterhalten können.
• Embeddings und Vektor-Datenbanken, die unstrukturiertes Wissen durchsuchbar machen.
• Metadaten – Prozessbeschreibungen, Business Rules, Data Lineage – die Agenten benötigen, um effektiv zu operieren.

Darum haben wir die Domäne von Data Architecture in Data & Knowledge umbenannt. Es geht nicht mehr nur darum, Daten zu speichern und zu modellieren. Es geht darum, die Metadaten und das Knowledge Fabric zu kuratieren, auf dem Agenten schlussfolgern.

Dabei geht es weniger um agentische KI als um Trends, die sich seit Jahren abzeichnen: Cloud, Virtualisierung, Everything-as-a-Service, Zero Trust.

Wenn Infrastruktur als Service konsumiert wird, nimmt die architektonische Bedeutung ab, Systeme, Netzwerke und Virtualisierung separat zu modellieren. Mit Zero Trust verliert sogar der Netzwerkperimeter an Relevanz – Security ist nicht länger eine Funktion der Topologie, sondern von Identität und Policy.

Was das für Sie bedeutet: Technologie-Capabilities – System-, Netzwerk- und Virtualisierungsarchitektur – gehen zunehmend in Plattformentscheidungen, Cloud-Konfiguration und Security-Policies auf. Sie verschwinden nicht, aber ihre strategische Bedeutung als eigenständige architektonische Domäne nimmt ab. Enterprise Architecture stiftet heute den grössten strategischen Nutzen im Design von Business Capabilities, Agents & Applications sowie den Data & Knowledge, die diese antreiben.

Beispiele:

• Ein Entwicklungsteam kann heute Compute, Storage und Networking mit einem einzigen API-Call beziehen – oder serverless gehen. Eine eigene Serverarchitektur ist nicht mehr nötig.
• Ein Unternehmen migriert auf eine Cloud-Plattform, die Infrastruktur, Security und Compliance «out of the box» bündelt – was früher eine komplexe Technologiearchitektur-Entscheidung war, wird zur Konfigurationsentscheidung.

Ein Capability Model definiert, was wir architektieren. Gleichzeitig benötigt ein Unternehmen Capabilities, um Enterprise Architecture zu managen, das Enterprise-Architecture-Repository zu pflegen und Governance sicherzustellen.

Während Enterprise-Architecture-Management und Repository auch in einer agentischen Welt weitgehend stabil bleiben, verändert sich Governance grundlegend. Wenn Agenten autonom handeln, entstehen neue Fragen: Wem gehört ein Agent? Wer ist verantwortlich für seine Entscheidungen? Wie stellen wir Compliance sicher?

Zwei zentrale Ergänzungen im Governance-Modell:

• Guardrails: maschinell durchsetzbare Grenzen, die das Verhalten von Agenten in Echtzeit einschränken – ein zentrales Governance-Konzept.
• Agent & Data Governance: adressiert Verantwortlichkeit, Ownership und Compliance für autonome Agenten und die von ihnen genutzten Daten.

Wir lassen bewusst zwei Fragen offen: Wie sollte Governance für autonome Agenten angepasst werden? Und wie werden sich Architekturrollen weiterentwickeln? Das sind Themen für einen weiteren Blogpost.