Information Age: News, analysis & insight for IT & business leaders

Early in 2004, analyst group IDC asked its corporate customers a question: "Are you getting the expected value from your software solutions?" More than 80% of the company's European customers said they derived more value than they had expected. But when US customers were asked the same question, says Bill Clough, research director of IDC's European Software Group, "the results were almost exactly reversed."

The explanation for this disparity lies in the respective customer groups. "In Europe, at least two thirds of our customers are IT directors. In the US, there is a much larger number of line business managers," said Clough. It is no surprise that IT professionals and business executives disagree over software value. IT professionals "usually have more realistic expectations than business managers, because they are closer to it [software development and deployment] and understand better what is really possible," says Clough. On the other hand, it could be argued that business managers tend to put too much faith in the promises of their suppliers (including sometimes their own IT department).

However, the results of IDC's research also point to another, more serious problem. Whether they are pleased or disappointed by their return on investment in software, neither IT professionals nor business executives are getting the return they expect. The reason for this is disturbingly simple. "The number of companies who properly assess their likely return on any software investment, either before or after it is deployed, is pathetically low," says Clough.

Measure for measure

With many companies preparing to spend thousands, and in some cases of millions, on new application server and web services-based software projects, the time is clearly ripe for them to also re-assess how they justify the cost of these investments, and how they measure the real worth of them once they have been made.

Certainly, even where they are used, traditional approaches to software cost and value measurement will not go far in the new era of application server and services based development and integration. Notions of programmer productivity based on counting lines of code produced per day, for instance, are obviously redundant in a world where effective development requires that programmers write less code, rather than more.

Conventional cost comparisons of bespoke and packaged solutions, or in-house versus third party or offshore development, are also likely to have limited value when modern software investments are likely to comprise elements of all these approaches. Above all, there is the prospect that code re-use and component-driven (and services-based) software "assembly" will rewrite the software rule-book, and foster renewed corporate confidence in the economic viability of in-house development and integration.

Utilising ITILs

Great though the potential savings and efficiencies of reuse and component assembly may be, they will not be realised spontaneously just because organisations adopt application server technology and development frameworks such as .NET. Most organisations still treat their software estate as a collection of discrete applications. To identify the functionally useful "wood" hidden in amongst the trees of the legacy software forest, organisations must create software asset libraries - effectively auditing their software investment in a finer-grained way than they have done so before.

This process is already underway at many companies, particularly among those who have adopted the Department of Trade and Industry's guidelines on the creation of IT infrastructure libraries (ITILs), which includes a module offering guidance on application management.

Once an ITIL-style software asset library is in place, such organisations have a more informed view of the value of those assets, and can embark on future projects with more confidence that they will not be prone to wasteful duplication of existing capabilities, and that they are working with proven, reliable materials. This will make building the business case for new systems easier and more accurate.

But there are still plenty of variables which must be factored in assessing the likely return on any new investment.

In particular, says IDC's Clough, companies must pay greater attention to the "soft" benefits that they expect to derive from new systems. These include likely improvements in systems usability, reliability and, of course, commercial functionality.

Measuring these benefits in advance of a systems deployment is never going to be a precise science. However, the good news is that because systems builders are now working with a catalogue of known software assets, the outcome of their efforts should be more predictable, both in terms of the time it takes to construct new systems and the likelihood that they will meet their original functional specification.

Indeed, not only should integration and development projects become more predictable using service and component driven methods, the ability of business analysts, as opposed to software specialists, to manage the development effort and to ensure it remains aligned with business goals, should also be greatly enhanced.

In the past, some experts have calculated that as many as 86% of new systems typically fail to work first time. This kind of statistic ought soon to be a thing of the past.