Einführung

← Zurück zur Übersicht

1. Möglicher technischer Stack

Ein möglicher Start-Stack:

Git Repositories
GitHub/GitLab/Bitbucket Webhooks
CI/CD Pipeline
AURA Ingest Service
Markdown
Mermaid oder PlantUML
ADRs
OpenAPI / AsyncAPI
architecture.yaml
MkDocs Material
Search Index
Vector Database
Graph Model
MCP Server
Jira Integration

Optional später:

Structurizr DSL
Backstage Integration
Graphdatenbank
Policy-as-Code
LLM-basierte Drift-Erkennung
Automatische ADR-Vorschläge
Automatische Diagramm-Vorschläge

2. Einführung in Phasen

AURA sollte nicht mit maximaler Governance starten. Empfohlene Phasen:

Phase 1: Dokumentationsstandard

• Repo-Struktur definieren
• architecture.yaml einführen
• Markdown-Templates erstellen
• ADR-Template erstellen
• C4-Minimalstandard definieren

Phase 2: Zentrale Webseite

• AURA Ingest bauen
• Snapshots erzeugen
• MkDocs Webseite generieren
• Service-Katalog anzeigen
• Links zu Repos und Jira herstellen

Phase 3: PR Checks

• AURA bei Pull Requests triggern
• fehlende Doku kommentieren
• API-/Dependency-Änderungen erkennen
• zunächst nur Warnungen erzeugen

Phase 4: AI Context Layer

• Suchindex erstellen
• Embeddings erzeugen
• Quellenmetadaten pflegen
• KI-Assistent anbinden
• Antworten mit Quellen ermöglichen

Phase 5: MCP Server

• AURA Resources bereitstellen
• AURA Tools bereitstellen
• standardisierte Prompts bereitstellen
• externe KI-Clients anbinden

Phase 6: Governance und Gates

• harte Checks für kritische Services
• Policy-as-Code
• Drift-Erkennung
• regelmäßige Review-Fristen
• Qualitätsmetriken

3. Minimum Viable AURA

Ein sinnvoller MVP startet klein.

MVP-Bausteine:

1. architecture.yaml pro Repository
2. Markdown-Templates für overview, context, containers und ADRs
3. C4 Context und Container als Mermaid oder PlantUML
4. AURA Ingest Service
5. AURA Repository mit Snapshots
6. MkDocs Portal
7. einfacher PR Check für fehlende Dokuänderungen
8. Volltextsuche
9. einfache Jira- und Repo-Links

Noch nicht im MVP nötig:

vollständiger MCP Server
Graphdatenbank
automatische Drift-Erkennung
harte Merge-Gates
komplexe Embeddings
vollautomatische KI-Doku-Erzeugung

4. Beispielhafter MVP-Flow

1. Repo enthält architecture.yaml und docs/architecture/overview.md.
2. Entwickler öffnet PR.
3. AURA prüft, ob bei relevanten Codeänderungen auch docs/ oder architecture.yaml geändert wurde.
4. AURA kommentiert im PR, falls nicht.
5. Nach Merge zieht AURA die Doku.
6. AURA erzeugt Snapshot mit Commit-ID.
7. MkDocs Portal wird neu gebaut.
8. Entwickler können zentrale Service-Übersicht lesen.

5. AURA und DORA

AURA passt gut zu den Erkenntnissen aus DORA im KI-Zeitalter.

Die Grundidee:

KI erhöht die Geschwindigkeit. Ohne gute Plattformen, klare Ownership, kleine Änderungen, Versionierung und zugängliches internes Wissen steigt aber auch das Chaos.

AURA stärkt genau diese Grundlagen:

• Versionierung
• kleine überprüfbare Änderungen
• interne Plattformfähigkeit
• zugängliche Dokumentation
• schnelle Feedback-Loops
• menschliche Kontrolle

AURA ist damit kein KI-Spielzeug, sondern ein organisatorisches Kontroll- und Verständniswerkzeug für KI-beschleunigte Softwareentwicklung.

6. Nächster sinnvoller Schritt

Der nächste Schritt wäre nicht sofort die technische Implementierung, sondern die Definition des Standards.

Konkret sollten als Nächstes definiert werden:

1. Welche Repository-Typen gibt es?
2. Welche Doku-Dateien sind pro Repo-Typ Pflicht?
3. Wie sieht architecture.yaml exakt aus?
4. Welche C4-Diagramme sind Pflicht?
5. Wie sieht ein ADR-Template aus?
6. Welche PR-Regeln gelten initial?
7. Welche Informationen braucht der erste MkDocs-Prototyp?
8. Welche MCP Resources und Tools wären für den ersten AI-Use-Case nötig?

Erst danach sollte ein MVP gebaut werden.

Weiterlesen

• Nächste Seite: Abgrenzung und Risiken — was bei der Einführung schiefgehen kann
• Vorlagen und CLI — Templates für den Phase-1-Start
• Zusammenfassung — Kernaussagen kompakt

← Zurück zur Übersicht