Strategic Options Development and Analysis

Purpose

In large IT initiatives, strategy formation usually fails because executives, architects, and product managers all carry different cognitive maps in their heads. Strategic Options Development and Analysis, or SODA, created by Colin Eden and Fran Ackermann, repairs that failure. It turns the subjective and often stubborn viewpoints of individual experts into a shared networked model from which rational strategy options and trade-offs can finally be negotiated.

Context of Use

SODA rescues situations where IT leadership is stuck in analysis paralysis for months. Typical examples include questions such as whether to shut down an on-prem monolith in one big bang or strangle it over five years. Both camps hold strong opinions, throw buzzwords at each other, burn political energy, and no code gets written.

Step by Step

1.Run individual interviews: The architect interviews key players separately and asks each of them to draw a causal strategy map from goals to actions to consequences.

2.Merge the maps: The architect overlays the individual maps from the CTO, CISO, head of product, and others, then looks for tail nodes without consequences and head nodes without supporting actions.

3.Identify conflict nodes: Where does one leader claim that A necessarily leads to B while another insists that A prevents B?

4.Facilitate a group workshop: Put the merged map on the wall. The discussion shifts from opinion against opinion to node against node, and options emerge from paths through the graph instead of gut feeling.

Example

A cloud center of excellence is arguing about Kubernetes strategy. The CISO wants maximum isolation per team to maximize security. The lead developer wants maximum shared resources to maximize velocity. Their meetings go nowhere. A SODA analysis maps both positions as causal paths and uncovers a hidden agreement: both sides would benefit from a central policy engine, such as OPA, that reinforces security for one side and automation-driven speed for the other. The SODA map turns an either-or war into a shared infrastructure initiative.

Diagram

How Diagnosis Turns into Action

SODA protects development tribes from schizophrenic strategies. Without it, boards often approve compromises that demand two physically incompatible outcomes at once, such as cutting QA budget by half while insisting on zero-defect releases. Once those statements are mapped in SODA, the missing or torn causal link becomes obvious. Architects can use that map as documented evidence of strategic pain.

When This Method Fits Best

Stakeholder Mapping evaluates the political power of actors. SODA diagnoses the logical content of what they are saying. It borrows techniques that resemble Causal Loop Diagrams but applies them not to technical systems such as servers and code, but to the strategy statements of decision-makers.

How to Use the Diagnosis in Everyday Work

As an architect, dare to take the moderator role in endless debates. Walk to the whiteboard when two product owners start shouting and draw their sentences as boxes and arrows. Ask, "Peter, am I representing your cognitive map correctly when I connect node X directly to node Y?" SODA removes ego from the discussion and shifts the problem into the logic of the wall drawing.

First Analysis Steps

Use strong bipolar constructs in SODA interviews. People often speak vaguely, as in "We need more agility." Force them to name the opposite: "What exactly is the opposite of the agility you want?" The contrast reveals what the stakeholder really means. Often they do not mean Scrum. They mean, "I do not want the Ops team blocking my deployments anymore."

How You Recognize a Useful Diagnosis

Have you ever tested the core beliefs behind your largest strategic architecture roadmaps for internal consistency by explicitly plotting the statements of your C-level leaders next to each other?

Sources

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

Wikipedia: Strategic Options Development and Analysis

Wikipedia: Cognitive Map