A word of warning on adopting RPA

Preface

All technological choices are essentially tradeoffs between multiple factors and RPA is no exception. We have a natural and understandable bias to overemphasize the short term - being more immediate and concrete. One of the most important factors of making technological selections is weighing the tradeoffs between the short, medium and long term outcomes and costs - the business case must take into account not just the immediate cost but the long term costs including elements that are not immediately quantifiable in monetary terms without expertise.

I unfortunately have some experience on the subject of RPA from a few sources and my motivation for this is to give a word of warning for those contemplating kickstarting capability based on sales hype that still lives in various conferences and domains.

Overview

RPA (short for robotic process automation) is essentially UI based automation - treating the user interface of an application as a programmatic interface (you could liken it to programmatic APIs). But while APIs are designed to be used for integration (and naturally breaking changes are avoided - or with good practices at the very least made deliberately and communicated well) there is no corresponding expectation with the UI since totally different expectations are made of the end user (a human with an ability to dynamically adjust to minor or even major changes in conditions - and to think outside the box).

This paints the background for what are both the strengths and the weaknesses for RPA as a technology. And what, via a multitude of different interactions and systemic side effects, causes the various long term effects which are not immediately apparent from the plain mechanisms for people inexperienced in the domains where such things are routinely handled with tens of years of experience (i.e. IT development).

Sales angle

RPA sales is very often targeted at business and leadership personnel at companies and IT's involvement is downplayed and de-emphasized - it's easy to see why. This factor plays into the commentary on many of the points below.

In RPA sales the over-simplified quick wins angle is over-emphasized while disregarding the large varieties of sometimes non-obvious mid- to long term cost factors (combined with the target audience's lack of insight on these non-obvious long term consequences).

The good

These are the things which show up on hype slides and have some truth to them:

• Specifications don't necessarily require deep understanding of system internals or technical matters at any level because the implementation can happen purely against UI layer which is also how an operator would use it as well
• In cases where systems are old, rarely updated and it's highly impractical to expose modern APIs, the UI-based integration route might be the only option
• In case of very simple processes the implementation time could potentially be quick
• Assuming that the underlying systems play nice with the RPA tech which is not a given (see more below)

The bad

These are the downsides that most sales personnel pushing RPA also recognize and thus are mostly baked into realistic plans.

• RPA is not built to be maintainable. With the focus most often on immediate happy path results the maintainability of the processes is at best highly questionable and at worst a total nightmare
• Since vendors don't even consider communicating their internal implementation details regarding what happens behind the visible UI layer and minor changes in it, RPA processes essentially will randomly explode after seemingly minor or trivial updates that a human wouldn't even recognize as having contained a change
• This means that if the underlying systems get frequent updates then the RPA process maintenance can be expected to cause a major cost factor and headache. This is mitigated by the underlying systems not changing
• The ugly part of this is that in an ecosystem with a large variety of RPA processes this starts inhibiting actual system development and updates
• The outcome being reduction in agility in the longer term
• Failure situations in the underlying systems are a multitude and considering these in the RPA processes is possible only to a degree - and usually these end up being handled in highly inoptimal fashion. See below for more on the topic
• This leads to extensive testing requirements
• ...and bugs frequently still popping up in production. Further exacerbated by potential underlying system changes

The ugly

This is the part with the not so intuitive downsides that often only raises its head when it's too late to do anything about it.

• While very often it's listed as a benefit that no coding skill is required to be able to implement RPA processes, the outcome of this is the following:
• This means that very often people without a mindset for evaluating different execution paths (and no traditional development experience) are selected as RPA developers
• This leads to what everyone in IT knows to expect from junior developers who are not provided good guidance and mentoring i.e. frequent bugs, deficient exception handling, re-implementing basic patterns in non-ideal fashions, creating overtly complex structures that are difficult to maintain
• All of this leads to significant costs in the medium and long term while they may provide the benefit of getting simple happy path processes seemingly running in the short term
• This is further exacerbated by the next point:
• Compatibility of RPA with underlying systems is highly variable. While some systems play well with RPA automation, some systems contain frequent bugs which for users appear as minor annoyances (button at different place, minor naming glitch with text, etc.) but to RPA process cause it to totally stop working since the path selectors (fundamental building block of RPA automation) are often very specific
• Obviously your mileage may vary depending on underlying systems, OS, direct or VPN-based connection etc.
• Overall the RPA tech is very rickety and breaks very easily. This forces the processes to be restricted to ones without significant mistake potential and require additional overhead in the form of checks and balances and building the processes to be repeatable in cases of a significantly high percentage of execution attempts ending up in failure because "something weird just went wrong"
• We're learned through hard experience that there are certain things that must be done to make software (and RPA processes are just that despite the hype) reliable and high quality.
• Some of which are the following:
• Version control with clear diff and pull review for another person to sanity-check & approve changes
• Automated testing at unit and process level
• Automated deployment pipelines
• Monitoring, logging, automated observability to help with potential error investigation
• For all of these cases RPA usually provides basically no tooling out of the box and even makes it actively difficult to create these quality-increasing aspects
• RPA processes themselves cannot really be tested without actually running them. Sure you can manually change the process to only run a certain part of it (and this is 80% of development activity in trying to find the bug relating to some selector or another) but automated testing and verification is not really that's supported
• This leads to longer iteration times at low development level
• And increases the likelyhood that only happy path is covered, yet exacerbating the multitude of issues from all the other mentioned sources

Outcome

In an environment with modern development practices and for the most part functional APIs introducing RPA can only lead to net negative outcomes considering the variety of factors above.

For environments with very old, stable and rarely changing legacy systems representing a significant percentage of the integration landscape RPA can provide a benefit but you still need to consider ways to mitigate the variety of downsides listed.

Which one are you?

Related material

ThoughtWorks' TechRadar (an opinionated expert review at technological trends) has this to say about RPA - giving it the recommendation "Hold" - i.e. do not adopt:
https://www.thoughtworks.com/radar/techniques/rpa