Old Code Meets New Ideas in Latest App Modernization Projects

March 15, 2010 Dan Burger

The heat is on. For all the talk about IT integration and innovation, words that get casually tossed around as if saying them was doing something, there is progress being made in the area of application modernization. The time for talk is turning into the time for action in the IBM AS/400 community, which IBM has renamed the iSeries, the System i, and now just IBM i. The lower case i, IBM used to be fond of saying, is for integration and innovation.

Integration and innovation don’t come easy, despite all the promises that say they will. However, advancements in IT, specifically in the area of application modernization, have changed the landscape considerably in the past few years. Part of this has to do with software development, or what the vendors like to call solutions. Another major factor is that companies have done some testing, learned a few things about the modernization process, and are beginning to make real strategies for how it can be accomplished with goals and objectives that take into account entire enterprises rather than random quick fixes. Application modernization projects are meeting business challenges. This isn’t a tidal wave of change, but the tide is changing. Considerable investments of time and money are being noticed. Integration is a trend, which is different than a fad. It fits the “must have” criteria, not the “nice to have” criteria. And integration is innovation.

The biggest reasons it has taken so long to gain some semblance of momentum for application modernization projects are attributable to the enormity of the integration puzzle and a wounded economy that kept a lid on investing.

Legacy applications are the focal point of IT modernization planning and business process management that includes consideration of areas such as new application development, Web apps, composite apps, and database modernization as part of the picture in a growing number of projects. In most instances, the quickest, easiest, and least expensive projects tend to be the launching pad. Some projects don’t go any farther than the launching pad, however, and although some barriers to integration may have been eliminated, the problems of complexity, high maintenance, and limited functionality remain unsolved.

“A lot of people are dealing with old code and they have new ideas,” says Eric Figura, the director of sales and marketing at Business Computer Design. “New Web application development is one topic. Compared to just a few years ago, we see more companies wanting to develop new apps that access new databases, but also tying that into existing code, existing logic.”

Figura also noted an increased interest in accessing data on multiple platforms and a desire to break away from proprietary solutions. His best guess is that approximately 25 percent of the companies BCD talks with have a non-proprietary system as a goal.

Some folks would jump to the conclusion that companies with such a goal are pushing their old AS/400s out of second-story windows, but Figura refutes that notion.

“We see a lot of people making a push to keep applications on the i. We are doing proof of concepts to show why it’s wise to stay on the platform,” Figura says.

These are projects with a combination of new application development and modernization of selected existing applications. The selection process examines the inventory of applications, determining which are most critical and which are of low technical quality–meaning they under-perform and require high maintenance. Figura describes them as “big retrofit projects,” and says they are often being undertaken by organizations that have some experience in the application modernization area. Their experiences, however, have not necessarily been good.

“In some cases they were just not getting where they wanted to go,” he says. “They are frustrated.”

Some of this is due, Figura says, to beginning the modernization process “in a hodge-podge fashion without a good structure. Some things being done on the network, some things being done on the i. They don’t have a clear, cohesive plan. Some do, but some don’t.”

The changing face of application modernization projects with more emphasis on integration is also noted by Steve Gapp, president and CEO at LANSA.

“Some of the projects we take on are larger and meatier in terms of customer expectations,” he says. “Those projects have a strong business focus to them. They are not doing modernization because they anticipate a new GUI, they are doing it because they have a defined objective of improving an area of business. That’s a business process improvement or a new form of workflow.”

More multi-platform plans are evident in Gapp’s view as well. They extend beyond modernizing green-screen applications, and they also involve other applications and data that results in new composite applications that include Web pages, images, and additional features that become part of the modernization layers.

“It used to require a lot of programming and lines of code to do the integrating,” Gapp explains. “Now you find wizard-driven processes for integrating documents into business transactions. If you need to store an order confirmation with the order DB2 record, that’s easy to do as part of a modernization. If you use document management as an example–and that is the company goal of improved processes–you can do that in a fraction of the time it took two years ago, when it would have taken more developer effort.”

Because of the reduction in developer time for certain process improvements, overall project costs may be decreased. But don’t count on it, because other factors come into play.

