Enhancing UiPath Solutions’ Design Scalability

Making UiPath solutions more scalable at a design level

Designing a solution essentially means that the floorplan of a solution is formed for the team to execute on. The design instructs the team on what needs to be achieved and how it should be achieved. The solution design is debatably the second most important part of the solution, after process analysis, it forms the foundation for determining exactly how much effort the development team should put into developing the solution as well as where their attention and effort should be prioritized and focused.

As such, it is important for the person who is designing the solution to consider all the aspects of the problem, the process, the environment, and the envisioned solution. This can become tricky, and it is easy to get lost in or stuck on some of those aspects which can be simplified through a guided approach to enable an important aspect of any solution – the ability to scale. 

Key considerations 

Designing solutions often becomes easier with experience and a rich knowledge base of the available UiPath products and components that can be used within a solution, but it is important to note that those, alone, are not pre-requisites for being able to design solutions.   

Understanding UiPath products and licensing  

With the UiPath landscape growing as quickly as it has over the last few years, it is increasingly important to understand which elements of the UiPath stack can be applied, in which scenarios, and what licensing implication the implementation would bear. It is an important consideration when designing the solution to ensure that the proposed solution compliments the environment appropriately. 

Understanding the estimated lifespan of the solution

The lifespan of the solution is an important aspect of the solution design as it assists in depicting how much effort should be put into developing the solution. If a solution is estimated to be a stopgap implemented for between 3-6 months, it is not logical to spend a significant amount of time (4-6 months, for example) developing the solution. In such cases, it makes sense to put together a minimum viable product (MVP) to be deployed as soon as possible while the team’s attention is focused on bigger, more long-term implementations. 

For solutions that are estimated to be deployed and executed in production for a longer-term (more than 18 months, for example), which include multiple envisioned enhancements and development phases planned, it is highly recommended that the solution design is approached differently and with more attention. Long-term implementations are more vulnerable to system changes, like switching from Excel files to databases or organizations migrating to different enterprise resource planning (ERP) systems, for example. These types of changes need to be taken into consideration when designing the flow of the design. In traditional development, design patterns were implemented to try to mitigate the effects of these changes and the principle behind it could be applied in such automation scenarios as well.  

Understanding the estimated benefit realization 

Although pre-defined templates, design patterns, and strict development policies can be used to enforce standardization and consistency across an environment, the relevance and importance is debatable and may be very different among environments. Pre-defined templates may follow an environment or organization's approach to automation implementations in a standard way, including all process steps that may be standardized across solutions. Design and/or patterns are a strategy or an approach to development that helps enforce the distinction between layers to enforce the “separation of concern” development principle. There resources are available on the UiPath Marketplace, like this one, that explain the philosophy behind such approaches.   

In many environments, it does not make sense to implement advanced template structures and heavily design pattern-driven solutions for small/temporary automations. The estimated benefit realization should balance with the estimated resource allocation which is collectively constructed through the development time, the cost of development and the scope of development. It remains important to still adhere to certain standards and conventions when developing temporary automations, like the use of a Global Exception Handler as well as the use of annotations and naming conventions. Testing strategies should also form an important part of an automation environment and may be implemented very differently across environments. As such, it is important to ensure that a testing strategy exists and that it is addressed in the solution design.  

Validating a solution design

Validating a solution design  

One of the most difficult parts of designing a solution is the ability to verify its feasibility and validity before handing it to the development team for implementation. Based on the key considerations explored above, consider the following list of possible recommendations: 

# Recommendation

1 Use standardized naming conventions as well as usage of variable/argument and annotations

2 Modularize the code (consider a design pattern)

3 Consider an alternate component/product

4 Explicitly define in solution design

5 Reconsider automating the process

6 Reconsider implementation degree of modularization. Modular to exactly what is necessary

Each of the above recommendations can be used as possible outputs that can be improved upon to address the validity of the solution design. A set of questions can be grouped by categories, aligned with the above, and the answers to each question would render a number related to the recommendations listed above. The questions are posed below and can be refined based on environmental need:

Once the solution design has been validated, the development team can keep the responsibility of focusing on the effort required to develop the solution by the solution design. It is important that developers trust the design they have been given so that the solution that is developed maintains the same level of trust before being deployed. Well-designed solutions should lead to well-developed and easy-to-enhance, scalable solutions.