LANSA Upgrades Modernization Tool

May 15, 2007 Dan Burger

For a lot of companies, the reality of an overworked IT department doesn’t mesh well with the idea of an application modernization project. Where does the time to modernize fit into a schedule that keeps the staff humping just to do the day-to-day stuff? If you are a development tool vendor, like LANSA, you upgrade your products to improve performance and productivity so that modernization projects become less of a workforce burden.

LANSA introduced RAMP, its Rapid Application Modernization Process, in March 2006, and the product was first shipped to customers in June. RAMP was designed to be a tool for incremental modernization allowing users to choose how they want to proceed based on the amount of time the company has to devote to the project, the skills that the staff possesses, and the allotted budget.

The LANSA definition of incremental application modernization is evident in the multiple-stage approach provided by RAMP. Stage one is the screen-scraper method that presents 5250 screens in a Web browser interface. But rather than this being a dead end in terms of adding functionality (this is the case with true screen-scraped 5250 apps), RAMP allows application extensions to be built in when the time and the money are right.

Screen-scraping is a popular method for taking green screens to the Web. It’s the fastest and least expensive, but it is limited in functionality by the original 5250 application. LANSA’s RAMP framework allows the screen-scraped stage of modernization to be extended to reach stage two (increased functionality and interoperability) and stage three (replacing the old application with a new one). At some point, separation of the presentation layer from the application layer is going to be important to you. Most applications that have been screen-scraped for Web delivery and an appearance that is not traditional green screen have no way to add functionality and eventually become composite applications without relegating the screen-scraped application to the junk yard. That means the time and effort put into it has not paid off in the long run.

Although it is not necessary to accomplish the screen-scraping stage before moving to more advanced application development, it appears that most iSeries shops want to take this step first in order to get a modern interface as quickly as possible. Having data accessible through tabs, folders, and drag and drop navigation tools is a big step forward for many companies. At the same time, there’s still a familiar green-screenishness that maintains a comfort zone for many users who are familiar with the 5250 world. There are RAMP customers that skip the screen-scraping step and make composite application building the goal of their deployments right from the start.

LANSA customers are heavy-duty iSeries users. The application server in 90 percent of the instances is an iSeries application server. LANSA has been promoting and selling Web development and Web extensions for iSeries applications since 1996 when it introduced LANSA for the Web.

RAMP Upgrades

One of the features of LANSA’s Rapid Application Modernization Process upgrade is the capability to open and control multiple application framework windows at the same time. Think of this in terms of a framework window containing a new instance or a subset of the framework. It could be, for example, a specific application, a specific view of an application, or a specific business object. The capability to open and work within multiple windows (toggling back and forth) is naturally going to increase productivity.

Another improvement allows application designers to create personal favorites folders. This feature brings the convenience of creating a selection of application components containing only the most frequently used business objects. An example of how this could be put to use is when different end users have different favorite folders (order entry favorites or end-of-month favorites, for instance), which simplify navigation and usability. Think of this as a shortcut that avoids navigating through a tree to get to the information the user frequently needs.

Also a new addition to RAMP are the screen wrappers that let developers put a graphical interface that replaces one or more 5250 screens without having to analyze, rewrite, and retest the business logic. These wrappers are graphical components that provide a functional and extendable user interface without having to change the server-side code.

Don Nelson, vice president of customer support at LANSA, says the upgrades to RAMP came from customer feedback and what LANSA learned from its own internal RAMP project. There are about 50 companies with RAMP licenses and about that many more that are undergoing demos, trial installs, proof of concepts, and RAMP challenges. Some are taking on very large projects, but most start with small pilot projects.

LANSA RAMPs Its Own ERP

Nelson led a large project at LANSA that involved a LANSA-based ERP system. More than 3,800 screens were modernized. The project included customer entry processing through shipping, billing, receivables, payables, ledgers, and inventory purchasing. It took about one man-year to do it, but LANSA officials estimated the project would take 10 man-years if the goal had been to rewrite all the code.

The two people committed to the project were recent college graduates. They had some Java and C++ programming skills, but no RPG skills. Nelson did the specifications–laying out how the screen navigation should work–but very little of the scripting work, which was left to the new guys. “After they got into the project, they were able to do some of the layouts and figure out how things were working,” Nelson says.

One of the challenges Nelson finds in application modernization projects is that people are initially slow in designing a GUI application as opposed to a 5250 application. That should come as no surprise, he says, because “the navigation–the look and the feel of that application–compared to 5250 is dramatically different.”

In the LANSA ERP project that Nelson headed, they took the approach of a business object type of interface. “Instead of having a customer order-entry type of program and a customer inquiry program, we took a customer order and looked at all the things that could be done with customer orders,” he says. In other words, the layout of the system was by business function. “That can be a difficult transition for people who have not designed applications that way before,” he says. Rather than having options one through 10 that all deal with customer order processing as is typical with green-screen programming, it could be turned into one business object and then you’ve redesigned how you interface with that application.

For most projects, Nelson recommends starting with the basics. In his ERP project they started with the maintenance programs. Once they understood those applications and how to navigate them, they had better skills when they took on more complicated tasks.

Because people have few skills in that area, LANSA set up a mentoring group to help get them going. “Once they get through the beginning stages of their application,” Nelson says, “they get the concept down; they get up and running. The work itself is not complicated, not difficult. Understanding the application and taking what the users use day to day to gain efficiencies is a big thing.”