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 gravierend 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 aufwendig 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 klaren, vertraglichen Prozess, der Leuten offizielle Macht zuweist (oder entzieht).

Wie du die Intervention sauber einleitest

Streiche in Management-Vorlagen unklare Formulierungen wie "wir haben entschieden". Wer ist in diesem Fall "wir"? Der Meeting-Moderator sollte bei wichtigen Architekturentscheidungen nach einer konkreten verantwortlichen Person fragen: Wer trägt die Entscheidung, wenn diese Migration in 12 Monaten hohe Kosten verursacht oder das Datenbank-Setup beschädigt? Die Person, die diese Verantwortung übernimmt, hat das Decision Right. Alle anderen sind 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 schädlichen Veto-Holdern, die eigentlich gar nichts mit dem Code zu tun haben.

Woran du Wirkung erkennst

Haben wir für unsere 3 sehr 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)