Architektur-Audit

Sie wissen nicht genau, wie Ihre Software wirklich funktioniert?
Dokumentation ist veraltet oder fehlt? Risiken sind unklar?

Ich analysiere Ihre Software systematisch und mache den Ist-Zustand transparent.

Was Sie nach 2–4 Wochen bekommen

C4/arc42-Systemlandkarte

  • C1: System Context – Externe Schnittstellen, Nutzer, Abhängigkeiten
  • C2: Container – Services, Datenbanken, Queues, APIs
  • C3: Component – Interne Module, Abhängigkeiten, Datenflüsse
  • Trust Boundaries – Security-Grenzen visualisiert

Risk Register (Risiko- und Massnahmenliste)

5 Risiko-Kategorien:

  • Security Risks – Threat Model (STRIDE), Authentifizierung, Verschlüsselung
  • Operational Risks – SPOF (Single Point of Failure), Performance, Skalierbarkeit
  • Cost Risks – Cloud-Kosten, Wartungsaufwand, technische Schulden
  • Delivery Risks – Deployment-Risiken, fehlende Automatisierung
  • Data Risks – Datenverlust, Inkonsistenzen, fehlende Backups

Jedes Risiko enthält: Severity, Impact, Mitigation

ADRs (kurze Entscheidungsprotokolle)

  • 5–15 ADRs für bestehende Architektur-Entscheidungen
  • Format: Kontext, Optionen, Entscheidung, Konsequenzen
  • Ziel: Trade-offs transparent machen, Bauchgefühl → Fakten

NFR/SLO-Baseline

  • Non-Functional Requirements: Performance, Availability, Security
  • Service Level Objectives: Messbare Ziele (z.B. "99,9% Uptime")
  • Ist-Werte: Aktuelle Baseline (wo stehen wir heute?)

90-Tage-Roadmap

  • Priorisierte Maßnahmen: Quick Wins, mittelfristig, langfristig
  • Inkremente: Kein Big-Bang, schrittweise Verbesserungen
  • Governance-Empfehlungen: Reviews, Gates, KPI-Tracking

Anonymisiertes Arbeitsbeispiel

Ein typischer Kontext ist ein Java-/Spring-basiertes Dokumentmanagement-/Data-Vault-System mit Upload, OCR, Lucene-Volltextsuche, semantischer Suche, REST/OpenAPI, Rollen/Rechten, Audit und wiederverwendbaren Java-/Spring-Plattformbibliotheken.

Daran zeigt sich der Ablauf: zuerst Systemlandkarte, dann priorisierte Risiken, dann Entscheidungsprotokolle, messbare Qualitätsziele und eine 90-Tage-Roadmap, die direkt in Umsetzung und Teamarbeit übergehen kann.

Ablauf: Woche für Woche

Woche 1

Discovery

  • Repo-Analyse (Code-Struktur, Abhängigkeiten, Tech Stack)
  • Runtime-Checks (Logs, Metrics, Traces, Performance)
  • Datenfluss-Analyse (woher kommen Daten, wohin gehen sie?)
  • Erste C4-Hypothesen

Ergebnis: Überblick über Systemarchitektur, Tech Stack dokumentiert

Woche 2

Architektur & Security

  • C4/arc42-Systemlandkarten erstellen (C1–C3)
  • Trust Boundaries definieren (Security-Grenzen)
  • Interviews mit Team (Entscheidungen verstehen)
  • Threat Modeling (STRIDE)

Ergebnis: Visualisierte Architektur (C4), Security-Grenzen dokumentiert

Woche 3

Risiken & Qualität

  • Risk Register erstellen (Security/Operational/Cost/Delivery/Data)
  • ADRs für bestehende Entscheidungen dokumentieren
  • NFR/SLO-Targets definieren
  • Ist-Werte messen (Baseline)

Ergebnis: Priorisiertes Risk Register, ADRs dokumentiert, NFR/SLO-Baseline

Woche 4

Roadmap & Workshop

  • Workshop mit Stakeholdern (Ergebnisse präsentieren)
  • 90-Tage-Roadmap erstellen (priorisierte Maßnahmen)
  • Governance-Empfehlungen definieren
  • Definition of Done erreichen

Ergebnis: Abgestimmte Roadmap, Governance-Framework

Definition of Done

Wann ist das Audit abgeschlossen?

  • Alle Deliverables liegen vor
  • Risiken sind priorisiert (Severity × Impact)
  • Roadmap ist mit Stakeholdern abgestimmt
  • Team kann eigenständig weiterarbeiten
  • Artefakte sind wartbar (nicht nur PDF, sondern als Code/Text)

Für wen?

Architektur-Audits sind sinnvoll für:

  • CTOs, Geschäftsführer, Produktverantwortliche
  • Unternehmen mit Legacy-Systemen (5+ Jahre alt)
  • Vor großen Modernisierungen (Risiken transparent machen)
  • Vor Audits/Due Diligence (Investoren, Compliance)
  • Bei unklaren Architektur-Entscheidungen (Bauchgefühl → Fakten)

Typische Situationen:

  • "Unsere Software ist kritisch, aber niemand traut sich ran"
  • "Audit steht an, aber Architektur ist nicht dokumentiert"
  • "Cloud-Kosten steigen, aber wir wissen nicht warum"
  • "Jedes Team baut anders, Integration wird zum Albtraum"

Umsetzungsbegleitung (optional)

Nach dem Audit können Sie wählen:

Retainer (Governance)

Ich begleite Ihr Team bei der Umsetzung: Reviews, Milestone-Steuerung, ADR-Updates

Hands-on (Entwicklung)

Ich unterstütze bei der Entwicklung kritischer Pfade, Referenzimplementierungen

Sparring Partner

Regelmäßige Abstimmungen, technische Entscheidungen auf Augenhöhe

Meine Rolle ist flexibel – von reiner Beratung bis hands-on Unterstützung.

Häufige Fragen

Abhängig von Systemkomplexität. Typisch: 2–4 Wochen. Aufwand und Konditionen klaeren wir im Erstgespraech - kostenfrei (30 Min.).

Ja, zumindest Read-Only. Ohne Code-Zugriff ist die Analyse oberflächlich und wenig aussagekräftig.

Interviews sind wichtig, um Entscheidungen zu verstehen. Minimum: 2–3 Stunden über 2 Wochen verteilt. Ohne Interviews fehlen Kontext und Historie – das Risk Register bleibt unvollständig.

Ja, das meiste ist remote möglich. Vor-Ort-Termine sind nach Absprache möglich.

Sie gehören Ihnen. Ich empfehle:
  • C4 als Code (Structurizr, PlantUML) – wartbar, versionierbar
  • ADRs im Repo (Markdown) – nah am Code, immer aktuell
  • Risk Register in Jira/Confluence – priorisiert, verfolgt

Bereit für Transparenz?

Lassen Sie uns in einem ersten Gespräch klären, ob ein Architektur-Audit
für Sie sinnvoll ist. Unverbindlich, 30 Minuten, kostenfrei.

Erstberatung vereinbaren (30 Min., kostenfrei)