Will RPA kill the API Song?
A New Year, a new debate, this time about Robotic Process Automation (RPA) versus Application Programming Interface (API).
So, what do we all feel about the above headline? A lot of time, money and resources have built up the API development and management message into a significant world force in terms of business transformation and change.
Products such as Salesforce’s Mulesoft, Googles Apigee, Red Hat 3Scale and IBM API Connect all help organisations to transition to open, data sharing and integrated platforms. All of these technologies allow organisations to re-use legacy technology, access hidden away data and reduce technical debt. But are they over-kill or even actually required?
API integrations, by their nature, are technically driven, requiring the design and building of data gateways to present data in a usable format. Typically, an API project uses developers, analysts, technical consultants, with lots of time, energy and IT budget costs, all paid for by the organisation, not to mention the opportunity lost from not doing something else.
RPA starts from the User perspective, it focuses on the user interaction with a system or systems and translates this into an automated process supported by technology. This compares to creating a new technical layer that is then integrated in to all the other target systems that store the data the users need access to.
Those organisations looking to automate and improve their return on investment through better use and access to their data can benefit from both API and RPA implementations, however, there are situations where RPA has the upper hand and is worth considering.
RPA Consideration 1 – Try and test first
RPA products typically allow for test cases to be designed and run against a business process before licenses are purchased. Real end user experience and workflows are used for process mapping, enabling the RPA Analyst to quickly capture the user behaviour to define the process.
This means that it does not matter where the data resides or in what system it is in, as the user, through their actions, finds the data. This allows organisations to test, review and analyse the results of a single process and to quantify the benefits, before embarking on a full-blown transformation program of work.
With an API, the data gateway needs to be built and data presented to the user, requiring a range of skills as described above. With RPA the data connection is already available and an assessment of suitability and productivity benefit is demonstrated quickly.
RPA Consideration 2 – When an API has not been built
There are other areas and times when RPA should be considered in favour of API’s, especially when there are multiple systems, applications, data streams and technical platforms.
If the API’s for some, or all, of these elements, have not been designed or built yet, a lot of resources will be required to build and implement them. Why not experiment with a single RPA process first and assess the results?
RPA Consideration 3 – Legacy Systems, Technical Debt & Knowledge deficit
The world moves on, systems change and are added to, but are very rarely retired. This means that for many organisations the personnel that implemented those systems have either left the building or have had their skills upgraded.
This is compounded by the lack or loss of documentation, impacting the ability of an organisation to develop, support and enact meaningful change. The users know what the system does but do the IT staff know how it does it?
With RPA you are reverse engineering the system by starting with the process. This means that you can capture the user interaction first and map this to a technical, automated process without needing to know or understand the technology or code sitting in the background.
RPA Consideration 4 – Skills and availability of resources
If the organisation wants to change it typically starts in the business and then quickly moves to IT. Implementing API’s can require new skill sets, however, they also require the incumbent teams to stop what they are doing and work on something related to the API project. This leads to log jams, missed deadlines and loss of productivity when people are forced to wear two technical ‘hats’ at once.
With RPA the focus is on the user first, to define the process and then typically a cloud-based platform can be used to prove the benefits, or demonstrate failure before any significant budget is spent.
This approach can carry on until the business are assured that the RPA solutions work and will deliver, using users time rather than IT. Once the users are comfortable with creating their own work and business process flows the IT footprint becomes minimal, increasing return on investment, lowering total cost of operation (TCO) and improving productivity.
RPA Consideration 5 – Business Process Agility
So, imagine you have just invested in a new, shiny API platform linking all your legacy applications, systems and data stores and then out of the blue your Head Honcho announces a merger with another organisation or department.
The disruption this would cause is difficult to calculate. The need to review and assess the combined systems estate will include what can be integrated, what can be replaced, what stays and what goes. In the API world, this would mean another transformation exercise, building integration points, pulling data and developing the systems to talk to each other.
With RPA, processes can be captured and mapped, then automated, so that the users in either department or organisation can reduce workloads and combine tasks, whilst they focus on bringing the two organisations or departments together.
With an understanding of what the processes are doing, you can then allow an evaluation of which processes stay first, rather than which systems.
RPA Summary – Will RPA kill the API Song
With my hand on my heart, the world of IT solutions will always contain RPA Solutions and API Integrations and it will be interesting to see how this battle develops. Big Industry players like Salesforce have already invested heavily in API management technology and API projects suit big consultancies as they require lots of warm bodies.
I personally believe that as RPA becomes more mainstream in its application and with the advancement of machine learning and artificial intelligence, coupled with the benefit of not needing to invest significant amounts of energy and resources to improve business processes, organisations will adopt RPA in large numbers.
To find out how RPA can help your organisation and automate a process or two please contact ONQU Solutions.