Strategy & Planning

The Architecture Roadmap: Planning Across Three Horizons

How to build a multi-horizon architecture roadmap with governance checkpoints that survives executive scrutiny and drives real transformation

9 min read

Your beautifully crafted architecture roadmap just got shredded in the quarterly business review. The CFO wants to know why capability investments span three years when the business needs results in six months. The CTO questions why emerging technologies appear in year two when competitors are already deploying them. And the CEO just asked the question that makes every enterprise architect's stomach drop: 'What happens if our strategy changes next quarter?' This scenario plays out in boardrooms across every industry because most architecture roadmaps treat time as a linear progression rather than a portfolio of strategic horizons. They optimize for completeness instead of adaptability, creating detailed three-year plans that become obsolete before the ink dries. The result? Architecture teams get marginalized as 'ivory tower planners' while the business makes critical technology decisions without architectural input.

The accelerating pace of business transformation—driven by AI adoption, regulatory changes, and market volatility—has fundamentally broken traditional roadmapping approaches. McKinsey's Three Horizons framework, originally designed for innovation portfolios, provides the solution: architect your roadmap as a balanced portfolio of incremental improvements (Horizon 1), emerging opportunities (Horizon 2), and transformational bets (Horizon 3). This approach aligns naturally with how executives think about investment allocation and risk management.

Key Takeaways

  • Map each capability investment to strategic horizons based on business value timeline, not technical complexity—Horizon 1 optimizes current operations, Horizon 2 builds emerging capabilities, Horizon 3 explores transformational possibilities
  • Establish governance checkpoints at horizon boundaries where investment allocation can shift based on performance metrics and strategic changes, not calendar milestones
  • Use capability heat mapping to identify which L2 capabilities belong in each horizon—red-hot capabilities requiring immediate investment go to Horizon 1, emerging needs go to Horizon 2, future possibilities to Horizon 3
  • Structure roadmap dependencies across horizons so Horizon 2 and 3 investments don't create technical debt that undermines Horizon 1 performance
  • Build investment reallocation triggers into the roadmap governance model—define specific business conditions that automatically shift budget between horizons

Mapping Capabilities to Strategic Horizons

The foundation of three-horizon planning lies in correctly categorizing your capability investments based on strategic value, not technical timeline.

Start with your existing capability map and overlay strategic urgency using heat mapping techniques from the BIZBOK methodology. Horizon 1 capabilities are those requiring immediate optimization to maintain competitive position—think core transaction processing, customer onboarding, or regulatory reporting. These typically represent 60-70% of your architecture investment and focus on reducing technical debt, improving performance, or ensuring compliance. Horizon 2 capabilities enable emerging business models or market opportunities your organization is actively pursuing. Examples include AI-powered personalization, real-time analytics, or omnichannel customer experience platforms. These represent 20-30% of investment and require proof-of-concept validation before full deployment. Horizon 3 capabilities are transformational bets that could fundamentally reshape your business model—quantum computing applications, decentralized identity management, or autonomous process orchestration. Limit these to 10-15% of total investment. The critical insight: capability maturity and strategic horizon are independent variables. You might invest in cutting-edge AI technology as a Horizon 1 initiative if competitive survival depends on it, while moving legacy modernization to Horizon 2 if current systems adequately support business needs.

Building Horizon-Aware Governance Checkpoints

Traditional roadmap governance fails because it treats all investments with the same risk tolerance and success metrics across different time horizons.

Establish distinct governance models for each horizon with appropriate risk tolerance and decision-making speed. Horizon 1 governance should mirror operational management—monthly reviews, clear ROI metrics, and rapid course correction when investments don't deliver expected business value. Use stage-gate processes from TOGAF ADM with compressed timelines and binary go/no-go decisions. Horizon 2 governance requires venture capital thinking—quarterly portfolio reviews, learning objectives alongside financial metrics, and willingness to kill projects that don't hit proof-of-concept milestones. Apply capability-based planning principles to define minimum viable capabilities that prove business value before scaling investment. Horizon 3 governance operates like corporate venture capital—annual strategic reviews, option value metrics rather than ROI, and explicit innovation theater limits to prevent runaway spending. Each horizon should have different approval authorities, budget flexibility, and failure tolerance. The key insight: don't force Horizon 3 moonshots through Horizon 1 operational governance, and don't let Horizon 1 performance requirements kill Horizon 2 learning experiments. Cross-horizon dependencies require escalation to portfolio governance level—typically your enterprise architecture review board or technology steering committee.

  • Horizon 1: Monthly ROI reviews, 90-day course correction authority
  • Horizon 2: Quarterly capability maturity assessments, 6-month pivot decisions
  • Horizon 3: Annual portfolio rebalancing, 18-month option value evaluation