The average corporate application portfolio is growing in size. Danny Bradbury looks at how IT departments can rationalise applications and strip cost and complexity out of the business
The prevailing ethos in IT has always been “keep it simple”. So why is it that the complexity of the average company’s application base is increasing? The number of applications a company has to support is climbing, and it is pushing up the cost of doing business, while decreasing the IT department’s agility. Solving the problem is a daunting task, especially when most IT departments simply do not know how to let go of old software.
“An interesting conundrum that we find when we talk to customers is the inability of their IT shops to figure out how to end the life of applications. The portfolio tends to grow and grow,” says Kris Brittain, research vice-president at analyst firm Gartner.
At a recent conference on change management, Brittain asked the audience whether anyone had experienced a reduction in their application portfolio over the past two years. “In an audience of 300, not one hand went up. I was finding that in service desks, if you compared the number of applications that the level-one folks had to support from 1995 to 2000 and from 2000 to 2005, there is about a 300% growth.”
The benefits of consolidating applications are obvious. It cuts change management requirements considerably because application interdependencies are reduced. Support staff no longer have to deal with as many pieces of software, and training costs fall. Software and hardware maintenance costs can also be slashed, leading to a more efficient IT operation that can concentrate on business goals.
So, why isn’t it happening? Purely from a technical perspective, consolidating applications is a daunting task that can easily unravel.
“A common mistake has been for IT departments to attempt wholesale consolidations of applications onto the newer technical platforms such as .net, J2EE or best of breed applications,” says Peter Stevens, a consultant at PA Consulting. “There is a high risk that such ventures can turn into runaway projects without adequate business justification, and it is simply too expensive an approach to be justified just through consolidation of hardware platforms.”
It does not help when applications are poorly documented and contain hardwired business processes. Understanding what an application does and why is only part of the problem. Understanding how the underlying processes drive the business and whether the process should be changed is another challenge.
Consequently, you cannot look at paring down your application base as a single, isolated task. Instead, take all of your IT assets, including business processes, applications and data, and try to look at rationalisation with all of them in mind, says Noomane Fehri, head of innovation and solution management at consultancy Atos Origin.
Then, prioritise the applications based on your business criteria. These could include maintenance cost, the application’s ability to contribute to business change, and how long supplier support is likely to continue.
Analysing the underlying business processes in a 20-year-old application running on a legacy server should provide your IT department with no end of fun. Use a business process rules engine, says Fehri – a suggestion which will doubtless have the average cash-strapped IT manager chuckling. After all, this stuff does not come cheap.
Other consultancies and suppliers are also trying to upsell customers to an even more complex process on the back of application consolidation: service oriented architecture. SOA carves up applications into services, which it exposes through a middleware layer, enabling companies to craft new applications by bolting them together in different combinations.
SOA does not immediately solve the problem of application consolidation. After all, the legacy code from a company’s applications is still all there, running on the same boxes. But it does throw a veil between the application base and the end-user, which has ramifications for support and training costs, and for enabling future migration.
“Initially, whenever you are going in and selling SOA, the selling point is that you eliminate applications at the back end,” says George Glass, head of strategy and architecture at BT. He is four years into an SOA project that is serving as a platform for software rationalisation.
“People had 12 to 15 applications on the desktop, depending on what they were offering the customer,” he says of his user base. “That had an impact not only on the complexity of the desktop, but also on the training time of agents and our ability to change anything from the agent’s perspective.”
BT standardised on off-the-shelf applications about three years ago, but most of their details and product inventory were in legacy applications, says Glass. He used SOA tools from Corizon to create a middleware layer of user interface components that could be bolted together into new application interfaces for the client.
But isn’t this simply an expensive way to extrapolate functions out of applications in new ways without actually consolidating them? Not according to Glass. “We accelerated the delivery of the standard user interface, but in the background we are still running a massive migration activity to move onto the SOA.”
Putting an SOA front-end on the applications is only part of the process. Moving their functions gradually into the commercial software tools is the next. As he gradually carves up his old application base into services, redeploying select services into the new software packages over time, Glass uses switching software to direct calls either to new data structures, or old legacy ones, depending on which services have been migrated and which ones have not.
Still, SOA is the Cadillac of application consolidation, and not everyone will be able to afford it. For one thing, doing the data analysis and resolving the inter-application dependencies in the legacy code base could present problems. For another, hooking the SOA layer into back-end software is usually a complicated manual process.
“For a smaller company, to move to SOA is probably premature because they will not get the benefits of it,” says Glass. “The standards are not there yet. They would be better to wait until the commercial software guys start exposing the standard business services.”
Lofty ideas about SOA and business rules engines will not impress the average cash-strapped IT manager. Isn’t there a poor man’s solution?
“Focus on what data you need,” says Fehri. “Focus on what you need from this application, and sort out that problem and disregard the others.” By trying to condense just the parts of an application that are useful, you can eliminate the functions that were once important but which have been long since depreciated, or which embody processes that no longer serve a useful purpose.
Understanding the functions of a legacy application that are still required will get you on the road to choosing a consolidated system, but even then, boiling down selected functions from 10 pieces of software into one presents problems. Much will depend on the customisation ability of your commercial software (although if you are developing a bespoke system to replace a variety of others, you have more room to manoeuvre).
“Enterprise resource planning software, whether it is higher- or lower-end, could in certain cases solve 80% of your problem, but you still need to build the 20% to adapt it to what you need,” says Fehri. This is a problem that Glass has grappled with, but the larger your budget and the more muscle power you have as a customer, the more you are able to push the supplier to cooperate.
While you grapple with suppliers to help them customise your consolidated system, you will also face challenges from end-users and line managers. Political strife comes with the territory, says Dave Turner, group marketing director at financial software house Coda.
“Everyone thinks that their way of doing these things is right,” he says, adding that business analysts have to work out what processes are genuinely essential, and which are there simply due to territorialism and inertia. The more dispersed your organisation is, the more likely it is that you will face genuine regional disparities, and the decision may be easier to make if you are dealing with an intranational organisation rather than an international one.
Turner has been using shared service centres as a way of integrating applications with his clients. Moving functions from many different areas into a single shared service centre enables a company to begin bringing together different regional operations at an organisational level even before it starts the application rationalisation process. An added benefit is that, because staff are being consolidated too, you get the chance to shake out ingrained attitudes.
“You get organisations bogged down with organisational cultures that have grown up over the years. It gives you the chance to break out of that mould and impose new procedures,” Turner says.
No one should be fooled into thinking that application rationalisation is easy, but the opportunities to strip complexity and cost out of the business are immense. “If you look at software, the cost of development is about one-tenth the lifetime support of the application. The lifetime support includes the maintenance and operations cost,” says Glass.
He has a base of 3,500 applications throughout BT’s infrastructure and has shed about 300 this year. In about five years’ time, when his rationalisation project is complete, Glass hopes to be down to about 300 applications in total. “We are out by a factor of 10 right now,” he says.
But then, boiling down years of legacy systems smoothly into a refined code base is not something you do overnight.
Case study: Icelandair brings financials in from the cold
Icelandair used a shared service centre model when it decided to rationalise its financial applications. The airline, which created its first domestic airline subsidiary in 1998, centralised rapidly after that, explains Helga Guðbjörg Guðmundsdóttir, IT department manager for Icelandair Shared Services.
All the subsidiaries were using different financial packages, and Icelandair Shared Services was created to bring them together. The organisation centred on Coda-Financials, eliminating the other financial systems, but retaining the other specialist line-of-business applications, such as sales, maintenance, hotel booking and car rental.
Coda’s data integration toolset, Coda-Link, helped the firm tie 120 applications into the consolidated financial systems in three months.
Getting buy-in from the subsidiaries was an important part of the process, which meant that the consolidated software had to be flexible enough to support different companies’ requirements.
“We created workflow groups for each company that enabled us to group their reports in a certain way,” says Guðbjörg Guðmundsdóttir. “They told us exactly how they would like to see their financial statements.”
The process of accommodating subsidiaries’ requirements to create a consolidated financial application system was worth it from a management perspective. “Management can see how all the companies are doing,” she says. “They are having real-time information every day.”
The company has expanded its base of subsidiaries, growing to 16 at the time of writing. Because its financial applications have already been consolidated, the company is able to use the Coda-Financials software for new subsidiaries when they come on board.
Application consolidation has helped to tidy up loose ends from the past, and has also created a simpler future.