Microbots Architecture for RPA

Independent, self-contained, reusable, exchangeable and single objective.

My main goal in this post is to share an architecture that I have been developing and using to build my automation. This is not a new idea for the software development industry, so what I am doing is exploring these concepts for automation development.

Microservices have been gaining many adherents in the software industry since people have been observing the benefits in adopting this approach. Moreover, it is possible to notice the relevance when companies like Netflix and Amazon are committed to use and contribute to the development of the architecture.

Honeycomb

There is a very interesting analogy between Microservices and honeycombs described in “Microservices: Building Scalable Software”.

"In real world, bees would build a honeycomb by aligning hexagonal wax cells. They start small, using different materials to build cells. Construction is based on what is available at the time of building. These individual cells collectively form a pattern and result in a strong fiber structure. Each cell in the honeycomb is independent (decoupled) but also strongly integrated with other cells. By adding new cells, the honeycomb grows to a big, solid structure. The content inside each cell is abstracted and not visible outside. Damage to one cell does not damage other cells, and bees can reconstruct these cells without impacting overall honeycomb"

These features similarity are very curious and you will see throughout this article that it is actually present in Microservices Architecture and also in Microbots Architecture.

Portability

The article developed by Martin Fowler and James Lewis about microservice is very quoted and respected, for this reason, I have used this article as a basis to write this essay about Microbots Architecture.

As mentioned earlier this approach has been already used and endorsed by software development industry, then what I have done was to apply these concepts in automation development. I have named it as Microbots Architecture, in spite of having several similarities with software development an automation has some innate characteristics and applicability. Therefore, there are peculiarities and limits that need to be explored, for that reason, I have thought it was important to use a different name. A new name makes possible to explore it in an independent way in order to adapt this architecture to the challenges inherent to RPA development.

Microservices and Monolithic Architectures

As this approach has been creating under the Microservices Architecture idea, therefore it is important to establish a formal definition for Microservice, therefore:

 "In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies." (Fowler and Lewis)

This definition is also acceptable to Microbots Architecture. However, there is an issue in the definition that needs to be tweaked to the reality of automation development. Performing the robot communication over the HTTP protocol entails an unnecessary complexity, for this reason, I prefer to opt for a shared database or use queues, in order to keep a simple communication system between the robots. Evidently, without losing the robots independence.

I have been noticing that there are a preference to create automation using a monolithic structure, consequently, it is being created without modularity. In other words, using the monolithic approach the automation will perform all the process tasks and actions or at least the major part. Although a monolithic construction can be modularized through internal design, it will generate a dependence between the parts. 

Characteristics 

We need to beware of monolithic applications scalability, since these architectures are scaled horizontally, therefore, any changes made in the automation must be replicated to all instances in execution. Besides that, small changes may impact the whole automation.

In the Microbots Architecture, we opt to scale on-demand when it is necessary to increase the processing capacity at a specific point. Therefore, we only need to replicate when and where it is necessary.

Supposing the following scenario:

"We need to read a file and insert the data in two systems, A and B."

We could create a single sequential automation to read and write in A and B. However, assuming that the insertion in A suddenly starts taking a very long time and it is necessary to replicate the automation, in order to perform A in an acceptable time. In monolithic constructions, we must replicate the whole automation instead of just escalating the action which is the bottleneck in the automation. Following has an image to make it clearer,

In a Microbots Architecture, each action (Microbot) will be separate in an instance and it will be replicated as needed.

A monolithic automation put all actions into a single instance and scale by replicating all the actions.

Microbots must have their boundaries well-defined and must be able to run independently, in other words, they must be self-contained. Therefore, they must perform their tasks independent of the integrity and execution of the other microbots.

This independence and self-sufficiency make possible use the most appropriate technology for each situation, let’s assume the following scenario:

"There is a business process that must read data from an application in a Citrix environment and then insert the data into a local web application."

Working on this scenario using the Microbots Architecture, we could use two distinct technologies for each action, that is, we could use UiPath to read data via Citrix and Blue Prism to insert data into a Web application, and furthermore, we could use different teams to build the microbots. 

Note: In this example, the two technologies mentioned were random choices, so there was no comparison to evaluate which would perform better with the Citrix or Web scenario. They were cited just to exemplify the possibility of using different technologies.

Another benefit would be to choose the technology based on the cost, since, there are many technologies that can perform almost in an equal way. Consequently, the technology could be chosen by the cost of implementation or licensing. The main point is, you are free to choose the better way to solve the issue and acquire the highest benefits.

Additionally, you can use unconventional technologies for RPA to increasing savings and performance. As an example, you may use languages like R or Python to manipulate large data collections.

The crucial point is that your architecture will be oriented to better fit in the action, in other words, will be possible use the best way to perform the action within the process that will be automated aiming at cost optimization, performance, scalability, stability.

Componentization

For several reasons such as flexibility, reusability, scalability, the software development industry has been trying to build plug-and-play applications, that is, applications that can be assembled and deployed at runtime without prejudice to the whole.

"For as long as we've been involved in the software industry, there's been a desire to build systems by plugging together components, much in the way we see things are made in the physical world. (Fowler e Lewis)"

In the automation development is not different, this benefit is also desired, and it is possible using a componentization approach. Therefore, we must focus on creating microbots with limits well-defined, with a single objective, independent, self-contained, designed to reusable and exchangeable. 

Decentralized Governance

This topic is undoubtedly a point that makes this approach even more attractive,

"One of the consequences of centralized governance is the tendency to standardize on single technology platforms. Experience shows that this approach is constricting - not every problem is a nail and not every solution a hammer. We prefer using the right tool for the job and while monolithic applications can take advantage of different languages to a certain extent, it isn't that common." (Fowler e Lewis)

It is not mandatory use several technologies, however, the freedom and flexibility provided by the architecture are important.

Microbots Repository

In this model, reuse is a premise and the independence of the robots is something that allows creating a repository of microbots, which can be reused, this leads to savings, delivery speed, stability and increase the code quality.

Assuming the scenario,

"There are two distinct projects made by distinct teams and the action scope is to automate the extraction of reports from the SAP at a particular point in the automation."

A repository idea is to provide for these teams a way to reuse a microbot, for example, a robot able to extracts SAP reports. This extraction may be a small piece of automation, but no make sense write two times the same robot or almost the same.

Someone may argue that there are peculiarities for each process, in fact, it is true but the basis would remain the same and the peculiarities issues could be worked through parameterization.

"Netflix is a good example of an organization that follows this philosophy. Sharing useful and, above all, battle-tested code as libraries encourages other developers to solve similar problems in similar ways yet leaves the door open to picking a different approach if required. Shared libraries tend to be focused on common problems…." (Fowler e Lewis)

Design For Failure

The automation needs to be designed to tolerate any microbot failures. The robots independence must ensure the automation integrity, ignoring failures in parts. These characteristics give us the possibility to generate a command center since fails are accepted we should monitoring it in order to recover the microbots quickly, or even for scaling.

Final Considerations

Although Microservices is not really the proper architecture to develop automation it was possible to import concepts to Microbots Architecture, adjusting and apply it to the automation development.

I have no intention of saying it is a perfect solution or an ideal architecture, I wrote just for the purpose of sharing my experience and how I have been building my automation. 

Thank you for your time,

I would like to kindle thanks for the translation:

Russian (Dr. Nikolai S. Kabanov)

Please contact me if you would like to translate for your language.