RPA Processes – Pets vs. Cattle

• 

• 

In DevOps, it’s common to think of your IT infrastructure as either Pets or as Cattle.

RPA Process Selection and Design should be thought of in terms of Pets and Cattle as well.

What are Pet Servers?

Pet servers are often:

• Highly specialized and few in number
• Indispensable and cannot tolerate downtime
• Setup and changed manually by hand
• Scaled vertically (by increasing CPU or RAM)

Pet servers are characterized by being heavily cared for by staff and are often single points of failure like relational database servers, firewalls and mail servers. When a Pet server goes down, critical business functions are affected and there’s a panic to nurse the server back to health.

There’s an inherent risk associated with having Pet servers in any enterprise, as they are not easily replaceable, and there’s no automated way to bring them back up after failure.

What are Cattle Servers?

The alternative to having Pet servers, is to have Cattle servers. Cattle servers are:

• Treated as a group and large in number
• Created using scripted or automated methods
• Scaled horizontally (by adding more servers)
• Designed with failure in mind
• Replaceable (disposable) and stateless

Over time, IT has shifted away from Pets, towards more and more Cattle. In the Cattle way of thinking, individual servers are not important; the group is. If a single server fails, a new server can take its place. In order for this to happen, servers must be stateless, i.e. processing a request must not depend on anything that is unique to that machine.

Analogous to IT infrastructure, for enterprise grade RPA, our processes should be thought of as cattle and not as pets.

This Pet vs. Cattle concept applies to RPA in two ways: Process Selection and Process Design.

Process Selection

One of the biggest questions for a new automation project is: Which processes should I automate?

Note that the advice in this section applies primarily to those just starting their RPA journey

Many companies choose Pet-like processes that are:

• Highly specialized and few in number. Processes that only impact one or a few individuals and have low work volume have a hard time demonstrating the ROI of an enterprise RPA platform.
• Indispensable and cannot tolerate downtime. While these types of processes may be suitable for those with a mature RPA capability, these characteristics pose too much risk for an immature RPA team. A failure here can sink the entire RPA endeavor
• Setup and changed manually by hand. A process that was not consciously designed by the business, is often non-standardized with dependencies on one person’s knowledge, relationships or computer setup. It is significantly more difficult to reproduce the steps in a process that doesn’t have any standardization. The scope of the process can differ wildly depending on who you talk to, as it has undergone multiple undocumented revisions
• Scaled vertically. Avoid choosing processes that ‘scale’ by adding more steps to the process as they likely have less potential for returning hours to the business compared to processes that scale horizontally

In the Pet RPA frame of mind, we are delivering something similar to Desktop automation or RDA, helping select individuals automate their ‘Pet’ tasks.

Instead, look to automate Cattle-like process that are:

• Treated as a group and large in number. The successful implementation of processes automations that are high in work volume, affecting large numbers of people convincingly demonstrates the ROI and value proposition of enterprise RPA
• Created using scripted or automated methods. Processes that have been consciously designed by business have an inherent level of standardization. The process is more easily reproduced in the RPA platform and has a well defined scope
• Scaled horizontally. If you choose processes with high volume workloads, work can scale horizontally by running multiple Digital Workers in parallel. This will likely increase the hours returned to business much faster than low volume processes that scale by adding new work steps

With Cattle RPA, we are automating high volume, highly standardized tasks away from many people at once.

Process Design

Note that some of the design terminology used in this section refers to the Blue Prism platform. There are likely equivalent concepts available on other RPA platforms

After we’ve chosen our Cattle processes, we need to start designing them from a Cattle point of view. Recall that Cattle servers are expected to fail. They are disposable and stateless. These same principles should be applied to process design. Processes should be:

• Designed with failure in mind
  • Use the Work Queue Item Status to keep track of what process steps have been completed. If the whole Work Queue Item needs to be retried, check the Status and skip process steps that have already been successfully completed
  • Have exception handling with retry loops to retry common failures that happen inside your process, such as application and page loading timeouts
  • Consider splitting the process into multiple processes and queues. For example, it is common for processes to have a “notification” or “reporting” step after completing the required work. Creating the report and emailing the results can be split off into a separate process to prevent email failures from marking the entire process as an exception
• Replaceable and stateless. Avoid storing anything on the Digital Worker or assuming the state of the computer system. If state is needed, it should be stored in a central repository that is accessible from all Digital Workers, for example: FTP, network attached drives, or cloud storage. Design your process to work on any computer that has the correct set of applications installed. This will help ensure that many runs of the process can occur simultaneously

Adopting the Cattle way of thinking has led to more robustness, fault tolerance and scalability for IT infrastructures. It can do the same for your RPA.