Welcome to Synpulse’s digital reading experience – Please choose your region of interest

The Magazine
Management. Expertise. Inspiration.

Date: 24/11/2021

Title: Your Architecture Setup for Automation

Teaser: Best practices to follow for an on-premises robotics deployment. One of the main reasons RPA initiations are delayed or fail is poor architectural setup. Read about the pitfalls and how to avoid them.

Button: Find out how it's done


graphic graphic

Your Architecture Setup for Automation

Best practices to follow for an on-premises robotics deployment.

It’s common knowledge that globally 30-50% of all robotics projects fail. A significant reason for this is poor architecture set-up. So don’t fall into this trap: read this short, synthesised guide to two possible solutions – Blue Prism and UiPath – their functions and merits, and examples of a poor approach to the setup.

Authors: George Peters | Blair Cowan 

Blue Prism Setup

graphic graphic
Figure 1: A typical Blue Prism architectural setup. Coloured swim lanes represent an independent virtual machine. Red = PROD and green = DEV

The Blue Prism architectural setup can appear to be a bit of a minefield. But we at Synpulse take care to guide our clients through this crucial first step. Figure 1 above shows the six virtual machines (VMs) that are required in an ideal solution and how they interact with one another. There are three core environments. One of the most important things to note is that each environment is split into test and production, with the former dedicated to the initial build and testing, and the latter committed to running the process live.

But first, back to the three different environments. The interactive client on the right-hand side of Figure 1 is where the main bulk of the configuration is performed and where the developer will spend most of their time. There should be no reason to interact with either of the two other environments while in the development stage of the project.

The run-time resource on the left-hand side of Figure 1 is the environment that the process will run in when in live mode. We suggest keeping access to the run-time resource as limited as possible. There are technical means available to avoid this

The application server VM in the middle of Figure 1 is the environment that usually hosts the SQL database and essentially moulds the three different environments together and directs the flow of information from the databases to the other elements of the architecture. Although you could theoretically develop in this environment, usually no configuration is to be done here.

The main benefits of splitting the architecture into several environments include ensuring the confidentiality, reliability and scalability of your RPA solution going forward. It will also enable you to get your RPA project off to a swift start.

Avoid pitfalls & read the full version of this article, available as a whitepaper.

Get the full white paper

UiPath Setup

graphic graphic
Figure 2: A typical UiPath unattended architectural setup. Coloured swim lanes represent an independent virtual machine. Red = PROD and green = DEV

We’ve talked about Blue Prism, the first RPA tool of its kind. Now let’s move on to the most popular RPA tool by revenue: UiPath. There are both similarities and differences. Figure 2 above depicts a typical setup that Synpulse usually encounters on the client site.

Similar to Blue Prism, an on-premises set-up will have an SQL database at its core. Here, all of the information needed to build and deploy automated solutions is stored and called upon when executing commands. Here it’s advisable to split, with a test/UAT SQL database mirrored by a PROD SQL database running in production guise. This design makes sure that you only have production-approved processes communicating with live applications on the client site, and that once processes have been built and successfully tested on the non-production servers they can be released to the production database to run in production. It also guarantees reliability and scalability.

The orchestrator plays a pivotal role in the overall sequencing of processes. It communicates with the databases to pull out desired information needed to run automations. It then directs the recovered information to other elements in the architectural system. There is typically a production and non-production orchestrator.

UiPath Studio is where you perform the main development. Typically there will be a production and non-production instance of this module. Conversely, there will be no Studio on the production VM; only what is known as a UiPath robot. Similar to Blue Prism, the UiPath orchestrator can accommodate multiple robots, both attended and unattended. The UiPath robot can be thought of as an executor of unattended processes. It communicates with the production orchestrator and will run processes with no human intervention via a trigger or schedule.

The final element of the “best of breed” UiPath architectural setup is the production level VM that houses applications such as Tableau or Indexer. It’s optional but highly recommended: it can be very useful for an organisation to have access to logs for trouble-shooting and dashboarding for management information to help guide a business to make informed decisions. It can also be vital for an organisation when conducting audits to have this data, so for most clients this is a must-have.

This setup is widely regarded as the most scalable deployment at a commercial client, as it allows solutions to be controlled in a contained environment, monitored as accurately as possible, and developed safely without affecting business-critical applications and processes.

If you’d like to find out more, contact us or download the PDF with a more comprehensive version of this article.

Download for free

Alternative Designs and Their Drawbacks

The other potential deployment method that UiPath offers is an attended solution. This is where the solution is started, is controlled by and sits on the subject matter expert’s (SME’s) local PC. A disadvantage of this setup is the fact that it requires human intervention, and can be ineffective at scaling an automated process whose goal is to take work off SME hands. In our experience, choosing the an attended solution simply because it’s cheaper can end up being a costly mistake. Time and money can be saved if you consider the long-term scalability of the setup.

graphic graphic
Figure 3: The main benefits of the “best of breed” robotics structures and the impact they have on your architectural landscape.

Closing Remarks

A superior architectural setup is crucial when preparing for an automated solution within your business. One of the main reasons RPA initiations are delayed is poor architectural setup. To ensure you avoid this pitfall, it’s a good idea to understand and follow the steps we’re described in this article.



Marouane Bakhtar

Continue reading and find out more about how to avoid the most common misconceptions about intelligent automation.

Keep reading
Category | 01.12.2019

RPA Part1

Lorem ipsum dolor sit amet consectetur adipisicing elit.

read more
Category | 01.12.2019

Lorem ipsum dolor sit amet consectetur adipisicing elit.

read more
Category | 01.12.2019

Lorem ipsum dolor sit amet consectetur adipisicing elit.

read more
Category | 01.12.2019

Lorem ipsum dolor sit amet consectetur adipisicing elit.

read more
Category | 01.12.2019

Lorem ipsum dolor sit amet consectetur adipisicing elit.

read more
Cookies help us deliver our services. By using our services, you agree to our use of cookies. Find out more.