Design
Von der Anforderung zur dokumentierten, entscheidbaren Architektur
Die Design-Phase überführt das Anforderungsmodell in eine Agentic-Ready-Zielarchitektur: fachliche Domänenschnitte, Agenten- und Tool-Architektur, Datenarchitektur und Guardrails. Jede Architekturentscheidung wird explizit dokumentiert und gegen Qualitätsanforderungen bewertet.
Einordnung der Phase im TRANSFORM-Vorgehensmodell
Vorgehensmodell
Ergebnis ist eine nach arc42 dokumentierte, über Architecture Decision Records nachvollziehbare Zielarchitektur mit definierter Agenten-Topologie, API-Verträgen und einem Migrationsdesign von Legacy zur Ziellandschaft.
Fachlicher Schnitt (Domain-Driven Design)
Ableitung von Bounded Contexts und Ubiquitous Language aus Prozess- und Anforderungsmodell; strategisches Design mit Context Mapping als Grundlage des System- und Agentenschnitts.
Agenten- & Tool-Architektur
Design der Agenten-Topologie (Orchestrierung, Spezialagenten, Human-in-the-Loop-Punkte), der Tool-Schnittstellen und der Kontextversorgung (Retrieval, Wissensbasen) entlang der ReqPOOL-Referenzarchitektur.
System- & Datenarchitektur
Zielbebauung mit API-first-Schnittstellen, Ereignisflüssen und Datenprodukten; Ableitung der Migrationsarchitektur aus dem Horseshoe-Modell der Analyse-Phase.
Qualitäts- & Guardrail-Design
Attribute-Driven Design gegen priorisierte Qualitätsszenarien (ISO 25010); Definition von Sicherheits-, Compliance- und KI-Guardrails inklusive Berechtigungs- und Auditkonzept.
Architekturentscheidung & Dokumentation
Bewertung von Alternativen, Festschreibung als Architecture Decision Records und konsolidierte arc42-Dokumentation; Review nach ISO 42010-Stakeholder-Sichten.
Methodik-Mix
Agentic-Ready-Zielarchitektur und Lösungsdesign
| Methode | Einsatzzweck im TRANSFORM-Kontext | Referenz |
|---|---|---|
| Domain-Driven Design (strategisch) | Bounded Contexts und Context Mapping als fachlicher Schnitt für Systeme und Agenten; verhindert monolithische Agentenlandschaften. | Evans (2003) |
| arc42 & C4-Modell | Standardisierte Architekturdokumentation und hierarchische Visualisierung von Kontext bis Komponente; ReqPOOL-Dokumentationsstandard. | arc42; Brown |
| Attribute-Driven Design (ADD 3.0) | Iterative Architekturentwicklung aus priorisierten Qualitätsattribut-Szenarien; verankert nicht-funktionale Anforderungen im Design. | Bass, Clements & Kazman (SEI) |
| ISO/IEC/IEEE 42010 | Norm für Architekturbeschreibungen: Stakeholder, Concerns, Sichten und Korrespondenzregeln. | ISO/IEC/IEEE 42010:2022 |
| ISO/IEC 25010 Qualitätsmodell | Taxonomie der Produktqualität (u. a. Zuverlässigkeit, Sicherheit, Wartbarkeit) als Bewertungsrahmen der Qualitätsszenarien. | ISO/IEC 25010:2023 |
| ReqPOOL Agentic Reference Architecture | Hausinterne Referenzarchitektur für agentische Systeme: Orchestrierung, Tool-Verträge, Kontextversorgung, Guardrails und Evaluationsschleifen. | ReqPOOL (intern); vgl. Anthropic (2024) |
Plattform-Unterstützung
ReqPOOL Suite: REAM (Enterprise-Architektur) · Requirements Manager (Agentisches Requirements Management)
REAM — IST-Landschaft als Design-Grundlage
Prozesse, Applikationen, Schnittstellen und Infrastruktur aus dem Inventar bilden die faktenbasierte Ausgangslage des Architekturentwurfs.
REAM — EAM-Entscheidungsboard
KI-abgeleitete Architektur-Empfehlungen werden im Board entschieden und dokumentiert — jede Empfehlung bis zur Datenbasis nachvollziehbar.
REAM — Zielarchitektur & Transformations-Roadmap
Entscheidungsreife Ziel-Landschaft und Roadmap je Jahr, inklusive der Migrationsstufen aus der Gap-Analyse der Analyse-Phase.
Requirements Manager — AI Coding Intent
Der maschinenlesbare Umsetzungsauftrag übersetzt das Lösungsdesign (Use Cases, Geschäftsobjekte, Schnittstellen, Rechte) in eine direkt implementierbare Form für die Build-Phase.
Best Practices der Plattformnutzung
- KI-abgeleitete Architektur-Empfehlungen immer im EAM-Board entscheiden — die Entscheidung bleibt beim Menschen und wird mit Datenbasis dokumentiert.
- Jede angenommene oder verworfene Alternative als ADR festhalten; Architektur ohne Entscheidungshistorie gilt als undokumentiert.
- Qualitätsszenarien vor dem Strukturentwurf priorisieren — ADD beginnt bei den Treibern, nicht bei der Technologie.
- Human-in-the-Loop-Punkte explizit im Agenten-Design ausweisen und mit dem Governance-Rahmen aus der Strategy-Phase abgleichen.
- Den AI Coding Intent gegen Zielarchitektur und ADRs reviewen, bevor er an die Implementierung geht.
- Migrationsdesign stets rückwärts vom Zielbetrieb denken: jede Zwischenstufe muss eigenständig betreibbar und rückrollbar sein.
Artefakte & Ergebnisse
- Zielarchitektur nach arc42 mit C4-Diagrammen
- Agenten-Topologie mit Tool-Verträgen und Kontextversorgung
- Architecture Decision Records (ADRs)
- Qualitäts- und Guardrail-Konzept (ISO 25010, EU AI Act)
- Migrationsdesign Legacy → Zielarchitektur
Quality Gate — Design
Der Übergang in die Folgephase erfolgt über ein formales Quality Gate (Go/No-Go). Die Gate-Kriterien werden im Gate-Review dokumentiert und vom Engagement Lead freigegeben.
- Zielarchitektur vom Architektur-Board freigegeben
- Alle kritischen Entscheidungen als ADR dokumentiert
- Qualitätsszenarien bewertet, Restrisiken akzeptiert
- Migrationsstufen mit Rollback-Fähigkeit definiert
Wissenschaftliche Vertiefung
Grundlagenwerk des fachgetriebenen Software-Designs.
SEI-Standardwerk zu Qualitätsattributen und Architekturmethoden.
Norm für Architekturbeschreibungen und Stakeholder-Sichten.
Qualitätsmodell für Systeme und Software.
Praxisstandard der Architekturdokumentation im deutschsprachigen Raum.
Forschungsbasierte Entwurfsmuster für agentische Systeme.
Best-Practice-Anleitung: Phase Design
Kompakte Checkliste mit Vorgehensmodell, Methodik-Mix und Plattform-Best-Practices für den Einsatz im Engagement.
Best-Practice-Anleitung als PDF laden