Demystifying RPA in the Cloud
by
Ashish Nangla - July 21, 2021
Introduction
RPA vendors have traditionally built their applications for on-premises deployment, however, in response to heightened demand for the cloud, have taken their on-premises software as-is and placed it in the cloud. There is a lot of debate about “cloud native” vs. “cloud enabled” RPA Architecture however one needs to understand the underlying challenges which are inherent to RPA. The RPA in-cloud pricing models from most of the top commercial vendors are not true Cloud (consumption-based) pricing models. Currently they look more like traditional on-premises software licensing with cloud-based orchestration pricing stacked on top. This makes most Cloud enabled RPA solutions from these Vendors even more expensive than the on-premises RPA solutions (which are already inherently pricey).
SaaS Software has made life easier for enterprises. The word SaaS has become synonymous with “No Infrastructure, sign up, and use” software. So, naturally the industry was excited when RPA Software vendors started to offer a “SaaS” model. However, with this new model, customers very quickly discovered that SaaS does not really mean what it implies when it comes to RPA. Before we get into how SaaS for RPA differs from traditional SaaS software, it would be good to define the basic components of a RPA platform.
Definitions
Robot (Bot): A Robot or bot is a software agent that has the capability to execute predefined rules/actions to complete a business process.
Process Automation: The automated business process itself. Process Automation defines the steps for a business process along with exception handling scenarios added to the code. This is generally in the form of a deployable package and is created by an automation developer.
Studio: Studio is the software that an automation developer uses to define the business process intended to be automated. In an RPA software development practice, this type of tool is generally referred to as the IDE (Integrated Development Environment).
Orchestrator/Control Room/Server: The software that manages the bots and the execution of processes by the bots. This software also allows users to schedule process automation job executions. This type of tool can also generally hold work items, process execution logs, and credentials used or generated by the process automations. The Orchestrator/Server also often provides the ability to monitor process executions. This software DOES NOT perform the process execution. It only manages the robot agents executing the business processes.
Keep in mind that RPA software is not a system of record for any business process. It is merely a platform that facilitates the execution of business processes. It accesses only the data that is required to execute a given business process.
Infrastructure
- The Robot (Bot) Machines: Since RPA Robots mimic human actions to execute business processes, the bot, similar to a human worker, requires access to all the applications used within the business process including any business productivity applications such as Word, Excel, PDF readers, etc. If the process assigned to the bot involves the use of these applications or similar, the bot will require a machine that has these applications installed. This machine is required to be in a network that allows access to internal applications if the business process involves these applications (most process automations all use internal applications). In order to minimize any underlying business application compatibility issues, these machines usually run the windows desktop operating systems the same way the machines used by human workers executing these business processes do. This is the machine where all business process execution occurs.
- The Orchestrator/Control Room/Server: This software requires server infrastructure usually consisting of an application server and a database server. There may also be additional servers needed depending on additional components provided by various RPA providers. Keep in mind that all RPA platform implementations require at least the application server and the database server. Generally, business process execution does not occur on this machine. (There are certain exceptions for this in the case of server-side process execution, which we will discuss in another white paper).
The Challenges with the RPA SaaS Model
RPA differs from most SaaS software in a unique way. Process execution is delegated to a robot and this robot requires access to credentials and applications used by the business process. This means that the machine that the bot uses must be in a network that allows access to these applications being automated. Here in lies the biggest challenge with SaaS RPA. It is practically impossible for the RPA vendor to provide your organization with a machine that not only complies with your internal security policies, but also has your applications installed and has network connectivity to your organization’s network to be able to run those applications.
Think in terms of (digital) workers. The robots are your workers, and the Orchestrator/Control Room/Server is the manager. Your RPA vendor provides you with the workers, and the manager for these workers, however you still need to provide these workers with machines and applications so that they can work. Keep in mind that since the manager only manages the work, it does not actually require access to the applications and hence can “sit” anywhere (inside your organization or outside).
Hence when you hear “SaaS RPA”, the only thing that you are getting is an instance of the Orchestrator/Control Room/Server. You would still need to provision the bot/agent machines.
Benefits of the SaaS RPA Model
As depicted in some of the sample architecture diagrams below, the server infrastructure required to support an PRA implementation can become tedious for some organizations, especially those that do not have a mature, dedicated server infrastructure group. Not only does the server infrastructure need to be provisioned, but it also must be monitored, patched, and maintained. Organizations choosing to host the server infrastructure on premises, also incur licensing costs for Windows OS and SQL Server licenses. Additionally, scaling this infrastructure for resiliency adds to the costs.
By selecting to use the Cloud RPA Model, organizations can eliminate the overhead associated with procuring, provisioning, and maintaining numerous servers for an RPA Implementation. The RPA Cloud Provider is responsible for uptime and scaling of the server infrastructure required.
Bot Machine Options for a SaaS Implementation
- On-Premises Data Center: This is the simplest option. Institute virtual machines within your On-Premises data center using virtualization software already in use and provide network connectivity between this machine and the RPA Orchestrator/Control Room/Server. This connection is over secure channels.
- PaaS: If your organization utilizes a cloud provider such as AWS or Microsoft Azure for virtualized servers and desktop machines, and the networking exists such that your business applications can run in this environment, you can provision your robot machines in this environment.
- RPA Vendor Provided Agent Machine: This option will generally only work if the processes involved only require the use of 3rd party applications that are publicly accessible. Your organizations information security and networking groups may also be able to work with the vendor to establish secure networking so that internal facing applications can be used.
OpenBots approach to RPA & Cloud
OpenBots remains the only vendor in the market actively democratizing RPA. The company’s zero bot licensing and usage-based cloud orchestration make process automation accessible to all businesses. By offering the ability to build RPA bots without any licensing costs and run those bots either on-premises, all in cloud, or hybrid with some on cloud and some on-prem, OpenBots is revolutionizing the way businesses approach automation. The platform’s increasing popularity marks a welcome paradigm shift in the enterprise automation space, an industry traditionally dominated by pay-per-bot commercial products.
The Diagrams below outline various approaches to deploying and orchestrating RPA Bots using OpenBots Platform
Share This
About Ashish Nangla
An InsureTech Leader with more than 16 years in the Insurance & Financial Services industry, Subject Matter Expert in User Experience (UX), Blockchain (Distributed Ledger including Ethereum, Hyperledger, Quorum, Corda), Artificial Intelligence (AI) & Machine Learning, Predictive Analytics, Chat Bots, Internet of Things (IOT), Usage Based Insurance and Cloud. Ashish is an Avid supporter of the technological evolution and is constantly exploring the possibilities of how technology and innovation can be leveraged to add more value businesses and their processes. At OpenBots, Ashish’s vision is to democratize enterprise RPA by eliminating bot license costs and make automation and the benefits that come with it more accessible to all.
Share This
Recent Posts
Related Blog Posts
Hospital Automation – Eleven Processes You Need to Automate
Explore Hospital Automation and Eleven Processes You Need to Automate. Discover how RPA and AI are transitioning healthcare operations, patient care, and efficiency, all while maintaining a human touch.
Announcing the Retirement of OpenBots Discovery: Embracing the Future of Automation
As a company that continuously strives to deliver the best automation solutions, we have always aimed to stay at the forefront of industry innovation…
Transforming Healthcare Document Processing with Artificial Intelligence
Uncover how AI-driven automation in healthcare billing and document processing enhances productivity, reduces errors, and streamlines administrative workflows…
