WAF++ WAF++
Back to WAF++ Homepage

Best Practice: Architektonische Kostenschuld managen

Kontext

Architektonische Kostenschuld entsteht still. Jede Architekturentscheidung, die ohne vollständiges Cost-Impact-Assessment getroffen wird, ist ein potenzieller Kostenschuld-Eintrag. HA-Designs ohne SLO-Grundlage, proprietäre Services ohne Exit-Plan, Retention-Defaults ohne Lifecycle-Strategie – sie alle akkumulieren monatlich Kosten, deren Ursprung nicht mehr zur ursprünglichen Entscheidung rückverfolgbar ist.

Diese Best Practice zeigt, wie Kostenschuld systematisch verhindert, erkannt und abgebaut wird.

Zugehörige Controls

  • WAF-COST-050 – Cost Impact Assessment in Architecture Decision Records

  • WAF-COST-100 – Architectural Cost Debt Register & Quarterly Review

Zielbild

  • Alle Architekturentscheidungen mit Infrastruktur-Impact haben ein vollständiges Cost-Impact-Assessment

  • Bekannte Kostenschulden sind im Cost-Debt-Register mit Owner und Status erfasst

  • Quartalsweiser Architecture-Board-Review stellt sicher, dass keine Schuld unbemerkt bleibt

  • Bewusste Akzeptanz von Kostenschuld ist möglich – aber dokumentiert

ADR-Template mit Cost-Impact-Sektion

Vollständiges ADR-Template

# ADR-XXXX: [Titel der Entscheidung]

**Status:** [Proposed | Accepted | Superseded | Deprecated]
**Datum:** YYYY-MM-DD
**Entscheider:** [Team / Architecture Board]

## Kontext

[Beschreibung des Problems und des Entscheidungskontexts]

## Optionen

### Option A: [Name]
[Beschreibung]

### Option B: [Name]
[Beschreibung]

## Entscheidung

[Gewählte Option und Begründung]

## Konsequenzen

[Positive und negative Folgen der Entscheidung]

---

## Cost Impact Assessment (WAF-COST-050)

> Pflichtsektion für alle ADRs mit Infrastruktur-Impact.

| Dimension                | Bewertung                                        |
|--------------------------|--------------------------------------------------|
| **Geschätzte TCO/Jahr**  | XX.XXX EUR                                       |
| **Lock-in-Risiko**       | X/5 – [Begründung]                              |
| **Datentransfer-Kosten** | ~XXX EUR/Monat (Schätzung Egress-Anteil)         |
| **Betriebsaufwand**      | X.X FTE/Jahr (Ops + Engineering)                 |
| **Exit-Kosten (est.)**   | ~XX.XXX EUR Migrationsaufwand                    |
| **3-Jahres-NPV**         | -XX.XXX EUR (Infrastruktur, ohne Business-Value) |

**Lock-in-Score Erklärung:**
- 1: Standard-APIs, Open Format, einfacher Anbieterwechsel
- 2: Geringe Proprietarität, Alternativen verfügbar
- 3: Mittlerer Lock-in, Migration möglich mit überschaubarem Aufwand
- 4: Hoher Lock-in, Migration teuer (erfordert AB-Genehmigung)
- 5: Extremer Lock-in, Migration sehr teuer oder praktisch unmöglich

**Kostenschuld-Risiko:** [Gering / Mittel / Hoch]

**Begründung:**
[Warum ist diese Option trotz des Kostenschuld-Risikos die richtige Wahl?]

**Cost-Debt-Register:**
[Eintrag CD-YYYY-XXX angelegt / Kein Eintrag erforderlich weil: ...]

**Nächster Review:** [Datum des nächsten Cost-Debt-Reviews]

Beispiel: Ausgefülltes Cost-Impact-Assessment

## Cost Impact Assessment (WAF-COST-050)

