Architecture Lab

Environment-Landschaft & ALM-Fluss

flowchart LR
  PERS["Personal<br/>sandbox · default DLP"] --> TEAM["Team<br/>shared maker envs"]
  TEAM --> DEPT["Department<br/>governed pre-prod"]
  DEPT -->|"pipelines · approvals<br/>env variables · connection refs"| PROD["Managed production<br/>managed solutions"]

DLP-Klassifikationsmatrix

Betriebsmodell

• → Dataverse-Rollen und Zugriffsmodell je Environment-Klasse; App-Ownership registriert — verwaiste Apps werden erkannt und neu zugewiesen oder stillgelegt.
• → Managed Solutions jenseits von Dev; Environment-Variablen und Connection References machen die Promotion reproduzierbar.
• → Center of Excellence: Telemetrie zu Makern/Apps/Flows, Reifegradmodell für die Maker-Segmentierung, Support-Playbooks.
• → Explizite Übergangskriterien von Citizen Development zu professioneller IT: Datensensitivität, Nutzerzahl, Verfügbarkeitsanforderungen, Integrationstiefe.

Use-Case-Lifecycle

flowchart LR
  A["Idea"] --> B["Classification"] --> C["Architecture"] --> D["Risk review"] --> E["Pilot"]
  E --> F["Readiness review"] --> G["Production"] --> H["Monitoring"] --> I["Retirement"]

Bausteine des Betriebsmodells

• → Intake: Jeder KI-Use-Case wird mit einem Business-Owner UND einem technischen Owner registriert — keine verwaisten Experimente.
• → Die Risikoklassifikation bestimmt den Pfad: freigegebene Datenkategorien, freigegebener Modellkatalog, Review-Tiefe.
• → Freigabegremien mit Security-Review und Production-Readiness-Gates; Ausnahmen mit Ablaufdatum statt Dauer-Waivern.
• → Kostenverantwortung je Use Case; Monitoring und Incident Response vor dem Go-live verdrahtet; Modell-Stilllegung als vollwertige Phase.

Auswahlmatrix (Methode — Werte sind use-case-spezifisch)

Routing & Lifecycle

• → Task-Klassifikation + Datensensitivität bestimmen das Kandidatenset; Qualitäts-Benchmarks je Task-Familie, keine globalen Leaderboards.
• → Routing mit Fallback-Ketten und Circuit Breakers; Versions-Pinning mit deklarierten Migrationsfenstern.
• → Deprecation- und Rollback-Pläne bereits bei der Einführung geschrieben; Verbrauchsbudgets je Workload.

Kontrollen je Phase

Telemetrie-Rückgrat

flowchart TD
  REQ["Request"] --> TR["Trace<br/>prompt ver · model ver · tools"]
  TR --> TOK["Tokens · cost"]
  TR --> QUAL["Quality<br/>groundedness · retrieval · tool success"]
  TR --> SAFE["Safety<br/>filter hits · escalations"]
  TOK --> SLO["SLO evaluation"]
  QUAL --> SLO
  SAFE --> SLO
  SLO --> AL["Alerts · rollback thresholds"]

Beispiel-Scorecard

• → Verfügbarkeit · P95-Latenz · Kosten je erfolgreicher Task
• → Grounded-Answer-Rate · Tool-Erfolgsrate · Drift vs. Baseline
• → Eskalationsrate an Menschen · kritische Sicherheitsvorfälle (Ziel: null)
• → Jedes SLO hat einen Owner, eine Alert-Schwelle und einen Rollback-Trigger.

Modellbausteine

• → Architekturprinzipien + Referenzarchitekturen als gemeinsame Sprache; Standardkatalog mit explizitem Ausnahmeprozess.
• → Design Reviews aus Dokumenten (ADRs), nicht aus Slides — Entscheidungen festgehalten, revisitiert, bei Bedarf eskaliert.
• → Wiederverwendbare Komponenten und Plattform-Ownership; technische Schulden mit demselben Ernst verfolgt wie Features.
• → Architektur-Community über Streams hinweg; Roadmap-Alignment, damit lokale Optimierung nie die globale Kohärenz schlägt.

Design-Review-Checkliste (Auszug)

• → Ist die Entscheidung als ADR mit Alternativen und Trade-offs festgehalten?
• → Identität, Datenklassifikation und Audit-Pfad vor dem Build definiert?
• → Kostenmodell und SLOs benannt? Rollback-Pfad getestet, nicht nur beschrieben?
• → Kann ein anderes Team das System ohne seine Autoren betreiben?