Resource Dependency Theory and the IT Sourcing Problem

I have been thinking about why organizations keep making IT sourcing decisions that they later describe as mistakes. The pattern is familiar. A company outsources its IT infrastructure to a large vendor, spends two years integrating deeply into that vendor's proprietary stack, and then discovers that switching costs have eliminated any practical alternative. Or a company moves everything to a single cloud provider, builds internal tools on that provider's proprietary services, and finds that the cost structure has shifted dramatically because the provider changed its pricing after the organization was committed. The organization knew the risk was possible. They did it anyway. And a few years later, they are trapped.

Transaction cost economics, which is probably the most commonly applied theory to make-vs-buy decisions in IS, frames this as an efficiency problem. Williamson argued that organizations internalize activities when external transaction costs, including the costs of specifying, monitoring, and enforcing contracts, exceed the costs of internal production. The sourcing decision is a cost minimization problem. TCE would say that organizations get locked in when they underestimate asset specificity at the time of the sourcing decision. The assets they build become specific to a particular vendor, and exit becomes expensive. That is true, but I think it is incomplete. It focuses on costs and misses the power dynamics that make vendor relationships so consequential.

Pfeffer and Salancik published "The External Control of Organizations" in 1978, and the core argument is different from TCE in a way that matters. Organizations depend on external entities for critical resources. When resource providers are few and the resources are hard to substitute, the dependent organization loses discretion over its own strategy. Power flows to whoever controls the critical resources. This is not primarily about transaction costs. It is about the structural conditions that determine who has leverage in the relationship. The dependency shapes what the organization can do, not just what it costs to switch.

The IT sourcing context maps onto Pfeffer and Salancik's dependency framework in ways that are almost embarrassingly direct. Resource criticality is high almost by definition. ERP systems, cloud infrastructure, and CRM platforms are not peripheral tools. They are the operational backbone of the organization. Stop the ERP and you have stopped procurement, finance, and supply chain. Lose access to your cloud provider and your applications are offline. The criticality of these resources gives vendors structural power even before you factor in concentration.

Concentration is where the picture gets interesting. The enterprise software market is dominated by a small number of vendors. SAP and Oracle together hold a disproportionate share of the large-enterprise ERP market. AWS, Azure, and Google Cloud account for the overwhelming majority of enterprise cloud infrastructure globally. Salesforce has an extraordinary share of enterprise CRM. In each category, organizations depend on a handful of providers for resources that are critical to operations. Alternatives exist in theory. Switching costs in practice are enormous. The switching cost structure is exactly what Pfeffer and Salancik described as the mechanism by which dependency translates into power. When leaving is too expensive, the dependent organization is subject to the resource provider's discretion on pricing, feature decisions, support quality, and strategic direction.

What resource dependency theory adds to the IT sourcing conversation that TCE does not is the focus on how organizations respond to dependency rather than just whether they entered the dependency wisely. Pfeffer and Salancik described several responses. Absorbing the dependence through vertical integration, meaning building the capability internally. Finding substitutes that reduce the criticality of any single provider. Diversifying across multiple providers to reduce concentration. Building political capital with the provider to negotiate better terms. Forming coalitions with other dependent organizations to balance power collectively. Every one of these responses is visible in enterprise IT strategy.

The multi-cloud strategy is the clearest example. Organizations that run workloads across AWS, Azure, and Google Cloud are paying a real premium in operational complexity. Running a multi-cloud architecture requires more skilled engineers, more management overhead, and more sophisticated tooling. From a pure TCE efficiency standpoint, it often looks irrational. A single-cloud strategy is cheaper and simpler to operate. But resource dependency theory explains it. Multi-cloud is not about efficiency. It is about preventing any single provider from having unconstrained leverage over the organization's infrastructure. The complexity premium is the price of maintaining strategic alternatives. It is an insurance policy against dependency exploitation.

The make-vs-buy decision itself looks different through a resource dependency lens than through a TCE lens. TCE asks whether the transaction costs of the market exceed the management costs of hierarchy. The optimal answer is wherever total costs are lowest. Resource dependency asks a different question: which choice gives the organization more discretion over its own strategy? Sometimes building internally is more expensive in TCE terms but substantially reduces dependency on a powerful external actor. Organizations in regulated industries, or with genuinely proprietary processes, often make this choice. They are not optimizing for efficiency. They are optimizing for strategic autonomy.

I have been following the "build vs. buy AI" debate in the enterprise market, and it maps directly onto this framework. Every large organization is currently deciding whether to use a proprietary AI model from OpenAI, Anthropic, or Google, or to deploy an open-weight model on its own infrastructure. The TCE argument for the proprietary model is compelling. The API is cheaper than the infrastructure and talent needed to run your own model. The quality is higher. The transaction costs of the API relationship are low. But the resource dependency argument cuts the other way. A proprietary API creates dependency on a provider whose pricing, terms of service, and capability roadmap you do not control. An organization that builds its product on a single model provider's API has handed over strategic discretion in its most important competitive area. The open-weight alternative costs more in TCE terms but buys back dependency independence.

The organizations that seem to navigate IT sourcing best are the ones that treat sourcing decisions as dependency portfolio management. They are not asking "what is cheapest?" or even "what performs best right now?" They are asking "what is the dependency structure we are creating, and do we have the mechanisms to manage it?" The answers lead to multi-vendor strategies, contractual protections around data portability, investments in internal capability that maintain switching credibility even when the organization has not switched, and explicit governance processes for reviewing dependency concentration over time.

TCE and RDT are often presented as competing theories in the IS sourcing literature. I think they are more complementary than competitive. TCE explains the cost structure of the sourcing decision. RDT explains the power structure that the sourcing decision creates. An organization can make a low-transaction-cost sourcing choice that creates a high-dependency power structure. The costs look good. The dependency builds quietly. A few years later, the provider changes its terms, and the organization finds it has no practical recourse. TCE predicted the initial savings. RDT predicted the eventual trap. You need both to understand what happened.