← Zurück zur Übersicht

Abgrenzung und Risiken

1. Warum AURA kein klassisches Wiki ist

Ein klassisches Wiki hat oft diese Probleme:

• Informationen sind manuell gepflegt
• Dokumentation ist vom Code getrennt
• Aktualität ist unklar
• Ownership ist unklar
• Diagramme sind oft veraltet
• KI kann schwer erkennen, welche Informationen vertrauenswürdig sind
• Änderungen sind nicht sauber mit PRs, Commits und Releases verbunden

AURA unterscheidet sich dadurch:

Repo-nah
versioniert
reviewbar
CI-validiert
quellenbasiert
zentral auffindbar
maschinenlesbar
KI-nutzbar
mit Ownership
mit Trust Status

2. Warum AURA kein reines Developer Portal ist

Ein Developer Portal oder Service Catalog ist ein wichtiger Teil von AURA, aber AURA geht weiter.

Ein klassisches Developer Portal zeigt häufig:

Services
Teams
APIs
Dokumentation
Links
Ownership

AURA ergänzt:

PR-basierte Architekturprüfung
Doku-Pflicht bei Architekturänderungen
Architecture Snapshots
KI-Kontextschicht
MCP Server
Feature-Impact-Analyse
Architekturdrift-Erkennung
Trust Status
Human-reviewed AI Documentation

3. AURA und Jira

AURA sollte Jira nicht ersetzen.

Zusammen ergibt sich:

Jira  = Arbeits- und Produktkontext
AURA  = Architektur- und Systemkontext
Git   = Code- und Änderungskontext

4. Risiken bei AURA

AURA selbst kann scheitern, wenn bestimmte Risiken nicht berücksichtigt werden.

Risiko 1: Zu viel Bürokratie

Wenn AURA zu früh zu streng ist, umgehen Teams das System.

Gegenmaßnahme:

• stufenweise Einführung
• Warnings vor Errors
• gute Templates
• automatische Vorschläge
• klare Regeln
• schnelle Feedback-Loops

Risiko 2: KI erzeugt schöne, aber falsche Doku

Gegenmaßnahme:

• Human Review
• Quellenpflicht
• Trust Status
• CI Checks
• keine ungeprüften KI-Texte als „validiert" markieren

Risiko 3: Zentrale Doku wird neue Wahrheit

Gegenmaßnahme:

• Repo bleibt Source of Truth
• AURA zeigt immer Quelle, Commit und Snapshot
• keine manuellen Änderungen nur im Portal

Risiko 4: Diagramme veralten

Gegenmaßnahme:

• Diagrammquellen versionieren
• C4-Minimalstandard
• PR Checks bei Abhängigkeitsänderungen
• Drift-Erkennung

Risiko 5: Sicherheitsprobleme durch KI-Zugriff

Gegenmaßnahme:

• Permission Model
• Audit Logs
• keine Secrets
• gezielter Code-Kontext statt Full Repo Access
• Rollen und Sichtbarkeiten

5. Offene Entscheidungen

Für AURA müssen noch mehrere Entscheidungen getroffen werden.

Dokumentationsstandard

• Welche Dateien sind Pflicht?
• Welche Dateien sind optional?
• Welche Struktur gilt für alle Repos?
• Wie unterscheiden wir Service, Library, Frontend, Infrastruktur-Repo?

Diagrammstandard

• Mermaid, PlantUML oder Structurizr?
• Welche C4-Ebenen sind Pflicht?
• Wie werden zentrale Systemlandschaften erzeugt?

Metadatenmodell

• Wie sieht architecture.yaml genau aus?
• Welche Felder sind Pflicht?
• Wie werden Produkte, Systeme, Services und Teams modelliert?

PR-Governance

• Wann kommentiert AURA nur?
• Wann blockiert AURA?
• Wer darf Ausnahmen genehmigen?
• Wie werden False Positives behandelt?

KI-Kontext

• Welche Inhalte werden eingebettet?
• Welche Inhalte sind nur per Tool abrufbar?
• Wie werden Quellen zitiert?
• Wie wird Berechtigung geprüft?

MCP

• Welche Resources stellt AURA bereit?
• Welche Tools darf ein KI-Assistent nutzen?
• Welche Tools sind read-only?
• Welche Tools dürfen Aktionen auslösen?

Weiterlesen

• Nächste Seite: Vorlagen und CLI — Templates und CLI für den praktischen Start
• Einführung — wie die Risiken durch Phasen entschärft werden
• Governance und Drift — Sicherheit, Trust, Policies
• Zusammenfassung — Kernaussagen kompakt

← Zurück zur Übersicht