I had the opportunity today to participate in a panel discussion on low code modernization. Specifically, our panel discussed how using low code platforms can accelerate application modernization. The exchange among the panelists and attendees was fantastic, and I will attempt to summarize the highlights of low code modernization in this post.

First, let me introduce the panel of experts for this discussion:

Each of us had a unique perspective and expertise to bring to the discussion. There was certainly no shortage of opinions on this topic among my fellow panelists! Incidentally, Tom has just published his new book, Modern Mainframe Development: COBOL, Databases, and Next-Generation Approaches. It includes a chapter on mainframe modernization strategies. His publisher, O’Reilly, has granted our readers a free, online pass to access their full catalog of resources, which includes Tom’s new book. Use this link to get 30-day access to these works. The link is good through the end of this year.

You can view the recorded panel discussion here:

Low Code Modernization Highlights

We opened by discussing the need for modernization. By all accounts, enterprises that run core business applications on the mainframe are pursuing some form of modernization. We then dove into the challenges. To successfully modernize legacy applications, you have to solve two problems:

1. Getting applications and data from the mainframe in a reliable, scalable manner.
2. Providing customers and users access to mainframe-hybrid applications through a rich front-end.

These problems are the two big pieces of the modernization puzzle. Both challenges have a myriad of solution options. There are, however, many tradeoffs in terms of cost, risk, time to develop and deploy.

Problem 1: Getting Mainframe Apps and Data

I shared with the panel and attendees a recent Gartner article, “7 Options to Modernize Legacy Systems.” The article does a great job of summarizing the modernization approaches and their tradeoffs. In my experience, few enterprises choose just one of these options. It’s far more likely to see two or even three of these approaches in use by enterprises as they modernize. Our focus, however, was on the first option: encapsulation. This is the most agile, least expensive, and lowest risk option. This approach makes legacy applications available to any external platform or application via an API. Our blog has a number of posts about using APIs for modernization, so I won’t replicate that information here. It suffices to say that APIs are a fast path to getting mainframe apps and data for modernization. APIs solve this problem very well, allowing developers and modernizers to turn their attention to the second problem.

Problem 2: Providing a Rich Front-End Experience

It’s great to have easy, scalable access to mainframe apps and data via modernization APIs, but what will consume those APIs? As Andrew pointed out, the bar is set very high in terms of user expectations. We are conditioned to find and download well-designed, easy-to-use apps from the App Store. In this Bring-Your-Own-Device world, users and customers expect simple, intuitive interactions through interfaces that provide a rich experience. Indeed, the experience we provide users is one of the largest factors in generating satisfaction and loyalty. The back-end source of data matters not to the user. The experience, on the other hand, is everything.

It’s here where we have all seen modernization projects slow to a crawl, if not cease entirely. The challenge of developing the new front-end applications is perhaps the bigger of the two modernization puzzle pieces we discussed. Tom shared an example of a company that spent 20 years trying to move mainframe functionality to a new, more user friendly platform and front-end! Who today would embark a modernization project that requires a generation to complete?

Low Code and Modernization APIs Solve These Problems

There is good news for both of the problems raised in our discussion. Organizations that need to modernize can do so quickly, easily, and at a relatively low cost. Andrew and I shared our respective pieces to the modernization puzzle:

1. The HostBridge JavaScript Engine. A JavaScript engine that runs inside CICS, zIIP-enabled, that provides a complete solution for rapidly developing and deploying reusable CICS APIs.
2. HCL Software Volt MX. A low-code platform that empowers developers, architects, and IT leaders to deliver enterprise mobile apps, fast.

The session included a brief demo of the Volt MX platform, designed to let developers build once and publish anywhere. Volt MX easily invokes HB.js-created APIs and generates applications from a single code base for any digital touchpoint.

The Q&A

One of my favorite parts of online sessions is the Q&A, because it reveals audience interest and engagement. We had some great questions, which I’ll summarize here:

• What IS low code? A low code platform, like HCL Software Volt MX, is a graphical software application development environment. It allows developers to rapidly create new applications for multiple platforms and device types from a single code base. To learn more, get a copy of the low code study HCL Software commissioned Forrester to complete.
• Where does Volt MX run? Volt MX has two components: Foundry and Iris. Foundry is the integration layer and is offered on-premise as a managed SAAS offering, or in your own cloud. Iris is installed on the developer’s machine and is the IDE for designing both native and responsive/PWA applications from a single code base.
• We use a combination of low code products today, such as RPA tools to do green screen automation. We have the ability to expose these as APIs. We also have some API tools that provide low code options for creating RESTful services for database resources along with providing a lot of ready-made connections to common systems. How does Hostbridge compliment or replace what these tools do? We see this integration pattern a lot. Something outside of the mainframe, such as a low code or RPA platforms, interact with screen-based transactions via terminal emulation and screen scraping. Screen scraping is a bad idea. Why? Nothing is more brittle than relying on the location of fields on a screen for integration. If there is a change to where data is located on the screen, the integration fails. We know of organizations using screen scraping integration to issue edicts not to change the mainframe app out of fear the integration will break. Another reason not to use screen scraping to link to mainframe apps: performance. We use integration analytics to understand how these integrations perform. It’s highly inefficient and expensive in terms of mainframe resources. Replacing screen scraping integration with RESTful APIs is a much better approach, and it’s not difficult to do.
• Can the developer’s workstation be a Mac? Yes!

I was eager that we not leave our audience wondering how to proceed with this modernization approach. HostBridge is an HCL Software business partner. Together, we can help an organization complete a modernization prototype quickly using the approach and solutions we discussed in the session. To learn more about building modernization APIs and/or developing front-end applications that invoke them using Volt MX, please use the contact information at the bottom of this page to reach out to us.