Three hidden threats of RPA technical debt you might have overlooked

If you’re looking to selectively automate the work of individual components in legacy systems, and help automate processes without a significant time investment — RPA should be on your radar. 

Global companies like Deutsche Telekom have already introduced and automated 2,500 individual bots, resulting in savings of more than 100 million Euros. However, relying too heavily on RPA can land you in hot water. Paul Jones, Business Automation Services at NatWest even classifies RPA as technical debt. 

So what can you do to avoid this debt? Prevention is the best cure and before jumping on the RPA bandwagon, think carefully about whether you need an RPA solution, or a workflow engine.

Losing control of long-running processes

The ability to automate and orchestrate long-running processes end-to-end is essential for business continuity and customer experience alike. But to do this, you need state handling and persistence — the ability to wait, either for users to complete a task, a timer to expire, or perhaps an external event to occur. 

RPA tools are not able to handle such orchestration end-to-end because they are designed to be synchronous. As a result you would always have to ‘chop up’ your end-to-end processes into individual pieces, triggered by intermediary actions. This makes it hard to see the overall flow and easily lose track of important processes.

Equally, you can’t afford to lose state if things go wrong. In order to manage a long-running process, you require certain features, such as the ability to repair and retry a failed instance, like timeouts and escalations when your processes get stuck. You also need to consider version migration, especially if old versions of that process are still running. RPA tools often don’t provide such features.

If you’re relying on an RPA tool alone, you’ll struggle to handle long-running processes end-to-end. Instead you’ll require a workflow engine that can persist state and provide mechanisms to track time and trigger time-related events. This is easily managed by Camunda, which supports standard BPMN 2.0 timer events, allowing you to react on dates, durations and cycles, and gives you freedom to handle these situations in the right way for your business. Camunda is also able to migrate state across versions.

Overlooking external events

In most processes, it is imperative to be able to react to something happening outside of the  process. For example, a customer may cancel an order while it is being processed by the warehouse and the process needs to react to this by making sure the order is not shipped.

In order to implement this, you need the ability to listen for and notify processes of events that are happening outside. Because RPA technologies are not designed to interact with external events, you run the risk of missing vital updates to your processes.

However, Camunda implements message events, for example to start or interrupt processes, which specifically wait for external events to happen to trigger actions. Camunda goes further by providing a Message-API via Java and REST, which can be used to integrate with other messaging systems like Kafka or RabbitMQ, giving you a unified event architecture.

Lack of Orchestration

RPA users should be able to choose the right RPA technology for their use case, combining tools as needed. Let’s imagine you have a process where the first step involves accessing data in a legacy mainframe user interface — an ideal RPA use case. Then for the next step of the process, you need to interact with a modern web-based user interface. You can easily use two specialized RPA tools to manage this. 

However, what you can’t do is orchestrate the workflow itself. This is where a workflow engine, able to integrate different RPA technologies from different vendors, is the better approach. 

Another point to dwell on is visibility. RPA tools typically lack the process layer, which is essential for cross-tool integration and facilitates transparent, end-to-end visibility of a process across different RPA vendors. This can lead users into vendor lock-in situations.

RPA or Workflow Engine?

Technical debt can be a millstone around your neck. That’s why it’s essential to use the right tool for the job. There are advantages to both RPA and workflow engines, and choosing the right technology really boils down to your use case. 

RPA excels as a tactical solution to automate individual tasks but really should not be used to automate core business processes. Instead, it should be viewed as part of your strategic journey towards a modern IT infrastructure, with sound APIs and other integration points.

If you’d like to learn more about how leading enterprises are successfully blending RPA and workflow automation, as part of their digital transformation, join Marco Einacker, VP IT Services, Deutsche Telekom, free at CamundaCon LIVE 2020.2 this October 8th, where he’ll be presenting his company’s RPA strategy: Bots and process improvements at the same time – is that possible? 

  • Creating a Frictionless Enterprise: Five Fundamentals

    What if you could remove all of the friction in your enterprise, allowing for a streamlined, perfectly aligned flow of information across both internal and external stakeholders? Manuel Sevilla — Chief Digital Officer of Business Services at Capgemini — recently shared his thoughts on this topic at CamundaCon LIVE 2020.2, identifying the framework businesses must adopt to embrace the frictionless attitude. Let’s take a closer look at the five fundamentals enterprises should consider when trying to increase efficiency, get to market faster, and provide users with an enhanced experience.  1. Hyperscale Automation To improve your enterprise’s efficiency, focus on delivering a touchless process — one that uses automation in a way that makes it easier for the end users (and...

    Read more
  • Should data be embedded in business processes?...

    In October, I had the opportunity to lead a session at Camunda Unconference. This was a rather unique event, with an “unconference” format designed specifically for the community; it was most conducive to great peer-to-peer discussions, and exhange of ideas, experiences and learnings. What was also interesting was that the topics for the sessions were sourced from within the community, and each topic was voted in to a final shortlist. The sessions themselves were discussion-led, to encourage collaboration and creativity. Data in Process I had voted for “Data in Process” as one of the topics; it has always intrigued me, and needless to say, I was thrilled at the opportunity to lead the session! I have been consulting for customers building...

    Read more
  • Testing Process Dependencies

    Welcome to the next post in our blog series: “Treat your processes like code – test them!” You can find the last post: “Testing entire process paths” here. Today’s topic is “Testing process dependencies”. For the execution of a model, there are often additional resources required. This might be source code or the dependency on other models. But how can we deal with this when testing our models? In this post we will take a closer look at the following dependencies: Models: Dependencies to BPMN diagrams referenced by the executed model Code: Dependencies on source code referenced in the BPMN. We will get to know another library that will help us with testing: camunda-bpm-mockito. The examples for this blog post...

    Read more