Decision Rights Clarification

Systemproblem

In flachen, "agilen" Hierarchien regiert oft die Illusion des perfekten Konsenses: 15 Entwickler sitzen zwei Stunden in einem Call und diskutieren, ob man React oder Vue.js für das neue Projekt wählt. Keiner will autoritär wirken. Keiner entscheidet. Am Ende trifft das Team eine pseudo-demokratische Entscheidung ("Wir nehmen beide Frameworks und machen Micro-Frontends!"), die architektonisch katastrophal ist. Wenn unklar ist, wem eine Entscheidung gehört (Ownership), übernimmt der Sumpf der Verantwortungslosigkeit (Bystander Effect).

Intervention

"Decision Rights Clarification" räumt mit dem Demokratie-Irrtum in der Softwarearchitektur auf. Nicht jede Code-Basis darf vom Praktikanten überstimmt werden. Diese Intervention etabliert (z.B. per RACI Matrix oder klare Governance-Dokus) für jede strategische Tech-Entscheidung exakt *einen* Owner (Accountable). Es wird klargestellt: Wer darf "Code Ownership" einfordern? Wer kann vom Architektur-Board überstimmt werden (Veto)? Wer wird zum Status des bloßen "Consulted" (darf mitreden, darf aber nicht blockieren) degradiert?

Erwartete Wirkung

Entscheidungsstaus (Delays), die Projekte um Monate verzögern, lösen sich über Nacht auf. Das berühmte "Darüber müssen wir beim nächsten Mal noch einmal sprechen" verschwindet aus den Meeting-Kalendern. Entwickler empfinden wieder psychologische Sicherheit, weil die Regeln des Spiels transparent sind. Konflikte (Frontend Lead VS Backend Lead) werden nicht mehr wochenlang im Code über API-Workarounds ausgefochten, sondern in 10 Minuten durch die Eskalation an die Person mit dem finalen "Decision Right" (Entscheidungsrecht) sauber beendet.

Nebenwirkungen und Risiken

Wenn "Decision Rights" zu autoritär auf ein zentrales Elfenbeinturm-Architektur-Board konzentriert werden, tötet man die Autonomie der Dev-Teams. Die Reaktion ist "Shadow IT" – Teams entwickeln im Geheimen an der Architektur vorbei, weil das Warten auf Erlaubnis von oben (Bottleneck) zu schmerzhaft ist. Der Schlüssel liegt in der dezentralen Klärung: Man gibt dem Team *vollumfänglich* das Decision Right für das lokale Modul, sichert aber über C4-Diagramme ab, dass das Team nicht *global* den AWS-Account der Nachbarn verändern kann.

Diagramm

Wann diese Intervention wirksam wird

Gregor Hohpe (The Architect Elevator) lehrt: Ein Architekt ist kein Herrscher über Tools, er ist ein *Decision Engineer*. Eine sehr effiziente Praxis zur Ausübung von Entscheidungsrechten sind *Architecture Decision Records (ADRs)*. Der ADR dokumentiert nicht nur *was* entschieden wurde (Wir nutzen Kafka), sondern *wer* es entschieden hat, und *warum* im damaligen Kontext. Dies schützt den Entscheider davor, zwei Jahre später von einer neuen Generation von Managern unrechtmäßig geblamed zu werden.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

*Stakeholder Mapping* ermittelt vorab diagnostisch, wer Macht und Interesse in der Firma hat. *Decision Rights Clarification* formt aus dieser Diagnose einen harten, vertraglichen Prozess, der Leuten offizielle Macht zuweist (oder entzieht).

Wie du die Intervention sauber einleitest

Zerstöre in Management-Vorlagen das Wort "Wir". "Wir haben entschieden..." ist das gefährlichste Wort in der IT. Wer ist Wir? Zwinge den Meeting-Moderator bei jedem Architektur-Piviot zur Frage: "Namen auf den Tisch. Wenn diese Migration in 12 Monaten eine Million Euro und unser Datenbank-Setup vernichtet, wer von uns hier im Raum hält den Kopf hin und wird dafür gefeuert?" Die Person, die sich meldet, hat das Decision Right. Alle anderen sind nur beratend.

Erste Umsetzungsschritte

Verwende etablierte Tools wie die *RACI Matrix* (Responsible, Accountable, Consulted, Informed), aber adaptiere sie für Software. "Responsible" ist der Coder in der IDE. "Accountable" ist der Tech-Lead, der den Pull-Request merged. Wenn du Stakeholder nach dem RACI-Modell in die Rolle "Informed" (Nur informieren) drängst, befreist du die Architektur von toxischen Veto-Holdern, die eigentlich gar nichts mit dem Code zu tun haben.

Woran du Wirkung erkennst

Haben wir für unsere 3 absolut kritischsten Kern-Infrastruktur-Zonen klare, namentlich benannte "Code Owner" im Git-Repository definiert, die als einzige "Approve" drücken dürfen, und gilt diese Rechtenzuweisung ausnahmslos auch für spontane C-Level Forderungen?

Quellen

Gregor Hohpe — The Software Architect Elevator, Kap. 12: Decision Making (O'Reilly, 2020)

Wikipedia: RACI Matrix

Michael Nygard — Documenting Architecture Decisions (Blog, 2011)