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.