Automation Design Principles to Help You Scale RPA
I joined UiPath and the robotic process automation (RPA) world two years ago after being a software developer for more than 10 years. It was quite easy for me to get started since automations were built on top of .NET and many of the technologies I had already worked with.
The UiPath framework itself is easy to use and to start with, even if you do not have software development experience.
RPA is often introduced by businesses, most of the time starting in one department (finance, or human resources, for example). As IT and business work together to scale automation across the organization, there are four areas that can help with scaling: best practices, tools, automation operating model, and design and development principles.
I’ll briefly discuss the first three (UiPath best practices, tools, and automation operating model) and include links to helpful UiPath resources. In this post, I’m primarily focusing primarily on design and development principles.
1. Best practices in automation
The UiPath documentation contains a lot of best practices starting from user interface (UI) automation to naming conventions, security, and governance and project lifecycles.
Use them! There is already plenty of experience writing automations and the UiPath Community has come up with a lot of best practices, such as:
Create and use a naming convention—it is much easier to work together if everyone is using the same format and language.
Run Workflow Analyzer before you commit your code.
Use governance files to enforce rules and control over functionalities. Automation Ops, currently in preview, will help you manage the governance rules in a centralized way.
Deploy more than one Orchestrator to separate non-production development and testing environments from production environments. If you are using
™, you can do the same thing by using multiple tenants.
And the examples can continue. Check out the links below for more in-depth reading:
2. Tools used in automation projects
In software development, tools are part of the process. You do not start without unit tests, and you set up CI/CD as soon as possible. A nightly smoke test will identify if a bug has been introduced during the daily development. UiPath Studio can be used with GIT repositories, Microsoft Azure DevOps Server (formerly called Microsoft Team Foundation Server), or Apache Subversion (SVN). There are ready-built plugins for Jenkins and Azure DevOps, or you can use PowerShell scripts for other CI/CD tools.
With RPA testing, application changes can be found much faster. The sooner you find an issue, the less expensive it is to fix. If you must investigate the production environment, you might need to involve people who have the required rights. Their time is surely expensive. You might also need to contact people for approval.
Try to write tests for all the key features. There are several types of tests, each with their own purpose. Think of unit tests, integration tests, functional tests, or end-to-end tests. It is hard to achieve 100% coverage, but it can be realistic to keep it over 90%. If you find a bug, try to add a test for it. UiPath Studio provides functionalities for mocking to help you achieve this high percentage.
3. Automation operating model
An automation operating model is a comprehensive view of the program management decisions that need to be made, such as roles and responsibilities, governance, and infrastructure management. Executives often raise questions about how to get started with automation quickly and on the right track. Executives also typically ask about determining the required resources or how the enterprise should be organized for automation success. All of those questions can be addressed by an automation operating model.
Seth Catalli has written a fantastic, three-part blog series on automation operating models. Start with Benefits of an Automation Operating Model (Part 1).
Now let’s take a closer look at how development principles can help you build better, more robust automations.
4. Development principles
If you have identified a problem, you want to be able to fix it as fast as possible. Even if you are using all the tools, and your automation passes all the analyzers' rules, follows all naming conventions, and passes through all development cycles, your automation might still be difficult to change. You can deal with this problem by following these simple design principles (below). They are well established in software development, and they can be useful in RPA too. The examples below are based on features from the UiPath framework, but the principles are agnostic of technologies.
Single responsibility principle
A component should do a single thing and it should be used just for that purpose. Your library should only serve one purpose.
For instance, an SAP® library should only have SAP logic, nothing else. Emails or Microsoft Excel operations should not be part of this library. A workflow for an SAP transaction should only serve that logic. It should not contain the invocation of any other transaction. It should not do any data processing. It is not part of its job. The arguments should only match the fields from that sequence. A datatable from which I will compute data is not to be used here. Query the data before and pass it as an argument.
This can continue with everything that you can identify as a component. It can also be a container sequence, or a snippet, or pretty much anything. Moreover, it can be features, functionalities, etc.
Separation of concerns (SoC)
Try not to mix application automations or logic. If you need to automate two or more applications in your process, do it one after the other. Read the data from files separately before dealing with user interfaces. Do the same with emails or API invocations.
Each distinct section should address a separate concern.
Often, processes can be split into separate processes using queues. If you notice that a part of the process does not have anything to do with the queue item you’ve started from, it is a candidate to be extracted to another process.
Grouping logic that belongs together in a sequence container is also good practice to separate it from the rest of the process.
Any unnecessary dependency increases complexity. If your process does not have anything to do with Excel, remove the Excel dependency. At some point, you will have to do some work to update the version. It is the same with everything you can identify as dependency.
Don’t repeat yourself (DRY)
Identify repeating logic and extract it to a common place. There is a single place where maintenance work needs to be done. This can be a sequence, a snippet, a template, a folder, a library, or a new object repository. In Object Repository, you can collect UI elements and reuse them. If a selector is challenging, you only need to deal with it once.
You ain’t gonna need it (YAGNI)
Always develop something when you need it and only when you need it. Do not prepare for something you are not facing yet.
Complicated, generic solutions are a common cause for a lot of effort spent on maintenance. Do not try to write such a component unless it is required. You will also spend a lot of time designing it, but also later when you need to change something.
Keep it simple, stupid (KISS)
Simple components or features are easy to understand and easy to change. Often it is another person who needs to keep them up to date, and he will have it much easier if it is simple.
Do not create a workflow to process Excel files as there are already activities to deal with this. Do not use complex UI automation if it is possible and easy to invoke an API.
A particular scenario in UiPath automation is nesting which involves many sequences. Do not nest too many activities. Instead, you can have one activity after the other by adding a variable to the condition. Extract the logic from a foreach or a while activity to a separate sequence. You should avoid nesting and try to keep your workflow easy to read.
If your implementation is hard to explain, it might be too complicated. The same goes if you are having a tough time writing tests for it. This is also a second benefit for writing tests. They help you identify complex components and candidates for refactoring.
You might notice the points from above are slightly contradicting each other. That is correct! You need to find the balance of when to use them, when something needs to be extracted to a different component, or when it is fine to keep it as it is.
If you need some activities to process a text, and the rest of the workflow is quite small, the best option is to group the text processing activities together. If the workflow is already larger, a better solution would be to extract these activities to a separate file. You must decide when to do this. The same goes when extracting workflows to a library.
All the examples above are about some simple scenarios: some sequences in a library, some “if” statements, or a classic foreach. It is always good to start small, but you can also apply these principles to complex processes containing user interfaces, human in the loop, and processes deployed in many folders in UiPath Orchestrator.
All these small issues can add up. You might have to spend a lot of time finding out what a variable is used for because of bad naming. You might be unsure of your changes because you do not know what they will cause and end up spending a lot of time understanding the logic. Maybe a new hire will need to make changes several months later and will be looking at your automations for the first time.
Following the best practices and principles will help you reduce maintenance time.
Happy automation!
Horea Soanca is an Automation Advisor and Senior Sales Engineer at UiPath.
Editor’s note: views represented in this blog post belong to the author and are not necessarily representative of UiPath.
Topics:
RPA
Automation Advisor and Senior Sales Engineer, UiPath
Related articles
