The purpose of this white paper is to propose an engineered approach inspired by microservices to help organizations implement and scale enterprise RPA solutions successfully. The ascent of Robotic Process Automation (RPA) has been disruptive. It has revolutionized the way organizations operate business processes, yielding efficiencies, and economies of scale while bringing down operating costs simultaneously. Global spends on RPA programs are being projected to rise to 2.4 billion USD by 2022, according to a Gartner report . Organizations are seeking to embrace RPA solutions swiftly while aspiring to realize productivity gains with minimal CaPex (capital expenditure). However, good intentions and promising technologies alone cannot yield the desired results. Organizations are facing teething issues while scaling their RPA implementations from individual business process automation to enterprise-grade RPA. These challenges are classified into three themes — bot instability, low bot velocity, and code base complexity issues. Bot instability implies the frequency of bot and automation failures at runtime. Bot velocity is a metric which highlights the speed at which an organization/business unit embraces RPA adoption. It is a good indicator of the scalability of the RPA solution. A combination of these obstacles translates into budget overruns, missed deadlines, and higher operating costs — the very problems RPA was supposed to eliminate. A sub-optimal RPA solution not only results in poor user experience with the technology but also hinders its adoption in organizations inhibiting its true potential, setting back the innovation clock by a couple of years in the process.
Following are some common challenges of the RPA programs.
RPA programs in organizations usually start as proof of concepts or pilots. However, they scale up at an exponential rate when business/tech users get exposed to its power and ease of use. New converts baptized in the ways of RPA adopt a one size fits all approach while attempting to automate complex business processes using a single automation script. This approach works for a while before blowing up. However, what works for an individual business process may not work while automating tasks running across an entire business unit. A poorly implemented solution results in higher throughput times. The ability of RPA solutions decreases to respond to business demands rapidly. The codebase size starts spiraling out of control. RPA Program Managers find themselves staring at projects which do not resemble their former self — when the program started.
Processing time increases drastically, sometimes even higher than the time taken to execute business processes manually. It becomes difficult to scale the solution in terms of functionality as well as the volume, which negates the advantages of RPA solutions and impedes their scalability and associated advantages.
Period As mentioned earlier, monolithic architecture results in a high degree of dependence and coupling within the automation, which results in making change management difficult. Even a minor change results in an impact on the entire automation. Deploying new changes requires exhaustive testing, which results in lengthier development times and slippage in delivery dates. Similarly, frequent changes and the addition of redundant code result in increased complexity, making it riskier to perform changes without breaking pre-existing functionality.
A poorly designed implementation falls in the trap of reinventing the wheel. Components which could have been reused are repeatedly implemented throughout the automation script resulting in more boilerplate code. Inability to reuse component not only adds to the development effort but also results in a bloated and error-prone codebase. It also makes change management tedious.
Inadequate Error and Exception Management
A poorly designed implementation adopts a piecemeal approach towards handling exceptions. Such an approach results in bot hardening — a situation wherein a generic automation script is deliberately altered to handle exceptional conditions. Exception and error handling logic are incorporated as and when such scenarios occur at runtime. However, this approach runs into scalability issues as the number of execution paths and components increase in your automation.
Let us take the example of a business process which requires an employee to open an excel spreadsheet. The employee extracts column values from a row and feeds them into multiple systems based on certain business rules. These rules are susceptible to change for technical and business reasons. The automation script can take multiple execution paths depending on a combination of business rules, and the number of systems with it must interact. A non-microservices inspired approach attempts to automate this business process by trying to drill these business rules inside the automation script itself. As a result, the automation script looks like an unwieldy bunch of if-else statements padded with exception and error handling logic.
In the absence of a robust design, developers will continue to ‘harden’ the bot resulting in further deterioration of the codebase. The codebase will be not only bloated but also brittle. The underlying design does little to manage complexity. The possible number of exceptions which may occur at runtime will go on increasing exponentially with the addition of newer execution paths — ensuring that factoring all possible exceptions and surrounding them with code will become either difficult or a tedious activity ultimately burying your business logic in the pile of code.
How do RPA Program Managers resolve these challenges? The answer lies in implementing an engineered perspective to facilitate and scale RPA adoptions rapidly within your organization and adopting a Microservice inspired architecture approach. Microservices Architecture entails following the principle of decomposition on two levels:
● Functional decomposition — Splitting a monolithic implementation into atomic, independent sub-components.
● Horizontal decomposition — Achieving scale and performance through cloning .
A microservices oriented design paradigm advocates loose coupling between data and its corresponding business logic. Instead of implementing business rules in code, we can export and implement in at the data source itself in line with the fundamental principles of microservices. To re-engineer the example discussed earlier, the business rules used to decide which system/module should be invoked can be extracted and applied at the data source(worksheet) itself resulting in a more simplified design. Similarly, by the principle of functional decomposition, the monolithic solution can be divided into independent modules, performing a singular responsibility within the automation script. A modular approach helps us to manage complexity and keep a check on it. Also, incorporating new change requests will getstreamlined, and isolating errors will be easier than the earlier monolithic approach. Instead of adding more boilerplate, errors and exceptions will be better managed using a global exception handling module. A combination of modularization and generic exception management solution will boost bot stability and reduce the need for bot hardening substantially. A micro-services inspired design will improve code test-ability and reduce development times as well. The RPA implementation will be able to respond to frequent business change requests in an agile manner, even when scaled up to enterprise-grade. A microservices-based approach speeds up the development process as teams can work simultaneously on multiple assignments. It also incorporates the principle of re-usability resulting in faster RPA implementations. Microservices’ based solutions coupled with Automation Anywhere features such as Workload Management (WLM) can result in achieving horizontal scaling and reduced turnaround times, thereby realizing the true potential of RPA.
More on this approach will be in following article.