SOA begins with application rationalization |
 |
By Rich Seeley, News Writer
09 Aug 2006 | SearchWebServices.com |
|
|
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.
|
|
|
|
|
If you have hundreds of redundant applications, which application's functionality do you expose? Application rationalization helps you sort that out.
Lyn Robison
Analyst, 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."
|
|
|
|
