In recent years, there has been a lot of hype surrounding two terms, Low-Code and RPA (Robotic Process Automation). Although they are connected, they are not the same.
RPA is a special kind of Low-Code, focusing on automating human tasks by developing software robots that mimic human interactions with the User Interface (UI). So, in a sense, to talk about RPA, we need to have two components: Low-Code and UI-Interaction. Let’s start with the first component, Low-Code.
Quoting IBM, “Low-Code is a visual approach to software development that enables faster delivery of applications through minimal manual coding.” The key expressions here are “Visual” and “Minimal hand-coding”.
Visual because currently Low-Code solutions provide rich graphical environments with Point & Click and Drag & Drop interfaces, well-designed diagrams and pop-up windows full of context cues.
Minimal hand-coding, because software development has come a long way in terms of reuse and modularity, is long gone the development from scratch.
The modern developer reuses modules, previously defined by other developers, which incorporate large chunks of underlying code, removing enough complexity that non-specialists can easily develop professional-looking applications.
Reusing modules is nothing new, and “old-time” developers have been using libraries for a long time.
However, with the combination of both the power of modularity and easy-to-use graphical interfaces, the cycle can really speed up in terms of both development and training time.
What about RPA? RPA is Low-Code, supported by expert systems that mimic humans in their interactions with User Interfaces. So not all Low-Code is RPA, however, all RPA is a kind of Low-Code.
Although most new applications are Web-based and some provide rich and well-structured APIs for programmatic interaction, the truth is that majority of business applications are still “legacy”, with no Web-UI, no APIs, and probably little documentation (except the User Manual, based on the UI). Also, the lack of free modularization of something like “business rules”, usually interleaved with the UI code and the database.
In order to interact via code with these kind of systems, RPA is usually the best compromise approach, since one can simply “pretend” the code is a “user” and interact via the UI, rather than trying to go through an old, unmaintained API, trying to create wrappers around older code or dealing directly with the database (which God forbid).
User Interfaces are properly maintained when people use them every day, there is a lot of knowledge about them and we get the benefits of the business rules. And it’s a two-way interaction, using RPA we can get data from the UI, but also put new data through the UI.
Good RPA systems, such as UiPath, know how to interact with all the challenges of dealing with a UI in different desktop technologies and legacy solutions that use terminal emulation. They use AI to identify fields, prompts, do OCR when needed, all provided through a good graphical interface, with process diagrams. This allows a developer to start producing good Low-Code in a matter of weeks, and for the team to focus on the processes rather than the implementation.
This technology does shorten the development cycle and especially when combined with Agile methodologies. Internally, we use a 2-week sprint, ensuring shorter start-to-production times.
Companies such as Microsoft entering the RPA realm, you can expect the merging of Low-Code and RPA environments, which is a good thing. RPA projects almost always need some non-native extensions, and sharing common eco-systems is obviously the way to go.
A word of caution, Low-Code and RPA are still software and when implemented in large organizations, projects based on either of these technologies will scale exponentially, with all the inherent pitfalls and challenges.
Several Low-Code or RPA software providers tout a “citizen-developer” approach, where non-coders produce ad hoc automations for their own work, most often without articulation or involvement from the IT team.
In our experience, this approach must be avoided for any company aspiring to create a scalable automation initiative.
In fact, it can really backfire and create antibodies about using RPA in the organization, due to the intrinsic efforts (versioning, different development / QA / production environments, maintenance, evolution, reuse, operation, scalability, among others).
In short, there are no silver bullets in this business. It may be Low-Code, but it will always be code.
Anyway, and when used properly, Low-Code and especially RPA are incredible tools to deal with the implementation phase of Digital Transformation, and we will see a lot more of them in the next few years. They came to stay.
A word of caution, Low-Code and RPA are still software and when implemented in large organizations, projects based on either of these technologies will scale exponentially, with all the inherent pitfalls and challenges.
