According to Everest Group, “roughly 35% percent of business applications, which run on mainframes or similar systems, force users to access applications through what is known as 3270 or 5250 emulations, sometimes known as “green screen”. In some industries with higher technical debt, this share is higher. For instance, when we examined the record-keeping systems for the leading ten firms in the US, we found 8 of the 10 firms running these applications on mainframe systems.”
Maintenance of these applications can be complex as many are fragile and few businesses want to extend their capabilities with Application Programming Interfaces (API) even though advancements in the operating systems on these platforms now facilitate this using high-level programming languages, such as Java. This results in one of three options for business: automate the interaction with these systems through the use of keyboard and mouse emulation via robotic process automation (RPA) tools, refactor/re-platform/redevelop on a modern application platform, or automate with RPA to create an API, which then can assist in the refactoring efforts.
Keystroke and mouse emulation or “Screen scraping” has been available for many years and is a great option. Now that this capability is incorporated into RPA tools, business users can develop complex logic for purposes of navigation, analysis, and decision-making as part of the flow. Moreover, users can use simpler user interfaces to capture input, such as HTML forms or spreadsheets, and then automate the manipulation of the “green screen” applications via a bot.
Once the user has created the bot that automates the steps necessary to navigate, read and update the mainframe application, it can operate in both attended—executed with the user watching—or unattended mode. Bots can also be executed via an API. This is an interesting option for businesses as it forms the foundation for IT to move toward refactoring. In programming, this is commonly known as the “choker” pattern. As the bot now uses an alternative means of capturing input to the mainframe application, IT can migrate the existing mainframe application or start to redevelop it on a more modern platform (see Figure 1 below). When completed, the bot can be modified to send its input to the new platform, thus sunsetting the use of the mainframe application.
Figure 1: Use of choker pattern to modernize over time Figure 1 illustrates the modernization approach over time. In the middle row, the user is using an HTML form to provide input to the bot that is automating existing mainframe applications using a keyboard and mouse emulation. In the bottom row, the business has replaced the mainframe function with a modern application. The business now has a few different options, update the HTML form to directly communicate with the modern application via API or, to minimize interruption and reduce the amount of rework, they can simply update the bot to call the modern application instead of the mainframe application.
In either case, the user should be unaware that the underlying application has changed. Moreover, the business has reduced dependencies on expensive MIPS (mainframe execution metrics usually associated with the cost of licensing) and, hopefully, reduced the amount of technical debt that may hinder operations in the future.
This approach has been widely adopted for many business users who feel “locked-in” to their existing way of working and believed that their only option was to wait for IT to modernize the existing application. Not only does it increase overall data quality and user productivity, but the investment is leverageable even after some modernization has taken place. Moreover, it limits the number and types of changes users must embrace.