Way back in the early 1980s, when I worked for IBM, I used to teach a class in application design concepts for the System/38 (the precursor to the IBM i). In that class I taught programmers that, for performance reasons, they should write big monolithic programs that comprised all the steps of an entire business process. I taught that the calling overhead on the System/38 was too high for writing lots of small programs. Unfortunately, that approach led to the situation today in which many IBM i applications have programs that are thousands or even tens of thousands of lines long. The interface, the program, and the database are all tightly intertwined. Unfortunately, big monolithic programs with chatty interfaces between the UI, the program logic, and the data can be extremely difficult to modernize. So, the first step in modernization is to break down those systems into individual parts.
By breaking your application down into its component parts, you can constantly move parts of the application forward and into new technology as necessary. Having a componentized architecture will ensure that you will never be “stuck” in an old technology and you will be able to take advantage of whatever changes come down the road in the coming years.
Moving to componentized architecture does not mean you need to immediately rewrite all of your RPG or COBOL programs. Those programs are proven, dependable and have evolved over decades to support your unique business requirements. The best way to start modernizing is to leverage your existing codebase to support a modern user experience. The first step in componentization is to separate the UI from the program logic and data. Fortunately, that tends to be the easiest thing to do and provides the most visible improvement for your end users.
There is a wide variety of tools and technologies available for the IBM i that can help simplify this process. The IBM i supports modern development languages like Python, Java, PHP and JavaScript. It supports server JavaScript languages like Node.js and Client frameworks like Angular and React. However, you need a connection framework to tie that new technology to your existing code. It’s important that the people developing in the new open source technology can connect to your existing IBM i resources via techniques designed for their environment and with which they are familiar. That’s where RESTful web services come in. By exposing your IBM i resources via web services, non-IBM i developers can access IBM i resources using standard RESTful calls.
Fortunately, creating access paths via REST is not difficult and there are tools available to automate the process. Using these tools, you can create REST access via direct database connections, program, procedure and command calls or you can even create REST services that mimic accessing your application through the existing green screen interface.
Once you have those REST access paths, you can take advantage of the productivity offered by languages like JavaScript. Our staff at Eradani worked with a client that wanted to create a responsive web UI for an existing green screen application. Because of the productivity offered by Node.js and Angular, we were able to create a working version of the new UI that accessed the IBM i application via web services in just a few days. The original green screen UI had taken their team months to build.
As you move forward, you will be able to reuse those web services to take advantage of new technology and support new business processes. And, since the UI is talking to your programs via web services, you can update those programs with whatever technology you choose without impacting the UI (as long as the new technology supports REST web services).
If you would like to further explore your options for creating these REST connections for your applications, contact us about our Modernization on-demand webinar.
