IT-Business Alignment: Still Unsolved After Three Decades

In 1993, Henderson and Venkatraman published a framework that the IS field has been citing ever since. The Strategic Alignment Model, as it became known, proposed that organizations need alignment across four domains: business strategy, IT strategy, organizational infrastructure, and IT infrastructure. The argument was that misalignment across these domains was a major reason IT investments failed to produce expected business value. The framework is widely cited in IS research as a foundational contribution to the field. I want to be clear that I'm referencing it as it is broadly described in the IS literature, because I did not find the original paper in my local study-hub files to verify specific passages directly.

What I can say with confidence is that the alignment problem Henderson and Venkatraman named in 1993 is still alive. Surveys of CIO priorities, conducted regularly by organizations like Gartner and others, have consistently put IT-business alignment near the top of the list for more than two decades. The problem doesn't go away. This is either because it is fundamentally difficult, or because the solutions proposed haven't addressed the structural causes. My read is that it is both.

The first structural cause is temporal. Business strategy can shift quarterly. A merger happens, a competitor launches something unexpected, or the board decides to enter a new market. IT projects take twelve to twenty-four months to deliver, if things go reasonably well. By the time an IT system designed to support a strategic initiative is live, the strategy it was built to serve may have already changed direction. This is not a failure of planning. It is a gap between how IT investment cycles work and how business cycles work. The two move at different speeds, and alignment that existed at the start of a project does not automatically persist until delivery.

Organizations try to address this through governance mechanisms: steering committees, portfolio reviews, project prioritization processes. These help, but they don't fully close the temporal gap. The more agile the business strategy, the harder it is for IT to stay aligned with it. Which creates a secondary problem: the organizations most likely to need fast IT capability are the ones whose strategies are moving fastest, and those are exactly the organizations where the alignment gap is largest.

The second structural cause is linguistic. IT leaders and business leaders often struggle to communicate across a vocabulary gap. A technical capability is described in technical terms. A business need is described in financial and strategic terms. The translation between those two vocabularies is harder than it looks and is not reliably performed by either side. IT leaders who are trained in systems and architecture don't automatically think in terms of revenue impact, market share, or customer lifetime value. Business leaders who think in those terms don't automatically understand what it costs or what it takes to build certain technical capabilities. The gap is cultural and organizational, not technical. Better tools don't close it.

The original alignment model, as I understand it from the IS literature, was built on an assumption that IT enables strategy but doesn't create it. That assumption was reasonable in 1993 and remained reasonable for a while afterward. But it has weakened significantly. Amazon's recommendation engine didn't just enable a retail strategy. It was the strategy, and a business model that would not exist without the technology grew around it. Netflix's content recommendation shapes what gets produced. Google's search algorithm is the business. In these cases, IT is not supporting a pre-existing strategy. The strategy emerged from what the technology made possible. The alignment model didn't fully account for that direction of causality, where IT is ahead of strategy rather than behind it.

I think this is worth dwelling on because it changes what alignment should mean. If technology sometimes creates strategic options that business leaders haven't yet imagined, then the alignment problem isn't just about getting IT to match business intentions. It is also about creating organizational conditions where business leaders understand enough about IT capabilities to recognize what new strategies those capabilities make possible. That requires a different kind of CIO role, a topic I explored in my post on how the CIO role has changed but job descriptions have not. It also requires a different kind of business leader, one who can have a substantive conversation about technology without delegating it entirely to IT.

There is also a governance dimension that I think gets undervalued. Alignment isn't just a strategy question. It is a question of who has authority to make which decisions, how IT investment choices are made, and how the costs and benefits of IT projects are attributed across the organization. Business units that don't bear the cost of IT projects may have different investment preferences than the IT organization that has to execute them. Business units that don't fully understand technical constraints may push for timelines or feature sets that are unrealistic. Getting alignment at the strategy level while misalignment persists at the governance level produces frustration in both directions.

The persistence of this problem after thirty-plus years of research and practice suggests that the solutions people keep proposing, better communication, clearer governance frameworks, more business-oriented CIOs, are necessary but not sufficient. They address the surface of a structural problem that has deeper roots in how organizations separate the people who make strategic decisions from the people who build and run technical systems. As long as that separation is deep, alignment will require constant deliberate effort to maintain, rather than being a natural condition. And that is essentially what every CIO concern survey keeps saying. The effort is ongoing and the alignment is never quite finished, which is maybe the most honest description of where the field is after three decades.

For more on how IT strategy choices depend on context rather than universal best practices, I wrote about why there is no single best IT strategy.