The Limitations of First-Generation Hyperautomation Platforms

automation integration

In this blog, I discuss the limitations of existing first-generation standalone Automation and Integration platforms. In a follow up blog, I will propose how to overcome these limitations.


Automation is usually defined as the mechanism of automating tasks normally performed by humans.  There are many benefits to Automation, which are usually equated with RPA (Robotic Process Automation).

George Brooks, People Advisory Services Leader at Ernst & Young, said it best, “RPA actually enables us to ‘get back to human’ and engage in relationships, activities and projects that are more inspiring and align with our purpose.”

In our view, Automation augments and often replaces a human worker. It can improve productivity, reduce costs, and deliver measurable results. Obviously not all human tasks can be automated, but those that require mechanical, repetitive, manual steps are usually the primary target for Automation initiatives.

Despite the potential benefits, not all is rosy with Automation in real-world enterprise implementations. Ernst & Young reports that between 30-50% of all initial RPA projects fail. They cite reasons such as not considering IT infrastructure, targeting RPA at the wrong processes and applying traditional delivery methodologies to deploy RPA. Another reason for failure is treating robotics as a series of independent automations rather than an end-to-end change program.

The other issue facing organizations is that deploying and executing RPA workloads at scale is still a challenge to even the largest enterprises. Deloitte’s most recent report found that only 3% of companies had achieved substantial scale in deploying RPA Automations, citing process fragmentation as the biggest barrier among 478 respondents from different industries:

– The Robots Are Coming, Deloitte Consulting

In our view, such a large failure to deploy at scale is the result of how the Automation is thought about and developed within an organization. It is normally viewed as a quick, stand-alone way to simplify the job of an individual, a quick hack to get a “win” without a major investment. Automations are created on an ad-hoc basis as siloed, point-solutions with no thought given to their re-use or applicability to any other parts of the organization. The long-term viability of these point-solutions and how they can become more than just a hack are not often considered. What is needed is a way to change this approach to create a real foundation for Automations, a platform designed from ground-up for building viable business solutions.


A related area of enterprise computing is Integration. Integration, as the name suggests, provides for integrating multiple systems and services into a single application that is easier to access and control. By connecting multiple systems together, integration facilitates an automatic data exchange and synchronization. More complex and customized applications can be built from constituent parts, enabling their reuse as abstract building blocks in another system or process. Most often, integration involves a conscious design decision by a software vendor to provide the hooks needed to integrate their software with others, the most common way by providing externally accessible APIs. A new piece of software can be created then, often completely independent of the original software vendor, that provides new and automatic ways to:

  • Control and orchestrate the software whenever and however desired by the customer
  • Pass information in and out to connect it to other systems
  • Monitor, shut-down, restart, etc. related systems and software
  • Create new human user interfaces
  • Create new, value-added functionality leveraging the application

The abstract nature of programmatic interfaces makes it possible to treat individual applications and services as a black box with a well-defined entry point and a documented result. Integration platforms are designed to be easy to manage and to scale on demand, unlike Automation. These are also usually first-class citizens in a cloud or a SaaS deployment. But there are natural limits to how and when integration platforms can be used. Integration doesn’t work well when a system can’t participate because of lack of APIs or other integration capabilities. This is still the case with a large number of custom and legacy systems, often the same ones that the enterprise depends on to conduct daily business.

When integration is not possible, it becomes the job of a human worker to act as the “integration glue” that connects these systems together. The user is challenged with passing data from one system to the other manually, sometimes by re-typing, sometimes by copy/pasting, sometimes by exporting spreadsheets and data files, editing them, and then re-importing into the other system. The manual processes can involve many systems, sometimes simultaneously, and often in real-time, as in the example of a customer representative that must operate 10-20 different apps to look up relevant information while at the same time speaking to a customer. And all the while, the user must keep track of the whole process, know how to recover from errors, and not make any mistakes.

In effect, this legacy Integration challenge places the burden on the employee to be the integration interface, to manually provide the “automated workflow” connecting multiple systems with all the usual liabilities of a human worker:

  • Requires training
  • Can be distracted, gets tired
  • Makes mistakes
  • Expensive to operate

The human worker acting as the integration glue between various systems results in the same set of issues that the Automation initiatives aim to address, and yet Automation and Integration are normally not considered together as part of an overall business solution.

Given these limitations of hyperautomation platforms, is there a way forward that can help address this list of the deficiencies for an enterprise? Can we build reliable and scalable automations and have them become an integral part of the enterprise computing fabric?

These are the questions that I’ll tackle in the next blog.