Application modernization. When referring to the AS/400, it's one of those terms that can mean many different things...
depending on who you talk to (and what solution they're selling). Therefore, let me first tell you what I'm selling, so you know what you're getting into.
On the System i, to me, application modernization means making the best use out of your existing application programs and especially your application programmers. The single largest IT asset most companies have is in the heads of their programming staff, and the only way to move into the future is to leverage that knowledge.
That being said, let me provide you with a synopsis of the state of application modernization in today's i community.
What we're modernizing
One of the hard parts of the modernization process is the fact that we're modernizing what may be one of the most efficient interfaces ever designed. Considering the fact that the IT industry was originally the data processing industry, and its primary goal was to take paper documents, input them into a computer and generate reports, the combination of RPG and green screen terminals was perhaps the most perfectly evolved solution in the business world. I remember watching trade slips from the Chicago Board Options Exchange being keyed into a System/38 by the thousands, and realizing just how powerful this technology was.
But we've moved past that, because where data entry was a specialized field with dedicated employees, in today's IT world the end-user is no longer just the data entry clerk, and with the Internet, that end user isn't even part of our company. In order to keep that user using our applications, our interface needs to be intuitive, good looking and engaging.
That does not describe the 5250.
What are the options?
I've been writing about modernization options for a long time. In my vernacular, there are three: replacing, refacing and rewriting.
Replacing involves one of two sub-options: rip and replace or migrate. As its name implies, the former is a complete removal of existing applications and replacement with a new one. While that may work for commodity software like mail systems and file servers, if you agree with me that your primary assets are the business rules you've developed over the years (and the programmers who developed them), then the chances are slim that you can find a drop-in replacement that does everything your system does today. Migration, on the other hand, has a certain appeal, especially when it's migration from platform-specific RPG and 5250 applications to platform-independent browser-ready Java code or some popular platform such as Windows .NET. Vendors exist who will sell you complete conversion utilities. My biggest caveat is that I've rarely seen a successful line-by-line conversion between two similar languages (such as C and Java), much less between completely dissimilar ones like RPG and C#. And of course, your entire programming staff is looking at a complete retraining exercise, unless you plan to replace them as well (and of course in my opinion replacing your entire programming staff is the worst possible thing you could do).
Refacing is the next option. By placing an adapter between the 5250 data stream and the browser, you can generate relatively good looking applications that emulate the 5250 experience within a browser. You can usually enhance the "out of the box" screens to look more graphical, but ultimately you're limited to the concept of the 5250 screen. While wildly popular in previous decades, this technique is slowly going out of favor. The biggest reason is probably the fact that browser interface technology, with frameworks like Dojo and YUI, and highly interactive graphical tools like Flash and Silverlight, are now so far beyond the 5250 paradigm that any sort of mechanical conversion of a 5250 data stream, no matter how sophisticated, is going to still be less than adequate. Even my product, which allows inclusion of external metadata through hidden fields and database tables, can only provide a partial transition to the new graphics.
Rewrite: This option is by far my favorite. Although the term seems a little bit drastic at first glance, it's really not that bad. It's certainly a lot less painful than replacing or migrating your software, and it positions you much better for the future.
Rewriting doesn't mean replacing
Repeat after me: "Rewriting is not replacing." The goal of rewriting is not to rewrite your applications, but to separate out the business rules that are embedded in your existing programs. How hard that will be depends on your current code. If you've spent time in recent years taking advantage of ILE concepts and modularizing your applications into called programs, modules, procedures and service programs, then a lot of your work is done already. If, however, your primary code base is still 30,000 line monolithic RPG III code (or worse!), then you will have more of an uphill battle.
Tools exist that will analyze your existing applications and even help to extract your business logic. They're not magic bullets, but they will go a long way to getting you through this most painful part of the process. But once it's done, the world becomes a lot better.
At it's simplest, encapsulation looks like this:
Basically, you're removing the business logic from the UI (or vice versa, depending on how you look at it). On the left is the monolithic BIGPROG which has both user interface and business logic, and on the right it's split up into two pieces, the UIPROG program which has the display file and the CancelOrder routine which contains the business logic.
Note that at this point, we don't really care what the syntax is. In the example above I'm using free-format RPG primarily because it takes less space in a diagram, but this could be RPG II for all you care at this point. The only issue is that the call to CancelOrder in UIPROG is a prototyped call; in earlier RPG dialects you would have to write that as a program call with a PLIST.
But the idea is the same, no matter what the syntax. The simplest rule of thumb for this exercise is that the display file is in the UI program and all database updates are in the business logic.
Where is the ROI?
Great! Now instead of one program, we've got two! Where's the return on that particular investment? Well, multiple avenues of return actually exist. The first builds on the fact that your business logic is encapsulated in callable components instead of in green-screen applications This gives you the ability to quickly expose this logic to other parts of your IT infrastructure, using everything from Web services to stored procedures. Examine the diagram below:
Unlike a replacement, your existing business rules are still in place. Unlike a migration, you still have your old green-screen programs (no costly all-or-nothing turnover; you can use dumb tubes where they still make sense). Unlike refacing, you don't have to touch your green-screen applications to make your browser applications look good; instead, you can concentrate on the business requirements for each type of user interface, whether it's a Web service interface to a trading partner or a rich client application for your CEO.
The other return on investment, though, is the fact that the business logic can continue to be maintained by your existing programming staff. Although you would love them to become skilled in the other technologies that make up your infrastructure, it's often unreasonable to expect your entire staff to become Web designers. Instead, you have a ready-made division of labor where those who are most comfortable in the RPG world can be productive members of a multi-skilled team, creating the business logic that underlies the new interfaces.
Creating a user interface
Those that know me know I won't leave this without a pitch for EGL. That's because while it's true that you can use this newly re-architected environment to build applications based on various languages such as PHP or even RPG-CGI, one of the big benefits of this approach is that it positions you to take advantage of 4GL approaches and particularly EGL.
With EGL, you can easily create library functions which call your newly encapsulated business logic. Those functions can in turn communicate with your EGL user interface handlers using the EGL Record concept. It's simple to drag and drop to create browser-based systems, AJAX applications, Web 2.0 interfaces and sophisticated mashups, all using the same business logic that powers your green screens.
Note that you may still have some funky RPG III code in your business logic servers. That's okay; if it does the job, there's no immediate reason to rewrite it, and that's one of the real benefits of this approach. At the same time, since it's just a called routine, the next time you need to do any real surgery on it, you can just open it up and rewrite it to your new corporate standards, and none of the callers will be the wiser -- in fact, as long as you leave the parameters the same, none of your other programs need to be touched.
And that is the real return on this investment -- separation of layers, hiding of complexity, leading to development that concentrates on business problems, not technical ones.
ABOUT THE AUTHOR: Joe Pluta is the founder and chief architect of Pluta Brothers Design Inc. Joe uses the Rational tool suite extensively, and is on the beta teams for most of its i-related products. He performs onsite mentoring and speaks at user groups around the country. He also blogs on EGL and i at the EGL Café. Joe can be reached at firstname.lastname@example.org.