Systems Administration

Digg This!

Page 2 of 3   « previous page   next page »

That said, let's consider each of the modernization options in turn, and its effects on the "four pillars" mentioned above - people, applications, processes, and data. As you read about each one, keep in mind not just these four pillars but also these good pieces of advice:

• Remember the meaning of modernization. IBM's definition of "modernization" is: "the enhancement, conversion, or rewriting of iSeries applications to include new technological capabilities that did not exist when the applications were originally developed." This is the target, but it must be achieved in the context of your business's specific circumstances and goals.
• Know where you are going. Consider the evolution of processes, the ease of integration, and the way people will fit into this ongoing evolution. As you develop plans for modernization, base these on a vision for the future of your business, and be certain that the new system will facilitate evolution toward that vision.
• Don't compromise. The iSeries is robust and stable - your target platform should be no less. Organizations that have "grown up" with an iSeries appreciate its safe environment of almost never-fail hardware (iSeries systems rarely crash) and resistance to hacking or security issues (few iSeries systems are hacked or become prone to virus attacks). Given that the applications running on the iSeries are the critical back-office applications of an enterprise - ERP, manufacturing and supply chain, and so forth-it is reasonable to maintain high standards for stability and security. Such solutions can be found.

REPLACE OR REWRITE APPLICATIONS
"Rip and replace" means reinventing entire applications. Enterprises that have chosen this route - typically in an attempt to duplicate applications in Java - have usually found it to be an exercise in futility. In reality, an organization that is replacing its systems is not engaging in modernization but in an expensive, time-consuming, and highly disruptive effort to create an entirely new system. This is not an entirely sensible way to approach the challenges of minimizing disruption and cost-or to take advantage of the opportunity to preserve, leverage, and enhance the investment existing on the iSeries system and related assets.

RPG/400 EMULATION
"Lift and shift" emulation leaves the application exactly as the original, nonmodern application, except that now it exists in a proprietary environment. Again, this option is not entirely sensible. It is demonstrably an expensive lateral move, and once accomplished, this sort of a platform shift is no closer than before to exploitation of modernization technologies such as Web services.

RPG/400 SCREEN SCRAPE
Screen scraping (or "Web facing") really isn't so much a method of Web-enablement as it is a look-and-feel "upgrade." It has been very popular among users seeking to make applications and data available through a graphical interface or to convert host screens to a Web-like appearance, without altering the applications or processes. The resulting Web pages are limited in functionality and cannot be enhanced. If any changes to the application are made, all of the affected screens have to be re-scraped - again, without the true benefits of Web enablement. As a result, business applications cannot evolve, and even simple modifications become risky, cumbersome, and costly.

An expensive option that rarely returns its value, screen scraping fails to leverage or enhance the organization's iSeries assets. Programmers simply pass the legacy source code through a tool that creates the output. The data, which remains on the iSeries, is not modernized in any way, and the legacy source code and applications also remain. Only the interface is modern. Screen scraping is at best a stop-gap measure; eventually, true modernization will have to be achieved through some other means.

HOST-BASED AD HOC
In a host-based "ad hoc" system, both Java and .NET are avoided. The iSeries remains central, preserving existing data assets. However, these solutions are extremely proprietary, placing the enterprise and its IT evolution at the mercy of the vendor or vendors involved with the solution. In this sense the "application" pillar is compromised, as is the "people" pillar, since the programmers will be largely dependent on an external party to maintain and enhance the system. This solution may be attractive to a small shop with a very small programming staff that would be overwhelmed by a change of platform. However, the disadvantages of this route suggest that alternatives should be explored if modernization for Web services is an eventual goal.

MIGRATION TO JAVA/C
Language converters attempt to translate RPG source code to C# or Java. It may be claimed that an RPG programmer can recognize the "ghost" of the original code, but in fact the converted code is neither native RPG nor native Java or C#. This code presents challenges for both current and future developers. It may be impossible for RPG programmers - who understand the application - to maintain. Interestingly, C# and Java programmers typically find the converted code just as un-maintainable. This is because C# and Java are object-oriented languages, whereas RPG is procedural. The translation results in an abomination to C# and Java language constructs.

RPG PLATFORM TRANSFORMATION
From the foregoing brief descriptions of modernization options, it may seem that there is no good alternative. Every option presents disadvantages that, depending on the organization's specific goals and circumstances, may be prohibitive, and often a combination of alternatives, and even of platforms, is the best solution to meet the challenges and opportunities of the enterprise's specific case. In many cases, however, a more integrated and flexible solution can be found in new tools that have emerged out of the demand for iSeries modernization.

Page 2 of 3   « previous page   next page »