Scenario Planning for Enterprise Architects

From Futures to Capabilities to Roadmaps

Many enterprise architects first meet “the future” as a date on a slide: “2027 Target Architecture.”

That “future-state architecture” usually means someone higher up took a single strategy narrative, treated it as a prediction, and asked you, as an enterprise architect, to design everything around it and translate it into execution. When that future doesn’t materialise, your carefully crafted roadmap becomes an artefact of a world that never happened.

You’ve probably seen it at work: a new leadership team, bold digital ambitions, a new AI strategy, maybe a consulting deck full of market forecasts and whatever the trendy buzzwords are that quarter. The organisation picks one path – cloud‑only, platform business, Agentic‑AI‑only play – and the architecture team is told to “make it real.” Three years later, regulation shifts, macro conditions change, the strategy pivots, and now your architecture is optimised for a future the company no longer believes in.

Strategic foresight, as a practice, exists because this pattern keeps repeating — and it starts from a simple premise: in complex environments, you cannot reliably predict a single “right” future, no matter how much data you collect. What you can do is explore several plausible futures, see how each one stresses your organisation differently, and design capabilities and options that keep you effective across that range.

This is where scenario planning should matter to architects. Not as a storytelling exercise bolted onto strategy, but as a disciplined way to move from “multiple futures” to “capabilities” and then to actionable roadmaps.

Before we get into how enterprise architects can apply scenarios in practice, we need to clear up some persistent confusion about what foresight and scenarios are – and what they are not. That confusion is a big part of why many architects dismiss foresight as vague or fluffy, even though the underlying methods are anything but.

Common Foresight Misconceptions

Foresight vs prediction

In many organisations, “thinking about the future” defaults to prediction: a single number, a single curve, a single story extended into the future. It looks precise, but decades of work on scenarios and judgment under uncertainty argue that overconfidence in single‑point predictions is a major reason strategies and big programmes fail when conditions change [1].

Strategic foresight takes a different stance. Practitioners assume uncertainty is structural rather than a temporary data problem [2]. The goal is not to be “right once,” but to improve decisions across a range of plausible futures [1, 2]. That means deliberately broadening the space of possibilities and then designing responses that are resilient or adaptable, rather than optimised for a single forecast. For architects, the key shift is from “what will 2027 look like?” to “what must we be able to do across several versions of 2027?”

Foresight vs forecasting

Forecasting still matters. You need demand curves, adoption rates, cost trajectories and budget projections. Forecasting and foresight are complementary, not interchangeable. Forecasting narrows uncertainty around a baseline; foresight keeps multiple structurally different futures on the table, including ones that would break your existing models [2].

When forecasting dominates, organisations tend to lock architectures around the most “probable” scenario and under‑invest in adaptability. When foresight is present, forecasts remain, but you also use scenarios to expose blind spots, test strategies, and surface capabilities you’d need if the world takes a different turn. For an enterprise architect, that is the difference between drawing a single rigid target state and designing a capability‑led roadmap that can flex as drivers of change and signals emerge.

“Scenarios are soft, architecture is hard”

Another misconception is that scenarios are soft, qualitative fluff, while enterprise architecture is hard, quantitative, and closer to engineering in its rigour. In reality, much of EA is already driven by qualitative assumptions: which markets matter, how regulators might act, which partnerships will hold, which technologies will mature. Scenarios don’t introduce fuzziness; they make those underlying assumptions explicit and testable instead of letting them lurk, unexamined, behind “hard” diagrams and models.

A long line of research and practitioner experience with scenario practice argues that the real risk is letting implicit future assumptions drive large, irreversible commitments [1, 2]. For enterprise architects, scenarios are a way to surface and confront those assumptions early before they are baked into platforms, integrations, and operating models.

“Scenarios are a one-off workshop”

Many people also believe scenarios are something you do once at an offsite, producing some colourful narratives that never touch day‑to‑day decisions. Corporate foresight research and public‑sector guidance stress the opposite: scenarios are most valuable when they are revisited, updated, and connected to regular decision cycles [2].

For EA, that means tying scenarios to existing rhythms: annual strategy and portfolio cycles, roadmap refreshes, and major principle or standard reviews. Instead of a one‑time exercise, they become a standing input into how you shape your capability map and architecture over time. That is the foundation we’ll build on when we move from scenarios to capabilities, but first, let’s define scenarios.

What Scenarios and Scenario Planning Actually Are

