We recently received a request for proposal (RFP) from an organization that had done a proof of concept (PoC) using Robotic Process Automation, better known as RPA. The PoC had gone so well that this organization promptly went out and purchased three bots from a popular RPA vendor. Now, all they needed was a certified RPA partner who could make all the bots do all the right things for them. It was one of those classic “we’ve got the solution all figured out; you just need to build it for a fixed fee” sort of RFP’s. I love these.
I’ve been hearing about RPA for the last few years, so I decided this was a perfect opportunity to learn more. In my research, I found the Wikipedia definition a helpful starting point as well as a pair of CIO.com articles ranging from positive, to not so positive. Most of the other RPA articles I found focused more on the hype and the promise of RPA and less on the results of RPA.
In a nutshell what I learned was RPA is essentially screen-scraping technology that has existed for years with configurable rules and a new name that includes robot in it. Basically, RPA deploys robots or bots that record and playback human interactions with a system’s graphical user interface (GUI). Once configured, bots are triggered when new data arrives so they can automatically type data into systems like a virtual human would, thereby increasing productivity and reducing tedious data entry.
While this may sound like a reasonable approach to automation, RPA has a fundamental Achilles heel. This flaw is immediately recognizable to anyone who has ever automated the testing of a system’s GUI layer.
RPA integrates with user interfaces which are—by design—the most unstable part of any system.
Let me explain. When designing software systems, core concepts like domain models and database tables tend to be more stable – on purpose. Over the lifetime of a system, they tend to change less often. GUI’s, conversely, are changed much more frequently – on purpose. This is actually a benefit. Buttons can be added and removed. Screens reformatted for responsive design. Menus updated to be more intuitive. DOM objects changed under the covers. New front-end frameworks replace old front-end frameworks. In fact, if you use a SaaS service, you often have no advance warning of GUI changes as vendors continually “improve the user experience.”
All these changes to the GUI layer presents a problem for RPA, primarily in the form of breaking the bots that were programmed to integrate with the GUI. This is because they break what Bob Martin calls the Stable-Dependency Principle (SDP) which states, “depend in the direction of stability.” There are event metrics like Afferent and Efferent Couplings that can measure software stability if you are so inclined.
So to recap, with RPA we are purposefully integrating with the most unstable part of a system. This can be described with the RPA maxim:
Bots that depend on unstable GUI’s are inherently unstable themselves.
In other words, don’t build your automation house on sand.
The Business Problem RPA is Solving
Setting aside my concerns, I decided to dig into the business problem driving this RFP. Maybe there was something I wasn’t seeing?
Over the course of 15 pages, the RFP explained the problem and the already approved solution. There were the traditional screenshots and flowcharts full of colored boxes and arrows. There were even port numbers and firewalls depicted with those little firewall icons. From the RFP I learned that about a dozen simple steps that a human does today they wanted RPA bots to do in the future. The flow was basically:
- Customers submit a new application using this organization’s website. Their data is captured electronically and stored in a relational database. We’ll call this System A.
- Next, a human is notified shortly after a new application arrives. They login into System A’s GUI, pull the information up on their screens, then login to System B’s GUI.
- After cross-validating some information in System B, the person manually enters the data from System A into System B’s GUI.
That’s it—the whole point of the RFP is to get data out of System A and into System B reliably, accurately, and quickly!
Unfortunately, instead of stating this as the real problem to solve, this organization had already picked an RPA solution and vendor, purchased expensive bot licenses, created and distributed an RFP so an external RPA expert could show them how to configure their shiny new toys. What could go wrong?
If RPA is so bad, what’s a better solution?
This is a fair question and the Stable-Dependency principle gives us clues to a better way. Remember, depend in the direction of stability. In this case, we want System A to depend on something more stable than System B’s unstable GUI. An Application Programming Interface (API) fits the bill nicely here.
API’s publish contracts describing how clients can consume their services via code and automation. Teams building API’s focus on contract stability from the get-go, unlike teams building GUI’s designed for humans. Even if the underlying technology of an API changes over time, that’s fine, they are purposefully more stable than GUI’s. That’s the whole point of API’s.
So instead of investing in expensive RPA licenses with expensive proprietary technology and expensive certified consultants, I would advise this organization to invest their resources in creating APIs for System B that handled this business use-case of accepting System A’s data. They could automate the integration of data from System A to System B’s API with ubiquitous technologies like containers or serverless. This could be deployed on a large variety of cloud and non-cloud platforms and the skills to do this are much more prevalent in the market than RPA-certified skills.
The containers and functions could handle the cross-validation logic requirements and they are relatively inexpensive to deploy and run. The benefit for System B is that other clients, like Systems C and D can also integrate with them via their API for no additional bot costs. System B can also evolve its GUI to improve its user experience without worrying about breaking bots.
Closing thoughts
Perhaps RPA isn’t all bad and perhaps there are cases where it might make sense. But my software Spidey senses and two decades of experience tells me that RPA’s approach to integrating with unstable GUI’s is just a bad idea. In 2020, we know of better ways to solve integration problems that don’t involve deploying a bunch of expensive automated bots against the most unstable part of a system.
While it is probably too late for this organization to change course, perhaps your organization thinks twice before throwing RPA at your next problem.