Leitfaden – Arbeiten mit dem Architecture Responsibility Framework

AFR ist kein Methodenbaukasten und kein Diskussionsinstrument.


Dieser Leitfaden beschreibt, wie AFR gedacht ist und wie es korrekt angewendet wird.

Leitfaden

1. Wann AFR eingesetzt wird

AFR kommt immer dann zum Einsatz, wenn:

  • Architekturentscheidungen getroffen werden

  • Systeme langfristige Wirkung entfalten

  • Verantwortung nicht mehr „mitgemeint“, sondern explizit sein muss

AFR ist nicht geeignet für:

  • Ideensammlungen

  • Brainstormings

  • frühe Lösungsfindung ohne Entscheidungsreife

2. Grundregel

Ohne Entscheidung keine Verantwortung.
Ohne Verantwortung keine Architektur.

Alles andere ist Dokumentation.

5. 3. Der AFR-Ablauf (minimal und hart)

1. Entscheidung formulieren

    • eindeutig

    • überprüfbar

    • mit klarer Reichweite

2. Risiken explizit benennen

  • Worst Case ist Pflicht
  • „Wahrscheinlichkeiten“ sind irrelevant

3. Verantwortung zuweisen

  • Name, nicht Rolle
  • dauerhaft, nicht temporär

4. Akzeptierten Zustand festhalten

  • nicht optimal
  • sondern tragfähig

5. Freigabe oder Ablehnung

  • kein Schwebezustand
  • kein „wir schauen mal“

    4. Was AFR bewusst nicht tut

    AFR:

    • priorisiert keine Backlogs

    • plant keine Sprints

    • optimiert keine Prozesse

    • ersetzt kein bestehendes Framework

    AFR legt den Rahmen fest, innerhalb dessen all das verantwortbar passiert.

    5. Typische Fehlanwendungen (und warum sie scheitern)

    • „Wir nutzen AFR als Diskussionshilfe“ → falsch

    • „AFR ist zu starr“ → Ausrede

    • „Das blockiert Agilität“ → fehlende Entscheidungskultur

    • „Wir müssen flexibel bleiben“ → Verantwortungsvermeidung

    AFR ist unbequem, weil es wirkt.

    6. Erfolgskriterium

    AFR funktioniert, wenn:

    • Entscheidungen nicht mehr verschwinden

    • Verantwortung nicht mehr diffundiert

    • Architektur erklärbar bleibt – auch nach Jahren

    Wenn das nicht passiert, wird AFR nicht wirklich angewendet.