Until 8 months ago, I don’t think I’d ever heard the term “bot” or “bots” used in any context other than search engine crawlers or FrontPage technology <shudder/>. But beginning three boot camps ago, someone asked me, “how do we license bots?” – and I’ve been asked this question at both boot camps since, and 3 more times in addition during that timeframe. Outside of licensing Office for use in a server application (step 1: don’t do that!), this is a really weird and notable barrage of the same question. My experience is purely anecdotal, but based on conversations I’ve had since, it seems like Robotic Process Automation (RPA) is growing in popularity. Perhaps it’s to save money on staffing, perhaps to “do things faster”, perhaps to enable new systems or applications without needing to unpeel legacy software. Regardless, it seems to be a thing.

You may well be asking, “What is RPA?” In a nutshell, I define RPA as follows:

RPA is the automation of a repeatable process, performed by mimicking the actions of a user performing the task. RPA automates the user interface of the end-user application, manipulates the resulting data as necessary, and performs an action with that data.

RPA generally does all this without modifying the underlying application – often because that isn’t an option. For those old enough to remember, “Windows Macro Recorder” and “screen-scraping” should both be coming to mind right now, and for good reason. That’s effectively what this is – it’s an automated data conduit from a legacy system to a new system.

From the first time I bumped into this, I’ve been a little bit terrified by the approach. Bear in mind, I have heard the term “mission critical Excel” used not in jest, so I’ve heard a few scary things in my time. But RPA is kind of newly worrisome to me. Why?

1. Because of the relative ease of setting up a server-based desktop farm  (RDS, VDI, Citrix, or other) and scaling this into really expensive territory by accident
2. Because most organizations don’t seem to be stopping to consider the licensing side-effects of RPA prior to betting big on the technology
3. Because there are huge long-term questions about RPA sustainability as it relates to automating Windows and Microsoft software (among other software).

I’m not going to get into the licensing side of this – I’m working on a report about that for work – but trust me, there are some things to be concerned about here in that regard – in particular, effectively none of Microsoft’s software was designed to be automated in this manner, nor is it licensed in a way that is really adequate for this model.

After I mentioned RPA on Twitter, a follower sent me this article on “the encasement strategy”. I think it’s an interesting and very relevant read. While RPA can be used to automate lots of different software, my particular area of concern is Microsoft Office – let’s just winnow it down to Excel, Outlook, and Word. While all three offer automation models, most RPA I’ve found doesn’t dive that deep – it performs raw UI automation (or perhaps even more complex automation if running over RDP). By wrapping – or encasing – Office applications and making them part of your infrastructure, you’re using the software in ways it wasn’t designed to be used, and isn’t supported for use in. More importantly (licensing concerns aside), when the Windows 10 Semi-Annual Channel update comes along and you have to update, and the monthly Office 365 ProPlus update hits and moves a menu or shifts a shortcut, the vault that you’ve built over these Office applications will start to crack open.

If I were to guess, it seems that much of the appeal of RPA is that it lets you perform this automation without writing code – perhaps enabling creation of applications by people who can’t write code. I don’t think that’s ever the right goal. The right goal has to be building stable, resilient applications that can perform the tasks you need for years at a time, using supported APIs, and supportable tools. This means stepping back, taking a look at the available inputs and desired output, and building a system that can integrate the two, without using automation of a Windows desktop environment (regardless of the OS) to perform that task. That’s not sustainable.