Strategy-to-architecture loops: why themes need initiatives need apps

Ask a CIO whether the organisation has an IT strategy. The answer is yes.

Ask whether the strategy is connected to the IT portfolio. The answer is usually: "We are working on it."

This is not a technical failure or a political omission. It is a structural problem. Most EA tools and strategy processes model either architecture or strategy — but not the loop between them. And the loop is precisely what determines whether a strategy translates into action or remains an aspiration document in a drawer.

This article describes the loop: themes, initiatives, and applications as three connected layers, and what happens when the connections are missing.

What is a strategy-to-architecture loop

The loop is not a new idea. It is formalised in Roger Martin and A.G. Lafley's "Playing to Win" (2013) as the strategy cascade: a winning aspiration broken down into where to play, how to win, the required capabilities, and the management systems that drive capability development.

Richard Rumelt adds a central insight in "Good Strategy / Bad Strategy" (2011): good strategy is not a list of aspirations. It is a diagnosis of the problem, a guiding principle, and a coherent set of actions. The actions are essential — not as independent initiatives, but as a system that reinforces each other.

In EA practice, this translates to three layers:

Strategic themes — the two to four overarching priority areas that define what the organisation is willing to sacrifice something for. Not "we will grow" (everyone says that). But "we choose to differentiate on customer experience rather than product breadth — and that requires us to invest in our customer data platform rather than additional product lines."

Initiatives — the concrete projects that translate themes into actions. Initiatives are time-bound, have owners, and cost something. They are the bridge between intention and execution.

Applications and capabilities — the technological reality. The applications that actually deliver the capabilities the initiatives require. And the technical debt that slows it down.

The loop is not linear. It is a feedback cycle: themes inform initiatives, initiatives drive application choices and investments, and the actual state of the application portfolio (TIME classification, technical debt, integration with other systems) informs the realism of the strategic themes.

Strategic themes without initiatives are aspirations. Initiatives without applications are theatre. Applications without strategic context are maintenance of the status quo. The loop is what gives all three meaning.

Themes as direction, not as goals

A strategic theme is not a KPI. It is a direction.

The difference is critical. A KPI says: "Increase customer satisfaction by 15% in the current fiscal year." A strategic theme says: "We choose to win on customer experience — that is what we are willing to invest in and sacrifice other things for."

The theme defines a priority, not an outcome. It makes it possible to answer the question "Should we invest in this initiative?" with something other than intuition. Does the initiative respond to a theme we have committed to? Or is it a nice-to-have?

In practice, an organisation's strategic themes should:

Be few — two to four. If everything is prioritised, nothing is.

Be exclusive — choosing themes means de-prioritising other areas. A strategy that excludes nothing is not a strategy.

Be specific enough to guide decisions. "We will be digitally excellent" is not specific enough. "We invest in our digital customer channel ahead of our distribution network" is.

Exist at a time horizon realistic for the IT portfolio investment cycle — typically 18-36 months, not a quarter and not ten years.

Initiatives as the translation layer

The initiative is the hardest link in the chain. This is where strategy and technology meet — and most often go wrong.

An initiative is a strategic theme made operational: it has a clear purpose (what is being improved?), an owner (who is accountable?), a time frame (when is it done?), a resource requirement (what does it cost?), and an IT connection (which applications and capabilities does it depend on?).

The last point — the IT connection — is what most initiatives lack. An initiative to improve the customer portal rarely explicitly defines: "We assume our CRM system can expose real-time customer data via API, and that our identity system supports SSO across mobile and web." When these assumptions are false (and they are more often than expected), implementation surprises arise, delays start, and the initiative delivers partially or late.

A good initiative register connects each initiative to:

The specific capabilities required. Not just "we need a good CRM" — but "we require the CRM to deliver customer interaction history updated with less than 5 minutes' delay to our sales assistant AI."

The applications that deliver or block those capabilities. This is where you cross-reference the TIME classification: are the relevant applications in "Invest," "Migrate," "Tolerate," or "Eliminate"? An initiative that depends on an application in the "Eliminate" category is already in trouble.

The dependencies on other initiatives. Initiatives are rarely independent. An initiative to migrate to a new data hub blocks three other initiatives that depend on the existing data structure.

Applications and capabilities as fact

The architecture is not what we wish it were. It is what it is.

That is the insight that makes EA something other than PowerPoint slides. An honest portfolio view shows the actual state of applications: technical debt, integration patterns, vendor contracts, support status. And that state is not malleable in the short term.

This has two implications for the loop:

Downward: Architecture defines the available space. Initiatives that require capabilities the existing application portfolio cannot deliver are not strategically feasible without additional investment. This reality should inform which initiatives are realistic to commit to within the strategic time horizon.

Upward: Architecture informs theme definition. If the portfolio's condition shows that fundamental data quality is too low to support AI-driven customer experiences, a theme about "Winning on AI personalisation" cannot be realised without a prior investment in data quality. That is a strategic reality — and it should be reflected in the theme definition.

Most strategy processes start with ambition and end with roadmap. The loop requires starting with reality: what can we actually deliver with the application portfolio we have — and what does it take to change that?

The loop as a feedback mechanism

What makes the loop a loop (and not a linear cascade) is feedback.

A strategic theme is formulated based on a certain understanding of what is possible. When initiatives are implemented and the application portfolio's actual state proves different from what was assumed, this needs to be fed back to the theme. Should the theme be adjusted? Should it be supplemented with a prior initiative to improve the technological foundation? Should the investment profile change?

The feedback mechanism requires two things:

A structured connection between initiative status and strategic status. Not just "the initiative is delayed" — but "the initiative is delayed because our CRM integration is more complex than assumed, and that delay impacts the theme 'Win on customer experience' by six months."

A forum that processes these feedbacks. Typically a combined architecture and strategy process that meets quarterly and looks at both layers. Not an IT steering committee (which only sees IT) and not a leadership workshop (which only sees strategy), but an integrated process.

What goes wrong without the loop

Three patterns are more common than others when the loop is missing:

Phantom initiatives: Initiatives approved strategically without checking whether the underlying application portfolio can support them. They deliver partially, late, or on unusable functions — because the foundation is missing.

Orphan applications: Applications not connected to any strategic initiative and therefore neither invested in nor phased out. They accumulate technical debt and maintenance costs without contributing to strategic direction.

Strategy drift: Themes that are not updated as architectural reality changes. Over time, the strategic plan and the technological reality diverge, and it becomes unclear what is actually prioritised.

All three patterns can be identified and addressed if the loop is visible. They are invisible if it is not.

What to do tomorrow

The strategy-to-architecture loop is not a project. It is a practice. Three steps to start:

Week 1: Identify the two to four strategic themes the organisation is actually committed to — not what is written in the strategy, but what is actually prioritised in investment decisions. Write them down in one document.

Week 2: Map active initiatives to themes. For each initiative: identify the top-3 capability requirements and the applications that deliver (or block) them. Identify initiatives that lack a connection.

Week 3: Review the TIME classification for applications that are critical to the most important initiatives. Identify the discrepancies that constitute a strategic risk.

The loop is never perfect. That is not the point. The point is to make the connections visible enough to make better decisions.

References

[1] Roger L. Martin and A.G. Lafley, "Playing to Win: How Strategy Really Works", Harvard Business Review Press, 2013.

[2] Richard Rumelt, "Good Strategy / Bad Strategy: The Difference and Why It Matters", Crown Business, 2011.

[3] TOGAF Standard, version 10, "Architecture Development Method (ADM)", The Open Group, 2022.