| Dimension                | Bewertung                                        |
|--------------------------|--------------------------------------------------|
| **Geschätzte TCO/Jahr**  | 48.000 EUR                                       |
| **Lock-in-Risiko**       | 4/5 – Proprietäres Datenformat, hoher Migrations- |
|                          | aufwand zu alternativen Streaming-Services       |
| **Datentransfer-Kosten** | ~400 EUR/Monat (Kinesis→S3 Egress-Schätzung)     |
| **Betriebsaufwand**      | 0.3 FTE/Jahr (Monitoring, Shard-Management)      |
| **Exit-Kosten (est.)**   | ~80.000 EUR (Consumer-Migration zu Kafka/etc.)   |
| **3-Jahres-NPV**         | -224.000 EUR                                     |

**Kostenschuld-Risiko:** Hoch

**Begründung:**
Kinesis ist die am besten integrierte AWS-native Streaming-Lösung für unseren
bestehenden AWS-Stack. Der Lock-in ist bewusst akzeptiert, weil:
- Kein Multi-Cloud-Requirement in den nächsten 3 Jahren (Architecture Decision AD-2023-11)
- Operationsaufwand von Kafka-Self-Hosting würde ~0.8 FTE mehr kosten
- Exit-Plan dokumentiert: Konsumenten können auf Apache Kafka on MSK migriert werden

**Cost-Debt-Register:** Eintrag CD-2025-007 angelegt.
**Nächster Review:** Q3 2025 (Architecture Board)

Cost-Debt-Register aufsetzen

Dateistruktur

repository/
├── docs/
│   ├── cost-debt-register.yml    # Haupt-Register
│   └── adr/
│       └── ADR-0042-*.md
└── infrastructure/
    └── ...

Register-Format

# docs/cost-debt-register.yml
version: "1.0"
last_reviewed: "2025-03-01"
reviewed_by: "Architecture Board"
next_review: "2025-06-01"

entries:
  - id: CD-2025-001
    title: "Multi-AZ PostgreSQL ohne SLO-Grundlage"
    category: "ha-over-engineering"
    description: >
      Produktionsdatenbank in 3 AZs deployed. Aktueller SLO des Services ist 99.5%,
      der auch mit Single-AZ (AWS-Garantie 99.95% für einzelne AZ) erfüllt wäre.
      Keine dokumentierte Business-Anforderung für Multi-AZ.
    detected: "2025-01-15"
    owner: "platform-team"
    estimated_annual_impact_eur: 22000
    status: "paydown"
    paydown_plan: >
      SLO-Review mit Product Owner bis 2025-04-15.
      Wenn SLO <= 99.5%: Downgrade auf Single-AZ, Multi-AZ nur für DR-Tests.
      Erwartete Einsparung: ~1.833 EUR/Monat.
    target_resolution: "2025-06-30"
    related_adr: "docs/adr/ADR-0038-database-ha.md"
    related_controls: [WAF-COST-050, WAF-COST-100]

  - id: CD-2025-002
    title: "CloudWatch Logs ohne Retention – 3 Produktions-Log-Groups"
    category: "infinite-retention"
    description: >
      Drei CloudWatch Log Groups aus 2022 haben retention_in_days = 0 (unbegrenzt).
      Kumuliertes Log-Volumen: ~800 GB. Wächst mit ~15 GB/Monat.
    detected: "2025-02-01"
    owner: "infrastructure-team"
    estimated_annual_impact_eur: 1200
    status: "paydown"
    paydown_plan: >
      Terraform-Konfiguration mit retention_in_days = 90 für alle drei Log Groups.
      PR geplant für Sprint 2025-03-1.
    target_resolution: "2025-03-15"
    related_controls: [WAF-COST-040, WAF-COST-070]

  - id: CD-2025-003
    title: "AWS Kinesis Data Streams – Lock-in ohne Exit-Plan"
    category: "lock-in"
    description: >
      Kinesis-basiertes Event-Streaming mit hohem Lock-in (Score 4/5).
      Exit-Plan bisher nicht dokumentiert.
    detected: "2025-03-01"
    owner: "data-team"
    estimated_annual_impact_eur: 48000
    status: "monitoring"
    paydown_plan: "Nicht geplant für 2025. Exit-Plan bis Q2 2025 dokumentieren."
    acceptance_rationale: >
      Bewusst akzeptiert: Kinesis ist optimal für AWS-nativen Stack. Operationsersparnis
      gegenüber selbst-betriebenem Kafka überwiegt Lock-in-Risiko.
      Voraussetzung: Exit-Plan-Dokument bis Q2 2025.
    target_resolution: "2025-06-30"
    related_adr: "docs/adr/ADR-0042-streaming-platform.md"
    related_controls: [WAF-COST-050]

