Chances are, Robotic Process Automation is already firmly entrenched in your enterprise and interacting with your mainframe. Gartner defines Robotic Process Automation (RPA) as “digital enablement technology that predominantly leverages a combination of user interface (UI) and surface-level features to create scripts that automate routine, predictable data transcription work.” RPA “bots” equip end-users to self-solve many of their data retrieval and integration tasks. End users can also realize major productivity gains.
RPA activity is pervasive in many enterprises, and industry analysts project significant near-term growth for the category. Forrester reports that the enterprise RPA market is experiencing compound annual growth of 65%, with predictions that the market will reach $2.9 billion by 2021. Today, most enterprises understand RPA as both a technology category and a vendor platform. A July 2019 Gartner Magic Quadrant profiles more than a dozen RPA vendors.
The technology to automate end-user interactions is not new. It has existed for years in the form of terminal emulation or Excel macros. The automation was often a simple recording of keystrokes that a human could initiate at will via a click. With RPA bots we can now automate the automation, where interaction occurs without human initiation and at scale.
RPA BOT ACTIVITY HAS THE POTENTIAL TO SIGNIFICANTLY IMPACT END-USER PRODUCTIVITY, WHILE ALSO DRIVING ASYMMETRIC INCREASES IN MAINFRAME TRANSACTION VOLUMES.
Enterprises that use RPA may experience asymmetric increases in mainframe transaction volume when RPA bots retrieve data from host applications. This isn’t necessarily a problem. The premise of RPA, after all, is to have computers do what humans were formerly doing, particularly for repetitive or tedious work. However, many RPA implementations are using inefficient, screen-scraping as the mechanism for getting data from the mainframe. Implementing RPA in an enterprise doesn’t have to be a “win” for the end users and a “lose” for the mainframe. But today, it seems most RPA vendors are screen-scraping data from mainframe applications.
How RPA Impacts the Mainframe
When RPA usage scales up in an enterprise, RPA activity can drive up mainframe cycles – and costs – far in excess of requirements to support business processes. Furthermore, a byproduct of the inefficiencies of how RPA bots get mainframe data is worsening response time. This is happening under the noses of anxious IT groups who see mainframe transaction volumes increasing, but are unable to link it to RPA activity.
This was the case with a recent HostBridge consulting engagement. The client is an enterprise whose core business applications run in CICS. The end users there have embraced RPA. As RPA bot usage has proliferated at this enterprise, mainframe transaction volumes have risen faster than expected. The IT organization suspected RPA activity was driving the increase, but had no way to precisely determine how much, if any, of the workload was RPA-driven.
When enterprises use RPA to automate business processes that are tightly coupled with mainframe applications, as RPA activity increases, an asymmetric increase in transaction volumes is a certain outcome. When RPA bots use inefficient mechanisms, such as screen scraping, as the interface to mainframe applications, operational inefficiencies are the result. One leading RPA vendor touts its ability to integrate mainframe data into a business flow with “100% accurate screen scraping”. Another RPA vendor, when describing its solution for the mainframe, states it “communicates directly with the IBM mainframe using the native IBM TN3270 protocol for industry-best RPA performance.” In other words, it too screen-scrapes to get host data.
THE ACTIVITY AN RPA BOT INITIATES ON BEHALF OF JUST ONE END-USER CAN SPAWN HUNDREDS OR THOUSANDS OF CICS TRANSACTIONS.
One certified RPA developer at Accenture Solutions shared this advice on Quora about automating a mainframe application using one of the leading RPA platforms: “However if we are reading from the screen we won’t know the sizes of the fields. For example where does the residential address field end? In these situations we identify the field to be the maximum width available on the screen to avoid the risk of cutting off the end of field data as below.”
This advice reveals the brittle nature of screen-scraping. What if the mainframe application developer makes a change to a screen layout, such as inserting a new row of data? The integration fails. That’s the problem with this integration approach: screen scraping technology is complex, performs poorly, scales poorly, and integrations that rely on it break easily. There is some irony in the fact that RPA, a leading-edge technology, relies on archaic, decades-old sub-optimal technology to get mainframe data.
Why Does Screen-Scraping Persist?
Screen scraping is a poor integration technology. But it’s easy to understand why it’s still in use: many of the mainframe applications that are integration targets output their data to a screen. During an October 2019 IBM Systems Media webinar, a participant poll revealed that for organizations running CICS applications, many are terminal-oriented.
ALMOST 80% OF THE ENTERPRISES IN THIS POLL HAVE CICS APPLICATIONS IN THEIR PORTFOLIO THAT OUTPUT DATA TO SCREENS.
These terminal-oriented CICS applications are the most challenging to integrate. Using screen-scraping technology to accomplish these integrations is the path of least resistance. The ease of developing integrations for them, however, is quickly offset by performance issues, operational costs, and ongoing maintenance requirements.
Measuring the Impact of RPA on the Mainframe
How can an enterprise know the degree to which RPA activity is impacting the mainframe? IT organizations want to understand how much of the host transaction volume is human versus bot initiated. The reason is simple: RPA bots don’t exploit the architecture of the mainframe and therefore get data in the least efficient way. The HostBridge team discovered this during the previously referenced client consulting project. In examining the activity of just one RPA bot automated sequence, the RPA bot caused the execution of almost 7,000 CICS transactions. Each transaction was accomplished via screen-scraping, and each required a full-travel from the RPA bot to the CICS application and back: almost 7,000 round-trips.
For those who understand how CICS works, each of these round-trips between the RPA bot and the mainframe did a CICS START transaction. Experienced mainframe IT staff understand that a one of the most resource intensive (expensive) things that happens within CICS is a transaction START.
As a result of how RPA bots were getting mainframe data in this enterprise, mainframe transaction volumes were increasing at a rate higher than associated with business volume increases. This relationship between RPA activity impact on the mainframe and business volumes is shown in the following graph.
THE RELATIONSHIP BETWEEN RPA ACTIVITY ON THE MAINFRAME AND BUSINESS VOLUMES.
To understand how RPA activity impacts the mainframe, HostBridge developed an analysis tool and process. It uses SMF records as input and displays the results on a series of Splunk dashboards. The details of this tool and the analysis it supports is found in an eBook, “Guide to Mainframe Optimization” by S. Michael Benson. HostBridge now offers this analysis as a service, and in many cases, we can complete the analysis offline. To schedule an RPA analysis, simply complete the form at the bottom of this post.
The HostBridge RPA analysis will help enterprises answer some critical questions, including:
- How much mainframe, CICS transaction activity is driven by humans versus RPA bots?
- How many transactions do RPA bots execute, and which ones?
- What is the source of the RPA activity, and what is its intent?
It is important for enterprises to gain deep insights into RPA activity that involves the mainframe to:
- Understand when RPA activity becomes operationally expensive and inefficient
- Plan how to increase IT support resources to diagnose issues or errors
- Know when Service Level Agreement (SLA) attainment is at risk
- Keep from inhibiting an organization’s ability to evolve their mainframe applications
- Anticipate when RPA activity might drive processor upgrades
Remediating, Optimizing, and Modernizing Mainframe RPA Activity
It’s important to analyze mainframe RPA activity to gain the insights necessary to optimize how RPA bots get mainframe data. The purpose of the analysis is not to create barriers to RPA adoption. Instead, the goal is to ensure that RPA interacts with the mainframe in the most efficient way. Knowing the precise nature of RPA mainframe interaction makes possible providing better, more efficient mechanisms for RPA bots to get mainframe data.
One outcome of the consulting project HostBridge referenced earlier was understanding what the RPA bots were doing. In this case, the bots mimic a human operator, making a complete set of queries into the sales catalog, to build an end-user specific version of the sales catalog in Excel. The cost of this approach – 7,000 CICS transactions per user – was high. When the RPA analysis revealed this, the IT team found it could accomplish the same outcome with a handful of DB2 calls, or via a nightly batch process.
In many cases, the need to run a series of CICS transactions to satisfy RPA automation sequences will remain. When this is the case, there’s still a better way that using screen-scraping. That better way is having RPA on the mainframe, which is exactly what the HostBridge JavaScript Engine (HB.js) provides. With RPA on the mainframe, the RPA bot can send a single request to the mainframe RPA engine (HB.js). The mainframe RPA engine will execute a single script to run the CICS transaction sequence far more efficiently, and much faster. The requesting RPA bot will receive a single JSON (or other format) document that contains all the data. HB.js takes full advantage of the mainframe architecture, performing its work on the zIIP-engine. This diagram shows how RPA bots should ideally interact with the mainframe:
PUTTING AN RPA ENGINE ON THE MAINFRAME ENABLES FAR MORE EFFICIENT DOWNSTREAM RPA ACTIVITY.
Smarter, Better RPA
The way forward for RPA platform vendors is to replace screen-scraping integration to the mainframe. They can do this by leveraging a mainframe RPA engine such as HB.js, and it is completely transparent to end-users. Every RPA stakeholder in the enterprise benefits from this approach:
- End-users: faster response, better performance, more reliable integration to mainframe data sources.
- IT group: more efficient utilization of the mainframe, ability to continue evolving mainframe applications without fear of breaking RPA integrations.
- RPA platform vendors: a competitive advantage from using efficient mainframe integration technology that minimizes the operational impact of RPA.
The way forward for enterprises that are using RPA is to complete an RPA mainframe analysis. With the results of this analysis, enterprises will understand how RPA is impacting the mainframe. More importantly, the analysis provides a roadmap to RPA remediation, optimization, and modernization.
Get a Mainframe RPA Guide
HostBridge has published a series of guides for using various RPA solutions with your mainframe applications. Visit the eBook Downloads page to find all of these resources.
If you’d like to know more about how HostBridge can help you optimize automations and macros that interact with your mainframe, reach out using the contact information found at the bottom of this page.