IT Management

Jan 19 ’10

While legacy applications may still get the job done, business continues to push for software upgrades and faster performance. IT teams have long had little or no leverage to resist these demands. Unfortunately, over the past 30 years, this attitude has spawned an archaic mess of siloed legacy applications maintained by separate staffs that many organizations can no longer afford to maintain.

Nevertheless, legacy code increases at an estimated rate of 10 percent per year. Without modernization or some kind of risk mitigation plan, this rate will eventually become impossible to support as more legacy code specialists retire, leaving little or no application documentation for their Java 2 Enterprise Edition (J2EE), Microsoft .NET, and Java-literate successors.

Despite these projections, not everyone is making a mad dash to modernize. First, there’s the issue of cost. Application modernization isn’t cheap. While many organizations want to move applications off the mainframe, they simply can’t. As mainframe power has escalated, so has the number of applications it supports; as a result, there’s just too much to move. Even if the prospect of changing platforms wasn’t so intimidating, most IT teams would probably admit to being cautious when it comes to making sweeping changes to a program because they may not know how it will impact business services.

While modernization may be a daunting, painful undertaking, most organizations prefer it to shouldering the burden of legacy application maintenance. According to two Forrester Research reports, updating key legacy applications is the top software initiative for enterprises and small and midsize businesses. Apparently, this also is the prevailing view of COBOL and mainframe heavyweights in finance and insurance, the second largest industry grouping in Forrester’s study.

Application modernization makes good economic sense: increased agility, improved interoperability, reduced risks, and lower application maintenance costs—which, for mainframe-based systems, can absorb as much as 75 percent of an organization’s development resources. However, modernizing your code doesn’t automatically secure user satisfaction. If your infrastructure has evolved into a cluster of moving parts that aren’t being holistically managed, your applications are definitely in trouble. Application and infrastructure lifecycles must be managed in tandem. If you’re making decisions about your applications based on the belief that “modernized is better,” without considering the complex connections this software has to the infrastructure, you’re putting your application performance— and business’s revenue—at risk.

Getting a New Vantage Point

You can’t effectively modernize and manage an application portfolio without understanding how these applications fit in the broader IT landscape. Nor can an application problem be immediately solved by investigating one technological layer. Often, the causes of malfunctions and poor performance are hidden deeply below the surface, intricately entangled in a multi-level labyrinth of technologies. Infrastructure problems will eventually surface. Even if they don’t instantly impact applications, they inevitably will, regardless of the level of application modernization. Being unaware of your infrastructure health puts application performance at risk and can choke business revenue.

Servers become overloaded. Networks become clogged. That’s reality. The trick is being able to identify the source of the problems before they impact the user experience. Accomplishing this requires far more than a surface-level, piecemeal understanding of your infrastructure and application portfolio. You can have good application tools for discovery and analysis, but you still might not be able to identify the cause of an application problem.

Consider two fictitious scenarios that reflect real-world problems:

• Bob Smith, IT director at Lizard Auto Co., has a superior application discovery tool. But when he experiences a performance issue that’s actually caused by a modernized code change, he has no way of detecting the cause. So, he resorts to making the rounds, talking to members of his IT team to determine where the problem originated.

2 Pages