In this article I am proposing some essential principles owners of legacy RPG applications must adopt in order to realize key goals of modern business management. The fundamental goals of management being considered can be summarized as:
– Implementing business process innovation and rapid, continuous process improvement
– Increasing process throughput and effectiveness by the use of technology
How can these goals be achieved when core software systems were conceived and developed decades before these goals were thought of as fundamental to business management?
Starting with the first article in this series I described the capabilities of BPM technology. In this article, this “manifesto”, I will break it down into what needs to be done with legacy RPG applications to “modernize” them into the BPM sphere. I put “modernize” in quotes because the term has been used to mean many things, e.g., converting RPG to RPG ILE, converting the database to DDL, refacing green screens, and so on. If you accept the premise, as I do, that BPM is today’s state of the art business application platform, then none of these techniques in themselves truly modernize applications, though they are certainly advisable.
Goals of Modern Applications
Let’s start with a recap of what a modern application should deliver and what BPM does in fact provide:
• Designed for business process innovation and rapid time to market
• Greatly increases IT and business collaboration
• Provides permanent transparency and visibility of the system for both IT and business
• Contains built in governability, change management, auditability
• Presents integrated tracking and metrics to inform continuous improvement
• Allows for maximum scalability, reliability and transactional integrity
• Is presentable to any end-user interface platform
• Provides social work environment capabilities
• Facilitates integration with most cloud and site-based applications and services
These capabilities are the promise of BPM, and have been proven out by a large portion of the Fortune 500 that are using IBM’s BPM platform. What needs to be done then with legacy RPG applications to deliver these promises on the back of RPG?
The RPG BPM Manifesto
1. Differentiate between RPG as a language and how it is implemented
This first point is simply to establish a clear mindset about RPG. There is a lot of discussion about the position and future of RPG. Properly used, the language itself continues to perform well for developing business functionality. At the same time, because of the long history of RPG coding, much, if not most, of the RPG code in the world is not well-designed and does not meet contemporary standards of software engineering. There is no reason RPG cannot meet those standards, and indeed, in the right hands it does, but there is also a lot of very bad old RPG code out there. Whether that code can be refactored cost-effectively requires individual assessment, which can be assisted with complexity metrics analysis and other techniques. Whether businesses want to invest heavily in RPG refactoring or new development is also an individual question. The point here is to differentiate between the existing, somewhat woeful, old codebase and powerful modern RPG capabilities.
2. Expose business logic as callable services; reorganize the codebase around this
Business logic should be organized and isolated at the proper level of atomicity and should mirror the organization of the processes it serves and data that it represents. Such business logic is primarily of two types: business rules for validations and business rules for data transformations. Each business rule should be individually callable. Aggregations of such rules may be packaged and callable if useful. All of this allows the BPM process model to call upon these as services, when needed. It also allows the business logic to be reused and its use in the model to be quickly and easily changed in response to business needs.
3. Make business logic transparent to and under the control of the business
Not only should business rules be individually callable, they should also be as visible and understandable to the business as possible. Some of the simpler business logic may be moved from RPG into the BPM process diagram itself, by use of gateways, which makes such logic clearly visible to everyone. However, a great deal of logic is not suited to BPMN specification and requires services to be developed. The best means for making service logic visible to users is to implement it into database tables as much as possible. The business logic is therefore manifested in the form of data relationships which experienced users can look at and understand how it might affect processing. Being based in tables also gives the users the ability to make changes without IT assistance. Coding rules in RPG is essentially invisible to users and takes control, flexibility and speed away from them.
4. Remove the UI from RPG and implement it in BPM; achieve UI fluidity and transparency
UI forms and operations should be removed from RPG code and developed as BPM coaches. This achieves two important objectives: 1) the workflow sequence, users and layouts of forms may be quickly changed at any time as business needs dictate, and 2) there is complete flexibility as to the devices on which forms are presented, e.g., desktops, tablets, etc. Developing the forms in the BPM Process Designer also ensures visibility to and collaboration with users.
5. Remove workflow control from RPG and implement it in BPM; enable rapid changes of business processes
The flow of activities is comprised of events that trigger processes, forms presented to users, calls to services such as business rules, and calls to external integrated services. A key objective of BPM is that this flow can be changed easily and quickly as business needs dictate. The extent to which the flow of these activities is hardcoded in RPG is the extent to which these goals cannot be achieved. Traditional RPG practice for interactive programs is for a single program to control a sequence of screen interactions. This control should be removed from RPG and implemented in BPM processes. The same can be said for calls to external applications, for example, calls to an EDI system should be executed under the control of BPM processes rather than RPG.
6. Remove stateful requirements from code
This objective may take care of itself if the previous objectives are dealt with properly, but it’s worth stating as an important goal in itself. Traditional RPG programs essentially expected state, i.e., variable contents, to be preserved between screens, subroutines, even program calls. In a BPM application, state is managed and held in the BPM engine. Data that is necessary for services to execute must be passed into the service in some way, typically as parameters.
7. Utilize BPM capabilities to facilitate phased implementation of re-engineering projects
BPM projects are meant to be short and iterative, with deployments often targeted in 2-3 months. This is achieved by breaking down deliverables into manageable sizes. Legacy systems, however, can be very difficult to break down into smaller pieces. BPM in itself will not untangle legacy systems, however, because integration and workflow can be changed quickly, it can facilitate a series of interim integrations between old and new systems. The web-facing capability for green screens can, for example, allow the presentation of new user forms, in new workflow sequences, at any point in a project. Creating integration services that present a consistent database interface between old and new systems can hide underlying database restructuring. Packaging existing RPG code as business rule services wrapped in SQL stored procedures can be an interim step towards creating more transparent business rules the users can work with.
The Future of RPG in Service of BPM
Many developers are understandably committed to RPG as a language. As a complete application platform, however, its days are long gone. By re-engineering legacy RPG applications following the principals described in this article, RPG can fully participate in a truly modern, and amazing, computing environment for years to come.
This article originally appeared in IBM Systems Magazine.