<<Enterprise architects looking to implement an agile SOA
infrastructure must first trim down the application bloat in their
current IT environment, argues Lyn Robison, an analyst with Burton
Group Inc.
Robison is the author of "Application Rationalization: Burning Fat and
Building Muscle," a 32-page Burton Group report released this week
that outlines a program for dealing with the common problem of too
many applications doing too little work.
If you have only a vague inkling of what application rationalization
might be, the analyst says he is not surprised. While the concept of
going through and weeding out unnecessary applications isn't new, and
is part of the consulting practice of Burton and other analyst firms,
it is not a popular practice. It doesn't have the buzz of SOA, Ajax or
agile programming. Perhaps it lacks a sexy name.
"Application rationalization is kind of a non-descript term," Robison
admits. But that doesn't mean it isn't important to the success of the
IT initiatives that are hot topics at conferences and in blogs.
"I look out and I see that it's such a common thing for enterprises to
have a real bloated and out-of-control application portfolio," he
said. "There are so many things that you can't do in terms of
important IT initiatives if you have that. Everybody should be doing
application rationalization, but at this point it's fairly early in
the adoption curve. It's a bit of a novelty actually."
That might change because he says the drive to SOA may force IT
professionals to tackle the problem.
"As companies initiate Service Oriented Architecture projects, they
will immediately be confronted with the fact that their application
portfolio is a weed patch and they'll need to clean that up before
they can make any progress," he said. "Application rationalization
really is a prerequisite."
Application portfolio bloat is also a product of trends in business
computing during the past 25 years as the IBM PC, along with the
server and networking infrastructure that grew around it, made it
possible for departments and even individuals to buy and install their
own application packages. This was not much of a problem in the
mainframe era when a few managers could control the number of
applications running on their hardware, Robison notes.
As with the fat versus muscle simile in the title of Robison's report,
the problem grew gradually as applications were developed or purchased
over the years without enough controls to prevent the inevitable
duplication and eventual bloat. And just as it is not easy trim fat
and add muscle, application rationalization requires work.
When application bloat is first identified as a problem, Robison said
there is a natural tendency to say, "Let's buy a tool to fix it."
But the analyst said tools provide limited help as a team of IT
professionals goes through lists of applications and exercises human
judgments as to what to keep and what to discard.
"The criteria by which the applications are judged is actually going
to be unique for each business," Robison explained. "In my experience,
the first iteration of application rationalization involves so much
decision making: What are the criteria for evaluating applications?
How do we decide what's an important application? You don't really
need a tool. A tool can't be helpful in that because that's a decision
that has to be made by a group of people."
Tedious as the early stages of application rationalization may be, it
begins to pay dividends in clearing the way for SOA projects, the
analyst said.
"It really is a prerequisite for Service Oriented Architecture," he
said. "An enterprise that has a bloated portfolio of applications with
no real firm grasp of which ones are truly important to the business,
and which ones really fit well into the IT architecture, if they try
to implement SOA, they'll really spin their wheels."
Robison said enterprise architects are ideal candidates for joining
the committee working on application rationalization because the work
done in weeding out applications will pay dividends in SOA
implementations. As the application rationalization process
progresses, an SOA architect participating in it will begin to
identify the functionalities that can be exposed as services, he said.
"If you have hundreds of redundant applications," Robison said, "which
application's functionality do you expose? Application rationalization
helps you sort that out. You're saying: 'This application offers all
of this functionality, or currently only uses this portion of it.
We've got overlapping functionality in these applications.' That type
of information could be very helpful. You're producing artifacts and
information that could be very useful to a SOA implementation.">>
You can find this at:
<http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1209346,00.html?track=NL-110&ad=560865&asrc=EM_NNL_437038&uid=5532089>
Gervas
