Problem solve Get help with specific problems with your technologies, process and projects.

Application modernization strategies for System i

Modernization on the i is not new. Modernization used to mean moving from System/34 RPG II to System/38 RPG III and DDS. And while a few readers may still be dealing with this, for most, modernization today refers to extending existing System i applications to the Web. Here is a discussion of key drivers, options and sources for application modernization solutions on the AS/400. Including a list of 10 key lessons learned from System i application modernization projects.

Jim Mason
If you're reading this article, there's a good chance you are reviewing your options to upgrade or replace one or more existing System i applications. We'll review some key drivers, options and sources for application modernization solutions with references to different modernization projects. This includes a list of 10 key lessons learned from multiple System i application modernization projects.

Application modernization is not new. I'm sure that people started planning application modernization strategies...

the year following the launch of the first business application, The following year, there was an entire industry of vendors dedicated to helping companies modernize their applications. When I started working at IBM a long time ago, modernization meant moving from System/34 RPG II to System/38 RPG III and DDS. For System i customers, it's possible (but not likely) you may still be running an application in the System/36 environment or an old System/38 application. Today, modernization often means extending existing System i applications to the Web.

Key drivers to select a modernization strategy
Step 1 in planning for application modernization is to identify the key drivers for your specific situation. Common drivers for modernization often fall into several categories.

  1. Business operation changes impact application requirements
  2. Business needs (quality, cost, value, timeliness) are not currently effectively met
  3. Business sponsorship for an application solution has changed
  4. Vendor support changes or limitations (your vendor no longer supports your application)
  5. IT staffing changes (your last RPG II programmer just retired)
  6. New platform or technology requirements

These drivers will be a primary factor in deciding which modernization options best fit your needs.

Modernization options: Replace, rewrite, reuse
Next, decide which of the modernization options fits your needs best. For modernization, focus on the three Rs:

  1. Replace: Replace the existing application(s) by building, buying or renting a new application
  2. Rewrite: Rewrite the existing application to support new business requirements, platforms or technologies
  3. Reuse: Reuse business logic from the existing application within an upgraded application, a converted application, a new front-end application or a service wrapper.

Where do these options work well and where don't they? Potential advantages and issues for each option are listed below.

Options Advantages Issues
No work to convert, migrate existing code Need to migrate data, services
May be quick to implement Need to migrate users and business procedures
May leverage new technologies fully Purchased and rental apps may have high license and maintenance costs, customization limits
May require new infrastructure
May fit business requirements best May need to migrate staff to new technologies
May be quick to implement with the latest tools Need existing application and business knowledge to succeed
May require new infrastructure
May have least business migration impacts May need to migrate staff to new technologies
May be quick to implement with the latest tools Need existing application and business knowledge to succeed
Reuse choices include refacing, complementing, extending, componentizing and converting existing application logic May require new infrastructure
May not solve existing application problems

Modernization solution sources
Each of the sources below have successfully provided modernization solutions for different customers. But it's not easy to identify which of them will actually pay off best for your project.

Some factors that lower success rates on modernization projects, of course, belong on the customer side and apply equally to any solution direction you choose: bad expectations, poor funding, failure to get good references for similar projects other companies have done, poor project management, poor technical engineering control, etc. Whatever solution direction you choose, find a customer reference similar to you who has had success with that solution and understands the factors that were key to their success and the problems they encountered.

Beyond successful references for customers similar to you, other questions you want answered for your any solution option include:

  1. What is the quality of the service provider support for the solution?
  2. What are the expected costs for implementation, operation and retirement for the solution?
  3. What is the learning curve to be successful?
  4. What is the re-engineering required to move to this new technology or solution?
  5. Who can help migrate your application and infrastructure quickly and successfully?

IBM: IBM always has plans for how you should manage your application portfolio for development and modernization. These plans change annually as IBM rolls out new software to buy.

It would seem simple that you can always get good results by just following IBM's recommendations on modernization strategies. While many customers have done well following IBM recommendations and focusing primarily on IBM software tools, there are also many other customers who have come up short delivering on those recommendations. IBM software recommendations aren't always warmly embraced by the System i market for a variety of reasons, including high license and operating costs, high complexity and short usefulness lifespans.

Solutions that paid off for a small segment of System i customers include Enterprise Java Beans (EBJs), WebSphere MQ, IBM Service-oriented architecture (SOA) and IBM portals.

On the positive side of the ledger, IBM has had many winners for customers: RPG, i5/OS, CL, Java, DB2, HTTP server and more. Carefully evaluate the successful IBM customer references for a given solution direction and decide if you will be successful as well. For example, IBM has been trying to replace the SEU editor for over 15 years. Only recently have more than 50% of customers stopped using SEU as their primary editor -- a long time during which the market told IBM that the new options they provided didn't fit their needs.

Third-party vendors: If you run a primarily ERP-driven application portfolio from a major vendor, you will likely look to that vendor's modernization strategy and tool recommendations. In some cases those will pay off well. In other cases, I've seen customers that were prisoners of old, expensive-to-maintain tools and software that couldn't meet modern application needs or new business requirements.

Don't overlook the single-point vendors that don't provide applications, but just tools. In many cases, a single tool may make a big difference in your project.

Enterprise open source solutions: The fastest growing segment of software solutions are enterprise open source solutions (EOS), which are the corporate model for open source software.

The value proposition for EOS includes all of the following:

  • High quality open source software based on open standards
  • Software distributed without a license fee or under a dual license model
  • Enterprise-quality support from EOS providers and related service providers

