How many applications is too many?
In March, Capgemini issued its 2011 Application Landscape report, which surveyed almost 100 companies application portfolios. It found that 60 per cent of enterprise respondents had more applications than they needed.
In large and enterprise-class firms, a bigger proportion of people felt that there were far too many applications.
This is not surprising. When companies grow, there are more cooks to spoil the broth. Bureaucracy can run out of control and different teams can develop applications with different sets of requirements, so their functions overlap.
In short, the right hand doesn’t know what the left hand is doing.
A case of indigestion
Large and enterprise companies also tend to buy other firms – along with their applications. Like a snake eating a rabbit, they can take some time to digest their prey, leaving a bloated IT infrastructure laden with applications they no longer need.
You could leave these applications puttering away happily in a corner, but application bloat has some nasty side effects. They cost money to support, which places burdens on the helpdesk, and they cost money to maintain. The more applications you have, the more you pay.
And all applications are not created equal. Many are custom jobs, tweaked and tailored to suit the user base. They may need extra work as the business’s requirements change, which can be a problem if they are not well-documented or if the original architects have departed.
According to the Capgemini survey, 56 per cent of large and enterprise customers said that more than half of their applications were bespoke.
No wonder that chief information officers are focusing on consolidating applications to make them more manageable.
The Cap Gemini survey found that adding more value to the business was the top priority for CIOs in 2011, followed by increasing the efficiency of IT.
Cutting out that fatty layer of applications being used by employees in single or low double-digit numbers, but which still incur heavy maintenance and support costs, is a way of achieving that.
Even more so if, for example, the app is running on that old DEC Alpha in a long-forgotten corner of the data centre.
The problem is how to sell this concept to the business while the economy is collapsing. Squeezing budget from the board during financial apocalypse is always tricky, and consolidating applications is going to be an expensive process no matter which way you cut it.
During happy times of growth, IT managers can use the promise of agility to promote foundational, infrastructural projects like this.
In times of frantic belt-tightening, the pitch has to be a little different. Instead of agility, cost cutting and efficiency are more appropriate talking points. Even then, the impetus may be towards other projects.
“It will consume bandwidth and effort that may not be available,” says Andy Bates, chief technical officer of Infrastructure transformation services at Capgemini UK .
Consolidating will save money that the IT department may be able to allocate elsewhere
“You’re always in competition with other business change initiatives. On the one hand, I could save dollars by shaving applications, but I have to create functionality for this new department. A lot of organisations know that there’s a business case there, but they don’t have the bandwidth to deliver.”
In that case, focus on infrastructure consolidation, says Bates. The application base that has grown up organically over the years will have a calcified layer of servers, networking and storage, built up like limescale on the inside of a kettle.
Consolidating that down to the essentials will save money that the IT department may be able to allocate elsewhere – such as to incremental application consolidation projects, perhaps. In any case, hardware virtualisation will be an integral part of application rationalisation, so you may as well tackle it while you can.
If you get the budget to go after those rogue applications after culling delinquent servers, how do you sift the wheat from the chaff?
Begin by understanding what you have and what it is used for. How many people use each application? What functions does it support? Pinpoint which applications are critically important to many business functions and focus on those.
What do you do with each application? Bates advises one of four options: firstly, decommission it altogether if you don’t need it.
Secondly if you need something to do what it does but it is too old and unwieldy, replace it.
“For example, you may have a fragile legacy system. You don’t even need to worry about that – turn it off and migrate across,” he says.
That tackles things at the business function level, but there are two others approaches. You can modernise the application by going in and tinkering around with the code. Or, you can farm the application, making more use of it.
This is likely to involve virtualising it. Even with legacy applications, some parts may be doable.
“If you look at an SAP system, you might say I can’t virtualise it. But lots of people do. Typically, you virtualise the application server layer rather than the database,” says Bates.
Of course, the moral of the story should be “don’t do it again”.
We would like to think that, having consolidated all of your hardware, virtualised your operating system portfolio, wrested the budget from the cold, dead hands of your finance director, and rationalised all of your applications into a finely tuned, streamlined stack of awesomeness, you won’t let your company make the same mistake again.
In reality, stopping application bloat from happening over the next few years will be a challenge. Internal politics and managerial myopia will see to that. But you can at least put policies in place to prevent things from running out of control.
Start with a proper application lifecycle governance strategy that allocates budget to decommissioning applications at the end of their useful life. That will help you to tie off the loose ends in your application portfolio.
Leave any frayed ends, however, and eventually your whole infrastructure will unravel. ®