When people say “scenario”, they often mean “plan B” or “a worse forecast”. That’s not how the field of futures and foresight uses the term. In strategic foresight, scenarios are structured “what‑if” stories about how the future might unfold, each built from different combinations of drivers and uncertainties. They are not strategies or predictions; they are alternative environments in which your strategies and designs must survive.

A standard definition from the literature describes scenarios as several informed, plausible, and imagined alternative future environments in which decisions may be played out [3, 4]. The emphasis is on plausible and alternative: plausible, so they are grounded in real drivers of change; alternative, so they stretch beyond a single extrapolated trend line. For enterprise architects, you can think of scenarios as different “operating contexts” for your organisation: different patterns of regulation, competition, technology, behaviour and shocks that will shape what your architecture needs to enable.

Scenario planning is the method for building and using those scenarios in a disciplined way [3]. The classic intuitive‑logics process, made famous by Shell’s planners in the 1970s, can be applied lightly or deeply depending on how much driver analysis you invest in — the full method runs to eight stages [1]; this article condenses it to three:

1. Define the focal issue and time horizon: e.g. “How does our business model and architecture need to evolve by 2030?”

2. Identify key drivers and critical uncertainties: scan political, economic, social, technological, legal and environmental forces; then separate relatively predetermined trends from genuinely uncertain, high‑impact factors.

3. Develop scenario frameworks and narratives: combine critical uncertainties into 2–4 distinct futures and write coherent, memorable stories that bring each to life.

Well‑run scenario work doesn’t stop at stories. The method is explicitly intended to support strategy and decision‑making under uncertainty, including testing strategies against different futures and identifying resilient options [1, 2]. That’s the bridge we’re going to walk across into architecture.

Scenarios as a Foresight Method (and Why Enterprise Architects Should Care)

Scenarios are one of the core methods in strategic foresight because they do three things traditional planning struggles with. First, they help organisations handle deep uncertainty by rehearsing multiple structurally different futures rather than betting everything on a single forecast. Second, they surface hidden assumptions: when you write parallel stories and ask “what would we actually do here?”, you discover what you’ve been taking for granted about markets, technology and institutions. Third, they widen the option set by forcing teams to explore responses they would never consider if they only planned around a baseline [1, 2].

Practitioner case work — most notably at Shell and in public sector foresight programmes — suggests that scenario‑informed organisations tend to make more robust decisions [2], but systematic empirical research on these effects remains limited [1]. The point of scenario planning, put plainly, is to build an organisation that can adapt when the future is unknown, which is about as clear a mandate as enterprise architects can get.

For enterprise architects, scenarios start to matter when they change what you build and in what order. The real value is not the narratives themselves, but the way they change your view of which capabilities you need, how those capabilities might differ across futures, and how you structure your roadmaps and platforms so you have options rather than one brittle line to a single “2027 Target Architecture.”

EA “Scenarios” vs Foresight Scenarios

If you’ve worked with TOGAF, you already know one use of the word “scenario”. TOGAF business scenarios are complete descriptions of a business problem, both in business and architectural terms, that enable individual requirements to be viewed in relation to one another in the context of the overall problem [5]. They are close to projects and programmes: one situation, one set of actors, one set of performance targets, leading to one set of requirements — and from those, a justified architecture response. Even when the scope extends beyond IT, the horizon remains fixed on a specific, bounded problem . This is a useful requirements technique, but it has almost nothing in common with how the foresight field uses the term “scenario”

TOGAF is not alone in this. BIZBOK uses scenarios to provide situational context for applying business architecture to specific business needs and for analysing capability gaps within a known strategic direction. ITABoK and SAFe both plan from a stated strategic direction rather than across alternative ones. Defence frameworks such as DoDAF and NAF go further in formalising scenario‑based descriptions: their operational viewpoints use explicit, deterministic execution scenarios — actors, activities, states and exchanges — as a primary mechanism for deriving and verifying capability and system behaviour. These are, therefore, highly specific operational use‑cases inside a fixed concept of operations, not scenarios in the foresight sense of multiple plausible futures.

Scenarios in the foresight context sit at a different level entirely. Instead of describing one problem in one expected environment, they describe several informed, plausible and imagined alternative future environments in which decisions may be played out. They reach further in time, combine multiple drivers and uncertainties, and are not tied to a single initiative. Where a TOGAF business scenario says “here is how our claims process should work in the next release”, a foresight scenario says “here are four very different worlds for insurance over the next decade — now let’s see what that does to our business model and capabilities.” That is the layer that no mainstream EA framework covers on its own — and the layer this article is concerned with.

