[TABLE]For many IT shops, the first and biggest hurdle is convincing the holders of the purse strings that application modernization is worth the time, effort and dollars. In other instances, it may be that the IT department members themselves need convincing. These two distinct groups each come to the issue with different biases and motives, so they have to be examined and convinced separately. Here we'll address them in reverse order, because if the IT staff doesn't see the need for app modernization, they aren't likely to do a good job selling it or handling the inherent challenges of this type of change.
Why application modernization is good for IT
There is a lot of pressure on any IT department, but for an iSeries shop, one long-time source of pressure has come from PC/Windows advocates. Let me preface this by saying I have nothing against applications that are built on the Windows platform and there are many instances where a Windows application is the best fit. At the same time, iSeries has always been one of the most, if not the most, reliable computing platforms available. That reliability, coupled with the wealth of solid business applications that have been developed on System i, makes it an excellent choice when deciding which platform to use for mission-critical applications.
While anyone familiar with the AS/400 knows it's a great choice for running important business processes, there is the impression that because the application runs on that "green screen thing," the application is out-of-date and should be replaced by something cooler and sexier, like a nice Windows-GUI application.
Making IBM i applications appear more "Windows-like" is a good thing because all most users really care about is how the application appears on their desktops and whether they can interact with it more like they do when they are using Word, Excel or their personal finance software. The users aren't going to know or care if the backend d
To continue reading for free, register below or login
To read more you must become a member of Search400.com
atabase is the super-reliable DB2, Microsoft SQL or some other database engine.
Another reason that AS/400 professionals should care about app modernization is self-preservation. While you don't have to become an expert at Web development or Java, it is important to understand the basics of the technology and how these technologies can fit into the bigger business application picture. It helps keep you relevant, and prevents you from appearing to be a dinosaur who only knows and cares about those old legacy applications.
The availability of RPG programmers has also become more of an issue, especially since the explosion of popularity of the Internet. True or not, many younger IT professionals look at iSeries and any iSeries-based application languages as old-fashioned and dead. In spite of the fact that RPG has continued to improve and evolve over the years to the point that RPGLE can do almost anything, including handle HTML and XML coding, there are fewer RPG programmers in the market than there were a decade ago.
I'm certainly not suggesting that those who declare that RPG is dead are correct. Far from it! But to be realistic, finding, hiring and retaining high-quality RPG professionals is more difficult than it used to be. Given that situation, app modernization makes sense because by splitting the application into smaller, more modular components based on function (presentation, database i/o, business logic) it becomes easier to let another language team handle a portion of the application maintenance, say by using HTML and Java for the presentation side of the application. Also, by modernizing and modularizing the application, it is easier for people who are newer to RPG to learn how the application works and to be able to maintain these smaller, discrete code blocks.
Learning how to modularize and reuse code is vital not only for businesses but for AS/400 IT staff as well.
Why application modernization is good for business
Business decision makers should support modernization efforts because a modernized application is going to be inherently more flexible than one that is tied to a single platform or delivery mode. Those 5250 applications are great, but there are a lot of business reasons why you may want to be able to deliver that application over the Internet. We are talking business reasons here, not just because Internet accessibility is trendy or sexy.
A modernized application has back-end database logic, core business processes and front-end user interface components all separate but still working together. An application like this can be accessed internally via the original 5250 interface, but it is equally available to a remote user or business partner using a Web browser over the Internet. When it comes to applications, accessibility and flexibility should be the primary goal.
That core business logic -- the stuff that IT staff has spent countless man-hours developing and refining -- can provide an important strategic business advantage if properly used. The logic can be more easily shared and re-used with modernized applications because that logic is no longer tied into a single-program process (or even worse, duplicated in multiple processes) but can be accessed from almost anywhere, including a brand-new, Java-based process. With a modernized application, a company does not have to pay Java (or some other language) programmers to recode core business logic for a new application that is going to be solely Web-based. This business logic can be presented as a service to be consumed by the Web process as needed.
Another important business reason for app modernization is that modernized applications are more easily maintained. Old-style, monolithic program models are filled with so much convoluted/spaghetti logic that they can be tough to work on, even for someone who is intimately familiar with the code. On the other hand, a modularized application can be updated and tested in less time and with less danger of creating unexpected ripple effects.
Case study: An example of the above situation is from a client I have been working with for several years. Originally, their primary, in-house written-and-maintained application relied on a database of just six physical files and two primary online programs. Each of the online programs was easily over 8,000 lines of code! Making changes to any of these required great courage and multiple pots of strong coffee.
As part of this client's application modernization program, the database was redesigned in two stages. For each stage, the online program was entirely replaced by many smaller modules to handle database I/O, presentation I/O, business logic functionality, etc. While a major undertaking, the benefits were both immediate and long-term.
Short-term, major improvements were provided to the users because business logic could be changed and enhanced, while only affecting a single module. Because the redesign relied on the use of both generated database I/O, presentation modules and "mainline" templates, an extremely consistent look and feel was provided to the users, and programmers could deal with smaller, easy-to-maintain program logic.
Over the long-term, these changes have made it a snap to modify business logic for some subset of the overall application, add functionality for the users and implement database changes. Additionally, this modernized application is now in the process of heading for the Internet, in this case using IBM's WebFacing Tool.
Modernized applications can give businesses the benefit of both worlds. Legacy applications remain strong and vital, supporting the core business in the same reliable manner as before. Web-based applications and application front ends can reuse the core logic with the assurance that this logic has been thoroughly tested and validated over years of development.
ABOUT THE AUTHOR: Chip Milosch is a consultant at Griffin Consulting. Chip has been in IT for over 25 years, with more than 15 years on the AS/400 and iSeries platforms. In addition, Chip trains clients on how to increase programmer productivity by using new tools. He has spoken several times at DevCon on print-related topics.
