23 September 2008

Fungibility

By Andrew Clifford

Fungibility is a critical concept for managing long-term costs and risk in IT.

Words are the tools of thought and the tools of communication. The right word lets us condense and communicate a difficult concept, and the lack of a good word can make thought impossible.

In IT, we should use the word "fungibility" more. Fungibility describes things that are capable of mutual substitution. For example, a barrel of oil is fungible because it can be used in the same way as any other barrel of oil.

Fungibility is important to IT management. Fungibility reduces risk by giving us options if components fail. By letting us replace failing components, fungibility helps us prolong the useful life of systems, which is important for return on investment.

In IT, fungibility is not an inherent characteristic of components, but a combination of the component and how it is used. For example, the Oracle database is fungible if you limit yourself to standard SQL and standards-based drivers. You can replace Oracle with any other relational database.

If you use the special features of Oracle, such as SQL extensions and stored procedures, then you have destroyed its fungibility. You are locked in, you have undermined your own bargaining position, and you have increased risk.

Standards do not only provide guidelines on how things work well, they also enable fungibility. Without standards, there is no fungibility, and costs and risk increase.

Fungibility is wide and important in IT. We understand fungibility for hardware and system software. It also applies to design. For example, fungibility is important when integrating systems: no system should impact the fungibility of another, which means that all interfaces should be loosely-coupled, and should not exploit nuances of other systems that would prevent their replacement with equivalents.

Fungibility is important in development tools. Compilers for standards-based languages are highly fungible, but this fungibility can be completely undermined if you use a development tool that then ties you in. (I used to evaluate a lot of development tools, and I wish I had known the word "fungibility" to explain my concerns to vendors.)

I am not sure what the opposite of fungibility is, but in IT terms it is often "strategic". I wince when people say things like "Oracle is our strategic database". They interpret strategic to mean that a component will remain forever, and therefore can be used in a non-fungible way. Without fungibility, a technology strategy can be counter-productive to the cost and risk objectives that it is trying to meet.

Fungibility can be applied to people, too. For effective support, its important that support staff are fungible. To achieve this, systems have to be well documented, designed to standards, and not need any unusual skills.

But I do not think we should generally treat people as fungible. People's knowledge, skills, aptitude and productivity are not as interchangeable as many project plans imply. Any project plan with an unnamed "senior designer" resource is treating the non-fungible in a fungible way.

You might well disagree, but you do now have a new word to use in your arguments.