How can you select just the right robotic process automation (RPA) technology for you? Is there an option for large commercial technologies – say an open-source solution? In this text, we compare commercial and open RPA technologies to help you make an easier choice.
Competition between RPA ecosystems: ease vs capabilities
Enterprise grade is the major promise of commercial RPA technology providers. Certainly, UiPath, BluePrism, Automation Anywhere, Workfusion and Pegasystems are familiar names for everyone working with software robotics. But what do these different technologies ultimately have to offer? Here, the keyword is technology, which in itself produces no added value for companies.
The general purpose of commercial technologies is to use partners to build a fairly sealed-off platform ecosystem, on top of which all functions are built. Service packages of different providers are still fairly similar in both capabilities and prices. An ecosystem provides users with tools, support and training easily in a single package. However, the restriction is often that if a solution does not include a specific function, its addition can be difficult or even impossible.
The power of an open-source ecosystem is based on users: anyone can produce added value in a readymade system. For example, Python and Robot Framework ecosystems have a huge number of open-source options to create different functions. This exceeds the capabilities of any commercial ecosystem, as long as you know what to look for and from where.
Currently, Python is a popular software development language offering opportunities and complete libraries in the areas of AI and machine learning. After all, the most popular machine learning libraries are Python solutions that can be integrated seamlessly with Python-based RPA solutions. A modern and credible RPA solution and provider must be able to expand functions by means of machine learning. This is one topical example of enterprise-grade integration.
The value of a technology is measured by its ability to respond to business needs and by everything it enables in the RPA field, for example, in terms of integration capabilities and effectiveness. This means not only the ability to integrate RPA technologies, but also the ability to integrate the entire ecosystem with your company’s operating models, overall architecture and other technologies.
The concept of a software robot – an artificially built restriction?
Commercial licence-based models have defined a certain concept of what a software robot is. Accordingly, a software robot works like a human being, with the robot (and the robot licence) being able to work no more than 24 hours a day, seven days a week. This concept is completely artificial and ludicrous. After all, we are talking about a computer application.
Open source software robotics delivered from a scaled cloud infrastructure turns this concept upside-down: capacity can be fully defined in accordance with process needs, both in terms of the number of software robots and their operating time. What can take hours or even days for a hard-working licence-based robot can be carried out in minutes by using dozens of open-source robots that are operated as necessary.
In addition to improved efficiency, cost savings can also be achieved, as there are no licence costs, and the robot efficiency rate does not need to be considered. Above all, the proper concept of a software robot should be an application which enables automation, supports business and ensures that the focus in software robotics projects is placed on business needs, not on costs or optimised efficiency rates. We have seen that companies are starting to understand what this concept means better. This has also forced commercial service providers and partners to enable new and more flexible pricing models.
A visual development tool – marketing or effectiveness?
One major advantage of commercial solutions is the graphic user interface of robot development tools, which anyone who uses a computer can, in principle and after brief training, somehow understand and operate. It is true that graphics and visuals add effectiveness and transparency to software robotics projects, but not so much to developers. Visuals make it easier to define, analyse and prioritise processes and tasks in projects.
Keeping larger projects under control so that they remain scalable and maintainable calls for a much more profound understanding of software development than the training programmes of commercial solutions have to offer. For developers, writing codes and scripts is often a much more powerful and effective way to build a well-functioning solution and a seamless system. What is more, although commercial tools are graphic and visual, the effective development of robots always requires scripts and pieces of code.
Best software development practices involved in software robotics
An RPA project is like any other modern software development project, which calls for an agile approach, while the customer and supplier work closely with different bits and pieces. The same laws and practices apply to both commercial technologies and open source. This means, for example, that individual processes are divided into reasonable parts so that the rules and logic of business are clearly separated from those parts that are used to integrate with target applications.
In other words, the system must be controllable and reusable. Most commercial providers have their own component bank, from where process templates and parts can be loaded and configured for individual needs. One starting point for a scalable and maintainable software robotics system is to build each process similarly. This ensures, for example, control and data transfer between different team members. An open source ecosystem and its thousands of users comprise one huge databank, where the functions required have already been built by someone, and these can then be openly used by everyone else.
DevOps, i.e. the continuous combination of testing automation and releases alongside application development, is part of modern and effective software development, and it applies equally to RPA projects. The effectiveness of development is rarely mentioned in conjunction with software robotics. Instead, the emphasis is placed on new automation and AI properties and the establishment of just the right centre of excellence. The open-source Jenkins tool is one of the most popular DevOps tools, and it is also ideal for the orchestration and management of open-source software robots. While a release, testing automation and robot orchestration can be effortlessly included in a single tool, commercial tools cannot offer similar integration or comprehensive management – at least not yet.
The scalability of software robotics is a well-known challenge
The current trend is that software and development projects are increasingly purchased as a service, with the supplier being responsible for the width of the project (technology, architecture, infrastructure and related expertise) and its depth (project lifecycle from start-up to maintenance and continuous services). Customers do not usually want to pay any monthly service charge. Furthermore, they no longer want to take care of licences or the infrastructure. In particular, it is an outdated practice in the field of digital services and technologies that a customer is tied for several years by a single licence or supplier. The aim is to minimise any risks associated with potential vendor lock-ins and unexpected changes in licence terms and prices. Projects need to be driven forward in a dynamic and agile way, while ensuring project benefits as early as possible.
A dynamic and agile approach is not the same as short-sightedness. It is necessary to consider any later scalability during the first stages, and to build the architecture and select the technology to support this. Commercial providers offer different licensing options that enable companies to get started at a low cost and to expand later as necessary. In principle, this is a good thing, but practice has shown that different licence options and restrictions cause confusion and disappointment in terms of supported features. Open source means freedom from licences and an opportunity to use solutions without any restrictions and, if necessary, with unlimited scalability.
Once again, we get back to what is essential: technologies must support goals and help to focus on business benefits and improved efficiency. Being free from licences, open source removes all these restrictions. By working with different customers, we have seen that investing in scalable technologies and architecture from the very beginning most quickly produces the most benefits. Later, automation can be expanded effectively to different business units and functions.
Software robotics projects also involve many non-technology-related risks – or perhaps we should say challenges. These are especially associated with change management, the establishment of correct roles and the centre of excellence and people’s overall readiness to accept automation in daily work and decision-making processes. We will discuss these in more detail later in a different text.
A commercial or open RPA solution? There is a place for everything.
You have probably noticed that this text has so far been strongly biased towards open source. However, the idea is not to criticise commercial providers or technologies. There is a place for everything and, in addition to having a ready-made RPA package, learning and adopting a commercial product can be easier for users who are not professionals in programming than, for example, taking over a system based on Robot Framework or Python.
What is more, commercial providers often determine the way in which software robotics is headed, and what it can enable for customers, regardless of the business area or sector. Sometimes, it may also be reasonable to build a hybrid of open-source and commercial technologies, making use of the best parts of both options.
However, the technology is not such a crucial factor for customers when software robotics is purchased as a service. Significance and value are produced when technologies produce the desired results within the defined schedule and budget. Currently, Finnish software robotics markets include many different suppliers who offer robotics as a service (RaaS), either using commercial technologies or open source. Different suppliers also price their services in different ways. As a result, every customer can select the best model and partner for their needs. For example, Robocorp Technologies and their Robocloud platform, which combines the management, orchestration and analytics of open source software robotics, brings new opportunities to open source software robotics.
What should everyone considering software robotics make of all this? Perhaps the most important thing is that when selecting a technology and supplier, it is better to focus on the big picture and not move forward driven simply by RPA technologies and expertise. As stated above, enterprise grade is not a technology. It means the understanding and coordination of different systems, architectures, cloud infrastructures and technologies – exactly what a software robotics project is in reality.
Open source is here to stay.
Erno Pirinen ja Timo Kostamo