RPA: Emulating and Becoming

A dog, an elephant, a robot. 

These were the three things I pretended to be most as a child. Ah, yes, and an old woman, hunching around the living room, snorkel deployed as a cane. 

Even today, those three feel like a relatively good description of my common states of being: genial silliness, a sort of solemn lumbering confusable with insight, and narrow, blind efficiency. 

After all, that is the attraction of the robot, what I used to find appealing: there is freedom in viewing the world through so pinched an aperture, as if you were looking at life through a letterbox. There are only rules, instructions, and the task in front of you — no such thing as distraction, procrastination, no state of aimless, broth-like ennui. 

And so I used to zip-zorp around in my socks, some private instruction in my head, emulating the obdurance of the robot.

But if humans find odd satisfaction in imitating the android, what is it that automatons (or their creators) hope for? Humanity, of course. The flawed but limber intelligence of the Homosapien. Which is to say that when robots sleep, they dream of us. (And perhaps, occasionally, of Electric Sheep.) 

In researching the Robotic Process Automation (RPA) space, one word appeared with curious regularity: emulate. When RPA companies sell the promise of their solution, this is often the word used. Here's an excerpt from UiPath's website: 

Robotic Process Automation is the technology that allows anyone today to configure computer software or a "robot" to emulate and integrate the actions of a human interacting within digital systems to execute a business process.

Emulate is doing all of the heavy lifting in this sentence. In its ambiguousness, it illuminates the promise and perils of RPA. Though heralded as the next great enterprise market and showered with venture capital, there's the sense that RPA has failed to truly live up to the hype. Large corporations leverage the technology to make processes more efficient and do so successfully, but deployments only work within tight conscriptions. In that respect, RPA feels a little like that fantastic, low-confidence friend we all have: despite being flattered and fawned over, there's a meekness, a lack of esteem that's self-defeating. 

Yes, RPA seems to say, I can help you move a little faster. But please, don't ask too much. 

That position may increasingly become untenable for the industry's most prominent players. The old guard risk featurization from tech's enterprise titans, disruption from sector-specific solutions and open-source models, and the incursion of AI. At the heart of the discussion is the difference between emulating and becoming. 

In today's briefing, we'll explore: 

1. What RPA is. 
2. The industry's major players. 
3. An impasse, and RPA's crisis of identity. 
4. Artificial intelligence and RPA as an aspirationless robot
   

Calvin & Hobbes and Modes of Delegation

What is RPA? While the joyless description provided by UiPath above gives an indication, it doesn't give a sense of the tech's trade-offs. Adding that RPA is essentially a way for "software robots" — unembodied automatons — to automatically complete tedious tasks like transferring data from a spreadsheet to an ERP solution via screen scraping and API integrations doesn't offer much more. 

The comics of Calvin & Hobbes prove a metaphor for RPA and the related fields of business process outsourcing (BPO) and artificial intelligence (AI). 

To get around cleaning his room, Calvin comes up with a plan to clone himself. That way, he figures, he and Hobbes can play outside while his clone does all the work! 

It doesn't go exactly to plan. Though Calvin's "Duplicator" successfully creates a copy of himself, the clone is all too human, sharing the same flaws as its creator. Instead of agreeing to adopt Calvin's duties, the clone runs outside, as keen to avoid working as Calvin is.

In an attempt to rectify the situation, Calvin creates more Duplicates. (And his Duplicates create Duplicates.) These successors have the same foibles as v1, and worse, they begin to make demands of their own, asking for an increased allowance. 

Through a business lens, Calvin's approach to delegation looks a lot like BPO. Instead of doing the work himself, Calvin contracts it out to a replacement for a lower cost (for free, he hopes). 

The problems he runs into are the same that a business faces in these circumstances, and with hiring, in general. Humans are fundamentally unreliable, self-interested, prone to whims and fancies. Though money is a good inducement, sometimes we just want to go outside.

Worse, the cost of adding new staff (even outsourced members) scales linearly. Each new person you add requires a salary, an "allowance," of sorts. 

What if you could get around those pesky impediments? 

After a few modifications to his machine, Calvin thinks he's found the answer. The problem with the first Duplicator, he explains to Hobbes, was that it created products that shared its author's entire character. The fix is to create a Duplicate without flaws.

In deciding to create a Duplicate with a partially ablated character, Calvin trades personality for utility. The product is fundamentally less human but better suited to meet his current needs. The Good Calvin is not only able to complete the required tasks, but he does so willingly and, crucially, for free. Good Calvin takes a bath without prompting, gets his homework done, and fixes himself a healthy breakfast.

