Executing RPG: Pull The Plug, Kilner Says

April 28, 2014 Dan Burger

Steve Kilner has been down nine miles of ugly road and he’s seen enough. If you’ve ever looked at 20-year-old, monolithic RPG code with the thought in mind that this code can serve another five or 10 years, it’s likely you’ve seen enough, too. It’s time for assessment, Kilner believes, and his assessment is that a lot of high maintenance RPG is beyond saving, beyond modernizing, and is unmistakably ill-equipped for the modern age of business computing.

This begins with a question of quality code and Kilner is talking about code that possesses inert amounts of quality. It’s so convoluted that even the best of RPG coders get tied in knots trying to sort it out and software designed to sort through this tangled web pulls off to the side of the road suffering from vapor lock. The time and expense to separate the wheat from the chaff is not worth the end result. “What you get for your efforts,” Kilner says, “is better code–it’s modernized and modularized–but it is not the right choice for businesses going forward.”

Last week, Kilner published a white paper with the title: AS/400 and RPG: Too Old for a New Age of Business. The subtitle is Why BPM is the Right Choice for Re-engineering. The reaction of RPG programmers to this idea is probably comparable to that of a cat if you’ve ever tried to give one a bath.

BPM is business process management. Some folks know this as the integration piece that is used to join existing disparate systems with the goal of improving business workflows. But there is a much bigger picture in which BPM is a scalable platform that hosts heterogeneous software, user interfaces, and connections. It is made for agile development, process visibility, and user collaboration.

Kilner, who has developed RPG code-analysis tools for preserving the value of complex legacy applications on IBM’s midrange systems, sees eliminating the mystery in business processes as one of the key features of BPM. It does this by making the system logic and the work process both visible and understandable to business users and, therefore, it bridges the traditional disconnect between IT and business users and business managers.

Improved workflow is the ultimate objective, and Kilner says BPM goes beyond handling transactional data by adding the capability for business users to analyze process metrics and recommend changes to improve results. Because BPM is visual, whereas code is not visual to the business user unfamiliar with RPG (or Java or .NET), those who are best at analyzing workflow can see the path a transaction takes, including who has worked with the data, when it was accesses, how long the application was used, if there were exceptions, and when work is delayed.

The chief role of IT has always been to increase productivity. The biggest challenge has been to get IT and the business people better aligned. Speaking different languages was not conducive to the alignment goal and achieving consistent results on an organization-wide basis was seldom achieved. Personnel changes during the lifetime an application, for instance, is one reason the code in large applications is so difficult to re-engineer to get the productivity gains that are built in to modern systems. Today’s process experts are stymied by applications that are flatteringly referred to as puzzling and not so flatteringly referred to as blankety-blank obstructions to progress.

Establishing a meaningful collaboration between the business process experts and the application developers is distinction that moves BPM ahead of traditional methods, Kilner says.

Co-development of applications takes a leap forward due in large part to the visualization features in BPM, which contributes to the speed at which innovation can occur. If it sounds like magic, it’s not. In real life, there are no just-add-money guarantees. Ideas still need to be tested and actually proved under fully scaled, mission-critical condition before they wear the crown of success.

As Kilner points out, the conundrum of what to do with legacy code is one of balancing cost and risk.

“The workflow logic and business rule logic is typically monolithic, neurotically coupled, and hopelessly tangled,” he says. “There is no tool on the planet that can fix this for legacy applications in RPG or any other language. Fixing it requires making sense of code whose purpose has often become undiscernible if not meaningless, and then rewriting the code. Rewriting the code means a complete testing of the code. This is a huge undertaking. If a company spends the kind of money necessary to do this, should it really be rewriting in RPG?”

You can safely assume that Kilner’s question is rhetorical. While modernizing RPG is an improvement of no small magnitude when it achieves meaningful goals–such as reducing application maintenance through simplification of code and attaining modularity through the use of subroutines and procedures–it falls short in areas that Kilner believes are critical. The criticism is directed at the lack of tools rather than the language itself.

He identifies “program slicing” as one of the deficiencies. This is the capability to extract relevant portions of large programs. Also lacking is the capability to analyze paths through programs with the exception of diagraming subroutines and procedures. Adding to the inadequacy is the absence of a tool to parse out complex IF/ELSE structures, or for analyzing variable scope, or doing cross-program analysis.

“From a daily, ground-level, practical point of view, these are critical problems for the analyzability of RPG software,” Kilner says. “There are third-party tools that address a subset of these concerns, but they only go so far and have obtained limited distribution.”

An IT staff that spends 40 percent to 60 percent of its labor attempting to understand existing code in hopes that it can be modified is not a staff that can devote time to learning new technologies that promote innovation.

Staffing and training are important issues. Kilner says RPG developers, because of their business knowledge (compared to developers with knowledge on the presentation side), are valuable in a transition to BPM.

It so happens that the chief architect of IBM’s BPM tools is a former IBM i architect by the name of Phil Coulthard. His familiarity with the IBM i platform and the RPG application development tooling runs deep. And although IBM BPM does not run on the IBM i platform, he believes there are many shops that would find good business reasons to move their applications to BPM while retaining the DB2 for i database platform.

(Kilner interviewed Coulthard for an article that appeared in IBM Systems Magazine. You can read that article here.)

IBM has more than 5,500 BPM customers and claims 64 percent of the market. The majority of this business is at the enterprise (large user group) level; however, IBM offers a version for mid-market companies with a smaller price that is not packaged with high availability and has user limits. The least expensive BPM software will start in six-digit country.

But Kilner plainly says that companies that are facing a future that requires something to be done with applications that are stuck in the past are going to invest a lot no matter if they modernize, rewrite, or re-engineer. There’s no cheap and easy solution to the problem. Replacing the system is not inexpensive. Investing in RPG brings with it the dilemma of an aging workforce. If there’s a clock ticking on existing systems, it’s the one that tells you business needs are no longer being met.

And for the record, Gartner projects an annual compound growth in the BPM market at 22 percent through 2019.

The link to Kilner’s white paper can be found at www.vlegaci.com.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search