How Foresight Scenarios Are Built

Foresight doesn’t just deal in different stories about the future; it also distinguishes different ways of constructing those stories. The distinction that actually matters for enterprise architects is the split between explorative and normative scenarios [4].

Explorative scenarios focus on the external environment and examine past and present trends that shape likely futures. Because they are treated as independent of your organisation’s specific values or desires, they assume the environment changes first, and that your organisation responds. Your architecture needs to be able to cope with a range of futures you don’t control. Note: Classic scenario planners (like those from the Shell school) heavily favour this approach, arguing that external scenarios should remain value-neutral testbeds to stretch executives’ mental models and avoid bias.

Normative scenarios, on the other hand, put the organisation’s choices and values at the centre. They are constructed from alternative images of the future that may be highly desired (or feared) and are conceived in a retro-projective—or backcasting—way. Their purpose is not just to brace for the future but to help create it, which is where most transformational ambition sits [4].

For EA, explorative scenarios help you understand the range of external conditions your architecture needs to cope with; normative scenarios help anchor the capabilities you deliberately want to build to achieve a desired end-state, even when the environment is messy.

Method‑wise, explorative scenarios pair naturally with testing and resilience work; normative scenarios pair with design and backcasting. Explorative scenarios are the obvious input to wind‑tunnelling: you treat each one as an external test environment and ask how resilient your current strategies and big architecture bets are if the world moves that way. Normative scenarios are the obvious input to backcasting: you start from a deliberately chosen future state and work backwards to the capabilities, architectures and decisions you’d need to help create it. In practice, wind‑tunnelling is most naturally introduced through explorative scenarios, but you can apply the same underlying logic to normative ones too; the question simply shifts from “Does this survive?” to “Does this move us towards the future we say we want to create?”

The intuitive‑logics process is primarily explorative — it first builds scenarios of the external environment, then uses them to stress-test and develop a strategy. If you are working in a more normative mode — designing the future you want to create — you will supplement the intuitive-logics steps with backcasting and vision-led techniques rather than relying on them alone. Whichever mode you are working in, you still need to decide how to structure the scenario content itself – and two approaches are worth knowing:

1. A 4‑archetypes method – Dator’s four archetypes (continued growth, collapse, disciplined society, and transformation) map onto capability patterns as follows: continued growth tends to map to scaling and optimisation; collapse to resilience and recovery; disciplined society to compliance and cost‑control; and transformation to innovation [6]. This helps you avoid four “growth” stories in different outfits.

2. The familiar 2×2 matrix – two critical uncertainties on the axes, four quadrants as scenarios [1, 2]. It is simple and widely used, but often overused; on its own, it doesn’t guarantee variety unless you choose genuinely different uncertainties.

You don’t need to be a connoisseur of scenario methods to get value as an enterprise architect. In practice, it is rarely either/or — most organisations need both. The useful question is: where does your organisation sit on the control spectrum? If you have limited influence over your environment, lean toward explorative; build scenarios of external futures and use them to stress-test your architecture bets. If you have significant market or regulatory influence, lean toward the normative; design the future you intend to help create, and backcast from it. Most foresight-informed enterprise architects will do some of each, which is exactly why the distinction matters: it tells you which mode you are in at any given point, and therefore which techniques to reach for.

Testing Strategies with Scenarios

Once you have built a small set of scenarios — whether explorative, normative, or both — the next useful move is simple: take what you’re already planning to do and ask, “How does this hold up in each of these scenarios?” That is what wind‑tunnelling does. It treats each scenario as a test environment and runs your strategies and architectural bets through it, the way a physical wind tunnel tests a design’s behaviour under different conditions [2].

In “prepare” mode, you usually start with explorative scenarios. You line up your big bets – “single‑vendor ERP”, “API‑first modular core”, “data mesh”, “agentic‑AI‑first customer service”, major sourcing or platform choices – and, for each scenario, you ask three blunt questions:

1. Does this still make sense here at all?

2. If yes, what extra risks, costs or constraints show up in this future?

3. What additional capabilities would we need to make this viable rather than fragile?

You can do this with nothing more than a matrix: scenarios on one axis, strategies and architecture themes on the other, and a short qualitative judgement in each cell. The goal is not a beautiful heatmap; the goal is clarity on which directions are robust or resilient across many futures, which are narrow bets that only work in a few, and where you need options instead of irreversible commitments. The wind‑tunnelling step is where scenario planning turns into scenario analysis: you systematically assess how each strategy or architecture pattern behaves across your futures, and let that evidence shape your capability and roadmap choices.

