Email delivery: Hate phishing emails? You'll love DMARC

Moving applications to the cloud can help to tighten the efficiency of the IT department, but does that mean that every application should be moved?

Software may have to be rewritten or at least reconfigured to function properly in the new environment, and it may not always be appropriate to invest the necessary time and money.

Assessing the business value of an application is therefore an important part of the transformation process.

In the modern IT department, delivering business value is everything. According to the HP and CapGemini Application Landscape report (2011), it was the top priority for 60 per cent of CIOs.

And yet for medium, large and enterprise businesses, an alarmingly high percentage of people say that they have more than enough applications for their needs.

Applications proliferate for all kinds of reasons. Mergers and acquisitions can introduce applications with duplicate functions, or different teams can create overlapping applications at different times.

Time for a clearout

Rationalising those applications can be key because the ones that do little more than introduce complexity tend to bring the business value down. They require costly maintenance. They duplicate data, which then has to be stored. They can confuse and muddy corporate workflow.

Companies considering moving their application portfolio to the cloud have the perfect opportunity to slash and burn those redundant applications. They need to evaluate each one so that they can decide whether to transform it for the cloud, decommission it or otherwise rationalise it.

How do we begin to understand the business value of an app?

Don’t touch this

According to the HP/CapGemini report, 75 per cent of respondents said that fewer than 70 per cent of their applications were business critical. Clearly, there’s quite a lot of superfluous stuff out there.

To work out just how superfluous it is, we need a common language in which the IT department and the business department can talk to each other.

Consider broad areas of business focus, then. Does an application contribute directly to top-line revenues? Does it support customer needs? Does it help the bottom line by cutting costs or mitigating risk?

Addition and subtraction

Cloud migration: The killing season

Each application that a cloud migration team is evaluating can be judged in terms of what it brings and what it takes away. Let’s look at what it takes away first.

Some applications may simply have aged so much that their value to the business has atrophied. Lehman’s first law of software evolution focuses on “continuing change”.

It says that systems affecting the real world tend to lose value because the real world (including internal processes, business conditions and regulations) tend to change around them. They become less relevant.

Linked to this is the concept of agility. An inflexible application can affect an organisation’s ability to change. How easy are applications to configure and adapt to changing conditions?

Software can also detract from business value if it costs an inordinate amount to maintain or to integrate with other systems. Applications can share infrastructure and resources to reduce costs (which is something that might happen during transformation).

Hard and soft

On the plus side, business software can bring both “soft” and “hard” benefits. Soft benefits, such as the indirect effect of a software application on customer satisfaction, can be hard to measure.

And trying to calculate its effect on employee productivity when the application is only one part of a broader set of inputs is equally challenging. It can require the kind of time and motion studies that are likely to be beyond most firms.

Hard benefits can be more easily measured using pre-agreed metrics. Perhaps an application can be used to reduce by half the number of days that an item is held in inventory, so reducing the manufacturer’s costs.

Maybe a customer relationship management component that facilitates cross-selling can be shown to increase sales of a particular product. And you might find that an application increases call throughput per call-centre employee by 20 per cent.

These are all solid, measurable statistics that can form the basis of the common taxonomy used by IT and business departments to measure business value.

Happiness index

Intel’s guidelines for measuring the business value of a software application have thrown up an interesting concept: the business value index (BVI).

Companies use matrices to measure all kinds of otherwise fluffy, vague things, such as corporate risk.

Intel’s BVI includes a three-dimensional axis charting the business value, the IT efficiency and the attractiveness of the investment to help evaluate value.

For example, an application with low business value and low IT efficiency can be classed as a failure and happily burned at the stake.

A high business value with a low IT efficiency indicates that it could be maintained to keep the business happy, but that an incremental IT budget will be necessary.

For organisations exploring whether to develop an application, the attractiveness of the investment would cover the whole software lifecycle. But for organisation moving apps to the cloud, it might just cover the necessary investment in transformation.

Hidden complications

Mapping applications according to business value might seem simple but underlying factors might include the risks involved in transforming the application, the volatility of the business environment, the alignment of the application with strategic investments and the potential for increased revenue or lowered costs.

All this is complicated by the fact that many organisations have no baseline data for comparison.

If there is no data available from when the application was not functioning, it is difficult to determine the software’s overall impact on the business. The best many organisations manage here is an estimate.

The last resort

At the end of the process, the IT department should have a better understanding of whether to approve an application’s transformation for the cloud and how that can be done.

Will the application be folded into a larger service oriented architecture project and re-created from the ground up to be more component-based?

Will it simply be ported to the cloud as part of a virtual machine environment, reducing its flexibility?

Or will the organisation take another approach, such as maintaining the application in its current state and leaving it outside the cloud, or simply retiring it altogether?

This last option is a tricky one. The HP and CapGemini report indicates that many companies have not factored retirement into the application lifecycle, meaning that it may not be prepared for the processes involved such as archiving data and mitigating other applications’ dependencies on the doomed app.

So companies may have a difficult time determining business value. And when they do, they may be unprepared to axe those applications that are not delivering it.

But to mangle William Faulkner (who admittedly didn’t do much systems integration), it’s still sometimes better to kill your darlings. ®

5 ways to reduce advertising network latency