Assessing RPA Time-to-Value with UIPath

Premise. 

Enterprises have been organizing work around applications for decades. As businesses transform, however, work streams can get locked into application limits. Robotic process automation (RPA) tools allow enterprises to integrate applications at the point of user work, thereby opening up automation, scaling, and reconstituted workstream opportunities to increase application, user, and business productivity. It’s a new approach for tying apps to business that opens the aperture to new types of programmer, if RPA vendors offer simple and strong community support.

with Peter Burris

For decades, enterprises purchased packaged applications that automated business processes. But these applications had boundaries that turned the processes they supported into operational constraints. ERP, for example, managed the order-to-cash process and CRM managed the prospect-to-customer process. Bringing them together has proven difficult and expensive, but in an increasingly digital world businesses must find a way to increase market responsiveness and operational efficiency, which requires continuously improving core processes and workflows.

The technology industry has made a number of attempts to solve this problem. For example, Enterprise Application Integration (EAI) was an approach in the late ’90s and early 2000s to bridge these silos by integrating multiple applications through a variety of different interface types, including remote procedure calls (RPCs), queues, and other mechanisms. The challenge has been that applications were so heavily customized that each connection required bespoke development — and ultimately maintenance. While EAI solved the problem where the business absolutely required it, typically it required an enormous effort by highly skilled programmers and took months — if not years — of waterfall-like planning and development. Moreover, the interfaces employed usually couldn’t be reused, which only added to the overall complexity and uniqueness of applications.

At the same time, enterprises were also trying to develop applications using desktop productivity applications as building blocks. Some desktop development approaches used “programming by example,” scripting languages, or some combination of the two. These tools had the advantage that they operated at the “point-of-work” — at the user interface where the application actually generated value — and not deep in the spaghetti of an application’s infrastructure. Consequently, the development effort could be more collaborative between a developer expert in creating software and a business person expert in the work domain being automated. In some cases, the tool was simple enough that it could be used by a business analyst with little contribution by an IT development professional (e.g., spreadsheet application macros).

Both of the approaches persist today, but the best of each hasn’t been brought together to better integrate either a wider array of applications or more complex combinations of processes. However, a new class of tool, Robot Process Automation, (RPA) is poised to change that. RPA tools use a programming-by-example approach to integrate applications at the point-of-work. However, in order to include enterprise applications, RPA has to be able to work with just about any application that an end-user can access. RPA applications that build on desktop apps, Web apps, and enterprise applications are a new way to automate business processes. Developers will be able to integrate enterprise applications with each other and with desktop applications where end-users previously had to bridge them manually. These new points of integration between enterprises’ digital assets will allow these same firms to relax embedded packaged (and legacy) application constraints, thus allowing business to rapidly reconstitute work in response to business opportunities.

When evaluating RPA tools, developers should consider the following factors:

• RPA can “open the aperture” for enterprise application development. Developers who have learned scripting or programming by example can now build new solutions that span enterprise applications such as SAP, applications accessible through a Web browser and/or an application virtualization platform such as Citrix, as well as desktop productivity applications.
• RPA improves time-to-value, but complexity still matters. UIPath can generate program code by example out-of-the-box. And the more narrowly defined the usage scenario, the faster time to value. But someone new to the tool must still master many options that are present for edge conditions that exist to support its ability to work with just about any application. As a result, time to value becomes longer as the developer has to manually generalize the auto-generated code, even if the code is embodied in visual artifacts.
• Community support will accelerate RPA adoption and time-to-value. In any software domain, experience matters. The rate at which knowledge can be shared about a digital technology strongly impacts which software tools win and lose, subject to certain diffusion factors. RPA tools can be applied to both increase the size of the user base capable of performing simpler development tasks and enhance the productivity of professional developers that have to go deeper into problems. RPA, by itself, won’t magically turn citizens into developers, any more than data visualization tools turned business analysts into data scientists. However, the goal of RPA should be to accelerate time-to-value, enhance developer/domain expert collaboration, and strengthen agility practices. All of that is made easier by a strong community go-to-market model.

RPA Can “Open the Aperture” for Enterprise Application Development

RPA tools consume application UI elements from across any number of products and turn them into reliable, performant, and secure automation and integration points.

