Robotic Process Automation (RPA) has reached a high level of maturity in the world of software development. As businesses automate more processes and developers dive deeper into RPA toolkits, the question arises: How can we ensure that our RPA solutions are sustainable, scalable, and maintainable in the long run?

Enter the 12-Factor App methodology. Before we delve into how this methodology can be applied to RPA, let’s first understand what it is.

What is the 12-Factor App?

The 12-Factor App is a set of best practices designed to enable the creation of software-as-a-service (SaaS) applications that are both scalable and maintainable. These principles, conceptualized by developers at Heroku, focus on ensuring application portability across execution environments and minimizing divergence between development and production, enabling continuous deployment for maximum agility. The methodology covers areas such as codebase management, dependencies, configuration, and more.

How Does the 12-Factor App Relate to RPA?

At first glance, RPA and SaaS apps might seem unrelated. However, the core principles behind building scalable and maintainable software applications can, and often should, be applied to RPA development. Here’s why:

Scalability: As businesses grow, so does the need for larger RPA deployments. Ensuring your automations are scalable from the get-go can save significant refactoring efforts down the line.

Maintainability: RPA solutions, like any software, will need updates and fixes. Adhering to sound development practices ensures that when changes are needed, they can be made efficiently without causing widespread issues.

Portability: RPA solutions might need to be transferred between environments (development, testing, production) or even between different departments or businesses. Portability ensures that this can be done seamlessly.

Given these points, it becomes clear that the principles of the 12-Factor App can guide RPA developers to create more robust, scalable, and maintainable automations.

Distinguishing between UiPath and .NET in Terms of the Twelve-Factor App Principles

As we dive into the 12-Factor App methodology, it’s beneficial to compare and contrast its application between general software, like .NET applications, and RPA solutions using UiPath. For each principle, we’ll also provide a simple example from the SaaS world, using prominent corporations and their products for clarity.

  1. Codebase: One codebase tracked in revision control, many deploys.

    • Example: Salesforce maintains a single codebase for its CRM but deploys multiple instances across various servers and regions.
    • .NET: .NET applications should have one codebase tracked in version control.
    • UiPath: UiPath Studio projects are essentially .NET projects, following this principle.

  2. Dependencies: Explicitly declare and isolate dependencies.

    • Example: Slack, as a SaaS, would declare its dependencies for video encoding, messaging queue, etc., ensuring it operates consistently.
    • .NET: .NET applications declare dependencies using NuGet packages.
    • UiPath: UiPath Studio projects use the Package Manager for dependencies.

  3. Config: Store configuration in the environment.

    • Example: Dropbox might store API keys or database connection details as environmental variables, keeping them separate from the codebase.
    • .NET: Configuration is stored in files or environment variables.
    • UiPath: Configuration data is stored in Orchestrator assets or Excel files.

  4. Backing Services: Treat backing services as attached resources.

    • Example: Google Workspace apps treat their storage and database services as external resources, allowing modular and flexible infrastructure.
    • .NET: External services are treated as attached resources.
    • UiPath: UiPath automations also treat databases, APIs, etc., as external resources.

  5. Build, release, run: Separate build and run stages.

    • Example: Amazon Web Services’ (AWS) CodePipeline defines stages for building, releasing, and running applications.
    • .NET: There are distinct stages for compiling, preparing, and executing the code.
    • UiPath: Automations can be packaged in Studio or via command line, then deployed and run on Robots.

  6. Processes: Execute the app as one or more stateless processes.

    • Example: Netflix’s streaming service runs stateless processes, ensuring user requests are not tied to a specific server instance.
    • .NET: .NET apps, especially web applications, can be designed as stateless.
    • UiPath: Automations are recommended to be stateless, storing state externally.

  7. Port binding: Export services via port binding.

    • Example: GitHub’s web service is accessible via specific ports to serve millions of developers.
    • .NET: Web services or apps inherently follow this principle.
    • UiPath: UiPath services have defined ports.

  8. Concurrency: Scale out via the process model.

    • Example: Spotify scales out its music streaming processes to accommodate its vast user base.
    • .NET: Apps can be scaled using methods like load balancing.
    • UiPath: Scaling is achieved by deploying more robots.

  9. Disposability: Maximize robustness with fast startup and graceful shutdown.

    • Example: Atlassian’s Jira Cloud ensures services can be started or terminated quickly without disrupting user experience.
    • .NET: Proper handling of startup and shutdown is crucial.
    • UiPath: Automations should ensure quick starts and safe stops.

  10. Dev/prod parity: Keep development, staging, and production environments similar.

    • Example: Microsoft’s Office 365 development ensures feature consistency across development, staging, and live environments.
    • .NET: A standard practice in software development.
    • UiPath: Orchestrator manages different environments, ensuring similarity.

  11. Logs: Treat logs as event streams.

    • Example: Zoom would treat its application logs as streams, aiding real-time monitoring and analysis.
    • .NET: .NET offers built-in and third-party logging mechanisms.
    • UiPath: Logging is integral, with logs managed in Orchestrator.

  12. Admin processes: Run admin/management tasks as one-off processes.

    • Example: Adobe Creative Cloud might run data migration or clean-up tasks as one-off processes post updates.
    • .NET: Administrative tasks are run as separate operations.
    • UiPath: Separate UiPath processes can be created for administrative tasks.

This distinction, combined with relatable SaaS examples, provides a comprehensive understanding of how the Twelve-Factor App principles apply across software development spectrums.

Conclusion

While the 12-Factor App methodology was primarily designed with SaaS applications in mind, its core principles offer valuable insights for RPA development. By understanding and applying these best practices, RPA developers can ensure their solutions remain agile, scalable, and sustainable, delivering long-term value to businesses.

Whether you’re an experienced RPA developer or just beginning your automation journey, considering these principles can significantly enhance the quality and longevity of your robotic processes.