4 Scenarios for replacing your core RPG applications


In their ICT landscape many companies have an iSeries server with one or more RPG applications running on it. RPG applications are often characterized as “black-green” screens systems. In other words, the look-and-feel is not of this time anymore. And that makes perfect sense, because RPG applications were originally setup in the eighties and nineties when graphical user interface were all character based and Windows did not exist.

By Frank Wijnhout, Principal Solutions Architect

Besides that, RPG applications are not suitable for mobile devices and difficult to apply in modern technologies, like PAAS, SAAS and DAAS. And that is also not a strange thing: These technologies did not exist at the time RPG emerged.

Another growing problem is that RPG developers are becoming scarce. Young developers do not learn this language at school and are not very attracted to it. They are more interested in C#, Java, Angular or React. So, the group of RPG developers is getting smaller and older on average.

For all these reasons many companies wish to replace their RPG applications with new ones. But this seems much easier said than done. Replacing a large application which had been working well for decades frightens companies a lot and therefore replacement is postponed many times. Companies are afraid that a replacement project can jeopardize their business. Will the new application be as good as the old one? What will it do with our time to market?

But also in terms of organization there are great question marks. Is the company capable of successfully handle such a large project? Is there enough support base in the company for replacing the application?

And then there is the technology question: What is the right direction for the company in terms of technology? It is quite easy to drown in all the possible choices available. Think of terms like: mobile, cloud, low-code, online, offline, on premise, SAAS, PAAS, DAAS, micro services, security, and so on.

Decision making and technology

Taking responsibility of all choices in replacing an RPG application is very difficult. How do you know what is the right direction and is there a right direction? Result of this is that the replacement is postponed over and over again. There are many examples where this process takes more than 15(!) years. And in such a long time stretch, technologies change faster and faster, and the decisions to make change a lot and become even more difficult. But what is the way out of this vicious circle? Though many technologies tend to give solutions to a part of the technological question marks, they do not really take companies by the hand with replacing their current application.

But should technology be so important to companies? The answer is simple: no, of course not. Companies need functionality to run their business. The only purpose of technology is to support the functionality. And the following is certain: both technology and functionality will need changes in the nearby future. In what directions these changes will take place, is hard to predict.

Though new technologies have a lot of new possibilities, one problem they still have: changes in technology ask for changes in or rebuild of functionality. And that makes the choice of technology so important, while it shouldn’t be so. When companies with RPG applications only had to make functional and methodological choices for their new solution, then most companies would have already replaced their current application.

Separation of functionality and technology

The Thinkwise platform solves the technology problem. In the platform technology and functionality are split up very naturally. In a software building process the project team takes care of defining functionality in models, while the Thinkwise company makes sure the technology which interpretates the models is always up-to-date with the newest technological developments.
The consequence is that technology choices become way less important for companies. They can focus on business functionality, exactly how it is supposed to be.

Strategies for replacing RPG applications

Replacing a core application which served the company well for decades has a great impact on the organization. It is time consuming, it is a risk, and the organization probably has never done it before. So how can organizations do this with the Thinkwise Platform? What is the strategy?
Thinkwise has four different strategies or scenarios for companies with a core system built with RPG:

  1. full one-on-one upcycle
  2. full rebuild
  3. phased replacement of modules
  4. phased build of new modules, core remains the same

 

Full one on one upcycle

With a full one-on-one upcycle the data model structure of the RPG application is imported in the Thinkwise platform. After some automated Thinkwise-enrichments, you instantly have an application consisting of a database, service-tier and GUI. The project will mainly focus on refining the datamodel, rebuilding business logic and modeling the GUI where needed.

Advantages:

  • Very fast development
  • Hardly any scope creep
  • Functionality stays the same
  • Technical legacy removed

Disadvantages:

  • Functional legacy is moved to the new system.

When to use:

  • When functional legacy is low and technical legacy is high.

 

Full rebuild

A full one-on-one rebuild means that the application is built from scratch with the Thinkwise Platform. The RPG application serves solely as source to define the requirements.

Advantages:

  • Fast development,
  • Funcional legacy is removed,
  • Technical legacy is removed.

Disadvantages:

  • Needs more effort than one-on-one upcycle.
  • More risk on scope creep.

When to use:

  • When functional legacy is high and technical legacy is high.

 

Phased replacement of modules

When replacing the core RPG application at once is too risky, or would take too much time, companies can choose to replace one module at a time. This means that the old and new application need an interface to communicate with each other.

Advantages:

  • Replacement of the core application is very controlled.

Disadvantages:

  • Instead of building functionality, interfaces to the old system need to be created/changed,
  • Legacy in the core system should be taken into account in the new application. This could give challenges when the structure of the new application is very different from the old application.

When to use:

  • When the core application is too big to replace at once.

 

Phased build of new modules, core remains the same

In this scenario the RPG application is not removed. Only the modules that need replacement are built with the Thinkwise Platform. This can be done by a partial upcycle, or rebuild of the module. It is also possible to create a new module, which doesn’t exists in the RPG application.

Advantages:

  • Only modules which need functional of technical replacement are build.

Disadvantages:

  • Functional legacy of the core remains,
  • Many interface to the core system need to be built and maintained.

When to use:

  • When only parts of the application need modernization,
  • When the core has low functional legacy,
  • When the technical legacy of the core is not an issue.

 

Interfaces on RPG applications

Phased build of modules need interfacing. To make sure these interfaces are secure and maintainable and comply to modern technology, Thinkwise offers a rather simple architecture which can be setup very fast:

The Thinkwise Interface Application is created with the Thinkwise Platform. In the DB2 database views are defined which collect data from the RPG database. The data from these views are published by the Indicium Service tier. Besides views, there can be stored procedures which do actions on the DB2 database in the RPG application. It is also possible that the stored procedures do calls to RPG functionality. The Indicium service tier is generated automatically by the Thinkwise Platform and needs no programming. This is a simple way to create a service tier on an RPG application.

The Thinkwise application connects to the Thinkwise Interface application from its own Indicium to the Indicium of the Interface application. Of course there are methods to connect the Thinkwise Application to the RPG application, but this architecture is simple to setup and has already been used in real life.

To conclude

Decisions to replace an RPG application are difficult, but when choices of technology become less significant, the step toward a new application gets a lot easier. The Thinkwise platform takes away the technology concern and offers several scenarios for replacing RPG applications. Check out our platform overview page if you want to know more about the platform or sign up for one of the upcoming webinars.

Similar posts

Get notified of the latest Thinkwise news!

Be the first to know about new low-code development insights, inspiring customer cases and the latest Thinkwise news.

By subscribing you will receive a weekly digest of our news & blog posts!