RPA: Stepping Stone or End-State Architecture Pattern?

For many years, one of the key applications we used to manage earned the unique distinction of being the most heavily scripted, screen-scraped application for our organization’s website, contributing to almost 75% of overall traffic. So why would someone choose to script its usage, or use robotic process automation (RPA) instead of a neater, well-defined integration?

In today’s world, RPA is being presented as the go-to solution for many things. There is nothing more appealing than a quick fix that’s easy to implement and seemingly cheap. That said, quick fixes rarely produce good results in the long run.

Essentially, leveraging RPA during digital transformation is akin to putting duct tape on a new boat. You would have created a new system which looks shiny and modern, but underneath, it remains connected to the old system in a very rudimentary manner. For example:

• Extracting data from a web application means the web server will unnecessarily be rendering an HTML page and sending the HTML page content across the internet instead of simply sending the data that the consuming application is interested in.
• Consolidating data from multiple pages of a web application that uses pagination means the automation will have to request multiple pages of data, one by one, instead of an API call returning the data in one shot
• Automating a mainframe’s 24 x 80 screen, which is filled with data elements means no more data elements can be added to that screen in the future
• Integrating with a desktop application means the application has to be deployed and maintained on that desktop instead of invoking a back-end API call

When you use an RPA to integrate with a legacy system, you are forcing yourself to continue running those legacy systems in the future. An effective transformation requires decommissioning older platforms to reduce your IT footprint and save costs in the long run. Going with the easy fix hinders this crucial move forward and does not allow for innovation opportunities.

As you continue with the modernization and digital transformation initiatives in your organization, you would encounter situations where you must choose between system integration and RPA.

Implement RPA or integrate?

An RPA solution may be able to perform a function much quicker than a user ever could, however, the response time and functionality of the provider application are only as fast and efficient as the current application. Whichever type of automation you choose is always bound by the functional and technical limitations of the current application involved.

Before you decide whether to implement RPA or to integrate, we’ve mapped out a few key decision points you need to consider.

Click to Enlarge

The decision flow covers three important aspects from an enterprise’s perspective—business requirements, organizational readiness, and cost and benefit analysis. It can help you visualize the consequence of each decision point, enabling you to address immediate opportunities and adjust for better future outcomes. We’ve included more questions below to help you make the right choice:

Business requirements

• Are you automating processes in an application or integrating two applications using RPA?
• Are you integrating with an internal provider that you have a controlled arms-length relationship with or is the provider an external entity which might only have a business relationship with your organization?
• How are you planning to use RPA to integrate with a provider? Is an account required for access or is anonymous access allowed?

• Do the key stakeholders understand that the new solution would be bound not just by the current functionality of the provider’s solution but also by the provider’s current UI or UX?
• What are the impediments for proper functional integration, and what’s required to remove them now or in the near future?
• Since RPA is primarily an anti-pattern to API-based integration, has the solution been approved to fit in the enterprise architecture roadmap?
• How is the functionality provider going to support your organization or application’s SLA, performance and stability requirements?
• Are you crossing technology boundaries which might make a functional integration more complex?
• If RPA is a short-term solution, are you setting aside sufficient resources for the long-term implementation?
• If RPA is a long-term solution, have you defined on-going resource requirements to maintain a stable solution?

• Is it cost prohibitive to improve UI or UX of the legacy application instead of automating the use of the non-efficient legacy UI?
• Have you done a detailed cost comparison between the upfront and on-going costs of a well-defined integration pattern vs RPA?

So, should RPA be part of your end-state architecture or just a stepping stone in your digital journey? With these guidelines, you would be better prepared to decide.