[TABLE]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.
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:
Where do these options work well and where don't they? Potential advantages and issues for each option are listed below.
[TABLE]
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
To continue reading for free, register below or login
To read more you must become a member of Search400.com
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:
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:
Better-known examples of EOS include
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 Search400.com looking for ideas from others as well. My key lessons learned over 25 years of modernizing System i applications include the following:
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:
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.
Taking the next steps
Leverage your resources to find more examples on application modernization.
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 jemason@ebt-now.com.
