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
Are your company executives concerned about how to maintain your core business applications when your RPG developers retire? Do users complain that their applications look old or don’t support the latest technological innovations? Do you have requirements to share data and application functions with customers and business partners but are concerned about how to do that securely? If so, you are not alone. According to the latest HelpSystems IBM i marketplace survey, three of the top four concerns of IBM i users are:
1. Security
2. Modernization
3. IBM i skills
Future Proofing Strategies
Fortunately, 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.
Mapping Out the Architecture
To support the blended application environment, you need an architecture that will allow multiple technologies to talk to each other. If you are going to add modern user interfaces or open-source modules (more on that later) using languages like JavaScript, PHP, C#, Java or Swift, you need an interface layer that supports the translation between how those languages communicate and what the IBM i requires. You want to make sure that the technology connections are loosely coupled so you can make changes on the open-source side or on the IBM i side without breaking the connection. This is why so many companies are adopting an API structure for these connections. The API layer provides the security, authentication, data transformation and routing functions for the connection. The API has a “contract” that essentially says, “If you provide me these fields of data, I will provide you with these responses.” As long as the requester provides the appropriate inputs and the host provides the appropriate response, no one needs to care whether the application code or data structures change.
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.
Enhancing your Security
Modernizing 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.
It is critical in adopting these security technologies that you are always keeping the security code up to date. This is a significant challenge if you are writing the code yourself or depending on a third party to maintain the code in an IBM i language like RPG. Thus, this is a place where you probably want to look at open-source technology. There are a wide variety of open-source modules in languages like JavaScript and Python that have already implemented the latest security capabilities. Those modules are in use by millions of users around the world and are constantly vetted by highly skilled security professionals. Importantly, if a vulnerability is found, they are updated rapidly. Most of them are available free of charge and can be easily downloaded and integrated into your environment.
To make the most of these technologies you should learn the basics of:
1. Encryption
2. JSON Web Tokens
3. OAuth
Modernization With APIs
A 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.
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.
Rather than adding new capabilities to the monolithic programs, users are writing the new functions in open-source languages like JavaScript, Python or C# and then calling those functions from their RPG or COBOL via APIs. High speed API connections can make this happen without slowing down the IBM i business process. We’ve seen IBM i users who have added e-commerce capabilities, text messaging, emails, bar code and QR code printing, scanning and many other functions just by connecting an existing, free open-source module to their IBM i code. You can also use this technique to replace existing functions in the monolithic programs with smaller, componentized open-source code. Secure, high speed APIs allow you to start breaking down your existing applications into components that will support whatever technologies the future brings.
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
2. Popular open-source languages like JavaScript and Python
3. API standards like Open API
Developing IBM i Skills
My 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.
2. Start to experiment with new languages: spend a few hours a week taking online courses in languages like Python and JavaScript. They are designed to be easy to learn and you can get up and running in creating your first programs in a very short time. Just working with these languages will reveal some of the possibilities they offer for modernizing your code. Having an understanding of what these languages are good for will make it much easier for you to guide new engineers in building functions for your application using them.
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.
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.