Effectively leveraging RPA
--
Is RPA alone enough ? 😊
While organizations are trying to use RPA, it’s really critical to understand how to effectively orchestrate RPA processes using various architectural patterns. For example Microservice based decoupled architecture or component based development. These patterns help avoid redundancy & promote re-usability. In Microservice based architecture, each service is a domain service & caters to one specific domain. These services work together to solve a business goal. Business process is not just one activity however a set of activities executed in a particular sequence.
Why architectural patterns intervene everywhere
While implementing RPA solutions, I ended up having one bot with 1000s of lines covering the whole business usecase. This not only makes the process complicated to understand, difficult to maintain but also it’s not reusable.
I started pondering about leveraging Microservices based architecture or component-based development to decompose a big giant bot to small reusable bots which serve different parts of the process. After creating these small bots, we need an orchestrator which co-ordinates the flow of these activities. Not only that, different business processes can have their own orchestrator leveraging the same set of activities with their own sequence of actions.
Well RPA is great, what about cloud technologies like AWS, business processes in Camunda, can they be integrated with RPA ? Well the answer is Yes. In this article I will deep dive how to use architectural methodologies to orchestrate reusable bots as well as marrying various technologies to achieve business goal.
Let’s get into action
Let’s consider a usecase for getting an insurance declaration which is pre-requisite for closing the loan.
Here insurance ordering system & loan processing system doesn’t have sophisticated integration mechanisms like API or event-streaming. This is where RPA shines & here is how it can be orchestrated to leverage component based development.
This RPA bot works as an orchestrator to call child bots which perform individual tasks like fetch policy details, order insurance declaration etc. Now question may arise, why to complicate this simple process? Well here are the benefits we get with this approach:
Reusability : These individual bots are reusable bots & we can have another business process which can reuse them
Flexibility : If any of these activities are not required with other insurance provider, we can have another orchestrator which can reuse only part of these activities.
Improves productivity: As we keep building these reusable bots & store them in repository, they become reusable assets which other people across organization can reuse.
Can I use anything other than RPA please?
Well we have not answered cross technology integration yet, I know, & that is where I am going now 😊
Say few months down the line, insurance provider has API for fetching policy details & there is an API over legacy system for updating loan status, it’s ideal to use API based orchestration over UI based, isn’t it?
Well am I going to write this all over again ☹. The answer is No. This is where our architecture shines in, just by changing few boxes our API is hooked in 😊
This is great, few months down the line except couple of tasks we have API’s for everything, do I still need to use RPA for API calls & UI integration. Well, not necessarily. If you have an existing business process, say in Camunda, it can orchestrate calling those API’s including a RPA bot which is exposed as an API.
Another scenario could be, If you have a cloud based echo system in AWS, you may have a Step function which orchestrates these API calls, including calling the RPA bot via an API. These are just examples, world is full of technology options 😊.
Summary
Right architecture & architectural patterns bring agility to the table, improve productivity & provide plug & play.
I hope you enjoyed this article, in-case you have questions don’t hesitate to ask 😊.