With automation points, RPA makes it possible to drive efficiencies in existing processes. Where all data capture and presentation used to happen via human operators in front of GUI forms and dashboards, RPA can augment or (for certain classes of non-agency tasks) replace human operators with programmable workflows. Moreover, the program-by-example style of RPA could accelerate the time-to-value of implementing these new workflows. Finally, our research suggests that RPA tools could amplify the power of Agile methods — if, in fact, RPA accelerates time-to-value, thereby strengthening the iterative nature of complex application development.

These are three powerful propositions. However, other tools have failed to deliver on these types of promises. We contacted three RPA vendors — Automation Anywhere, Blue Prism, and UIPath — to test and validate each of these propositions. Only one vendor, UIPath, responded. Consequently, we used UIPath to as the basis for our overall RPA time-to-value assessment.

Programmability using RPA can reduce or eliminate manual data entry by making it possible to address directly each field on a form (see Figure 1). Not only is it possible to program the forms, but RPA makes the process really simple. Developers program by example and RPA generates visual artifacts that indicate what to do with each field or step in the program (see Figure 2). Each visual artifact comes with default behavior. But developers can also customize the behaviors non-procedurally through a rich set of properties.

Getting under the covers of a form shows how RPA tools can simplify programmability in other ways. Those individual form fields that UIPath can collect  can be extremely hard to access with traditional developer tools (for an SAP example, see Figure 2). Developers familiar with programmable GUIs, whether native to Windows or within Web browsers, know they have to navigate a complex hierarchy of objects, some visible to the end user and some not. In order to deliver easy programmability, RPA tools identify exactly where an object is within the hierarchy without requiring code for navigation. UIPath Explorer, a tool that’s part of UIPath Studio, automatically highlights one element within a complex tree of HTML document elements (see the left window within Figure 3). That UI element corresponds to the UIPath box that’s highlighted in yellow and labeled “BUTTON” just to the right of the UIPath Explorer window.

While RPA tools integrating applications via GUIs has some challenges, we find that using application vendor extensibility and integration options is considerably more difficult. Integrating business processes across enterprise applications has always been really challenging under the best of circumstances. APIs typically have a huge surface area and require a lot of training to master. One of their biggest virtues, though, is their stability. APIs represent a contract with developers. Vendors can add functionality to APIs, but they are never supposed to break them, unless they give warning multiple years in advance. Even with comprehensive and accessible APIs to multiple applications and highly skilled consultants to do the integration work, the effort would be lengthy, expensive, and very brittle, requiring continual development. As a result, most handoffs between applications have typically been manual.

Programming against GUI forms is not as stable as the more conventional way of programming to an API. But it can be more accessible. GUIs display their capabilities. However, they typically evolve more often than APIs, which is a key reason why point-of-work integration at the user function has proven difficult in non-personal productivity application settings. RPA tools are using some clever advancements to continue to work even if the GUI evolves modestly. For example, optical character recognition (OCR) technology lets RPA tools recognize labels that identify UI elements even if those elements move around on a form. Developers can also identify UI elements relative to other elements so that they have some sort of anchor.

Programming against GUI forms without the aid of RPA tools to navigate UI elements and help maintain stability is even more challenging. Consider SAP’s native integration and extensibility options. There is HTML5 for those portions of the SAP UI that use the relatively new SAPUI5. If that sounds relatively inviting, see the screenshot in Figure 4, which shows the script required access to particular forms. However, note that it’s only showing the code required to set up the access. The black rectangle indicates where the developer has to add their own code. And there is a profusion of technologies to know about when accessing SAPUI5: Javascript, Jquery, Odata, OpenAJAX, CSS3, LESS, D3.js, ARIA, and others. If a developer needs access to functionality not present in the UI, there are a set of even more complex capabilities to go through SAP’s middleware gateway or to work directly on the DBMS.

When you add up all the challenges, it’s clear why it has been difficult for enterprises to make their existing processes more efficient with end-to-end flows. And it’s even more difficult to reorganize these processes if an enterprise finds a different configuration necessary to support the business.

Figure 1. An example SAP form shows how a GUI not only displays information but it also provides visual documentation of its functionality. Source: Google Image.

