RPA’s Promises & Realities


When you travel through the froth, reach to the core and witness the reality, RPA does not look like what you were told by the Sales reps and the Service providers. RPA as a concept certainly got a potential for cost savings. Is RPA useful at all? – Yes. Should you look at RPA? – Yes, you must. Can you eliminate dependency on Technical People and let Business Subject Matter Experts automate the processes? – A resounding NO. Can RPA use an App Store? Yes, Yes and Yes. These are RPA’s promises and realities – RPA minus all the BS built around it. RPA vendors must concentrate on building a highly extendable and customizable platform not the individual skills. Although vendors can build a few necessary skills, it must be the job of developers

If you are a pragmatic person and keen to produce value with everything you do, you want to understand a concept or a technology for its true worth. Because of the forth created by Marketing people, this info is unavailable in ready-to-consume form. This article is intended to process all the crude info that’s freely available around RPA and get to the core of what it is truly capable of – at least as of today. If you are new to RPA, please refer to my previous post to get an idea of what it is.

RPA is incapable of empowering business subject matter experts to automate without the help of technical people. RPA is a platform that comes with a suite of tools that make automation possible. However, the current platform and toolset are inadequate and unreliable to achieve this technical independence. Here is a list of ares where I think the problem is.

Openness

Openness is my big concern with RPA. Currently RPA products are mostly closed environments. The vendors look at them as a platform that does not need to integrate with other non-RPA systems. If the vendors do not open their platforms up to other systems, it would be a disaster for them. For example, ability to trigger an automation task – may be exposing the script as a REST endpoint, ability to share application context or transaction context among RPA and non-RPA systems, ability to pass input/output parameters with native datatypes instead of passing through files – pass an array of integers vs writing the integers to a file and pass the file as input etc.

OS Openness

Most of today’s RPA products can run only on Windows machines. This means irrespective of your IT policies and guidelines, you are forced to use Windows servers(or desktops) to run RPA. For a few organizations that would be a showstopper.

For a few vendors, this restriction is partly caused by the technologies they used to build the product itself. For example, if a particular vendor’s RPA product is built using .NET framework, it cannot run on non-Windows platforms. Some of the RPA products heavily rely on Windows internal libraries directly (instead of abstracting it out) to achieve majority of the system level work. This is another reason why they cannot be ported to other platforms easily.

Code Openness

Most of RPA products allow you to write custom code and run them along with other standard activities. Technically they can allow this custom code to be written in any language and still be able to run it with proper execution environment – whether they ship the environment along with the product or provide a way to the admins to install and configure it. In my opinion, this is a great opportunity to RPA vendors to open up their environment. But most of the RPA products allow only one or two scripting languages to write libraries in. VBScript, JScript – are you really serious, guys? This is 21st century AND we are 17 years into it already. Wake up !!! No technology can have mass adoption without support of developer community. This is the way RPA vendors to get the much needed support from developers – support as many programming languages as possible to implement custom functionality

Platform Openness

In general, RPA platform itself is very closed. For technical people, developing automation scripts with RPA products is nothing less than torture. For example, the script you compose through dragging and dropping a few activities cannot be hand edited – Behind the scenes this script is nothing but a bunch of commands written in a sequence. However, most of the vendors won’t allow you to edit this script by typing. If allowed, this would help developers save a lot of development time. The scripts are stored in proprietary binary formats. This is a lot of inconvenience that could be easily avoided by exposing the textual format of the script to developers. Even if the targeted audience to these editors are non-technical people, RPA vendors can support a developer mode of the editor which will allow developers to do more sophisticated development – one solution does not fit all.

Open for extension – App Store

No general purpose platform can claim that it supports all the use cases that are ever possible in the world. Even packaged solutions such as SAP FI/CO or SD which are built for specific domains need customizations and enhancements for real world scenarios. How can a generic platform like RPA which claims to support any domain – whether it be finance or energy or any other thing in the world – think that the standard tool suite provided would be comprehensive enough for all real world use cases? This problem can be solved by an App Store – Let the developers around the world build general purpose and specific purpose automation tools that can be seamlessly plugged into the RPA platform.

Compound Deployment Artifacts

Today all RPA vendors expect automation scripts to be single files. I think for any serious real world usage, you would build a bunch of reusable libraries which can save developers a lot of time. Although building reusable libraries is possible today, there is no proper way of packaging a script along with all the required libraries. Support for building compound deployment artifacts is necessary. Think of a script as a bunch of files that are packaged into a deployable package.

Reliability of Tools

Although there are a lot of tools – such as Web Scrapper, OCR, PDF reader – shipped with the RPA platforms, they are unreliable for real world scenarios. For example, PDF reader let you highlight a text and copy it – but few products let you specify which page of the file this text is expected to be found or which pattern should be used to identify the text etc. This information will be implicitly determined by the tool itself. The problem with this approach is, the script developer won’t have any control on influencing the decision except he/she will highlight and copy and product will figure out the pattern. In real world, this approach won’t work very well. For example, for all PDF’s the text may not appear at the same location on the same page – if not, then the script will fail. Similar reliability issues are present with other tools too. Again the solution could be to build an adaptable UI so that if the developer wants to work with the script at a higher level of sophistication, they can. RPA vendors must not keep the control with them – they must give it to the developer/implementer.

Cloud & CI/CD Support

It’s mostly safe to say that RPA vendors are not cloud ready yet. It seems they don’t have a proper plan to support Continuous Integration and Deployment also. Although you may achieve this today, it would prove to be a Herculean task.

Closing Remarks

RPA vendors must concentrate on building a platform that’s extendable, optionally customizable and can plugin and naturally play any custom built skills. Let the developers around the world build the skills. If they try to eliminate the developers from the equation, RPA will be a disaster and will bite the dust. Who knows what Artificial Intelligence would be fully capable of. Until AI proves that it’s feasible to eliminate coders, RPA should NOT assume it. As it’s today, RPA is an Orchestrator that can create symphonies by leveraging several individual skills that are part of or plugged into the platform or running externally somewhere on the Internet. Building the platform in such a manner could be the recipe for success. Openness alone can dictate the fate of RPA as a technology (or as a concept). The more open you are to the world, the more open the world is to you.

PS: Please leave your comments and share your views. Thank you.

Entering listen mode … Krishna Pisupat

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s