RPA Platform Cloud Architecture: 5 Must-haves and 3 to Avoid

Modern Robotic Process Automation (RPA) platforms must be built upon a robust infrastructure. This is especially true in cloud-based automation systems.

Historically, RPA systems were built for on-premises deployments, which made sense since the majority of applications were desktop-based (think traditional Microsoft Excel). However, as those applications moved to the cloud (think Office 365), the many RPA systems moved with them.

In this transition, most RPA vendors took the easy way out and moved their on-premises software as is into the cloud. This is euphemistically called “cloud-washed” architecture, as it’s cloud in name only; it retains all of the negative aspects of manually deploying and maintaining the software and platform — and none of the benefits of a truly cloud-native architecture.

Automation Anywhere Enterprise A2019 is the industry’s first — and only — cloud-native RPA platform. Why does that matter? Because effective RPA cloud architecture includes five must-haves:

Must-have #1: Cloud-native, multiplane RPA

Cloud-native is the best practice of building a cloud automation stack with segregated components, or planes: the management plane, control plane, and data plane — each of which performs a different function and carries a different type of traffic. Installing the planes independent of each other benefits both developers and customers with the best operational efficiencies and application consumption.

The fully cloud-native, multiplane architecture of Enterprise A2019 gives companies the option of where to place each plane: on premises, in a private or public cloud, or in a Software as a Service (SaaS)-based option managed by Automation Anywhere. For example, you could have RPA management in the cloud but data stored locally. That arrangement creates a flexible, fast, and very secure automation environment.

The Enterprise RPA platform uses Docker containers managed by Kubernetes. These containers are units of functionality packaged and deployed to operate as microservices. Microservices are collections of loosely coupled, independent services on an elastic cloud infrastructure. Containerizing these microservices promotes better horizontal scaling and is especially effective from a high availability (HA)/disaster recovery perspective.

The microservices architecture breaks up a whole application (aka a “monolith”) into logical blocks (think of them as “micro-apps”; see Figure 1). This allows well-designed systems such as Enterprise A2019 to scale only the parts the user needs, without scaling all of them — which provides fault tolerance and resilience while at the same time optimizing computing resources. 

Must-have #2: A multiplatform RPA approach

Building enterprise software to run the same way across the cloud, on-premises, and multiple operating systems is a challenge. It requires planning, design, and a lot of work. However, the benefits are phenomenal. From a single code base, we’re able to support cloud, on-premises, public cloud, Linux server, and even Raspberry Pi operating systems.

What has been especially compelling about this multiplatform approach is that we’ve been able to build Enterprise A2019 in a cloud-native way — horizontally scalable, container-ready, with microservices by design — and bring that depth to any cloud. Whether it’s our own SaaS cloud providing a turnkey experience for RPA or an enterprise’s private cloud, the underlying benefits from the architecture remain.

A key step to making this approach come to life was adopting the Java programming language — one of the few developer tools that was built from the ground up in the cloud era to work on a broad range of platforms. Java is the one language that provides out-of-the-box support for multiple operating systems in a manner that gives consistency of operation.

As a result, performance and quality tuning from a Windows environment apply equally to Linux and even to Internet of Things (IoT) environments.

Java is the lingua franca of the Enterprise SaaS universe. With the benefit of years of tooling, experience, and a broad developer ecosystem with the cloud, Java has been a strategic win for Enterprise A2019 and foundational to giving us an open, multiplatform, cloud-native solution.

Must-have #3: A Linux option

Linux is the most widely used operating system in the world, according to W3Techs, and is the preferred operating system of today’s data center, as well as the default go-to for Enterprise SaaS architecture. You probably interface with Linux in your daily life more often than any other operating system as it has become the mobile operating system of choice and popular in the embedded universe — your TV, car, and home security system all probably run on Linux.

When we set out to build Enterprise A2019, supporting Linux by default was part of the architecture. That meant weaving in modern Linux norms for IT managers to make administration familiar and easy. Existing management tools for Linux work with Enterprise A2019 out of the box and, indeed, our own SaaS offering is run on Linux — we depend on it daily.

Don’t worry, Windows is supported out of the box as well. That’s the great thing about being multiplatform by design: Linux and Windows can credibly get equal love. For the IT team, the ability to choose provides flexibility and familiarity. For developers, the multiplatform underpinning enables their work to be supported across Linux and Windows without any additional coding.

Must-have #4: Extensible architecture

The term “extensible” means a design that allows the addition of new capabilities and functionality. This describes a key requirement for RPA developers: the ability to expand their automation capabilities by adding in commands and other components to create even more powerful bots.

The plug-in architecture of Enterprise A2019 makes extensibility as easy as drag and drop. The Enterprise A2019 command set can be expanded dramatically, using built-in commands in addition to those from external sources. There’s virtually no limit to the number of commands users can add to their workbench.

Examples include productivity tools from Microsoft and Google, as well as for artificial intelligence (AI), machine learning, natural language processing (NLP), and other advanced technologies (see Figure 2). 

Must-have #5: High availability

Enterprise A2019 was architected with HA built into its very foundation — and for good reason. Considering that many automations are used in critical financial processes, for example, high availability is extremely important from an accounting, reporting, compliance, and customer satisfaction perspective.

Other vendors provide HA as an afterthought, increasing complexity (and the chance for problems) by adding third-party vendors, different operating systems, and servers. It’s just not a good way to ensure availability for mission-critical processes.

In addition to the five must-haves we’ve outlined, there are three things you definitely want to avoid when choosing cloud architecture:

Avoid #1: Cloud-washed architecture

As mentioned earlier, cloud-native architecture is mandatory for any cloud-based RPA system. The alternative, on-premises RPA software that was taken as is and placed into the cloud, is simply a bad idea. This short-term, check-the-box approach is called “cloud-washed” and is, well, all washed up. It keeps all of the downsides of on-premises deployment and maintenance — but gains none of the many benefits of a cloud-native architecture.

Don’t risk your career with a cloud-washed non-solution.

Avoid #2: Monolith-based architecture

In the days before the cloud, software applications were monolithic — that is, designed without modularity (see Figure 1). This siloed architecture was OK in the mainframe days, before the cloud brought virtualization and multitenancy to the table.

As described earlier, however, cloud-native RPA platforms use microservices to facilitate scaling, optimize efficiency and security, and improve agility. By comparison, monolithic applications are slow and cumbersome. And, they’re definitely not resource- or cost-efficient.

Monolithic architecture belongs in the days of the mainframe. Get with the times. Make sure your bots are built on a cloud-native, microservices-based RPA platform.

Avoid #3: Windows Workflow Foundation

RPA platforms architected on Windows Workflow Foundation, a former core foundations library, are not built on state-of-the-art technology. Windows Workflow was discontinued in 2012, the year of its last release. That means the programming model is no longer sold, updated, or supported by Microsoft.

A Windows Workflow-based RPA system could pose a risk for customers if it’s not maintained and actively supported. For instance, if a security issue is found in Windows Workflow, getting a security patch in a timely manner is unlikely, which can leave your business exposed and out of compliance. The security aspect alone should be ample reason to run directly away from RPA vendors that still use Windows Workflow.

Conclusion

In short, cloud-native is a lot more than just virtualizing one’s on-premises application and delivering it via the cloud. Doing it right means reengineering the design, implementation, deployment, and operation of your applications from scratch.

The benefits of the cloud-native architecture in Enterprise A2019 reach across all aspects of IT infrastructure: in scalability, management, security, cost, and ease of access — while providing a great experience for all users.