Figure 2. A screenshot of a UIPath program being built to access an SAP form. Each box is associated with a different field. The boxes have properties with default behavior that can be customized further non-procedurally. Source: Wikibon screenshot of UIPath SAP Automation tutorial.

Figure 3. A screenshot of UIPath Explorer that illustrates how it simplifies programmatic access to GUI applications that can have a very complex hierarchy. Source: Wikibon screenshot of UIPath Explorer.

Figure 4. This screenshot shows the HTML and Javascript required just to set up access to forms and their underlying functionality. The actual code to work with the form is another set of far more complex code. Source: SAP.

RPA Improves Time-to-Value, But Complexity Still Matters

As part of our accessibility testing for RPA, we used the freely available UIPath Studio community edition to do a proof of concept. Our example involved metadata maintenance on Wikibon’s library of 500+ reports. The steps involved attaching to a browser window, navigating to Wikibon.com, logging in as an admin, opening up a list of all the reports in the library, extracting all the descriptive attributes for each report, and then writing the result to a CSV file. Most of the steps are visible on the screenshot in Figure 5. As the tool records each UI interaction, it generates a box with a clip of the UI element in the center  pane. The box highlighted in yellow is actually a loop that collects all the attributes for each report. The loop continues until it reaches the last report.

What’s most noteworthy is that the “citizen developer” — in this case, Wikibon analysts — doesn’t even have to understand looping. UIPath knows it’s looking at a table and figures out all the attributes for an item once a developer identifies the first attribute. Setting a single property tells UIPath how many, if not all, reports to download. Actually generating these steps took no more than a couple hours of experimentation. UIPath has a fairly rich and extensible library of actions, which it labels as activities. The gallery on the left of the screenshot in Figure 5, shows some of the activities. The Excel activities show how deeply integrated the tool is with the native data structures and actions within the application.

What about handling exceptions? Today, exception handling works in one of two ways. First, a human operator handles what the RPA program cannot automate. Second, a developer can code some of the decisions into partially visible branching constructs in the tool. Down the road, developers should expect RPA tools to incorporate more AI and machine learning that can start to learn about handling exception conditions the way RPA can generate loops and branches today.

Figure 5. This figure shows a part of Wikibon’s proof of concept using UIPath Studio. The center window shows how to navigate to the admin’s repository of all reports on Wikibon’s site. The last visible element highlighted in yellow shows how simple it is to collect all the attributes for each report in a loop that runs until the last report is collected. Source: Wikibon screenshot of UIPath Studio screen.

Community Support Will Accelerate RPA Adoption and Time-to-Value

As with most developer-focused tools, a freemium pricing model with an easy download and self-service simplicity supports the entire “discover, learn, try, buy, recommend” lifecycle. Wikibon found UIPath Studio the tool most accessible to this life cycle, especially the early stages that require self-service. Table 1 below shows a variant of the life cycle. The large number of developers with access to the tool helps foster a healthy ecosystem. That ecosystem in turn provides support to developers via knowledge sharing capabilities such as forums.

If the goal is time-to-value — and increasingly that is the goal in digital business — then CIOs should encourage selection of developer tools that facilitate adoption of Agile methods, increase the productivity of in-house development talent, whether in IT or in the business, and fit naturally with DevOps practices. Wikibon believes that RPA tools should not force enterprises into complex consulting contracts. Indeed, one of the key promises of RPA is that it could help ameliorate the complex dependencies that have grown between the business and professional services firms. Speed is essential. Complex contracting, deployment of resources, ongoing haggling regarding variances between expectations and delivery — these are the enemies of speed, if tooling can deliver high-quality software products. Our expectation is that UIPath holds a distinct advantage in the burgeoning RPA market because it employs a freemium go-to-market approach that encourages organic adoption of game changing developer tools.

Table 1: The lifecycle of a development tool requires different capabilities at different stages. But all are important for customer success and the ecosystem that supports those customers.

Action Item. 

RPA tools are maturing rapidly. Developers responsible for creating automated efficiencies with enterprise applications can turn first to RPA tools. The tools’ accessibility makes it easy to experiment within the form of a PoC. Early test cases should focus on automated efficiencies. With greater mastery, developers can tackle new business process configurations based on integrating UI points from multiple applications.