Quarterly Cost-Debt-Review-Prozess

Vorbereitung (1 Woche vor Review)

  1. FinOps-Team erstellt vorbereitenden Report:

    • Neue Kostenschuld-Kandidaten aus dem letzten Quartal

    • Paydown-Fortschritt bestehender Einträge

    • Kosten-Anomalien der letzten 90 Tage

    • ADRs des Quartals mit Lock-in-Score >= 3

  2. Owners jedes Cost-Debt-Eintrags aktualisieren ihren Status vorab

Review-Agenda (60–90 Minuten)

  1. Quartalsbericht (10 Min): Gesamtkosten-Trend, größte Veränderungen

  2. Neue Einträge (20 Min): Für jede Neuaufnahme: Bestätigung Owner, Impact-Bewertung, Status-Entscheidung

  3. Bestandseinträge (20 Min): Paydown-Fortschritt, geänderte Einschätzungen, Status-Updates

  4. Acceptance-Entscheidungen (15 Min): Bewusste Akzeptanz mit dokumentierter Begründung

  5. Priorisierung (15 Min): Top-3 Paydown-Maßnahmen für nächstes Quartal

Review-Protokoll

# docs/cost-debt-reviews/2025-Q1-review.yml
quarter: "2025-Q1"
date: "2025-03-01"
attendees:
  - "CTO (Architecture Board Chair)"
  - "Principal Engineer Platform"
  - "FinOps Lead"
  - "Team Leads: platform, data, infrastructure"

new_entries:
  - id: CD-2025-003
    decision: "Accepted – Exit-Plan bis Q2 2025 erforderlich"

paydown_updates:
  - id: CD-2025-001
    progress: "SLO-Review geplant für April. Kein Paydown in Q1."
  - id: CD-2025-002
    progress: "ABGESCHLOSSEN. PR gemergt 2025-03-10. Einsparung: 100 EUR/Monat bestätigt."

strategic_decisions:
  - "Kein neues Kinesis-Deployment ohne AB-Genehmigung (Lock-in-Score 4)"
  - "Alle neuen ADRs mit Infrastruktur-Impact: Cost-Impact-Assessment Pflicht ab sofort"

next_review: "2025-06-01"
sign_off: "Architecture Board"

Typische Fehlmuster

  • Register als PDF: Versionskontrolle und ADR-Verlinkung unmöglich

  • Keine Owner-Zuweisung: Einträge ohne Owner werden nicht abgebaut

  • Acceptance ohne Begründung: „Accepted" ohne dokumentierten Grund ist Dokumentationsverschwendung

  • Review nur als Bestandsaufnahme: Review muss Entscheidungen produzieren, nicht nur Status berichten

Metriken

  • Vollständigkeit des Registers: Alle bekannten Kostenschulden erfasst (100%)

  • Paydown-Rate: Anteil der Einträge mit aktivem Paydown-Plan (Ziel: >= 50%)

  • Acceptance-Quote: Anteil bewusst akzeptierter Schulden (Richtwert: < 30%)

  • Durchschnittlicher Impact/Eintrag: Gesamt-Impact ÷ Anzahl Einträge (KPI für Priorisierung)