The field of Robotic Process Automation has been dominated by commercial products, licensed on a per-robot (or per-user, for development tools) basis. They promise non-technical users the ability to automate processes in business applications as self service. The resulting robots are able to interact with the applications, including clicking and typing input into fields, based on predefined rules.
Vendors such as UiPath and Blue Prism have done a great job in packaging these capabilities into commercial products. The techniques leveraged by these software, however, are not proprietary - all of the same functionality can be accomplished with open-source tools and traditional programming languages, such as Python. This realization has given rise to a disruption in the RPA market.
In 2020, Python was ranked by RedMonk as the 2nd most popular programming language in the world, and it's already being taught in universities. Robot Framework has grown into one of the industry standard tools in test automation. The application of these tools in the context of RPA is increasing, giving rise to the “open source RPA” movement.
The choice of technology and the programming practices applied affect the entire lifecycle of a software robot, including its maintainability and extensibility. In this article I will look at how visual RPA tools (such as UiPath and Blue Prism), and automation solutions driven by written code compare in these aspects. I will draw from my experience of working with both tooling (UiPath and Python complemented by Robot Framework), and having seen how they are used by companies in the real world. This should provide food for thought for RPA team leads and people in similar roles, when assessing their technological decisions going forward.
One of the major selling points of visual RPA tools is that they are understandable to non-programmers: Automations can be put together from ready-made building blocks, connected by lines indicating process flow. The problem with this is that often the ready-made activities are too generic for defining tasks performed in the real world. Even for a relatively simple task, they have to be combined in clever ways to produce the desired outcome. The intention of these kinds of workarounds is often very confusing for someone analysing them later. If comments have not been provided, the reader can only guess at what the program is supposed to do, and implementing a change can be difficult.
Written code on the other hand, when done well, is self-documenting. Python's syntax is so close to written English, that chunks of it can be read intuitively even by a non-programmer. The whole idea behind Robot Framework is that of forming human-readable keywords, e.g. “Login to System”, “Enter Customer Record”. The intention of the automations implemented in these languages often become clear from reading the code alone, without the need to document each step explicitly.
In an earlier blog post, I stressed the importance of following software development best practices when implementing RPA, such as modular programming. The technologies are not equal when it comes to practicing modularity. Particularly in UiPath, packaging repetitive procedures into functions is not exactly intuitive. This is why the DRY principle is often the first to be offended by users of visual tools. It is very tempting to copy & paste the same set of actions into all of the places where it is needed around the solution, instead of going through the trouble of creating reusable functions. This is not to say that written code is automatically better in this respect, it too can be abused.
With financial processes (and controls) becoming increasingly performed by automations instead of humans, external auditors will also be required to gain an understanding into the inner workings of software robots. Because of the impaired transparency of automations implemented with visual tools, such audits should make for a much more pleasant experience for teams using version-controlled written code.
It is true that tools with a visual approach can be taken up by people with little experience in coding. However, as the practitioner gets more skillful, this accessibility quickly turns into a trade-off for productivity, and a source of frustration. For example, the testing and debugging utilities in visual tools are not particularly useful, whereas in Python, the testing of individual components has been standardized with purpose-built helper libraries.
Because of its "wordiness" and nesting of layers, developing with visual tools is much more cognitively taxing than writing code. In UiPath, procedures and their parameters are often too long to fit in the space made visible, or they are tucked away from view completely. For a person with a basic level literacy in both, written code is much easier to make sense of than its visual equivalent.
Having worked with UiPath Studio since its 2016 version, I have not seen a meaningful improvement in the development experience since then. This could be due to its reliance on Windows Workflow Foundation, which itself has not had new releases since a few years. Modernizing the Studio would most likely require a major overhaul on UiPath’s part and a move away from WF. It is possible that RPA practitioners using UiPath exclusively will see their skill development stagnate alongside with the tool.
Even if good programming practices have been applied, visual tools are no match to the open source stack when it comes to robot performance. In an example of the same process being executed by both Robot Framework and UiPath, the latter ends up an order of a magnitude slower. (UiPath, by default, adds a wait of 600 milliseconds in conjunction with every action, making it slower out of the gate.)
A key consideration when choosing any kind of technology, is the availability of talent in the job market. This begs the question, if finding people with proficiency in established products like UiPath and Blue Prism is difficult now, how will the situation be in 5 years time? After all, because of their proprietary nature, students don’t get any exposure to them during their education. I find it troubling that firms are attaining large codebases using these tools, whose vendors include ones that are yet to report a profitable financial quarter.
Conversely, it is hard to see finding Python talent becoming a problem, looking at the momentum behind it. As a general purpose language, Python has applications in a multitude of domains besides RPA. It has been adopted by enterprises to run data processing, including machine learning jobs, to name just a couple. Companies utilizing the same language for different purposes can find synergies in a bigger combined team with maintenance capabilities.
The relevance of talent availability could be argued, due to the nature of RPA processes as temporary solutions from day one. But then again, the same was said decades ago about mainframe applications that still remain to be replaced today! Moreover, because these tools are marketed as all-in-one solutions, teams are increasingly using them to build hacky API integrations and artificially intelligent applications, things that they were not originally designed to do.
Otto Ahonen
Consultant who thinks in code. A recent convert to the open source RPA movement.