Drei Abteilungen wollen KI im Kundenservice einsetzen. Jede findet ein anderes Tool gut, Kundendaten liegen in mehreren Systemen, und niemand weiß, wer eine falsche Zusage verantwortet. Wer sorgt dafür, dass aus den einzelnen Ideen eine Lösung wird, die zum Unternehmen passt?
Enterprise Architektur verbindet Geschäftsziele mit Prozessen, Daten, Anwendungen und Technologie. Sie macht Abhängigkeiten sichtbar und hilft, Veränderungen über Teams und Projekte hinweg zu entscheiden. Architekturrollen übernehmen dabei unterschiedliche Ausschnitte: vom Aufbau eines Softwaresystems bis zur Entwicklung der gesamten Unternehmenslandschaft. Im KI-Zeitalter kommen Entscheidungen über Modellqualität, Datenzugriff und Handlungsbefugnisse hinzu. Ein Architekturmodell allein löst diese Fragen nicht; die Entscheidungen müssen in Umsetzung und Betrieb wirksam werden.
Gute Architektur macht Ziele, Abhängigkeiten und Konsequenzen einer Entscheidung verständlich. Bei KI gehört dazu, festzulegen, was ein System wissen, entscheiden und ausführen darf.
Wie Enterprise Architektur aus Einzelprojekten ein Ganzes macht
Im Kundenservice-Beispiel ist „Wir brauchen einen Chatbot“ zunächst ein Lösungsvorschlag. Das Geschäftsziel könnte heißen: Beschäftigte sollen verlässliche Antworten auf Kundenfragen schneller finden. Vielleicht reichen dafür eine bessere Suche und gepflegte Wissensartikel. Vielleicht hilft ein Sprachmodell. Erst das Ziel und die vorhandenen Probleme liefern die Kriterien für diese Entscheidung.
Enterprise Architektur betrachtet dazu vier zusammenhängende Bereiche. Die Tabelle beschreibt ein fiktives Unternehmen; sie enthält keine gemessenen Projektergebnisse.
Eine hilft, vom benötigten Können auszugehen. Zur Fähigkeit „Kundenanfragen bearbeiten“ gehören Menschen, Abläufe, Wissen und Systeme. Nur die Anwendung auszutauschen kann das Problem verfehlen, wenn niemand die Wissensartikel pflegt.
Aus dem heutigen Zustand, einem angestrebten Zustand und den notwendigen Änderungen entsteht eine nachvollziehbare Entwicklung: zuerst Datenverantwortung klären, dann eine begrenzte Assistenz erproben, anschließend anhand der Ergebnisse über weitere Schritte entscheiden. Die Architektur wird mit den Teams angepasst, sobald neue Erkenntnisse entstehen.
Diese Verbindung von Strategie, Abhängigkeiten und Veränderung beschreibt SFIA 9 für Enterprise- und Businessarchitektur. ist ein möglicher methodischer Rahmen. Die Open Group stellt außerdem ArchiMate als Modellierungssprache bereit. Eine Methode strukturiert die Arbeit; sie ersetzt weder Kenntnis des Unternehmens noch die Entscheidung der Verantwortlichen.
Welche Architekturrolle welche Fragen bearbeitet
Architektur ist eine Tätigkeit, die in unterschiedlichen Rollen und auch gemeinsam im Team ausgeübt wird. Stellenbezeichnungen und Zuschnitte variieren. Die folgende Übersicht ist eine praktische Orientierung, keine verbindliche Rangfolge oder vollständige Berufssystematik.
Eine Solution Architect kann sehr komplexe Lösungen verantworten; Enterprise Architektur hat einen anderen Betrachtungsbereich. Der Wechsel ist deshalb kein automatisches „Level-up“. Spezialisierungen wie Security oder Data können auf mehreren dieser Ebenen arbeiten. In kleineren Organisationen übernimmt dieselbe Person mehrere Aufgaben.
Architektinnen und Architekten arbeiten dafür mit Fachbereichen, Entwicklung, Betrieb und weiteren Verantwortlichen zusammen. Sie erläutern Alternativen, machen Zielkonflikte sichtbar und begleiten die Umsetzung. Ein Beispiel: Eine zentrale KI-Plattform kann gemeinsame Kontrollen erleichtern, aber auch Abhängigkeiten und Abstimmungsaufwand schaffen. Eine gute Entscheidung benennt beide Seiten und die Bedingungen, unter denen sie überprüft wird.
SFIA 9 zu Solution Architektur betont solche Abwägungen sowie Sicherheit, Betrieb und Kosten. Für den Zuschnitt der Softwarearchitektur beschreibt iSAQB CPSA-F Grundlagen des Entwerfens, Kommunizierens und Bewertens von Softwaresystemen.
In welche Richtung du dich entwickeln kannst
Ein sinnvoller Entwicklungsweg beginnt mit der Art von Problemen, für die du Verantwortung übernehmen möchtest. Dazu kommen technische Grundlagen, Verständnis des Fachgebiets und die Fähigkeit, Entscheidungen mit anderen zu treffen. Kommunikation gehört zur Architekturarbeit, weil eine Lösung nur trägt, wenn die beteiligten Menschen ihre Konsequenzen verstehen.
Die Übungen sind eigene Lernvorschläge, keine vorgeschriebenen Karrierepfade. Aus der Entwicklung führt oft ein Weg über Entscheidungen im eigenen System und später über Systemgrenzen hinweg. Aus Fachanalyse oder Prozessarbeit kann ein Weg über Business Architektur führen; aus Daten- oder Infrastrukturarbeit über eine Spezialisierung. Die fehlende Perspektive muss jeweils dazukommen: technische Umsetzbarkeit, fachlicher Nutzen oder organisatorische Verantwortung.
Als ersten Nachweis kannst du einen zu einer echten Entscheidung schreiben. Im Kundenservice könnte er erklären, weshalb die Assistenz zunächst nur Entwürfe erstellt, welche Alternative geprüft wurde und wann zusätzliche Befugnisse neu bewertet werden. Ein Review und spätere Betriebserfahrungen zeigen, was du daraus gelernt hast.
Wie du Lernrahmen und Zertifikate einordnen kannst
TOGAF kann die methodische Arbeit an Enterprise Architektur strukturieren. iSAQB CPSA-F vermittelt Grundlagen der Softwarearchitektur. SFIA beschreibt Fähigkeiten und Verantwortungsniveaus und eignet sich als Orientierung für ein Kompetenzgespräch. Diese Angebote haben unterschiedliche Zwecke und sind keine austauschbaren Stufen derselben Ausbildung.
Ein Lernrahmen kann Wissenslücken sichtbar machen. Für die praktische Entwicklung brauchst du außerdem echte Entscheidungen, Rückmeldungen von Beteiligten und Erfahrung mit ihren Folgen. Wähle deshalb anhand der Aufgaben, die du übernehmen willst, und der Arbeitsweise deiner Organisation.
Was sich durch KI an Architekturentscheidungen ändert
Bei einer generativen KI-Anwendung wird die Qualität einzelner Antworten zu einer eigenen Prüfaufgabe. Neben Schnittstellen, Verfügbarkeit und Kosten musst du untersuchen, ob Antworten für den vorgesehenen Einsatz brauchbar sind und welche Aktionen daraus folgen dürfen. Eine überzeugende Demo liefert dafür noch keinen belastbaren Nachweis.
Im Beispiel sind drei Ausbaustufen zu unterscheiden: Wissen finden, Antworten entwerfen und Aktionen ausführen. Jede weitere Stufe verlangt zusätzliche Entscheidungen. Eine Suche darf passende Inhalte liefern; eine Assistenz formuliert daraus einen Entwurf; ein handelnder Agent könnte einen Kundenvorgang verändern. Die Befugnisse sollten aus der Aufgabe folgen und technisch begrenzt werden.
verbinden die Qualitätsfrage mit konkreten Nachweisen. Im Kundenservice gehören dazu aktuelle und veraltete Wissensartikel, eine unbeantwortbare Frage sowie ein Vorgang außerhalb der Zugriffsrechte. Die Auswahl und Bewertung brauchen Fachwissen; ein einzelner Gesamtwert kann wichtige Fehlerarten verdecken.
Das NIST AI Risk Management Framework ordnet Risikomanagement den Funktionen Govern, Map, Measure und Manage zu: Verantwortung organisieren, den Einsatzkontext verstehen, Risiken prüfen und darauf reagieren. Das Generative-AI-Profil von 2024 ergänzt spezifische Risiken generativer KI. Das sind freiwillige Orientierungshilfen, keine automatische Freigabe einer Anwendung. NIST weist zum Recherchezeitpunkt auf eine laufende Überarbeitung von AI RMF 1.0 hin.
Ein Prompt wie „Lies nur erlaubte Kundendaten“ begrenzt keine technischen Berechtigungen. Der Zugriff muss im angebundenen System geprüft werden; folgenreiche Aktionen brauchen den vorgesehenen Freigabeschritt. Ein besseres Modell ersetzt diese Kontrollen nicht.
OWASP beschreibt unter Excessive Agency die Risiken zu vieler Funktionen, zu weitreichender Berechtigungen und zu großer Autonomie. Die AWS Generative AI Lens ergänzt die Perspektive auf Qualität, Zuverlässigkeit und Kosten im gesamten Lebenszyklus. Ihre konkreten Umsetzungshinweise beziehen sich auf AWS; die Entscheidungsfragen lassen sich auch für andere Plattformen prüfen.
Wie du KI für die eigene Architekturarbeit nutzen kannst
Ein sinnvoller Versuch ist, KI für einen ersten Entwurf einer Entscheidungsvorlage einzusetzen. Gib dafür freigegebene Informationen über Ziel, Randbedingungen und bekannte Systeme vor. Lass offene Annahmen und fehlende Informationen ausdrücklich kennzeichnen. Prüfe anschließend jede vorgeschlagene Abhängigkeit und Alternative mit den zuständigen Menschen und den tatsächlichen Systemen.
So kannst du beispielsweise Gegenargumente zu einer geplanten zentralen Assistenz sammeln oder einen vorhandenen ADR auf unklare Annahmen prüfen lassen. Nutze Unternehmensinformationen nur in dafür freigegebenen Werkzeugen. Plausibel formulierte Systembeziehungen und Quellen müssen überprüft werden; KI-Ausgaben sind Arbeitsmaterial, kein Beleg über die reale Unternehmenslandschaft.
Die praktische Schlussfolgerung aus den Quellen: Ein KI-Schwerpunkt erweitert Architekturarbeit um Modellbewertung und kontrollierte Handlungsfähigkeit. Ob einzelne Stellenbezeichnungen verschwinden oder entstehen, lässt sich daraus nicht verlässlich vorhersagen. Für deine Entwicklung ist greifbarer, Ziele zu klären, Alternativen prüfbar zu machen und Verantwortung bis in den Betrieb zu verfolgen.
Woran du eine tragfähige Architekturentscheidung erkennst
Für eine erste Entscheidung brauchst du ein konkretes Ziel, Zugang zu den beteiligten Fach- und Technikverantwortlichen und eine belastbare Übersicht der betroffenen Systeme. Eine kurze Skizze und eine Entscheidungsvorlage reichen zum Einstieg. Detailliertere Modelle helfen, sobald die Abhängigkeiten damit verständlicher werden.
Prüfe deine Vorlage an diesen fünf Fragen. Eine fehlende Antwort ist ein offener Arbeitsauftrag, keine schlechte Punktzahl in einem erfundenen Reifegradmodell.
- Ziel: Ist die gewünschte Verbesserung so beschrieben, dass ihr sie an realen Aufgaben prüfen könnt?
- Abhängigkeiten: Sind Datenquellen, Systeme und die jeweiligen Verantwortlichen benannt?
- Alternativen: Ist nachvollziehbar, warum diese Lösung gewählt wurde und was gegen sie spricht?
- Befugnisse: Ist festgelegt und technisch überprüfbar, welche Daten und Aktionen erlaubt sind?
- Betrieb: Sind Qualitätsprüfung, Ersatzablauf und ein Anlass für die erneute Bewertung vereinbart?
Enterprise Architektur hilft besonders, wenn mehrere Vorhaben gemeinsame Daten, Fähigkeiten oder Plattformen verändern. Für eine lokale, leicht rückgängig zu machende Änderung genügt oft die Entscheidung im zuständigen Team. Umfang und Dokumentation sollten zur Tragweite der Entscheidung passen.
Quellen und nächste Schritte
Recherche und Quellenprüfung: 8. Oktober 2026. Das Kundenservice-Beispiel, die Rollenübersicht und die Lernübungen sind eine eigene didaktische Aufbereitung. Die folgenden Primärquellen begründen Aufgabenbereiche, Lernrahmen und die Entscheidungen für KI-Systeme.
- The Open Group: TOGAF und ArchiMate – methodischer Rahmen und Modellierung von Enterprise Architektur.
- SFIA 9: Enterprise and Business Architecture – Strategie, Abhängigkeiten und Veränderungsplanung.
- SFIA 9: Solution Architecture – Lösungen, Abwägungen und Begleitung der Umsetzung.
- iSAQB: CPSA-Foundation Level – Entwurf, Kommunikation und Bewertung von Softwarearchitektur.
- NIST: AI RMF und Generative AI Profile – Risikomanagement im KI-Lebenszyklus.
- OWASP: LLM06:2025 Excessive Agency – begrenzte Funktionen, Berechtigungen und Autonomie.
- AWS: Generative AI Lens – Architekturfragen für Entwicklung und Betrieb generativer KI, veröffentlicht am 19. November 2025.
Wenn du den Wissenszugriff aus dem Beispiel genauer verstehen möchtest, erklärt Embeddings, wie eine semantische Suche Kandidaten für eine Antwort findet und wo ihre Grenzen liegen. Für den Übergang vom Antworten zum Handeln zeigt Web MCP, wie Anwendungen konkrete Werkzeuge für Agenten anbieten.