Better-known examples of EOS include

  • Linux OS
  • Apache HTTP server
  • Apache Tomcat application server
  • Java
  • Eclipse IDE
  • PHP
  • MySQL database
  • IBM WebSphere Community Edition JEE application server
  • Groovy and Grails high-level Web development
  • BIRT Web reporting
  • JSPWiki, a Java based open source wiki

While relatively new in the System i marketplace, EOS has moved in to System i shops as a high-value option to traditional commercial solutions that are often proprietary, complex and expensive. IBM and other System i vendors generally don't promote EOS choices to customers. WebSphere Community Edition is an excellent, free open source JEE application server from IBM that isn't promoted by IBM Rochester.

System i consultants: There's a solid group of System i consultants available to provide services, support and training to companies trying to move quickly and effectively to modernize applications.

While consultants may be business partners who sell software for a specific vendor, some are also independent consultants who focus first on the customer's needs to drive the right solution.

Ten key lessons learned for modernization success
My lessons learned won't be the same as yours or anyone else's. Take what you want from mine and leave the rest. Also go through looking for ideas from others as well. My key lessons learned over 25 years of modernizing System i applications include the following:

  1. Identify a new key business value that can be delivered easily with modernization
  2. Find the fastest route to make your existing IT staff successful with the new solution
  3. Minimize overall risks with solutions that fully implement open standards -- many vendor solutions fail this test
  4. Keep the solution architecture simple to build, maintain and support
  5. Enterprise open source solutions often have lower risks, costs and similar time to successfully implement compared with commercial solutions.
  6. A poorly sponsored and managed project will fail regardless of the solution chosen
  7. Don't assume that moving to a new technology for tools and infrastructure can be done within the timelines you want for any single project
  8. Find the right practices for your situation, not standard best practices approaches. Look for successful references similar to what you want to accomplish for risk mitigation tips
  9. Ensure you have good engineering resources either internally or on a contract basis
  10. Beware of limitations and risks that come with System i-only solutions

Start small and use existing staff
Start small in scope. After selecting a solution direction, do an internal IT application prototype first before creating your first business solution. Get a custom, hands-on workshop to build or use the prototype with your current staff. If you are buying a new solution, get the vendor to provide the software on a trial or rental basis for in-house evaluation before you commit to a purchase or contract.

If you are building a modernized application, start simple. A Web order inquiry application done in a week or two may be a great first step to easily move from an in-house, green-screen order entry application to an improved level of customer service. Good low-cost options that fit this model include WebFacing a portion of the existing order entry application or generating a Web order inquiry application to complement the existing green-screen application.

If your team is new to Web applications and you want to build and manage the Web solution in-house, there are three major tasks to accomplish:

  1. Participating in a custom, hands-on workshop to learn how to build and deploy the Web application
  2. Setting up the Web infrastructure to support the application
  3. Building and testing the Web application

Small projects offer fast payback and rapid skills transfer
The projects listed below were all small in scope, fast to implement and included rapid skills transfer to the existing staff using a custom QuickWeb workshop. Our company has had a high rate of success on a variety of projects following that model.

  • Web-enabled order entry application: WebFaced a green-screen order entry application and deployed on System i WebSphere Express and IBM WDSC. Two-day workshop for staff and four days to build and deploy the application.
  • Web order inquiry application: A Java Web application built with IBM Rational Application Developer (RAD) tools and JavaServer Faces (JSF). Deployed on WebSphere and Tomcat. One-week workshop to train staff. Three weeks for staff to build initial application.
  • Web services order status: Simple Web services order status application built with EOS Eclipse Web Tools for System i. Called RPG program using IBM's Java toolkit program call Beans. Three-day workshop. One week to build and deploy to Tomcat on System i.
  • Web reporting for sales: Six customized Web sales reports deployed on Linux Tomcat using EOS Eclipse BIRT. Two-day workshop. One week for staff to build and deploy reports to server.
  • Web database application: A simple Web database application to manage employees, tasks and work assignments during projects built with EOS Eclipse Web Tools and Grails and deployed on Linux WebSphere Community Edition and System i Tomcat. Two-day workshop. Three days for staff to build and deploy the application.
  • Web wiki : A powerful Web wiki (EOS JSPWiki) that runs on WebSphere, Tomcat or Java server. Includes user visual page creation with embedded tables, formatting, Excel worksheets, calendars, file attachments, blogs, comments, search, event calendars, RSS support, version control, imaging, automated SQL database queries, powerful Web scripting with Groovy and Web application integration options. Implemented many times quickly. One-day custom workshop. One day for staff to implement.

Taking the next steps
Leverage your resources to find more examples on application modernization.

  1. Visit the IBM System i website to get the current IBM strategies
  2. Use regularly to search for strategies, tips and customer examples. Other expert articles will highlight different modernization tools and examples. I've done Java Web development, WebFacing and Web services articles. New articles I'm working on cover easy Web wikis, Web database and Web reporting application generation solutions for System i environments.
  3. Contact user groups, other customers and consultants as needed

ABOUT THE AUTHOR: Jim Mason has worked with ebt-now as a System i Web consultant delivering architecture, development, training (QuickWeb workshops) and support for IBM WebSphere software and enterprise open source solutions. Jim has participated in IBM beta programs for System i software. He writes articles and teaches on System i Web technologies. He also speaks at a variety of System i conferences. You can reach Jim at

This was last published in July 2008

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.