The government announced its program to deal with toxic bank assets on Monday, and the stock market went wild. It was big news in all major newspapers the following day.

Most companies are sitting on a different kind of toxic asset, their critical business applications. These applications are large, complex, and often a decade old or older. Most haven’t been revamped since before Y2K. No one really knows how they work anymore. Most companies spend 80 percent or more of their IT budgets just maintaining the systems they have. What should be a valuable corporate asset—your application portfolio—could turn out to be a toxic liability.

Toxic applications are time bombs just waiting to explode at the most inopportune moment. For example, a computer glitch brought AirTran Airways to full stop at its Atlanta hub for several hours on a busy Monday morning. What do you think that cost?

Even a top technology company can suffer a costly application failure. Research in Motion (RIM), the maker of Blackberry communications devices, experienced a massive outage following an attempt to upgrade its software.

The point is that software is inherently complex and getting more complex. It can and does fail all the time, often with costly results.

Here is an explanation any CFO can appreciate, especially today. “Toxic applications are like toxic financial derivatives. These derivatives were concocted from large batches of loans, many of which were so risky they could never be repaid. Once hidden inside certain financial derivatives, the risks of these fatal loans become invisible. Without visibility into the risks hidden in derivatives, there is no way to evaluate the impact of these risks and, hence, no way to price these financial instruments,” explains Bill Curtis, chief scientist at CAST, a software tool vendor. We all know what happened.

The solution for toxic applications is visibility into the inner workings of the code. As with financial derivatives, the massive complexity and scale of enterprise applications and their often obscure interdependencies defy easy attempts at visibility. In the post mortems following a software disaster, it frequently turns out that a change to a small tangential piece of code brought the whole thing crashing down.

It is not easy to get visibility into complex production code. In addition to CAST, a number of vendors provide tools to inspect and test code quality. They include IBM/Rational, BMC, and more. A Google search on “software QA inspection” will produce pages of hits.

The CFO should not be delving into the intricacies of software code. Instead, Curtis identifies three steps top management should take:

1. Demand that IT executives and key stakeholders regularly measure and report the performance risks deeply embedded in mission critical applications.

2. Insist on a clear and detailed plan to mitigate these risks.

3. Use this risk information as the foundation of an ongoing dialogue with IT executives and key stakeholders about the future of applications that support your business.

Toxic applications are a corporate risk management issue more than they are a software coding problem. Your IT group can spend a fortune striving for bullet-proof application resilience and still not achieve it. The issue you have to decide is what level of application resilience you want and at what cost. ###