RPA Technical Insights, Part 7: Selecting the Right Code Structure for Process Design

David BrainBlog

This is part 7 of a 22 part blog series by the leading experts at Symphony Ventures. It addresses how to choose the right RPA tools for your business needs. Drawing from our global team’s extensive knowledge in automation consulting, implementation, and managed services across a range of diverse industries, we’ve drilled into the technical criteria to consider when selecting which RPA software best enables your company’s digital operation strategy.

Read part 6, Understanding the Learning Curve.

An RPA tool’s architecture can often affect usability and the direction of development. Different tools take different approaches to designing and constructing automations. These approaches can have asignificant impact on the effectiveness and resilience of the solution and the speed of implementation. Knowing the differences between the two approaches will help you chose the tool that is right for you. This blog will present the merits of both approaches and their implications of your project and your Center of Excellence (CoE).


Tools that adopt a functional structure are easy to get started with and quick to program in. They, by default, produce single scripts for the end to end process which include all elements, integrations and business rules. This is intuitive to teams who are familiar with producing macros or Standard Operating Procedures.

Functional tools also have another unique advantage – a recorder function. This can help speed up the configuration of the ‘happy paths’ through the process, but will not capture all routes, so will need supplementing with additional configuration once the recording has been made.

Not all tools that have a functional structure by default need to be used that way, some in the market enable the person configuring to produce code structures and take an object oriented approach, but this must be very carefully designed and implemented. Failure to manage this tightly will result in a mixture of approaches.

If you are embarking on a project with a functional based tool, then consider how you will use this and whether you wish to create reusable components based around screen elements, and whether your chosen tool can enable such an approach. Creating reusable components will slow down the initial build, but as you will read later provides great advantages with regards resilience and risk around future changes.

When deploying a functional based tool, we advise you to consider code management and governance and build these into your plans and your teams capabilities.

Object Oriented

Tools that use an object oriented structure bring different considerations to your project and CoE. These tools often do not have recorder functionality and require a greater level of design before commencement. When deployed appropriately however, these tools provide great reusability and resilience, which in our experience pays dividends in the long run. By separating out screen elements, from reusable objects and business logic, you can have multiple people working on the same automation at the same time. This not only reduces end-to-end build time but can help in ensuring that your process architect, often the bottleneck on a project, only spends their time working on the critical path activities of building the business rules and logic.

The real advantages of an object-oriented approach become more obvious over time. When embarking on your second, third or fourth process automating the same systems you find you have a lot of the components already built and can speed up configuration significantly.

When it comes to the ‘run’ stage the advantages are seen further. A lot of the changes made to an RPA process when in production relate to changes to the systems that are being automated. I.e. a new release of SAP requires a change in the RPA configuration. In a functional oriented tool this requires going through all related scripts to look for where the change needs to be made. In an object oriented tool there is one small script that needs changing. By limiting this maintenance work to the application connectivity layer, you are avoiding the risk of any process changes as the business rules are not included in the same object. This significantly reduces the risk of unintended changes.

Considerations When Selecting a Tool

While the two design methodologies listed above are not strictly enforced by all RPA software, each vendor has its own form of best practices and limitations which, in use, encourages or restricts you to one of the two. Based on the architecture of their software, a certain design methodology might make more sense. In any case, facilitating durable and efficient solutions requires one to follow some general design considerations.

One factor to focus on is solution durability, which has a large impact on usability. An automation that requires constant maintenance due to bugs can end up incurring delays. An automation especially cannot afford to break down when in use. This why an automation process must be built with long-term durability and transformation in mind. Safeguards like extensive exception handling can help, but the most important factor is a well-built process. With a comprehensive design methodology, developers can avoid common mistakes and build automations to last.

Another consideration is the business-level organization of the automation. It is crucial to have flexibility when it comes to modifying business components. Enterprise-level RPA is often implemented with a modular, hierarchical system that allows for easy process substitution, simplification or add-ons. It is up to a properly executed design methodology to ensure that these standards are met. When implemented well, this will not only increase solution durability but also hasten turnaround times for development.

It is also prudent to consider how certain practices can add to or detract from a developer’s experience. Methodologies each have their pros and cons. For example, deciding to use a single level process as the base of an automation is often a faster, simpler way to automate a process. However, it can lead to problems later when accounting for exceptions and design constraints. On the other hand, creating an object-oriented system requires long-winded initial development, but can be easier to modify with changes down the line.

Successful Designs Lead to Successful Deployments

When processes are deployed, success ultimately comes down to the solution design that was used in development. Decisions such as emphasizing exception control will result in robust solutions that require minimal user input. Whereas putting such components aside can cause inefficiency and increase risks of automation errors. Given the need for well-structured design principles, it is up to the business to adequately prepare for RPA development. To provide clients with the highest-quality service, Symphony has compiled best practices for many major RPA tools. This ensures that client automations are built with best principles in mind, knowledge which is continuously updated from our various deployments. For more of our content, explore the rest of our technical insights blogs.


Be sure not to miss part 8 of RPA Technical Insights, where we have a look at the benefits of building sustainable components into your RPA solutions.

Share this Post