You are currently on IBM Systems Media’s archival website. Click here to view our new website.

IBM i > TRENDS > WHAT'S NEW

An RPG Manifesto for BPM


In this fourth article in our series on business process management (BPM), I’m proposing some essential principles owners of legacy RPG applications must adopt 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?

This manifesto will break down 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, etc.). 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’re certainly advisable.

Goals of Modern Applications

Let’s start with a recap of what a modern application should deliver and what BPM provides:

  • 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 by a large portion of the Fortune 500 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’s implemented. This first point is simply to establish a clear mindset about RPG. I’ve heard 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 of the RPG code in the world is not well designed and doesn’t meet contemporary standards of software engineering. There’s no reason RPG can’t 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 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 isn’t suited to BPM Notation specifications 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 capability 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: first, the workflow sequence, users and layouts of forms may be quickly changed at any time as business needs dictate, and second, it offers 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 1) events that trigger processes, 2) forms presented to users, 3) calls to services such as business rules and 4) 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 and even program calls. In a BPM application, state is managed and held in the BPM engine. Data 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 two to three 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 won’t 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.

Let me provide three examples:

  1. The Web-facing capability for green screens can allow the presentation of new user forms, in new workflow sequences, at any point in a project
  2. Creating integration services that present a consistent database interface between old and new systems can hide underlying database restructuring
  3. Packaging existing RPG code as business rule services wrapped in SQL stored procedures can be an interim step toward 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 in this article, RPG can fully participate in a truly modern, and amazing, computing environment for years to come.

Steve Kilner is the creator of several software products and methodologies for the IBM i world. He writes a regular blog (http://www.vlegaci.com/). Steve can be reached at skilner@vlegaci.com.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

It’s Technical, Dear Watson

The “Jeopardy!” playing computer’s feeds and speeds

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters