It’s Big Picture Time for Application Development Projects

March 8, 2010 Dan Burger

Right away, application modernization sounds like a technical subject. But it really is a business topic. It’s about getting a return on investment by reusing existing assets. Those assets are applications and they need to be enabled for a business environment that has changed since those applications were born and raised. To understand application modernization, it has to be discussed in terms of business strategy, user requirements, and integration. As IBM has been fond of pointing out in the past, the “i” is for integration.

To a large degree, the short history of application modernization has been marked by a helter-skelter, shot-in-the-dark effort resulting in stubbed toes and blackened eyes. The failures seem to have gotten the best of the fight. That may seem unfair to those who have made useful modernization adjustments, but those tend to have been piecemeal projects designed to reduce specific pain points. In general, they have not been executed as part of an enterprise business strategy. If that’s calling the glass half empty, then rather than calling them failures let’s call them scattered successes. If I was a weatherman, I’d still describe what we’ve seen up until recently as mostly cloudy.

But like all who have suffered through a long and weary winter, spring is on the way.

Mike Garman, a lead analyst at Compass Management Consulting, prefers the term application rationalization over modernization because it places a greater emphasis on overall business strategy and reducing the application portfolio to a more manageable level.

The constraints to that goal are sometimes formidable. As Garman points out, legacy application maintenance costs are a burden that limits or prevents IT staff from delivering new functionality. This is particularly true because many companies have scaled back on staff. And the lack of integration with peripheral systems can be a huge impairment for a company.

From Garman’s view, applications can be grouped according to age. His categories are new, young, and mature. Anything over 10 years is considered mature. You can generally slap the “L” word, legacy, on them, unless they’ve been well maintained and updated with modern, modular development tools and languages.

“We find the more mature apps, those that have been enhanced for many years, have had the defects engineered out,” he says. “Those tend to be more stable, but are more expensive to support. The complexity is high. They are good quality, but cost more to support. The newer applications, three years and less, tend to contain more code defects. But they are less costly to support because they are written in newer technology and with newer tools.”

There’s a worthwhile cost-reduction opportunity in reducing the inventory of applications that require heavy maintenance. “Consolidating and sun setting older apps are ways to make productivity improvements in a current application portfolio,” says Garman. But the effort to do so can be considerable. So much so that it has frozen companies in their tracks.

Decision makers are confronted with whether to rip and replace or modernize the existing system.

Companies that choose to implement a new system, Garman says, often find the new applications provide, at best, 80 to 90 percent of the functionality provided by the legacy applications. Rather than lose critical functionality, the business ends up supporting two systems and growing its application portfolio. That’s an unexpected and painfully expensive lesson to learn.

The overview of new system implementations has few conclusive results.

“We don’t run into a lot of companies that have traversed the path from beginning to end,” Garman says. “Fundamentally it is pretty much the same game for the past five years. There is a trend to replace legacy systems with purchased packages such as SAP and Oracle. Purchased packages have been one of the mechanisms for reducing portfolios. But I haven’t seen an ERP system that provides all the functionality of a homegrown, highly customized, in-house system. Plus, there are always peripheral systems that need to be integrated. Homegrown and highly customized off-the-shelf systems have contributed to the propagation of legacy systems and the prolongment of them. If a system like that has been integrated in a way that tightly couples it to business processes, it’s going to be extremely difficult to remove those customized systems.”

Compass surveys and analyses are not platform specific, but Garman suspects the choice to modernize and stay on the platform is common in IBM AS/400 shops, but not unique to that platform.

“I see more people viewing this as a long and expensive initiative. People are looking at changes and going after the low-hanging fruit,” he says, referring to systems that are eliminated because moving data and functionality from one system to another is easy, not particularly costly, and can be accomplished quickly. I also see companies looking at their portfolio of applications that number in the thousands or tens of thousands and they are saying, ‘My God, how can I get my hands around this?’ They see that the portfolio needs to be rationalized and the importance of slowing down or stopping the proliferation that is going on with apps across business units.”

