RPA is "robotic process automation". The author worked with the uipath.com platform, which looks to be an automation tool to click on screens to automate processes (probably oversimplifying here).
You're not really oversimplifying. RPA is duct tape for situations where it's drastically cheaper to automate personnel doing repetitive tasks out of work and have a fraction of the original team supervise a fleet of(rather persnickety) 'bots' that insert keystrokes and clicks in a legacy application, as opposed to building proper systems integrations or rebuilding the underlying legacy app entirely.
I understand the niche, but I don't particularly care for it. It's an enabler for shortsighted, 'keep the lights on but cut costs and corners' operating strategies that usually go hand-in-hand with technical debt accumulation and brain drain.
I’ve worked adjacent to RPA and I’d like to think they were saving personnel from the most tedious and hair-pullingly annoying work routines.
Not using RPA is like not using macros in your text editor, because they are automating programmers out of work.
Some data can only be accessed through a legacy gui and it needs to be cross referenced with several proprietary databases that also can only be accessed through a gui.
Even if you begin migrating these it can take years if not decades. Meanwhile shit needs to be done.
> Even if you begin migrating these it can take years if not decades. Meanwhile shit needs to be done.
Yep, that's the key thing. The ERP systems which have their tentacles all over every part of the organization make changing stuff out effectively intractable.
I don't know if it's intentionally like this (by design on the part of the vendors) or if it's just a consequence of people being terrified of change.
Increasing interoperability sounds like a good reason to move the data to things that don't use GUI only proprietary interaction, rather than a good reason to throw some duct tape on. But that takes actual work
I don’t think even the RPA department will disagree on that one.
But while the 3rd 100million project to rewrite that legacy, proprietary cobolt data app is faltering, the RPA department is actually making it accessible via a rest api that activates a virtual mouse that clicks around and ctr+c,ctr-v the result back to the user.
The curse of building great digital infrastructure in the 80s is you might get stuck with it 40 years later.
Also, and I think this is underappreciated by the HN crowd, because they don't work at these types of companies -- interfacing with legacy business-critical applications.
Most software products that companies buy have interoperability as either the least prioritized feature or as something to be actively prohibited.
The best, brightest, most modern examples of software, we are not talking about.
"as opposed to building proper systems integrations or rebuilding the underlying legacy app entirely."
Spinning the blame around a bit, I've often thought that part of the problem is we keep building GUI toolkits that hate this usecase. If they supported this better, the RPA stuff would be less awful.
Appletalk almost did it, but my impression is that it is dead now.
Websites have decent support for it, but trying to use it in practice still involves a lot of little compromises everywhere. It still breaks pretty easily, and the workflow is bad even when you learn all the tricks.
But there's a lot of useful code buried in GUIs. If there was a way to write scripts against the UI, in a discoverable, testable manner, this would be a much more sensible strategy. And you wouldn't necessarily have to hire developers just to maintain a "real" solution.
But we persist in treating this as a fifth-class citizen in our widget sets, so... here we are.
I mean, yeah, it would always be a bit of a tech debt pit, but it doesn't have to be anywhere near as bad as it is now.
Unfortunately, A lot of RPA companies, including UiPath, have co-opted the word RPA into enterprise marketing, alongside words like 'AI', so the words lose meaning. But RPA is just automating the UI, when no API exists.
Disclosure: I'm a co-founder in an RPA startup. I think RPA is a confusing, historical accident of a name.
We think UI automation has a lot of potential as a programming paradigm accessible to non-coders. Once RPA hype and noise dies down, perhaps a few signals like that will remain.
A lot of unnecessary hype indeed, though you can actually throw in occasional OCR/NER blocks in the workflow you design. Most often it's common NLP tasks on documents being moved around, but also forecasting, etc.
Definitely the gist of it. You can also make .NET framework custom actions to put into your workflow. I dabbled in it for several projects and although its fairly powerful. Working in a GUI workflow designer is cumbersome for anything even moderately complex, and they lock you into their ecosystem of products for DB access from your workflow, OCR/Document processing, handing off tasks to humans, and just overall restrict your capabilities unless you pay them huge licensing fees.
It really seems to be an enterprise (and large-scale professional services) focused tool. It was difficult to get support as a small consulting agency working for a small client.
For the most part, the developer community is very insular and lacks a lot of technical skill. Its primarily Indian and latin american developers using RPA to get into the field. It was frustrating at times needing help on a platform-specific issue and being directed by the same social engagement-focused "experts" to watch their own "tutorial" videos when it didn't answer the question I was posing, and they had nothing to offer besides their video. When I did help answer people's questions in the forums, I was hounded with unrelated questions in my direct messages because I appeared competent. Its very much a "here's my problem please fix" kind of community, where the goal is to solve their immediate issue instead of learn how to do it themselves.
I'm a little jaded to the field of RPA after my experiences. UiPath has some novel solutions to targeting GUI elements using a selector language and introspecting the structure of the GUI itself, but the lock-in and licensing costs really make it inaccessible to most small-medium sized businesses, the performance is really poor, and the development effort of making a resilient solution is pretty high.
I think if I were to get back into it, I would look at workflow languages without a visual workflow designer instead, and avoid GUI interaction in the process at all costs.
I understand the niche, but I don't particularly care for it. It's an enabler for shortsighted, 'keep the lights on but cut costs and corners' operating strategies that usually go hand-in-hand with technical debt accumulation and brain drain.