Hacker News new | past | comments | ask | show | jobs | submit login

"Robotic process automation" was indeed what came up in my web search for the term, but it seemed an unlikely fit for generic distributed app development. Why is robotic process automation sweeping "IT shops"?



Because rather than upgrading software and building APIs that integrate at a low level, IT shops are building software and APIs on top of UI automations. Some new fancy service desk platform the suits want may not have a connector to your 15 year old heavily-customized SAP instance (which is run by another team you have no influence with), and budget / time constraints leave RPA as the only option.

It's pretty easy to see why this would cause problems, but the consulting companies have been pushing hard on RPA because when it blows up in 5 years, who are you going to call? I say this as a consultant who has to sell this awful crap because "partnerships".


Thanks for the context. Seems like the latest incarnation of scripting 3270/mainframe terminals, telnet/expect sessions or web/selenium/headless browsers.

Copy&paste is the enterprise API/data integrator of last resort. Image/video is another integration point. iOS can screen capture full-page images of web pages, with tools for human annotation. Soon the local ML/bionic processor and AR toolkit can perform text recognition on those images, which means they can be live edited, re-composed and fed into another system.

> fancy service desk platform the suits want may not have a connector to your 15 year old heavily-customized SAP instance (which is run by another team you have no influence with)

This intersects with DRM and the title of the OP story. When OrgA and OrgB fail to partner/cooperate (e.g. no formal integration) or are actively hostile (implement DRM to prevent data movement between OrgA and OrgB products), it creates pain for customers and new business opportunity for OrgC and OrgD.

Which is why scraping and reverse engineering are never going away, they are society's last line of defense against vendor org dysfunction.


Oh it's so much worse than that. Swivel-chair / copy-paste integrations are often a better solution than RPA in today's world.

It was one thing scripting mainframe terminals, but the equivalent today are SaaS apps. The major enterprise vendors like Salesforce are pretty good about roadmaps and release schedules, but a lot of the smaller ones work on more of a continuous deployment model. This means your RPA integrations are constantly breaking, and suddenly you have to hire a whole bunch of RPA analysts to deal with fixing them. Or you can just hire a few more data entry people to do it manually.


I ... I feel bad saying this, but I can totally see a use for RPA.

One, and more often than not, applications embed a ton of business logic in the client which is not easily available in the API.

Two, and honestly I feel dirty writing this, the UI is usually a lot better tested. Or tested at all.

I'm just the messenger, here. We were very adamant about NOT doing this in my previous company or our current projects, but I can totally understand the "it's good enough for humans, it's good enough for machines" attitude. It makes me sad though.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: