Future-Proof Your IBM i Applications
A look at top IBM i concerns, and how to address them through determining best practices for modernization, security, and future planning for IBM i applications
3. IBM i skills
Future Proofing StrategiesFortunately, there are several concrete steps many IBM i companies are already taking that can both protect your company from any negative impact from these issues while ensuring your company takes advantage of all the benefits new technology offers. You can modernize your IBM i user interfaces, application code and development tools while making it easier to recruit new, talented developers to work on your systems. In addition, you can do this without the risk and expense of a major rip and replace effort to move to another platform. As a result, you can continue to benefit from the unmatched reliability, ease of use and low cost of ownership of the IBM i while future proofing your applications.
The companies that are future proofing their IBM i systems have discovered that they must learn and adopt new technologies. They are pursuing what Steve Will, the Chief Architect of IBM i calls the “blended” application strategy. Continue to use the RPG, COBOL, CL and DB2 application code you have for running your core business applications while adopting new technologies for the tasks for which they were designed. This approach allows companies to continue using the applications that have been customized over years and years to closely mirror how they do business while incrementally introducing the technology of the future. As I discuss the approaches to future proofing your applications, I’ll identify some of the technologies you might want to explore. So, let’s look at the security, modernization and IBM i skills challenges in the context of this blended strategy.
The loosely coupled API structure needs to be bidirectional. It must support calls initiated from the outside to the IBM i requesting data and/or functions and it must support calls initiated from the IBM i to other platforms to the outside world.
Figure 1. Loosely coupled, secure, bidirectional APIs make it easy to call into the IBM i to retrieve data and perform business functions while also making it easy to call out from the IBM i to other platforms and technologies. The API layer can handle all the security, endpoint routing and data transformations necessary.
Enhancing your SecurityModernizing your security infrastructure is critical whether or not you are adopting new technology for your IBM i. Modern security can protect your IBM i applications and data from attacks that originate either from outside or from inside your network (a significant percentage of attacks these days come from compromised machines on a company’s internal network).
Too many IBM i companies today are relying on what is known as “Basic Authentication.” With Basic Authentication, a user ID and password are being sent with every API call. In the IBM i world, these are often native IBM i credentials that give the user direct access to the IBM i. Every time you send these credentials across the wire, there is a danger they can be discovered. In addition, you have to store those credentials on the requester’s machine which is another vulnerability. Worse yet, the default for sending data using Basic Authentication is to transform the data using 64-bit encoding. We have encountered several IBM i shops that mistake this for encryption. 64-bit encoding simply reformats the data using a well-known algorithm. If anyone were to intercept your transmission, it would be simple for them to decode your 64-bit encoded credentials. Because of these issues, many API providers (Google, Microsoft, etc.) no longer support Basic Authentication.
The great news is that there are a wide variety of open-source modules you can use to implement the latest in security technology for your communications. You can use encrypted JSON web tokens to ensure your transmissions cannot be read, you can use third party verification technologies like OAuth to verify that the user is who they say they are and you can add multifactor authentication for an added layer of protection.
Figure 2. A JSON Web Token has three parts: The Header that says that it is a JSON Web Token and identifies the encryption method it is using, the encrypted payload (eg. who is the user and what is their role), and a signature that ensures the message has not been altered.
Figure 3. OAuth flow for 3rd Party verification. The good news is that all of the code for this is downloadable via free open-source modules!
To make the most of these technologies you should learn the basics of:
2. JSON Web Tokens
Modernization With APIsA loosely coupled API architecture can ensure that you will always be able to take advantage of the latest in User Experience and User Interface technologies. It will also allow you to modernize your code base by making it simple to add open-source modules to your RPG/COBOL code via high speed connections.
With APIs, there is no reason that your IBM i applications cannot have the latest web and mobile user interfaces. You can quickly build user interfaces to RPG and COBOL applications using modern UI frameworks like React, Angular and Vue. Those frameworks allow you to create your UI by downloading open-source UI components. If you need a drop down list, an expandable tree, the ability to export data to an Excel spreadsheet or a pdf document you can simply download the code. You can download code to display images, handle file transfers and send emails or text messages. You don’t need to write the code by hand. If you really want to avoid coding, you can use the latest in low code tools and feed them with data and functions from your IBM i.
Figure 4. When you need new application functions, you can save a lot of time and money by plugging in an open-source module rather than writing the code yourself.
Probably the biggest challenge to modernization using APIs and new languages is the monolithic nature of many IBM i programs. I’ve seen programs on the IBM i that are tens of thousands of lines long. Basically, the entire business process is encapsulated in one program. Those monolithic systems make it difficult to pull out individual functions for API enablement. That is why many IBM i users are turning to open-source languages with prebuilt modules to extend their IBM i applications.
Figure 5. You can easily download open-source modules from sites like npmjs.com. The site shows you how popular the module is and what are its license terms. Passport is a powerful authentication system that supports over 500 methods of authentication. It is downloaded over 1.5 million times a week and is available under the very permissive MIT open-source licence.
Assembling applications via prebuilt, open-source modules is the wave of the future. By API enabling your IBM i applications you can continually and rapidly add the latest capabilities to your IBM i code.
To take advantage of open-source modules, it would be helpful to learn more about:
1. Open-source package managers like YUM and NPM
3. API standards like Open API
Developing IBM i SkillsMy father, who was a serial entrepreneur, once told me that a key measure of the quality of an organization’s leadership was how the organization functioned after the leader left the scene. That lesson applies to those of us who have been in the IBM i world for many years. We have participated in building highly functional applications that have evolved to support the unique ways our companies do business. Speaking as one of the elders of the IBM i world (I’ve been working in the IBM midrange environment for over 40 years), it is time to prepare our systems for the next generation. We need to lead the adoption of the technology that will carry the platform through the coming decades. Although the young people coming up understand the latest technology, they don’t have the domain knowledge around the business processes that make our company special. That is knowledge that has been gained over decades of real-world experience and countless conversations with end users.
There are several steps we can take that will ease the integration of new technology into our existing systems and facilitate the recruiting of young engineers.
1. Componentization: As you add new functions to your IBM i applications, think about how you can add the features as callable modules rather than as additions to the existing monolithic code. Take some time to examine your existing code to find opportunities to extract functions from the monolithic program and rebuild them as callable components. To really move this initiative forward, look to see if there are open-source modules you might be able to use.
3. Adopt open-source development tools: IBM just made a big announcement regarding open-source tools and the IBM i. Their new MERLIN initiative is designed to encourage IBM i developers to adopt open-source tools like Git, Jenkins and Visual Studio Code. Young developers learn these tools in college or in coding boot camps. If you use them in your organization, it will be much easier for them to become productive. If you also convert your RPG code to free format, you will erase almost all the barriers to recruiting new developers. Young developers are used to learning new languages as long as they can use the development tools with which they are familiar.
Figure 6. Today, you can use the same powerful open-source tools that are being used by millions of developers around the world to manage your IBM i applications. Use free open developer workbenches like Visual Studio Code for editing RPG and COBOL code, open version control tools like Git, process automation tools like Jenkins and Azure Pipelines and deployment scripting engines like Ansible.
4. Get out of your comfort zone: This is perhaps the most important and maybe the most difficult step to take. Future proofing your IBM i means aggressively learning new things. Rather than waiting for a problem that requires new technology, look for opportunities in your current priorities to use the latest languages and techniques. This may seem obvious, but for too long we have made the comfortable choices. IBM in some ways has spoiled us by never requiring us to move to new technology (there are many IBM i shops out there still running System/36 code). That backwards compatibility is part of what makes the IBM i so special but it is also part of what holds us back. I worked with a company recently that was looking at two different options for API enabling their IBM i, one option was, in their words, technologically superior, better for the future of their applications, higher performance and more secure. The other option used familiar IBM i technology and was more comfortable for their developers. They chose the comfortable option even though it locked them into the older technology. I understand the short term benefit of that approach, but if we are going to future proof our systems we have to stop making those kinds of decisions.
When you combine the low cost of ownership, the ease of operations and the reliability of the IBM i with all of the new technology support coming out of the Rochester IBM i lab, you absolutely can future proof your IBM i. The IBM i can become the most valuable platform at your company. It is up to us to drive the change.
About the author
Dan Magid is an IBM Champion who has decades of experience with the IBM midrange and is a frequent speaker and writer on IBM i modernization topics.
See more by Dan Magid