What’s Really Driving Application Modernization?
- By Stephen Swoyer
- May 8, 2008
To listen to some industry analysts tell it, organizations are rushing to embrace SOA, Web services, and other application integration or application modernization technologies.
That, however, is probably too optimistic by half. In fact, some organizations don't so much rush as get dragged -- often kicking and screaming -- into modernization projects.
In many shops, IT veterans say, application modernization is a matter of last resort, embraced only when the pain of licensing, maintenance, support, or platform costs becomes too much to bear. In other enterprises, IT shops are modernizing older applications (or swapping them out entirely) to mitigate risks -- such as the pending retirement of programmers, operators, or support personnel associated with their operation.
In both cases, IT shops aren't embracing application modernization chiefly as a means to ratchet up efficiencies, streamline or reconcile business processes, or introduce new (and potentially profitable) services. They're mostly looking to cut costs.
"There are two different paradigms where legacy modernization is not necessarily [done as a means to] adopt SOA, or to [transition] to a new platform. It's done for other reasons, cost being one of them," says Vivek Mehra, vice president of global financial services with Keane Inc., a $1 billion consulting and integration firm based in San Ramon, Calif.
"[Modernization] is mostly [driven] from a cost-reduction perspective, and often from operational risk reasons as well," Mehra continues. In the "legacy" application space -- and the government, insurance, and financial services segments are rife with such applications or platforms -- the latter issue is particularly pressing, he indicates.
"If you have legacy platforms where the code is 40 years old and the knowledge isn't documented, there's a definite risk there. What happens when these [IT pros] retire? Sometimes the answer is simply training more people and transferring [to] several people the knowledge that the incumbents have and making sure that there's a next-generation workforce ready to continue."
Mehra says the decision to modernize an application or to replace it entirely is often based on a sliding scale of costs versus benefits. In other words, he stresses, the ROI case for moving to a new system is relatively simple: the cost of doing so (projected over the course of several years) is cheaper than that of maintaining the status quo. Alternately, there's the incalculable cost of not modernizing and then being left high and dry. Imagine trying to support poorly documented application code once key knowledge holders retire and you get the idea.
"If you can forecast your earnings and your growth early in the year -- and a lot of these companies can do just that -- there's very little impetus for them to modernize just for reasons of niggling costs. There's got to be a lot of pain there," he comments.
"The one recurring theme is the high level of operational risk, what's going to happen to a system if it's going to be orphaned suddenly. That's a major driver for a lot of these companies."