In “shape” mode, you can run the same exercise on normative scenarios as well, this time checking whether your initiatives genuinely support the future you say you want, rather than just coping with whatever happens. That’s often where you discover that some cherished initiatives are, at best, neutral to your stated long‑term intent – or that you’re missing key enabling capabilities entirely.

Testing your strategies with scenarios on their own doesn’t redesign anything; it shows you where your current strategies and architecture patterns are brittle, over‑fitted or under‑powered. The constructive next question is: In each scenario, what must we actually be able to do that we cannot do today? That’s the move from scenarios to capabilities.

From Scenarios to Capabilities

The outputs of wind‑tunnelling – the gaps, brittleness, and missing capabilities you identified – become the direct input to the capability mapping workshop. You’re not starting fresh; you’re taking the “we’d need this” notes from your wind‑tunnel matrix and turning them into a structured capability map. That’s the bridge from scenarios to capabilities, and it aligns with how scenario‑based strategic planning and capability‑driven planning are described in the literature: use scenarios to surface strategic implications, then translate them into required organisational abilities [2, 7].

You can run this as a simple, structured workshop sequence. Scenario‑based planning work often recommends dedicated “implications” or “from scenarios to action” sessions rather than stopping at narratives [2]. This is where you make that explicit for EA.

1. Start in the scenario, not in today’s org chart.

For each scenario, briefly “step into” that future with the group:

• What does a typical day look like for key customers, regulators, and partners?

• What major events or constraints are present (e.g. strict AI regulation, supply shocks, new platforms dominating your market)?

Foresight practice emphasises this kind of immersion and concreteness to avoid getting stuck in abstract slogans; people reason better about implications when the future context feels real. Keep it concise but concrete enough that people can reason about actions, not just adjectives.

2. Ask the critical question: “What must we be able to do?” — and capture it.

Still in that scenario, ask:

• “In this world, what must our organisation be able to do to remain relevant, successful, or compliant?”

• “What would we need to be able to do faster, cheaper, at scale, or with more reliability than today?”

Scenario‑based strategy work recommends translating scenarios into strategic options and requirements [1, 2, 7]. Frame those requirements as capability statements, not systems or projects: “detect emerging risks in near‑real‑time”, “reconfigure our partner ecosystem in weeks, not years”, “settle 80% of simple claims straight‑through”, “spin up and shut down new products with minimal IT involvement.”

As you capture them, group closely related items under a provisional working label — for example, “monitor regulation continuously”, “simulate impact of new rules”, and “rapidly adapt controls” might sit under “regulatory sensing and response.” Keep the labels technology‑agnostic and treat them as working drafts, not final definitions. You are not building the capability map yet; you are making the raw material scannable and ready for cross-scenario comparison.

3. Repeat across scenarios, then consolidate into stable capabilities.

Run steps 1–2 for each scenario. Only once you have the full cross-scenario picture do you finalise your capability map. Then:

• Merge identical or very similar items across scenarios into a single stable, technology‑agnostic capability label (e.g. if three scenarios each produced a variant of “regulatory sensing and response”, that becomes one capability on your map).

• Mark which scenarios each capability appears in and with what intensity (e.g. “must‑have”, “important”, “only in scenario 3”).

• Note where the maturity requirement changes: a capability might exist today but needs a very different scale, speed, or quality in certain futures.

Clustering after consolidation — rather than within each scenario — ensures your capability labels are stable and comparable across futures, as capability‑based planning guidance describes the process [5]. Scenario‑based strategic planning and scenario‑driven roadmapping both recommend identifying robust elements (common across scenarios), scenario‑specific elements, and timing/maturity differences as inputs to strategy and roadmaps [1, 2, 7]. You’re doing the same, but through the lens of capabilities.

4. Make the patterns explicit

At this point, you can step back and look for patterns:

• Which capabilities show up as “must‑have” across all scenarios? These are your resilient bets.

• Which are only critical in a subset of scenarios? These are candidates for more option‑like, staged investments.

• Which archetypes (continued growth, collapse, disciplined society, or transformation) are driving which capability clusters? This can reveal whether your portfolio is over‑weighted towards one type of future — a pattern that the four archetypes make visible in a way a standard capability map does not.