Through his modified Duplicator, Calvin has essentially created a viable AI. Yes, Good Calvin lacks character, the ineffable flavor that makes us fallible beings. Still, he can complete various tasks without detailed instruction, showing the flexible thinking of an actual humanoid.

Further evidence of the thesis that Good Calvin is an AI arrives in his demise. Our primary fear with AIs is that they become too human. Rather than conforming to our stated agenda, serving us, they begin to operate based on their own motivations.  This is precisely what happens with Good Calvin. Unbeknownst to his designer, he develops a crush on Calvin's nemesis Susie Derkins, penning love notes to her. 

This leads to a clash between Calvin and Good Calvin, inventor meeting creation. Thankfully, Calvin has coded an AI kill switch  — the "Moral Compromise Spectral Release Phantasmatron" — into the source code.  When Good Calvin has an impure thought, he's destroyed. (This notion of a "kill switch" is at the center of AI debates; Google was said to be developing a product to serve this end.)

This is an encapsulation of general AI: hard to create (requiring plenty of modifications and tweaks) and incredibly high potential, but susceptible to veering off and wreaking havoc. 

By comparison, Calvin's third attempt at deputation looks relatively modest. Instead of making the bed himself, he elects to construct a robot. Note the difference between this and previous tasks: it's much more narrowly defined (make a bed vs. do all my work). It likely has clear instructions that can be relayed and then repeated.

From a business process perspective, you could argue that Calvin is making his first attempt at an RPA deployment. He has a clear goal in mind and makes no attempts to give his creation the ability to solve broader problems. This is exactly the kind of task for which RPA is suited. Rather than paying for outsourced human labor or dealing with the complexity and risk of AI (not to mention its current infeasibility), Calvin has found a low-cost solution programmed for a specific need. 

Unfortunately for Calvin, it only works incidentally. He cannot get the bot up and running and succeeds only by running out the clock, reaching the end of the day with his bed unmade.

That's alright, though. As any good RPA consultant will tell you, it can take a bit of time to get started with a new solution. The fact that there are RPA consultants in the first place indicates that setting up a slew of software robots is not usually a self-serve game. Companies have to commit to recording their processes (RPA solutions can track what happens on the screen and replicate a solution) and integrating with various APIs (though this isn't always necessary, it helps complex processes). Ultimately, knitting together disparate systems and processes is tricky and time-consuming. 

Nevertheless, we can imagine what a successful implementation would look like. And seeing Calvin's different solutions above, we get a sense of the trade-offs companies make. In its specificity, RPA does not promise the comprehensiveness of a human labor force or a general AI (if such a thing were genuinely available). Instead, it seeks to scalably automate the most repetitive, mechanizable tasks within an organization at a comparatively low-cost. 

That has proven a popular sell. 

The State of Play: Oasis or Mirage? 

In 2019, Gartner identified RPA as the "fastest growing market in enterprise software," having spiked 63% from the year prior. If venture capitalists have a bat signal — the outline of a fleece vest lighting up the night sky — this was it. 

Since, money has poured into the space with market leader UiPath upping its funding from $568 million to over $2 billion. This month, the company announced a $750 million Series F that valued the company at $35 billion, quite something given the market is only expected to reach $2 billion in 2021. (Other sources peg it at $7 billion.)  

At their core, RPA platforms sell efficiency. They promise to automate the most tedious, time-sucking, low cognitive load tasks an organization must complete. Think entering the details of an invoice into a second database, then pulling a report to email to a boss. Or copy/pasting data from one spreadsheet, combining it with a second, and then dumping it into a third. We've all had to do these chores, referred to as "systemantics," or the "quirks and shortcomings" borne out of the systems we use.

Incumbents have traditionally taken a horizontal approach to this simplification of systemantics. Companies like UiPath, Automation Anywhere, and BluePrism serve clients across sectors, emphasizing banking, healthcare, and insurance. Since their offering's breadth is relatively similar, these businesses look to compete on ease of use, service, and intelligence — all three tout the intuitiveness of their platform, the quick time to value, and the integration of AI and ML. This is an interesting evolution of the space that complicates our Calvin & Hobbes metaphors — as more RPA companies have emerged, the frontier of expectation has shifted such that automation is no longer sufficient. It is not enough to have a bed-making robot; instead, platforms need to provide some of Good Calvin's flexible, self-learning intellect. Solutions that leverage NLP or other advanced techniques are often classified as examples of "hyperautomation" or "cognitive RPA."

