As tools for Robotic Process Automation (RPA) have matured, teams like ours at Velocity have formed to address larger-scale RPA implementations. While RPA has many similarities to programming, it is wrong to apply the same thinking to the management of RPA projects as we have to “traditional” programming endeavors. While the technical talent within an RPA team can be pulled from existing programming teams, many of our pre-conceived notions about requirements for these teams need to be reexamined. Many of our engineers began their careers as developers working on projects with robust version control, continuous integration, one step builds, APIs and the like, and the transition to RPA was a little rocky. Here are some common software project patterns that may be tempting to apply to RPA but which you should probably steer clear of.
Using a Version Control System (VCS) like git or subversion is gospel in any software development project. Trying to apply that same thinking to RPA will result in a lot of wasted time and developer frustration. The binary file formats of tools like Automation Anywhere do not version well, and while you can attempt to wedge a tool like git into the mix, it is better to leverage the resources inside your RPA platform to accomplish similar goals. Automation Anywhere has the Control Room, Work Fusion calls it the Control Tower, and both achieve similar ends: provide a central repository for automations and a modicum of version management. These tools are assuredly not as robust as a “real” VCS but for the purposes of RPA are more than sufficient.
User stories are a great way to think about software requirements, but this paradigm falls apart when dealing with RPA, largely because the “user” at the core of the automation is a process rather than a human. Instead of user stories, constructing robust process documentation is the key to successful RPA implementations. Our engineers use combinations of screen recordings, written documentation, and in-person interviews to build successful automations. This package of documentation is created by a RPA Business Process Analyst and should capture as much information as is necessary to successfully automate a process.
While this is largely a limitation of the tools involved, “test driven development” (TDD) is largely unachievable in a traditional sense with RPA. Instead, the testing should be done on the process output, informed by the process documentation, and in close collaboration with the process owner. Some semblance of TDD could be achieved by leveraging external platforms to vet process output, but this is largely a hack and I can’t recommend it. Instead, focus on vetting the end result of the automation, and test it by providing as much test data as you can realistically manage.
Enforcing coding standards in a project is key, but the lack of reflection within RPA tools means any automated solutions are probably unachievable. Our team uses Confluence to create a set of guidelines for our projects, and code review and paired working help ensure that we (mostly) adhere to the standards. While this isn’t as bulletproof as an automated tool running during a continuous integration build, for the purposes of RPA it is fine.
Continuous Integration / One-step builds
The broad spectrum of “automatable” applications within the RPA ecosystem means that developing a cohesive build pipeline is probably unachievable. Instead, standardizing on application versions and a base virtual machine build will ensure that automations are mostly portable between systems, and can be deployed via the RPA framework Control Room/Control Tower/Panopticon without worrying that there are version mismatches on the target system. Leveraging the monitoring and logging solutions built into your RPA framework will help pinpoint any errors caused by automatic updates, but it is best to turn those off at the application and operating systems levels, and test any upgrades thoroughly outside of production before applying them to mission-critical bots.
As the user communities for RPA tools grow, many of these pieces will likely fall into place. Better version control within the RPA frameworks will allow for tighter collaboration between engineers, which will be helped by coding standards enforcement and testing paradigms. The community of RPA engineers is largely excluded from any larger participation in open source efforts by the binary file formats and closed ecosystems of current tools. Developers are not the target users of RPA in the enterprise, but as RPA grows so will the need for developer-friendly features like version control, test harnesses, and coding standards enforcement.