I’ve recently been learning Robotic Process Automation, or RPA for short. The robot in RPA isn’t the type of mechanical machine made popular by Science Fiction author, Issac Asimov. Instead, they’re software robots. I hadn’t realised this, but software robots have been a huge part of my professional life since the 90s. Back then, nobody called them robots. They were simply snippets of code cobbled together for the express purpose of removing the menial and mundane parts of work. These code could be written in different languages- Perl, Python, PHP, Java, Visual Basic- but they all accomplished the same objective: glorious automation.
For example, when I was webmaster over several corporate websites, I noticed that some of the sites would regularly go offline. Because I wanted to catch these random downtimes and report them to a skeptical engineer, I built a PHP script to do just that. I remember naming the file [TestBullshit.php]. The script was crude, though, with less than 10 lines of code. It used nothing more complex than a server-based tool called cURL, which enabled code to communicate with websites and harvest all kinds of interesting data. A CRON scheduler then caused the script to ping the websites at regular intervals. If the script received a HTTP code of 200, it meant the site was up and running- Hurray! If the script clawed back an error code of 400, it meant the site was down. For good measure, [TestBullshit.php] was not only able to send an email to alert me of the problem, but also despatch an SMS message to my mobile through a Twilio API. The faults would also be logged to a Trello board so I’d have a rough kind of dashboard on the sites’ health.
These were modest work hacks, but it made me realise that while proprietary software was often a good idea for businesses, it enslaved processes, making them needlessly complex. Yes, enterprise software standardised methods and procedures, but they also normalised inefficiency.
So when cloud aggregating applications like If This Then That (IFTT), Zapier and Microsoft Flow appeared, it made a lot of developers excited. These aggregators helped developers connect a whole suite of other applications into a chained solution. Suddenly, it no longer mattered what software we used in our work. Through clever connectors, we could submit project milestones into an Outlook Calendar, replicate them in a collaboration suite like Slack, send important reminders to our team member’s Skype account, and produce a daily email digest of the project’s status. IFTT, Zapier and Microsoft Flow literally changed the name of the game, making it possible for developers to combine different technologies and focus on building open, shareable solutions.
Of course, aggregators represent an early generation of robot. They remain very useful, and I’ve employed them whenever I have the chance to. Why not? They’re fun to play with, and like a Pandora’s Box, can often produce unexpected connectors. Fancy an automated pipeline between #Google Analytics and a Microsoft Excel chart that will calculate your online advertising campaign’s ROI? With aggregator platforms, this is completely possible, and I built it when I wanted to measure library outreach programmes.
I once interned for a company that ran eleven stores. At the end of the day, each store’s cashier had to count the cash received, tally it with the receipts, produce an Excel report and save it into a shared drive. More often than not, the report did not appear in the shared drive, either because the cashier had neglected to complete the step, or there were problems with the networked drive. In fact, the situation was so serious that if the whole system went down, nobody would notice until weeks later. I fired up my notepad and began building a VB code that actively monitored the networked folder. Firstly, it would check by end of the day whether the report had been successfully uploaded. Secondly, it would push an API call to a Zapier service that would parse the contents, apply some logic to re-organise the data, then send ‘failed’ email alerts to the store managers. It was really quite a simple workflow that caught errors quickly and made the system more accurate.
RPA has gained fresh momentum with the introduction of easy-to-use platforms like UIPath, which simplifies development work. These platforms help professionals, even non-developers, build all kinds of nifty little solutions to automate activities and workflows. With an RPA platform, I could have built a similar solution for the troublesome eleven stores without expressing a single line of code. Building RPA solutions is almost entirely visual, with lots of drag-and-drop options. Drag-and-drop, however, doesn’t mean that RPA takes a lazy approach to building solutions. Many good software-creation habits like centralising common configuration variables instead of hard-coding them into individual ‘robots’ are encouraged.
In spite of RPA’s benefits, there are downsides. Most RPA platforms like to boast that they are code-less, but this isn’t entirely true. While you can technically use RPA platforms without writing a single line of code, not knowing how to code would prevent you from maximising RPA’s full potential. What’s more important to gain, however, is the heuristic knowledge that only coding can give. Early in my coding career, I had difficulty grasping the concept of functions. To me, creating a piece of software was a linear process, where code and its corresponding abilities are built line-by-line, block-by-block. The idea of functions was counter-intuitive because in most cases, it expected me to predict my code even before I wrote them. Worse, I had to supply the function with further information called arguments that may not even have been imagined in any substantial way yet.
Incorporating functions eventually made my code more efficient, but it was a painful journey to get to that point. Initially, I had to return to my code multiple times and make significant changes. Code re-writes were common. Now, however, I’ve cultivated a kind of code-prescience whenever I develop solutions. It is this kind of knowledge, earned through the tedious act of coding and re-coding, that I find is somewhat diminished in RPA platforms.
What about you? I’d love to hear about your experience with RPA!