Alongside general use platforms, sector-specific solutions have emerged, particularly in the large markets mentioned above. Olive and Infinitus serve the healthcare space, Caremerge works with senior living companies, and Glassbox focuses on IT automation. As the market expands and competition increases, we may see more specialization around sectors or, indeed, the processing leveraged. Hyperscience, for example, focuses on ingesting data from documents. 

A burgeoning ecosystem of open-source alternatives is emerging, too. Companies can dip into OS communities to bootstrap automation rather than writing bots from scratch or relying on a full-suite platform. Businesses like Robocorp and Automagica seek to simplify and solidify drawing from these projects, making OS libraries more legible and usable to a business customer. Instead of paying for a specific software robot from UiPath, companies can use and modify an OS bot for considerably less money. 

Ancillary products and services have emerged to bolster the RPA platforms themselves. Often this comes in the form of "process mining," essentially software that reviews operations to identify potential improvements. Companies like Celonis, Minit, Fluxicon, and FortressIQ operate in this space, observing business processes in the background and transcribing them into implementable software scripts. The sell here is almost meta: helping the efficiency machines improve their efficiency. The existence of these solutions highlights some of the weaknesses of traditional RPA — if deriving value were truly as simple and intuitive as horizontal platforms suggest it is, support wouldn't be necessary. (It also suggests that real efficiency gains are to be found in rethinking processes, rather than simply accelerating them.) Again, we should expect more innovation here; even though platforms should improve, the scope of processes suitable for automation is likely to expand. Added complexity and the desire to understand the core processes at work should preserve the need for this kind of tooling. 

Looking at all of this activity, RPA seems to be thriving. Money is flowing into the space. The number of private market investments peaked in 2020, increasing nearly 30% year over year. The big players are heading toward the public markets (UiPath has confidentially filed paperwork) or cashing out through acquisition (Microsoft acquired Softmotive for ~$120 million). At the same time, creative insurgents are better serving valuable niches, tapping into a growing OS ecosystem, and innovating on functionality.

But there are signs that all is not well. Industry experts discuss the potential for the RPA "bubble" to burst, citing arduous implementations, underperformance, and considerable cost. In a piece entitled, "Is the RPA market the new dot-com bubble?" IDG noted: 

While good at automating processes, RPA will never drive genuine business transformation. It's for this reason that the immense valuation growth in the RPA market this year has led me to make comparisons to the dot-com bubble of the nineties…[T]he firms that were listed on the stock exchange in that period did little more than consume vast amounts of investor cash despite showing little prospect of achieving profit. The current expectations for the RPA market are similarly unrealistic.

Between frenzy and despair, where lies the truth? 

An industry once headed for the stratosphere seems to have stalled at a series of crossroads. The future of RPA relies on how it answers a series of questions. 

The Bridge of Death

Toward the end of Monty Python's Holy Grail, King Arthur's traveling party reach a bridge. Extending over a deep gorge, the "Bridge of Death" is blocked by a disheveled keeper. To cross, the knights must answer three questions or risk being "cast into the gorge of eternal peril." 

‍

And so like the ghoulish bridgekeeper, I stand in front of the RPA robot and say, "[he] would cross the Bridge of Death must answer me, these questions three:" 

1. Are ye a feature or a product? 
2. Should ye be no-code or developer first? 
3. And shall ye be used for dumb processing or serve as the guide for artificial intelligence?
   

So, to the first question: RPA, are you a feature or a product? 

Perhaps the greatest risk for the RPA industry is this threat of featurization. The relatively small size of the market has meant that tech's biggest companies have been relatively slow to move into the space, except for Microsoft. Neither Google nor Amazon offers RPA tools, choosing instead to partner with providers like UiPath. Google has shown some recent signs of interest with its "Business Application Platform," allowing for RPA adjacent processes. 

One possible implication here is that these goliaths are content to buy their way into the industry or build an alternative that can be easily bundled with existing enterprise purchases. As alluded, Microsoft is furthest along here — in addition to its own "Power Automate" platform, it now owns Softmotive and its WinAutomation solution. While at the moment, Microsoft's offering is on the less-technical side, it's easy to imagine how it might scale up its capabilities to be a direct competitor with someone like UiPath. In that scenario, buying from Microsoft would be a no-brainer, representing a more straightforward transaction (purchased in tandem with other products) and natively integrating with its entire software suite. 

This touches on our second question. RPA: should it be a no-code tool or a dev-first one? 

This is an inquiry the market is in the process of answering, with different businesses taking alternate approaches. 

