In the world of process automation, the key to success lies in the structure. Imagine your RPA operation as a house; without a solid foundation, it won’t withstand the changes that come from the business environment.
Any digital solution requires a plan, breaking down the tasks needed to achieve a desired goal. The agility and duration of the plan depend on the maturity of the solution and the defined objectives. Often, software development initiatives begin with a sketch or a proof of concept, with a focus on proving a concept in an exploratory manner and accumulating valuable experience.
Once the concept is proven, it’s crucial to define a comprehensive implementation plan. This includes considering various aspects such as tasks, milestones, teams, risks, infrastructure, support, and end-users. Planning should encompass a broader time frame and complexity. Many times, solutions are created to address immediate problems without considering the necessary changes in the technological, operational, and process ecosystem of organizations. The rigidity of these solutions can hinder their ability to adapt to new needs and teams, increasing the effort associated with change.
Initiatives related to process automation and RPA (Robotic Process Automation), as part of the software and digital solutions category, are no exception. Therefore, it’s essential to clearly define the architecture to be adopted, considering that each corporate technological ecosystem is unique. The RPA solution itself must take into account various points, which may vary depending on the solution adopted, such as the type of robots to be used and the allocation of machines – virtual assistants or autonomous, as well as the existence and hosting of orchestration, including license allocation and management.
Based on our experience with clients, we have identified five fundamental considerations in defining an architecture for an RPA solution:
Security
Security requirements influence the configuration of robots and the location of orchestration/data. Most solutions assume that robots operate within the organization’s infrastructure, whether in the cloud or on-premises. However, for larger organizations and depending on the criticality of process data, the orchestration server can also be hosted in the organization’s infrastructure. Major RPA software providers, such as UiPath or Robocorp, have their servers hosted in well-known and secure clouds, following high-security standards. Access control and roles must be carefully managed by RPA Center of Excellence (CoE) administrators. Passwords and credentials should be securely stored and encrypted, in orchestration vaults, and should never be written in execution logs of automations. Users with access to robot machines should store passwords in secure vaults, such as Bitwarden. We recommend a clear distinction between robots, orchestrators, and development, quality, testing, and production environments. Data and systems in non-production environments should be replica and fictitious versions of production data.
Audit
It’s essential that the RPA architecture, through solutions and best development practices, allows for the production of records and logs that enable the evaluation of possible application non-conformity situations or automation executions. In mission-critical operations, alerts should be triggered to enable rapid action by support and business teams, if necessary. A solution that doesn’t maintain a complete record of everything that happens is potentially dangerous since strange or anomalous situations can occur in any software, especially if it’s complex and extensive. Audit mechanisms serve as an anchor to regain control in these situations, providing quick action by support teams.
Scalability
It’s important to understand the scalability potential and align it with the organization’s strategic objectives. If an organization intends to develop several new automations with specific goals for the automation program, there must be an architecture and a solution that allows for the expansion of automated operations. This should be accompanied by models and governance features that support it. However, an organization that intends to implement only a few automations will have a more rigid solution and architecture. When considering scalability, the question that arises is always: how will the architecture evolve when transitioning from 10 processes to 20, 40, and 80? Will more machines, licenses, and developers be needed? Does the delivery and maintenance process need to be re-evaluated? Thus, it’s important to have processes and a foundational solution that allows scaling without exponentially increasing costs, aiming for linearity and enabling some economies of scale. However, dealing with additional complexity won’t be easy. Our recommendation is not to scale without first consolidating, avoiding making a problem bigger. Often, the effort spent consolidating will contribute to a fundamental pool of knowledge and lessons learned for when new scaling issues arise. Another crucial point is not to grow without analytical visibility of the automation program. What isn’t measured can’t be improved; therefore, in a larger scale, having clarity and representativeness in numbers facilitates prioritizing areas that require more attention.
Integration
RPAs, as entities that frequently interact with external platforms, have particularly important integration, especially when considering scalability and security. Therefore, the defined architecture must have the ability to easily interact with the necessary systems, such as email, databases, Excel, SAP, Salesforce, etc. This integration must be secure, with encrypted protocols that do not compromise the integrity of these systems. It must be done cohesively, allowing a configuration or library change to update the entire set of robots dependent on that integration. This is especially sensitive when changes occur in APIs or common interfaces. Many times, automation programs are managed without considering the maintenance of a cohesive, uniform, and well-planned architecture. Often, the focus is on immediate resolution, without considering long-term solutions. Furthermore, the existence of technical and functional documentation is important to enable the integration of RPAs with other platforms and with the organization as a whole.
Contingency
As automation programs expand and accumulate successes, a great responsibility and a perverse effect emerge. Part of the business becomes reliant on the virtual workforce of RPAs. Just as illnesses can affect human employees, virtual employees can be affected by other contingencies that render them inoperative. Therefore, it’s essential to prepare a contingency plan in case automations are not executed as planned. How will an incident be scaled? How will intervention occur? Are there possible alternative solutions for the process? What are the potential losses and penalties? The more critical the process and the more restricted the Service Level Agreements (SLAs), the greater the need to plan an alternative. Preparation and planning can make a difference in catastrophic situations. For example, placing robots in different data centers can be a simple action that prevents a complete shutdown. Contingency scenarios should always be considered in architectural plans, and there should be a matrix of scenarios by severity criteria to prevent potential solutions.
In conclusion, when defining an architecture for an RPA solution, it’s crucial to carefully consider five fundamental elements: security, audit, scalability, integration, and contingency. Security should be a top priority, with strict access control and secure storage of passwords and credentials. Audit is essential for tracking activities and identifying non-conformity situations. Scalability should align with the organization’s strategic objectives, allowing for sustainable growth. Integration should be secure and cohesive, facilitating interaction with external systems. Finally, preparation for contingencies is essential to ensure the continuity of operations in case of failures. Considering these elements in the definition of an RPA architecture is essential for the success and effectiveness of process automation initiatives.
