Evolute Consulting - Architecture & Process

The interest in RPA is undeniably there. Looking at the Google Trends graph for RPA below, there is a spike in interest at the start of 2018, and its interest has held nearly stable all the way up till now. Gartner predicts that RPA will become on of the top five investment priorities for CIOs by 2020, proclaiming it a major player alongside Cognitive Process Automation (CPA), characterized by machine learning and other AI developments. Similar numbers come from the McKinsey Research group where they estimate that by 2025 RPA will have an economic impact of 5 to 7 trillion dollars and will affect the jobs of more than 230 million knowledge workers (9% of the global workforce).

Before we can assess where to use RPA, it is helpful to put a finger on what it is. It is configurations that allow for the automation of manual and repetitive tasks through the use of virtual (read software) robots that can integrate with existing software. These repetitive tasks are mostly desktop actions such as for example filling up a spreadsheet with numbers coming from a different system. These configurations are typically driven by simple rules and business logic. Forrester Research defines it as such:

As mentioned in my recap of bpmNEXT 2017, Neil Ward-Dutton (MWD Advisors) builds on this definition of Forrester Research to introduce the three layers of RPA, where he states the evolution of RPA to progress from automated components to which humans must adapt into automated components (through machine learning for example) that adapt themselves to their environment. He also emphasizes that we are not yet at the point of job automation, or even process automation through robots, but rather still at a task level. The drivers for this evolution are rapidly evolving technologies, business pressures, and a pervasive familiarity with intelligent devices becoming common place.

Neil Ward-Dutton's Three Layers of RPA

A quick overview of the important players as stated by Gartner’s 2016 report, divided by their focus on RPA:

RPA Specialist Software Providers	Multiple Software Offerings (Including RPA)	IT and BPO Service Providers That Own Proprietary RPA Software
Automation Anywhere	Jacada	Infosys AssistEdge
Blue Prism	Kofax Kapow	Syntel
Epiance	Nice	Tech Mahindra
Exilant	Pegasystems	Conduent
OpenConnect	Verint
Kryon Systems	Redwood Software
UiPath	WorkFusion

RPA is poised to answer the demand for early wins and fast time to value for business opportunities. It aims to bridge the gap between systems and people by automating the process that could flow across multiple components within an enterprise application landscape. It does this by not so much focusing on the technologies being used in each of these components, nut by focusing more on what needs to happen from a functional and/or process standpoint. Ordina’s key points for RPA adoption by companies are threefold:

1. RPA automates processes from the user’s point of view and saves costs. Fewer mistakes, fewer administrative staff and higher employee satisfaction.
2. RPA enables your business to transform digitally faster without major modifications to your legacy back-end systems and other applications.
3. Your organization has an efficiency and process improvement. An extra step towards operational excellence.

In order to determine which opportunities are suited for the RPA approach, we can conclude that manual and rule-based processes, that are either high in volume or long in handle time or error-prone (for example manual copy/paste operations) make excellent candidates for robotic automation. Even better if these processes would be standardized and mature, meaning not changing a lot any more over time. This value proposition does however sound like it attacks the same prospects as would a BPM solution that makes use of a IBPMS. However, where RPA is a tool that involves automating the business processes and rules within an organization, it does not give us the tools for process redesign, but on its own be just a tool to implement as-is processes. It woud be more an alternative for an IBPMS than a replacement for the BPM discipline.

Familiar concerns arise when RPA vendors start talking about RPA tools that have a metalanguage easy enough for business user to master. This sounds very much like the zero-coding promise made by vendor of iBPMS systems. And as such, the four myths of BPM stipulated by Sandy Kemsley will also apply when going for an RPA approach:

1. Business users WILL create executable process models RPA configurations
2. Business users/analysts CAN create executable process models RPA configurations
3. Business users/analysts WANT to create executable process models RPA configurations
4. IT WANTS business analysts to create executable process models RPA configurations

The first statement we will call the Volition Myth. Vendors will try to create the “Field of Dreams” mentality of “If you build it, they will come.” Meaning that if you provide your business users with the capability of creating and maintaining their RPA configurations, they will do so. The reality is that these people have more than enough work without having to worry about this as well. They simply lack the time to put in the effort.

The second statement (called the Capability Myth) is what is generally presented by solution vendors as the “zero-coding” advantage, this is that business people will be able to change their applications without intervention of the IT team, therefore cutting expenses and reducing the time-to-market. While this might theoretically be possible if business processes are relatively simple, the reality is that most implementations are still complex, and thus development projects, with all the requirements and best practices a full-blown software development project entails. Not only do your business users need the analytical skills to determine pain points in the process, they need the modeling skills to properly translate their solution into the configuration as well.

The third statement is known as the Desire Myth. In most companies, there is a long-standing tradition of systems functioning correctly being the sole responsibility of the IT department. One of the goals of process automation efforts is that a joint accountability is created for the workings of such a system between business users and IT. Most business users are not that keen on taking on this increased level of responsibility.