Some, like ElectroNeek, highlight the usability of their platform, making it clear that it's a solution designed for the "citizen developer." These platforms hope that RPA can be made simple enough for non-technical business people to use it but powerful enough to get the job done. If managed successfully, the benefits are considerable: not only does it free up valuable developer time, but it allows automations to be created by the process owner, limiting losses in translation. Additionally, it could open up the market: at the moment, RPA deployments are constrained to large enterprises, but more intuitive tooling could put it into the hands of SMEs. 

Robocorp takes the opposite approach, building tools for software developers. The argument here is that as RPA increases in power, it will become more deeply embedded in existing processes, products, and codebases. Software engineers will best manage that complexity instead of business users stringing together basic actions in a visual editor. 

After Lancelot has successfully crossed the Bridge of Death, and both Robin and Galahad have been flung into the abyss, the bridgekeeper poses his questions to King Arthur. After answering the first two inquiries correctly, the keeper demands, in one of the film's most famous lines: "What is the airspeed velocity of an unladen swallow?"

King Arthur counters, "African or European?" 

When the keeper responds that he isn't sure, he is catapulted off the bridge. 

Which is to say that it would be reasonable for RPA to push back against the false dichotomy of this second question. Couldn't RPA diverge and prove viable for both the lower-and-middle market through no-code tools and fulfill complex tasks through a developer-led approach? Yes. But the potential for RPA does change depending on which direction it moves most quickly. Should it become more of a civilian tool, RPA risks drifting into the territory of companies like Zapier, IFTTT, and Integromat. There's nothing fundamentally wrong with that, but there are already decent tools here, and the willingness to spend is considerably lower. Moreover, because of the comparative shallowness of the tasks that can be automated, cost savings tend to be lower, and integrations can more readily be swapped in and out. RPA solutions that build developer power tools may find their number of customers curtailed, but with sufficient features, they have the opportunity to automate away more valuable, high-complexity tasks. 

This leads us to our final question. What should RPA be used for: dumb processing or infrastructure for artificial intelligence? 

Answering this question deserves a section of its own. 

Emulation and becoming

The examples we took from Calvin & Hobbes imply something like a scale. A spectrum from RPA to BPO (humans) that encapsulates the stepwise advancement towards a kind of humanness. We can call it the Calvin Curve. 

There's a vagueness in the term emulation. It suggests an attempt to capture the spirit of something, and at the same time, recognizes the failure of that effort. No one confuses emulation with the real thing; the distance between the two roughly equivalent to the discrepancy between imitation and duplication. You see the robot with its coffee-can hand and know it is not a human.

Before AI was introduced, RPA solutions seemed perfectly happy to live in this state of robotic drudgery. Platforms sought to do away with the tasks that made us less human — the humdrum, the soul-crushing, the lobotomizing — rather than trying to become more human, themselves. 

The introduction of AI to the sector has created something of an identity crisis. Now, it is not enough to just be a dumb robot. Emulation is no longer sufficient; we need software that can think, not just follow. 

In the subtlety of that change, the very definition of RPA is made diaphanous. If RPA is less defined by the processes it blindly runs, more by the improving logic through which it solves business problems, is it still RPA? Where does RPA begin and AI end? 

This may sound semantic, but the answer to this question affects the first one we asked. Yes, RPA may be featurized by existing enterprise platforms. But just as easily, AI could engulf it. Should that happen, it's by no means clear that the businesses that have excelled at convoluted software implementations are the same ones that will win a battle to create practical intelligence. 

There are signs the space is already moving in this direction, beyond incumbents vaguely proclaiming the acuity of their solutions. Newer companies like Pryon stay clear of the RPA terminology entirely, preferring "Enterprise AI." Nowhere on their landing page does the RPA acronym appear, but it's clear that the product is of a similar breed to others we've discussed. 

Comparing a product like UiPath with one like Pryon feels like a contrast between emulating and becoming. The robot without aspirations is RPA; the robot that dreams of humanity and its intelligence, that hopes to become a Good Calvin someday, is AI. 

In time, we may look at the term "RPA" as superfluous and outdated. Useful as a hazy prefix, a partial definition, perhaps, but not enough, in and of itself, to capture a product's functionality. In that respect, maybe we'll think of it like the phrase "World Wide Web;" we know it's there, we know it means something, but better descriptors have usurped its semantic strength. 

That isn't to say that RPA businesses are doomed. Far from it. In their introduction of the enterprise to software automation, incumbents set the foundation for broader AI adoption. But those that wish to thrive for the next decade or more may need to recognize that future success requires a different skillset. 

It's time to put away the Emulator and fire up the Duplicator. 

‍