During the last two decades, much of the Process Automation efforts concentrated on using Business Process Management Systems (BPMS) as a means to document and digitize business processes. This technology wave helped the Process Automation space make a significant step forward. BPMS tools armed with Integration capabilities allowed organizations (and their business and IT stakeholders) visualize the processes they wanted to automate. From this initial business process documentation phase, it was possible to create a manageable digital asset to help “orchestrate” all business process steps regardless of its nature (people and systems). Without risking to exaggerate, most of Process Automation (or Business Process Management) practitioners would agree, that one of the hardest implementation areas is integrating with systems of information that the business process needs to transact with. BPMS vendors offered a wide array of application integration capabilities, usually in the form of application adapters, to integrate with these Enterprise and Productivity Applications. As more systems needed to be integrated from the business process, the hardest the implementation phase became. As much as we would like for Applications to enable all transactions via publicly available APIs, this is not the case and limits what integration service capabilities can do to integrate in an automated and headless manner.
Simplification in the integration space helps!
New Enterprise and Productivity Applications have started to really invest early in Application Programming Interfaces (API). REST based Web Services as an implementation mechanism and an API-First approach to offer Application functionality, certainly offered a simpler consumption of Application functionality and by transition it simplified the Process Automation implementation projects “hardest” last mile: integration. Integration vendors can leverage these APIs and offer a direct and easy way to transact against these Applications.
But is this not well enough?
Well… if your business processes create logic around new SaaS Applications you may be lucky. But for many organizations (and specially those that have gone the path of merger and acquisitions) it is not. Whether we like it or not, there are still many systems that are very hard to transact or interact with. This category of Applications include mainframe systems and homegrown to Enterprise Applications. But also, any kind of application that has gone some kind of customization where this functionality is only available through the application user interface (UI).
Robotic Process Automation (RPA): The new kid on the block!
What exactly is Robotic Process Automation? These questions may have many different answers. But to me, RPA offers a new mechanism to integrate and transact against Applications using the same UI that their users use. And via this non intrusive approach, it is possible to interact with the application as if it would be done by an person, but rather than a person doing the clicks and entering data, it is an automated application that we call a robot. Period!
Why do we talk about RPA in the context of Process Automation?
My first observation is that these two technologies are not the same. Secondly, that if you combine them to work together, it is possible to take Process Automation to the next level as RPA offers new ways to integrate with systems of record that could not be integrated before. The simplicity of the way in which it transacts with Applications also offers a first step of automation while a more robust and throughput optimal adapter or API approach is used. Read the complete article here.
For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.