Resource-Based View and IT as Competitive Advantage

I keep noticing the same pattern across CRM sales decks. The pitch always uses the word "competitive advantage." Buy this platform, get ahead of your competitors. The vendor has a polished deck and some impressive case studies. What nobody says out loud is that every competitor in that industry is being pitched the same deck, by the same vendor, that same quarter.

That is the core problem with most conversations about IT and competitive advantage. The technology is for sale. Barney (1991) gave us the VRIN framework to think through this precisely. For a resource to generate sustained competitive advantage, it has to be Valuable, Rare, Inimitable, and Non-substitutable. Those are not four types of resources. They are characteristics that resources may or may not have. The distinction matters because the test is strict.

Most software purchases fail it immediately. The cloud platform you just signed up for? Your competitor has it too. The ERP you spent two years implementing? The same vendor is selling to your three closest rivals. Valuable, yes, probably. Rare, no. If it is not rare, the rest of the test does not matter.

This is essentially what Nicholas Carr argued in his 2003 piece "IT Doesn't Matter." His claim was that as IT becomes ubiquitous and standardized, it becomes infrastructure, like electricity or railroad tracks. Necessary to compete, but not sufficient to win. His critics thought he was being too dismissive. But he was not wrong about the commodity part. He was just applying the logic to the wrong unit of analysis.

That is where Wade and Hulland (2004) became useful. They applied RBV specifically to IS research and drew a distinction that Carr missed: the difference between IT resources and IT capabilities. IT resources, the hardware, the software licenses, the data storage, are easy to copy. But IT capabilities, the organizational ability to actually do something with those resources, can be much harder to replicate. IT capabilities combine infrastructure with human IT skill and with intangible organizational resources: the routines, the knowledge embedded in teams, the institutional knowledge of how a specific system works inside a specific context.

Bharadwaj (2000) tested this empirically and found that firms with high IT capability had significantly better profit ratios and lower cost ratios than matched firms. That is not just a theoretical argument. It showed that the unit of analysis matters. When you stop asking "how much did we spend on IT?" and start asking "what can our organization actually do with IT?", the picture changes.

The practical implication is this: the software you buy is not the advantage. Amazon's recommendation engine is not valuable because Amazon licensed some machine learning library. It is valuable because of years of accumulated transaction data, a culture of experimentation, and engineering practices that are deeply embedded in how that specific organization works. You cannot buy that. You cannot replicate it in a quarter. It passes all four VRIN tests.

Same logic applies to Google's search algorithm. It is not "software" in the way most people mean that word. It is the product of billions of search interactions, continuous refinement, enormous proprietary infrastructure, and specific organizational capabilities built over two decades. A competitor could write a search algorithm. Getting it to work as well as Google's, inside a comparable organizational context, is a different problem entirely. That combination of data, process, and accumulated capability is what VRIN looks like when it works.

The deeper issue is that most organizations are not actually asking whether their IT investments are rare or inimitable. They are asking whether other organizations in their industry have adopted the same systems. If yes, they adopt too. If no, they worry they are falling behind. Neither of those questions is the RBV question.

This is partly why so many IT investments disappoint. The technology works. The implementation goes reasonably well. And then two years later, every competitor has the same thing, and nobody has a clear advantage from any of it. The investment was necessary, but it was never going to be sufficient.

Wade and Hulland's point about IT capabilities points toward where the real question is. Can your organization integrate technology with people and process in a way that is hard to observe, hard to understand, and hard to reproduce? That is not something a vendor sells. It has to be built, slowly, with organizational commitment that goes well beyond the purchase decision.

I think about this a lot when I see organizations treat a technology purchase as a strategy. Buying the same ERP as your competitor is a table stake. It keeps you in the game. But the advantage, if it exists at all, is in what you build around it.