The Strategic Alignment Model (proposed by Henderson and Venkatraman) organizes a company into four domains: business strategy, IT strategy, organizational infrastructure and processes, and IT infrastructure and processes. What is the difference between the model's 'strategic fit' and 'functional integration' dimensions, and what does it mean for an alignment perspective to start from IT strategy rather than business strategy?

## The problem SAM was built for Henderson and Venkatraman published the Strategic Alignment Model (SAM) in 1993 to answer a specific problem: companies were treating 'IT alignment' as a single, static property — either IT was aligned with the business or it wasn't — when in reality alignment is the product of two independent relationships that both have to hold at once, and that shift over time. ## The four boxes SAM lays out a 2x2 grid: the two columns are the business domain and the IT domain, and the two rows are the strategic level and the operational (infrastructure/process) level. That gives four boxes — business strategy, IT strategy, organizational infrastructure and processes, and IT infrastructure and processes — each with its own defining scope. | Box | Defining scope | |---|---| | **Business strategy** | covers scope (markets, products), distinctive competencies, and governance (alliances, ownership structures) | | **IT strategy** | covers technology scope, systemic competencies, and IT governance (make-vs-buy, sourcing) | | **Organizational infrastructure** | covers the administrative structure, business processes, and skills that execute the business strategy | | **IT infrastructure** | covers the architecture, processes, and skills that execute the IT strategy | ## Strategic fit versus functional integration - **Strategic fit** is the vertical relationship inside each column: does business strategy actually drive an organizational structure and set of processes capable of executing it, and separately, does IT strategy drive an IT infrastructure capable of delivering it? A company can fail strategic fit on the business side alone — announcing a strategy to become a low-cost provider while its org chart and processes remain built for premium, high-touch service. - **Functional integration** is the horizontal relationship across the business/IT boundary, and it exists at two levels: **strategic integration** links business strategy directly to IT strategy (does the technology roadmap actually reflect what the business is trying to become), and **operational integration** links organizational infrastructure to IT infrastructure (do day-to-day business processes and the systems that run them actually fit together, independent of what either strategy document says). The reason SAM insists on naming both dimensions separately is that organizations routinely nail one and miss the other: an IT department can build infrastructure that fits its own IT strategy perfectly (strong strategic fit on the IT side) while that IT strategy has drifted away from what the business actually needs (weak functional integration) — technically excellent, strategically irrelevant. ## The four dominant alignment perspectives The model's other key contribution is naming four 'dominant alignment perspectives,' each a different causal chain through the four boxes, because in practice organizations pick one driver and let it cascade. 1. **Strategy Execution** is the default: business strategy drives organizational infrastructure, which then drives IT infrastructure — IT is purely an implementer, executing a plan it had no hand in shaping. 2. **Technology Transformation** also starts from business strategy but routes through IT strategy first, then IT infrastructure — business strategy defines what capabilities are needed, IT strategy decides how technology should deliver them, and infrastructure is built to match. 3. **Service Level** starts from IT strategy and drives IT infrastructure, then organizational infrastructure — IT is run like an internal service provider optimizing for world-class delivery, largely decoupled from business strategy, appropriate for utility functions like network and hosting. 4. **Competitive Potential** is the perspective that inverts the usual causality: IT strategy (specifically, emerging IT capabilities) directly shapes business strategy, which then drives organizational infrastructure. This is the perspective that explains, for example, a retailer whose cloud-native data platform makes a new subscription business model viable, or a bank whose API capabilities make embedded-finance partnerships possible — the technology capability came first and the business strategy changed because of it, not the other way around. ## The trade-off in choosing a perspective The trade-off in choosing a perspective is real: - **Strategy Execution** is the safest and most governable — IT never runs ahead of the business — but it structurally prevents IT-driven innovation, because by construction the business strategy box is never influenced by what technology now makes possible. - **Competitive Potential** unlocks that innovation but is much harder to govern, because it requires business leadership to trust IT's judgment about which emerging capabilities are worth betting the strategy on, and it is easy to rationalize an expensive technology bet after the fact as 'competitive potential' when it was really just IT chasing something new. ## The most common failure mode The most common failure mode in practice is a mismatch between the perspective an organization believes it is running and the perspective its funding and governance actually enforce: leadership talks about IT as a strategic partner (implying Technology Transformation or Competitive Potential) while the budgeting process still requires every IT initiative to trace back to an already-approved business case (which only Strategy Execution supports), so genuinely novel technology-driven opportunities never get funded because there is no business strategy line item to attach them to yet. A well-known real-world illustration is Amazon's internal decision to expose its infrastructure services externally, which became AWS — a Competitive Potential move where an IT capability (internally built elastic infrastructure) directly created a new business strategy, rather than a business strategy asking IT to build a cloud product.