The last statement is the Desire Redux Myth. The previous 3 myths address the qualms of the business users, but there are also qualms in the IT department camp. As mentioned in previous myths, business users need a lot of knowledge to be able to work well with process modeling, and most IT departments regard business users as being unable to model even the logical view of a process. And in most cases, they are right. Mostly, process modelers are business users that have been promoted into the job without any formal training.

So, when I said earlier that RPA is an alternative to an IBPMS, it is worthwhile discovering the differences between these two types of automation tools. A the very least, RPA seems most suited for the typical processes I described above, where IBPMS tooling can be used for virtually any type of process (with varying degrees of effort). In essence, RPA is about a robot replicating monotonous actions a human user would perform in computer system, where BPM technologies will allow for the orchestration of process across human participants, computer systems, and the aforementioned robots.

So, is one of these strictly better, or is there a nuance between them that lets us differentiate the two? Let’s examine their key differences in the table below:

RPA	iBPMS
Lightweight implementation process: Easier to deploy Faster time-to-market	Heavyweight implementation process: More governance options More monitoring interactions More Process Exception Handling
Non-disruptive to existing way of working to have a cost-effective way to deal with process inefficiencies.	Significant and Transformational redesign of processes to achieve gains in productivity and efficiency.
Focuses on Operational excellence or realizing business value for short-term results.	Can be geared towards Operational Excellence, Customer Intimacy, Product Leadership or any other strategic consideration.
Easier integration automation for components not accessible by API (e.g. Legacy systems)	Predisposed to conduct integrations with computer systems through standard APIs.
Best suited for “swivel chair” manual processes or for high-volume, repeatable tasks within more elaborate processes.	Suitable for the orchestration all types of processes across human participants, computer systems and RPA robots.
Focuses on processes performed in their entirety by a single user.	Focuses on processes across several distinct participants.

It becomes clear that RPA can be leveraged for a specific types of processes and/or tasks. This is only a subsection of what is possible in a full-fledged BPM approach, but RPA does offer some possibilities for initiatives within this approach that a standard iBPMS doesn’t offer. Very similar to creating this business process in an iBPMS is to orchestrate it using services. This is what could be conceived of as Sagas in Micro Services Architectures and Task Services in the more traditional approach of Classic SOA. And for me, the relation between Micro Services and SOA Services is very similar to the relation between RPA and iBPMS workflows. On the Camunda Blog, there is a BPMN model about an example process to embed an RPA process as a system task into an iBPMS process:

One part of this similarity can be seen in dealing with the amount (or lack) of human interactions in the process and the orchestration thereof. Where Micro Services and RPA tend to focus on removing human interaction as much as possible, iBPMS and Classic SOA tend to unite the different actors (human or system) in a coherent result. Eloquently put, RPA and Micro Services are geared towards replacing human tasks, where Classic SOA and iBPMS are geared towards assisting human tasks. Providing this possibility of human interaction within the orchestration also greatly enhances the functionalities for dealing with unstructured data. RPA flows and Micro Services feel more at home in the realm of structured data.

Another facet of this similarity is the tradeoff made between faster time-to-market (Micro Services or RPA) and stronger governance (Classic SOA or iBPMS). This is directly related to the frequency of change in these components. If we regard Gartner’s Pace Layered Architecture again: When a component isn’t a system of innovation, and thus not that critical for the continued progression of you organization, the increased time-to-market speed becomes less relevant, and you might wish for more control over the change of these components, and more specifically the impact this change has on the overall application landscape. In extremis, we abandon custom development altogether and implement our systems of record with Commercial Off-The-Shelf (COTS) software.

Combining these considerations, we can form a form of lifecycle for software functionalities, which progress from having to be an early-on quick win solution with RPA through a solution which has less technical debt accumulation, but which still retains a fast time-to-market with the ability to flexibly change (micro services). Next step in this progression would be to make the process canon for your organization, because it has become less prone and move it into the classic SOA/iBPMS arena. Only to end as a process that rarely alters anymore, and has become commodity for its industry, and which at that point benefits from the economy-of-scale a COTS implementation represents. This leads to the following diagram for the architectural tradeoffs:

A short coda moment to this article: As there was with every automation in human history, there are always those voices that rise up to acclaim such automations will take away jobs from human workers, but so far, no indication of this being true has been seen in companies adopting such transformation projects. Where manual labor is taken away from employees, their time is freed up to perform more meaningful and value-adding jobs within their companies. All work in human history can be divided into two parts: First we think about which steps are needed to achieve the desired result, and then we execute these steps. RPA as most of its predecessors focusses on the latter type of work. As a society we move our human work from an executive mode to a more validating and overseeing mode.

Thought

SOA

BPM

Business Architecture

Comment