Framework – Überblick

Das Architecture Responsibility Framework (ARF) beschreibt nicht, wie Systeme gebaut werden.
Es beschreibt, wann Architektur gilt.

ARF setzt dort an, wo viele Architekturansätze bewusst aufhören:
bei Verantwortung, Verbindlichkeit und akzeptierten Zuständen.

Worum es im Kern geht

In vielen Organisationen existieren:

– saubere Architekturdiagramme – dokumentierte Entscheidungen – abgestimmte Zielbilder

 

Und dennoch:

werden Entscheidungen relativiert, verlieren Zustände ihre Gültigkeit

bleibt unklar, wer wofür einsteht  – ARF adressiert genau diesen Bruch.

Die zentrale Frage von ARF

Wann ist eine Architekturentscheidung verbindlich – und für wen?

Nicht:

  • wann sie dokumentiert ist

  • wann sie beschlossen wurde

  • wann alle zugestimmt haben

Sondern:

  • wann sie gilt

  • wann sie getragen wird

  • wann sie durchsetzbar ist

Architektur als akzeptierter Zustand

ARF definiert Architektur nicht als Entwurf, sondern als akzeptierten Zustand.

Ein Zustand gilt nur dann als Architektur, wenn:                                  

– er explizit entschieden wurde – er einen klaren Geltungsbereich hat – er einen verantwortlichen Eigentümer besitzt – er als Maßstab für Abweichungen dient

Ohne akzeptierten Zustand gibt es:   

– keine Verbindlichkeit – keine Governance  – keine belastbare Verantwortung

 

Entscheidung ≠ Meinung

Ein zentrales Prinzip von ARF:

Eine Entscheidung ohne Durchsetzung ist keine Entscheidung, sondern eine Meinung.

ARF trennt klar zwischen:

  • Diskussion

  • Absicht

  • Entscheidung

  • gültigem Zustand

Diese Trennung ist bewusst unbequem – aber notwendig.

Verantwortung ist nicht delegierbar

ARF macht Verantwortung explizit sichtbar.

Für jede relevante Architekturentscheidung muss klar sein:

  • wer entscheidet

  • wer trägt die Konsequenzen

  • wer Abweichungen genehmigt

  • wer eingreifen muss, wenn der Zustand verletzt wird

Ohne diese Klarheit entsteht Schein-Governance.

Der schlechteste Fall als Maßstab

ARF bewertet Architektur nicht am Best Case, sondern am schlechtesten tragfähigen Fall.

Fragen, die ARF erzwingt:

  • Was passiert, wenn es schiefgeht?

  • Wer entscheidet dann?

  • Wer haftet fachlich?

  • Wer darf eingreifen?

Wenn diese Fragen nicht beantwortbar sind, ist die Architektur nicht tragfähig.

Governance als Rahmen, nicht als Prozess

ARF versteht Governance nicht als:

  • Gremium

  • Freigabekaskade

  • Prozessmodell

Sondern als klaren Rahmen, der sagt:

  • wann etwas gilt

  • wann es überprüft wird

  • wann es nicht mehr gilt

Governance dient der Stabilität, nicht der Bürokratie.

Übertragbarkeit als Qualitätstest

      Eine Architektur ist nur dann gut, wenn sie:

  •    erklärbar

  •     nachvollziehbar

  •     übertragbar

     ist.

     ARF nutzt Übertragbarkeit als härtesten Qualitätstest:

Wenn ein Zustand nicht auf eine andere Organisation, ein anderes Team oder einen anderen Kontext übertragbar ist, war er zufällig – nicht architektonisch.

Was ARF bewusst nicht liefert

ARF ist kein:

  • Methodenhandbuch

  • Toolset

  • Prozessframework

  • Ersatz für TOGAF, SAFe, Scrum oder ITIL

ARF ergänzt bestehende Ansätze dort, wo sie Verantwortung offenlassen.

Wie es weitergeht

Die folgenden Seiten konkretisieren das Framework:

  • Grundlagen – Begriffe, Abgrenzungen, Denkrahmen

  • Prinzipien – die unverhandelbaren Leitlinien von ARF

  • Entscheidungen – Aufbau, Gültigkeit und Lebenszyklus

  • Governance – wann Kontrolle notwendig ist

  • Lifecycle – Entstehen, Geltung, Revision, Auflösung

Kurz gesagt

ARF beantwortet nicht die Frage:

Wie bauen wir Systeme?

Sondern:

Wann tragen sie – und wer steht dafür ein?