Strategic Options Development and Analysis

Zweck

In IT-Großprojekten scheitert die Strategiefindung meistens daran, dass das C-Level, die Architekten und die Produktmanager komplett unterschiedliche "Cognitive Maps" (mentale Landkarten) im Kopf haben. "Strategic Options Development and Analysis" (SODA), entwickelt von Colin Eden und Fran Ackermann, repariert diesen Fehler. Es überführt die subjektive, oft sture Vorstellung einzelner Experten in ein gemeinsames, objektvernetztes Modell, auf dessen Basis überhaupt erst rationale Strategieoptionen (Trade-offs) verhandelt werden können.

Einsatzkontext

SODA rettet Situationen, in denen das IT-Management monatelang im "Analysis Paralysis" feststeckt. Zum Beispiel bei der Frage: "Sollen wir den On-Premise Monolithen hart abschalten (Big Bang) oder über 5 Jahre slowly strangulieren (Strangler Fig Pattern)?" Beide Seiten haben extrem starke Meinungen, werfen mit Buzzwords um sich, reiben sich politisch auf, und es wird kein Code geschrieben.

Schritt für Schritt

1.Einzel-Interviews (Kognitive Karten): Der Architekt interviewt die Schlüsselspieler einzeln (!). Er fordert sie auf, ihre Strategie als kausale Karte zu zeichnen (Ziel -> Aktion -> Konsequenz).

2.Die Verschmelzung (Merge): Der Architekt legt die 5 individuellen Karten (z.B. vom CTO, CISO, Head of Product) übereinander. Er sucht nach "Tail" Nodes (Aktionen ohne Konsequenzen) und "Head" Nodes (Ziele ohne Aktionen).

3.Konflikt-Nodes identifizieren: Wo behauptet der CISO "A führt zwingend zu B", während der CTO felsenfest behauptet "A verhindert B"?

4.Gruppen-Workshop: Die verschmolzene (oft chaotische) Gesamt-Map wird an die Wand geworfen. Jetzt wird nicht mehr "Meinung gegen Meinung", sondern "Node gegen Node" diskutiert. Optionen entstehen nicht mehr aus Bauchgefühl, sondern aus Pfaden durch den Graphen.

Beispiel

Ein "Cloud Center of Excellence" (CCoE) diskutiert die Kubernetes-Strategie. Der CISO will maximale Abschottung pro Team, um "Security" zu maximieren. Der Lead-Dev will maximale Shared-Ressources, um "Velocity" zu maximieren. Beide diskutieren sich in endlosen Meetings tot. Die SODA-Analyse mappt ihre Aussagen auf Kausal-Pfade. Sie deckt auf: Beide Akteure stimmen unbemerkt darin überein, dass eine "Zentrale Policy Engine" (z.B. OPA) ihr jeweiliges Kernziel (Security für den einen, Speed-durch-Automatisierung für den anderen) stützen würde. Die SODA-Karte dreht die Debatte von einem Entweder/Oder-Krieg auf den Bau eines gemeinsamen Infrastruktur-Knotens.

Diagramm

Wie aus Diagnose Handlung wird

SODA schützt Entwicklungs-Tribes vor sogenannten "Schizophrenen Strategien". Ohne SODA genehmigt das Board oft Kompromisse, bei denen zwei sich physikalisch ausschließende Ziele gleichzeitig gefordert werden ("Wir kürzen das QA-Budget um 50%, aber verlangen 100% Zero-Defect-Releases"). Wenn man die Aussagen des Vorstands in SODA mappt, wird der fehlende (oder durchrissene) Pfeil sofort offensichtlich. Architekten nutzen SODA als dokumentierten Schmerz-Nachweis gegenüber dem Management.

Wann diese Methode die richtige ist

*Stakeholder Mapping* bewertet die politische Zerstörungskraft von Akteuren. SODA hingegen diagnostiziert den puren logischen Gehalt ihrer Aussagen. SODA nutzt Techniken, die an *Causal Loop Diagrams (CLDs)* erinnern, wendet diese jedoch nicht auf physikalische Systeme (Server, Code) an, sondern rein auf die Strategie-Aussagen der handelnden Manager.

Wie du die Diagnose im Alltag einsetzt

Trau dich als Architekt, in endlosen Debatten die Moderationsrolle zu übernehmen. Gehe ans Whiteboard, wenn sich zwei POs anschreien, und male ihre Sätze Wort für Wort als Kästchen mit Pfeilen an die Wand. Frage: "Peter, sehe ich deine Kognitive Map richtig, dass deiner Meinung nach Knoten X direkt Knoten Y auslöst?" SODA entnimmt der Debatte das Ego und verlagert das Problem in den logischen Raum der Wandzeichnung.

Erste Analyse-Schritte

Verwende in SODA-Interviews starke "Bipolare Konstrukte". Menschen drücken sich gern schwammig aus ("Wir brauchen mehr Agilität"). Zwinge sie im Interview zum Gegenteil ("Was genau ist das absolute Gegenteil deiner geforderten Agilität?"). Erst durch diesen Kontrast wird dem Analysten klar, was der Stakeholder *wirklich* meint (Z.B.: Er meint nicht "Scrum Methodik", er meint "Das Ops-Team soll mir nicht mehr bei Deployments im Weg stehen").

Woran du eine brauchbare Diagnose erkennst

Haben wir die Kern-Glaubenssätze unserer massivsten strategischen Architektur-Roadmaps einmal formal auf Widerspruchsfreiheit geprüft, indem wir die Sätze der C-Level Executives aktiv nebeneinander geplottet haben?

Quellen

Colin Eden & Fran Ackermann — Making Strategy (SAGE, 1998)

Wikipedia: Strategic Options Development and Analysis

Wikipedia: Cognitive Map