This sentence caught my eye:
‘…so any task in a process that requires work from an external application that does provide an API can be handled by a BPM platform by itself–no RPA necessary.’
This implies a somewhat esoteric definition of RPA to me. If an process task can be handled exclusively by a BPM platform coordinating with an external software application via API calls and with no human intervention (essentially a microservice), then most (of my) end users would consider this to be synonymous with synonymous with RPA. Unltimately, the process task has been fully automated through software.
To extend this to an example from the blog. The task ‘Enter Sales Data into CRM’ is given as an RPA task, whilst ‘Enrich Customer Data’ appears to be a microservice. But to an end user reviewing the end to end BPMN model, the 2 look indistinguishable.
So my quesiton is, what are the a meaningful difference between microservices and RPA implementations, especially viewed form the business user / process owner perspective? Does anyone have a view on this?
To my mind it’s a practical difference-the way microservices communicate is designed and built with the idea and purpose of easy of use through API integration. The times you need to use RPA is where there is a service (usually legacy) that was created under a different principal. In most cases requiring a user to enter data through a UI rather than offering API.
RPA can then be treaching by the architecture as a normal microservice while behind the scenes it’s actually doing some very impractical interaction with hard to communicate to systems.
Thanks, yes it does, and fits with my pre-existing thinking. My starting point in asking the quesiton was:
There’s no real advantage in getting hung up on terminology when discussing automation options with business users and process owners. In that forum, automation = automation.
On the other hand, from an architectural / design standpoint, there is clearly a different emphasis, and there, I think your point about microservices having interoperability ‘designed in’ to support wide reuse across multiple process flows is a good one.
Will be interesting to see if there are any alternative viewpoints in the forum though.