Taken together, these three questions give you a prioritised, scenario-weighted capability map — and capabilities become the shared language connecting futures, strategy, and architecture.

5. Translate into EA artefacts

Only after you have a scenario‑annotated capability map do you start mapping into more familiar EA artefacts:

• Link capabilities to business services, processes, value streams, applications and platforms.

• Identify where existing architectures already support a needed capability, and where there are gaps or bottlenecks.

• Flag capabilities that require new principles, standards or reference architectures.

Scenario‑driven roadmapping work explicitly combines environment‑oriented scenarios with company‑oriented roadmaps, using capabilities as the connecting layer [7, 8]. Enterprise and business architecture practice already treats capabilities as the key link between strategy and portfolios; here, you’re simply ensuring those capabilities are futures‑informed and foresight-driven.

If, after doing these steps, your capability map looks more or less like your “business as usual” view, something went wrong. Either the scenarios stayed too close to today, or the group never really left current constraints. A simple litmus test, consistent with scenario‑to‑strategy guidance, is this: can you point to specific capabilities and honestly say, “we only saw the need for this when we looked at that scenario”? If not, you’ve probably done an interesting storytelling exercise, not yet foresight‑driven enterprise design work.

From Capabilities to Roadmaps

By this point, you have something most architects never get: a capability map annotated by scenarios. The point is not to freeze this into a one‑off roadmap, but to use it as the core of a foresight‑driven enterprise design capability – a cycle you can run repeatedly, not a workshop you do once [2].

In that cycle, roadmapping is the sequencing and learning step. You take the scenario‑annotated capability map and decide what to move forward with now, what to hold as an option, and where to place decision points as the environment evolves [7]. The roadmap becomes a living artefact that you revisit as you refresh your scanning and scenarios, rather than a static “2027 Target Architecture” picture you defend for three years.

Start with prioritisation, not boxes and arrows. Look at your capability map and ask: which capabilities are must-haves across all scenarios (resilient bets), which are only critical in specific futures (scenario‑specific bets), and which exist today but need a major jump in maturity (speed, scale, quality) under certain scenarios. Use this to cluster capabilities into a handful of roadmap themes – for example: “data‑driven risk sensing”, “partner ecosystem integration”, “automation and straight‑through processing”, “resilience and recovery”.

Next, define increments and decision points rather than a single end‑state. For each capability theme, identify a small number of maturity steps over time, decide what the next concrete increment is, and mark explicit decision points where you can double‑down, pivot or pause depending on how the real world evolves. Robust capabilities can move earlier and harder; scenario‑specific ones might start as small, option‑like investments that you scale if the corresponding future starts to materialise [7, 8].

Only then worry about how you visualise it. Whether you use a classic time‑based swimlane, a layered EA roadmap, or something more visual is secondary. If you like radial visuals, a sun‑ray roadmap works well here: put your long‑term intent or focal issue in the centre, use rays for capability streams, and rings for horizons. The key is the logic – capabilities, increments and decision points driven by scenarios – not the specific diagram template.

In other words, the value here is not another static target architecture, but a reusable way of thinking – a foresight‑driven enterprise design capability that treats scenario planning as an ongoing method to sense change, re‑imagine your enterprise, and adjust your capability roadmap before the future forces your hand.

---

References

1. Wright, G., Bradfield, R., & Cairns, G. (2013). Does the intuitive logics method – and its recent enhancements – produce “effective” scenarios? Technological Forecasting and Social Change, 80(4), 631–642.

2. van der Heijden, K. (2005). Scenarios: The art of strategic conversation (2nd ed.). Wiley.

3. Chermack, T. J., & Lynham, S. A. (2002). Definitions and outcome variables of scenario planning. Human Resource Development Review, 1(3), 366–383.

4. Spaniol, M. J., & Rowland, N. J. (2018). Defining scenario. Futures & Foresight Science, 1(1), e3. https://doi.org/10.1002/ffo2.3

5. The Open Group. (2018). TOGAF® standard, version 9.2. The Open Group.

6. Dator, J. (2009). Alternative futures at the Manoa School. Journal of Futures Studies, 14(2), 1–8.

7. Hussain, M., Tapinos, E., & Knight, L. (2017). Scenario-driven roadmapping for technology foresight. Technological Forecasting and Social Change, 124, 160–177.

8. Cheng, M. N., Wong, J. W. K., Cheung, C. F., & Leung, K. H. (2016). A scenario-based roadmapping method for strategic planning. Technological Forecasting and Social Change, 110, 164–176.