For RPA to succeed …

TLDR: For RPA tools to succeed for automation you need to add engineering practices.

BTW: All automation projects require good software engineering practices.

Yes, you can use RPA tools to do test automation. And yes, you can have business persons designing the flows. BUT in order to succeed you need to apply some software engineering practices.

Robot Process Automation (RPA) tools like tools like LeapWork , Blue Prism  and UiPath  can be used to build business automation – it’s their core job. It’s the enterprise version of the Apple iOS shortcuts, “If This, Then That” or home automation. And they can be used for test automation – in some contexts.

The RPA tools are interesting because they seem to have a low barrier of entry. Some let you design the flows and robots visually, others using flowcharts. Either way it’s a low-code way of developing solutions. It seems compelling to let business end users prepare the flows and bots, it’s all plug & play.

Until it’s not.

Until the RPA robots design is only kept in the head of one person or until the flows/bots is a mess of interdependencies and cross links, that somehow the business still relies heavily on. And you have yet again created a spaghetti solution to add to the pile…

via DevHumor

The bigger the visual flowcharts in your RPA designer the more the project is a coding project. And you need to apply software development practices like version control, BDD style documentation and designing solutions loosely coupled and highly cohesive.

Sometimes you can teach the people the details, sometimes you can have a guide (tool smith) to enable them – sometimes it’s best to let the engineers tackle the automation. That depends on your gameplay and map of the world. What end users are good at is intrinsic domain knowledge the novel and the uncharted – not coding nor town planning.

Loosely coupled and highly cohesive.

The terms loosely coupled and highly cohesive is from the world of Computer Science, and most examples are around coding in object oriented languages like Java. In java, and in the flowcharts and visual scripts of RPA tools, you can group things into reusable “building bricks” or functions or sub flows. The Computer Science word for this is encapsulation.

It turns out it’s important how you group the bricks, and what the inputs and outputs are. Vladimir Khorikov summarizes with the following (my emphasis):

• Cohesion represents the degree to which a part of a code base forms a logically single, atomic unit.
• Coupling represents the degree to which a single unit is independent from others.
• It’s impossible to achieve full decoupling without damaging cohesion, and vise versa.
• Try to adhere to the “high cohesion and low coupling” guideline on all levels of your code base.
• Don’t fall into the trap of destructive decoupling.

Without good engineering practices any automation initiative is, at best, just a smartass expensive one trick pony.