Improving the enterprise-wide view or maybe even taking the first look at the application portfolio has become a higher priority. For AS/400 shops this can be good and bad. For instance, when multiple business units each have a different application to do the job that one application could do for all the units, this visibility may result in a “the best app wins” scenario. If the RPG-based app is the best app, it wins. If it’s not modern RPG, it’s probably not going to win. If it has multi-platform capability, it has a better chance of winning. If it scales to enterprise levels, its survival rate improves.

In the case of three apps doing the jobs that one app could do, this can often result from a lack of information that a better tool exists. It could also result from platform prejudices.

In theory, greater visibility should lead to better decisions.

During the past few weeks, I’ve talked with several independent software vendors (ISVs) from the AS/400 (iSeries, System i, and IBM i) community about changes that have taken place in the planning and implementation processes involving application modernization. Every one of them has noticed the trend pointed out by the Compass report, which, by the way, can be obtained without charge by sending an e-mail request for the Qualitative Analysis of AD report by Michael Garman. You might mention that IT Jungle sent you, too.

From my conversations with the vendors, it’s obvious that application modernization projects are maturing and following a better business approach compared to five years ago or even two years ago. But it’s also clear this type of planning is not yet in the majority. And part of that is due to the wide range of application modernization project requirements based on a company-by-company view of what needs to be done and what is affordable.

“Two years ago, the economy was very different, and two years ago modernization might have been considered a fringe project, a departmental project,” says Steve Gapp, president of LANSA. “But now it can be a case of replacing the green-screen ERP system with a new solution and maybe a new platform, and a question of what is a more cost effective and safe way to get new business capabilities. In that case, the modernization project discussion has reached a higher echelon of the company. It’s getting boardroom approval. These are companies that say, ‘We are sticking with what we’ve got.’ This modernization strategy is going to deliver the business capabilities we need now and for at least the next couple of years. Therefore, it is a strategy. It’s not a prop to hold up a shaky system.”

Eric Figura, director of sales and marketing at Business Computer Design, says the scope of projects has broadened.

“It’s sometimes surprising that large organizations are not farther down the road with application modernization projects,” Figura notes. “But one thing that’s changed is that we see more projects now that have a combination of new application development and modernizing of some existing applications. The focus is not just Web enabling, although Web enablement is part of the package. There are more big application retrofits and we are working with companies that want to stay on the i.”

According to a Forrester Research report from mid-2009, updating “key legacy” applications was the top initiative for 64 percent of enterprises and 55 percent of small and mid-sized businesses. And more than 25 percent of enterprises and 20 percent of SMBs describe updating and modernizing key legacy applications as “very important.”

It seems the log jam of projects is breaking up based on comments by each of the vendors.

“An increase in projects moving forward can be seen in the last three months or so,” says Profound Logic‘s president, Alex Roytman. “Our typical customer is a mid size company that knows they need to modernize. They realize the benefits. Primarily it’s better application functionality for end users and improved maintainability of the legacy systems. Five years ago those simple green screens produced in HTML format impressed everyone. That doesn’t impress as many people any more. We see a trend toward richer functionality.”

The changing landscape in application modernization is also reflected in the observations of looksoftware‘s Marcus Dee, a managing director of that company.

“Modernization strategy is a fundamental ongoing requirement for IBM i customers and ISVs. It’s not the one-off tactical project it once was,” he says. “Today you need a strategy to cope with the evaluation of new technologies and implementations that can help your business, without repeatedly rewriting the core applications. Application modernization is a lot broader; it includes extending the reach of IBM i apps to front-end devices like the iPhone and the new iPad. More than half of our new customers are more interested in services based back-end modernization.”

Next week, the follow-on article in this series will continue with insights into the changes in application modernization tools, the obstacles that stand in the way, and the paths that can be taken to make progress.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search