Lately I've seen several discussions of commoditization in the enterprise software space. Or perhaps "commoditisation", depending on which side of the Great English-language Divide on which you happened to spend your school years. Specifically the claim has been made that applications (ERP, BI, analytics) or skills (programming, project management, for example) are becoming commoditized.

I'm not going to link to any of these claims because my claim is that the word is being subject to rampant misuse and I'd rather not call out anyone specific. The misuse is widespread and I don't think it would be fair to name individuals.

This misuse is a shame. There is a lot of really useful economic and social theory around commoditization. Incorrectly labeling a market trend as "commoditization" creates the incorrect impression that these bodies of theory are applicable, and this can result in incorrect analysis.

See, for example, the insightful discussion of commoditization as a competitive strategy in this blog about Facebook's Open Compute Project by Marco Arment. When we use the term incorrectly, we poison the well from which this sort of analysis is drawn.

So, what is commoditization? Wikipedia, as usual, has a fairly good definition. To break it down, a commodity is:

Undifferentiated - a commodity from supplier X is basically the same as the same product from supplier Y
Fungible - an instance of a commodity can easily be switched for another instance of the same commodity without significant impact on the user of the commodity - in other words, a commodity has low switching costs

When a product is a commodity it will usually have a price that is determined by a market of exchange. Markets are not always efficient, and very few products are truly commodities, but there are some products that come fairly close. Wikipedia gives several examples, but here are a couple for your consideration:

Salt - All salt is basically the same, and switching from one brand of salt to another has no noticeable impact on the user (not withstanding "premium" salts, for example sea-salt).
Unskilled labor - The initial pay of grocery store shelf-stockers, for example, is determined primarily by market forces or minimum wage as the labor pool is considered fairly undifferentiated and the cost of hiring a different employee is fairly low in some labor markets.

So what about enterprise software? I can't think of anything that's a commodity in enterprise software. Maybe servers, as the advent of virtualization and cloud computing begins to lower switching costs (improving fungibility).

What is not a commodity in enterprise software? Lots of stuff. Here are some examples:

ERP and BI software - Different offerings are still quite differentiated, and switching costs are astronomical because of the amount of customization required of all solutions. Additionally, cloud vendors are now creating data lock-in scenarios that can make it very difficult to migrate old data to a new solution.
Switching from "build" to "buy" does not commoditize a market - An IT department switching from a "build" to a "buy" approach, or a vendor pushing solutions that require less customization, does not result in commoditization of a market. This is because different solutions are still differentiated based on features, performance, or ease-of-use, and because switching costs remain high. Switching costs should be lower when going from a custom solution to an "off-the-self" solution than the other way around, perhaps making the product more commodity-like, but this is a stretch. Implementation costs are still going to be quite high.
Developers and consultants - There is lots of suspect research talking about how the best developers are some multiplier (usually 6-20X) more productive than the average developer. In fact, it's probably worse because this research tends to focus on long-term employment. Because of the time taken for on-boarding (switching costs) and the increased administration costs that come with a larger team, hiring a middling developer or consultant for your project can often make the project progress even more slowly than hiring no one at all!
Tool-kits - Development tool-kits have a real impact on the performance of custom development. The choice to use language A versus language B for a given development project is not academic. The differentiation equation depends on your existing skill-set as well as features of the tool-kit and switching costs are high due to the need for retraining and reorientation.

Commodity theory does not apply to any of these areas. The goods are not fungible and the products are differentiated.

Any vendor who says otherwise is probably peddling a subpar product (or labor). Any IT department that believes this is probably making some bad purchasing decisions. And every purchasing department likely talks to their suppliers about how this is a commodity market ... because they are trying to negotiate a better price.