“The cost of the project has become less, but not necessarily the cost of the component software,” Gapp says. “If it was a one-year project two years ago, it may be a six-month project today because there is more capability out of the box. What happens in the real world, however, is that the requirements have gone up significantly. So even though you can complete tasks faster, there is typically more to do. The bar is raised. Things that weren’t expected a couple of years ago are expected now.”

Expectations for better tools with better functionality are also higher.

“A common reason for customers failing with modernization projects is the tools can be unnecessarily complex,” says Marcus Dee, managing director at looksoftware, who also believes that “some simple modernization tools don’t deliver much value due to limited functionality.”

The combination of high complexity and limited functionality result in unsatisfactory results and much frustration.

“Complexity is commonly regarded as IT’s biggest challenge and the most common reason for IT project failure,” Dee says. “Everything we can do as software developers to reduce complexity has a significant impact on project success, cost reduction, and improved performance.”

Simple refacing of 5250 screens is widely regarded as the epitome of the low-function tool and substantial success using the “make it look GUI” approach is not common. The functionality that Dee and the other vendors point to as integral to success involves the integration of 5250 data with applications such as the ubiquitous Microsoft Office productivity suite that includes Excel, Word, and Outlook, as well as Lotus Notes. The big picture view of app modernization has integrating workflow as a priority, too.

Tool maturity is a big part of the increased interest in modernization, Dee says. “Without mature tooling, manually creating services-driven, back-end projects were very difficult and beyond most i shops.

Alex Roytman, president of Profound Logic, thinks that about one out of every four companies he’s worked with on application modernization projects have tried some method of modernization without satisfaction. And Roytman frequently hears comments about how organizations describe themselves as being stuck in maintenance mode with barely enough time for other projects. Yet business is picking up and Roytman attributes it, to a large degree, to the advancements in application modernization tools that have added functionality and reduced the labor intensiveness of these projects.

Philip Roestamadji, Profound’s marketing director, says that in many cases companies have ideas about app modernization projects that are adversely flavored by technology that is no longer current.

“If they have not undertaken something specifically, they have a preconceived notion that is based on a product like HATS or WebFacing or another tool that they’ve dabbled around with,” says Roestamadji. “They may not have undertaken a project, but they have some idea of what a tool should be and what it is they are trying to accomplish. They are looking at tool capabilities, but sometimes are unaware of what the capabilities are because the tool they are familiar with was limited in functionality. Now they see newer solutions and they see new functionality.”

Beyond the issue of tool functionality there remains another source of frustration. It’s the state of the applications that require modernization. Some of these are horrific. Not only do they involve a great deal of work to put them in order before the modernization process can be brought to bear, but they are often the poster applications for two great misconceptions. The first is that modern code cannot be written in RPG and the second is that RPG is the only code that qualifies for legacy status.

Roytman says companies can be divided into categories based on how their code was maintained and these categories define the difficulty of the modernization project. “Some have existing code that is really old and not maintained and never modularized. Some code is pretty good. The capability of RPG is not what’s at fault. RPG is still one of the best business languages available. It’s just that some of the code has not been put together well or in a modern way. The concepts of modular organization have been around for 15 years or so. Anyone who has taken advantage of that probably has good code. Almost no one wants to throw away code and start from scratch. All the business rules that have been put into the system over a decade or two is valuable. Starting from scratch is not the best way to modernize, but there are times when things are so bad that it makes sense, but they are rare.”

As an example of non-RPG code that qualifies as legacy, Roytman cites a company that Profound is working with that is throwing away Microsoft ASP applications because they consider it legacy and it was written 10 or 15 years ago. They are rebuilding it with RPG.

As much as anything, IBM i shops are looking for innovation to lead to integration, which then leads to more innovation. Application modernization projects have, in the past, had a tendency to splinter and lose focus. To achieve real success in the big picture of improved business processes requires excellent project management with an eye toward meeting objectives such as improved integration, increased functionality, better performance, reduced application maintenance, and a high degree of reliability and scalability.

If legacy applications didn’t fall short in at least one or probably multiple categories, companies wouldn’t have application modernization on their minds. But it’s also true that in 99 percent of the situations, modernization is a better choice–a wiser investment–than replacing entire systems and starting from scratch. The existence of tired old applications is not automatically the death knell for a given platform, be it the IBM i or any other system that has been doing its job for 10 years or more.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search