Technische Verantwortung über Produkte hinweg
Der Architekt / Senior Engineer stellt sicher, dass von Agenten implementierte Anwendungen mit den Engineering-Standards des Unternehmens vereinbar bleiben. Diese Rolle definiert oder interpretiert die freigegebene Architektur, leitet folgenreiche Entwurfsentscheidungen, prüft die Implementierung und steuert Änderungen gemeinsamer Bausteine.
Der Architekt ist aktiv am Entwicklungsmodell beteiligt und nicht nur ein Genehmiger am Projektende. Frühe Beteiligung hilft, ungeeignete Integrationen, unnötige neue Abhängigkeiten und Implementierungsansätze zu verhindern, die der Unternehmensumgebung widersprechen.
Die Leitplanken schaffen
Architekten helfen, freigegebene Stacks, wiederverwendbare Bibliotheken, Authentifizierungs- und Sicherheitsansätze, Architekturmuster, Repository-Konventionen und dokumentierte Anweisungen für Coding-Agenten zu pflegen. Gemeinsam mit dem Product Engineer ermitteln sie, welche vorhandenen Bausteine zum Projekt passen und welche projektspezifischen Entscheidungen Aufmerksamkeit benötigen.
Sie stellen außerdem sicher, dass die verfügbaren Ausführungsmöglichkeiten und Berechtigungen des Agenten den Unternehmensrichtlinien entsprechen, üblicherweise zusammen mit den Teams, die diese Kontrollen verwalten.
Technische Grundlage in Phase 2
Der Architekt wirkt früh in Zyklus 1 mit: Er interpretiert Unternehmensstandards, bestimmt den freigegebenen Stack und geeignete wiederverwendbare Bausteine, legt erste Architekturgrenzen fest und stimmt sich bei technischen Zugriffskontrollen mit Plattform- und Sicherheitsverantwortlichen ab. Product Engineer und UX-Designer arbeiten mit ihm zusammen, während sich Funktionsspezifikationen, Benutzerabläufe und technische Entscheidungen gegenseitig beeinflussen.
Ziel ist ein solider, nutzbarer Ausgangspunkt für die Implementierung statt einer vollständigen Architekturübung vorab. Wichtige Ausnahmen oder risikoreiche Entscheidungen folgen den bestehenden Freigaberichtlinien der Organisation. Das SHAPE Framework schafft kein separates verpflichtendes Architecture Readiness Review.
Der Product Engineer verantwortet die Steuerung inkrementeller Implementierung, Testartefakte und die fortlaufende Produktwartung innerhalb dieser Grenzen. Wenn neue Anforderungen eine Architekturfrage oder eine notwendige Abweichung von Standards aufzeigen, bezieht er den Architekten ein und holt die passende Entscheidung ein. Routinearbeit innerhalb freigegebener Muster verlangt nicht automatisch eine neue Architektenfreigabe.
Prüfungen in Zyklus 1
Zyklus 1 umfasst zwei geplante Architektenprüfungen der Implementierung. Nach der ersten funktionalen Implementierung prüft der Architekt die entstehende Anwendung und erkennt wesentliche technische Probleme vor einer umfassenden Stakeholder-Prüfung. Nach Stakeholder-Iteration und unabhängigem spezifikationsbasiertem Testen führt er die Abschlussprüfung durch und erteilt vor dem UAT die technische Freigabe gemäß Unternehmensrichtlinie.
Diese Prüfungen behandeln architektonische Stimmigkeit, freigegebene Wiederverwendung, Sicherheit, Integrationsentscheidungen, Wartbarkeit und die Behebung wichtiger Befunde. Ihre Tiefe richtet sich nach Projektrisiko und technischer Komplexität. Technische Freigabe ist von fachlicher Abnahme zu unterscheiden.
Prüfung in Zyklus 2
Spätere Erweiterungszyklen erfordern Architektenbeteiligung entsprechend Änderungsrisiko und Unternehmensrichtlinien. Eine kleine Textänderung innerhalb eines freigegebenen Systems ist nicht mit der Einführung einer neuen externen Integration oder eines Berechtigungsmodells gleichzusetzen. Organisationen sollten sinnvolle Auslöser definieren, statt jede Bearbeitung als neue Entscheidung eines Architekturgremiums zu behandeln.
Governance gemeinsamer Bausteine
Entdeckt ein Projekt eine nützliche Komponente, ein Bibliotheksmuster, eine Agentenanweisung oder eine Architekturverbesserung, bewertet der Architekt, ob diese in die gemeinsamen Unternehmensmaterialien gehört. Eine lokal erfolgreiche Behelfslösung wird nicht automatisch zum organisationsweiten Standard. Gemeinsame Änderungen sollten auf Allgemeingültigkeit, Wartungsaufwand, Kompatibilität und Sicherheit geprüft werden.
Kapazität und Zusammenarbeit
Architekten unterstützen mehrere Produkte oder Pods, ihre Verantwortung muss jedoch begrenzt bleiben. Sie sollten früh genug erreichbar sein, um Entscheidungen zu beeinflussen, und für zeitnahe Prüfungen verfügbar sein. Werden Architekten zu einer überlasteten zentralen Warteschlange, geht ein Teil des Zeitgewinns agentischer Implementierung verloren.