Stop catching up on the latest RPA trends

Author | Anupam Krishnamurthy

Translated by | Phoenix

Planning | Cai Fangfang

This article was originally published on the anupam.de blog, translated and shared by InfoQ Chinese.

I was an RPA developer for 4 years – 2017 to 2021. At the end of 2019, I made an important decision to be named one of UiPath's 62 MVPs of 2021. The decision was to stop catching up with the latest RPA trends and focus on mastering traditional software development instead.

Of course, this wasn't the case at first, and for the first two years of my time as an RPA developer, I insisted on automating processes using only native RPA workflows. I don't come from an IT background, so I don't think traditional programming and scripting is for me, and I see RPA as a different programming paradigm than text-based programming and refuse to stray from it. At the same time, I was struck by the power of RPA and how quickly it was getting started, which blinded me to its limitations.

The RPA market is growing by orders of magnitude every year, and the RPA platform is now much more powerful than it was in 2017. This makes it more like an RPA developer to "specialize" in RPA rather than to get out of its boundaries. Here are 3 reasons to briefly describe why this idea is wrong.

Why is it wrong to limit itself to "RPA"

GUI-based automation is ultimately a compromise

The automation of any software process essentially requires the use of a series of commands to move data from one place to another. Over the past few decades, programmers have perfected the way to perform these operations on the command line with apt name. However, to extend the use of computers to everyday users, we created a more intuitive user interface – with mouse pointers, buttons, text boxes, touch screens, and so on.

Going into graphical user interfaces, we are now so accustomed to using GUI that we take them for granted. As programmers, we need to remind ourselves that every time we use the GUI, the computer performs digital gymnastics to meet our needs. Every time you tap a button on the screen, the computer puts a huge amount of effort into translating the gesture into a command. It must:

Correctly render the button on the screen

Tracks the position of the mouse pointer

Click on the Register button

Execute the appropriate command

Or, issuing commands with a single line of program code, as if speaking in a computer's native language, is efficient and robust, with minimal information loss.

Most native RPA automation is GUI-based, and take a moment to understand that GUI-based automation, which involves instructing a bot to communicate with another program through the UI, is similar to forcing two identical native speakers to communicate with a word puzzle. GUI-based automation is ultimately a compromise because there are always more efficient ways to perform the same task at the bottom, which leads to my second reason.

Native RPA processes are fragile in a production environment

For a long time, I didn't realize how fragile GUI-based automation was because I automated every process on my own computer, so I couldn't predict how different it would be to run it in production. When I moved to a team that maintained RPA processes in a production environment, everything changed. My team spends more than 80% of its time on repairing broken processes, which leaves us little time to automate new processes. This vulnerability stems primarily from the fact that production environments are always different from the laptops and test systems we develop automated. An automated process of 100 consecutive steps has the same "strength" as its weakest step, and only minimal changes to the GUI can break the entire process.

As an RPA developer, you yourself may encounter this situation a lot. I haven't seen an RPA process that performs flawlessly the first time in a production environment. Of course, one might think that this is changing, and with advances in RPA technologies such as smart selectors and computer vision, RPA processes can now respond more flexibly to changes in the GUI. This brings me to my third reason.

Commercialization

In pre-RPA, to automate a web application, you needed to examine web pages on the browser and filter complex HTML and CSS to find a reliable selector; with RPA, developers could retrieve their selectors by simply clicking on an element; in the next iteration, we had intelligent selectors that supported regular expressions and contained some fuzzy logic; and the next leap was computer vision—RPA software can now look at screens, recognize text fields, and act like human users. Radio buttons and check boxes.

As the RPA platform matured rapidly, so did the RPA effort. The easier it is for RPA platforms to automate, the lower the skill levels of employees required, a trend similar to the industrialization of the restaurant industry, where in the past you needed to hire a chef to run a restaurant; however, industrialization makes it possible for you to run a fast food restaurant with a middle school dropout. Yes, chefs are still valuable in today's world, but it's because they honk their skills and constantly reinvent themselves.

Workaround

Early in my RPA career, my mistake was not to recognize these factors, and here are 3 things I wish I had taken sooner.

Think like a software engineer

In December 2019, I read Bob C. Martin's The Clean Way of Code, which changed the way I looked at computer programming, allowing me to examine a piece of code from the perspective of an experienced software developer. I noticed that one needs to not only solve the problem at hand, but also design for second- and third-order problems that may arise downstream. I also realized that, in essence, RPA development is not much different from good traditional software development. In addition, software engineering techniques that predate RPA decades have solved most of the problems that RPA developers are just waking up to.

In addition to reading books like The Dirty Way to Code and Stupid Ways to Learn Python 3, it helps to talk to software engineers about how they can automate, and I often explain to my development friends the scenarioS I'm automating and ask him how he'll handle it. This helped me discover a great alternative to GUI-based automation, which led to my second suggestion.

Learn to automate using traditional programming languages

All RPA platforms are built on top of traditional programming frameworks, and most RPA automation is built on top of . Done on the .NET platform, so C# or Visual Basic is used at the bottom layer. Start with a simple workflow and try it out. The NET language bypasses the RPA platform, and in this way you can gain a deeper understanding of how RPA software works. In addition, you'll realize that in some cases, a few lines of code can achieve the same end result as a complex RPA workflow that spans two lengths of your monitor.

Another way to gain more experience is to create custom campaigns for your most commonly used RPA platforms. This experience will give you valuable insight into its inner workings.

One excellent resource I recommend for learning Python automation is "Automate the Boring Stuff with Python".

Integrate RPA with legacy software

Once you start thinking like a software engineer and adding some programming skills to your toolkit, you can build elegant processes that combine the centralized orchestration of the RPA platform with the robustness and efficiency of traditional programming. use. .NET, you can automate tasks on most Windows applications, you can map network drives, integrate DLLs, create custom activities, all of which will speed up your RPA code. To integrate with SAP, see Stefan Schnell's SAP Scription Tracker (https://tracker.stschnell.de/) and its magic how it works, and you can automate RPA deployment by building a CI-CD pipeline. The last integration is the scenario I'm most interested in and will continue to be my most valuable contribution to the RPA community.

Summary

Some of the things I've written above can be hard to accept, and RPA vendors and industry insiders are unlikely to make such a point, and I myself am only able to see this clearly after stepping out of my RPA career and looking at the industry with a whole new eye.

Also, my advice is to go back to traditional software development rather than keep up with the latest RPA trends, which can seem outdated. But if you're going to take a long-term view of your career as a developer, you'll need to master traditional skills that have stood the test of time.

I wish I had realized this sooner.

https://anupam.de/projects/descriptify/articles/articles/BiggestMistakeasRPADeveloper.html