Microsoft's low-code strategy paints a target on UIPath and other RPA companies

Well said.

> The moat protecting the market share of the big RPA companies is created by the mature deployment systems that enable large enterprises to run hundreds or thousands of automated processes

This is completely incorrect. Managing processes and bots is the absolute easiest thing they do, because it's entirely under their control and a solved problem.

The actual moat is legacy compatibility -- how broad a tech stack does your RPA engine cover?

Microsoft Active Accessibility? Excel? Excel + VBScript? Legacy Windows native? VB6? Early Java with custom UI grid classes?

The point the author should be making is that Microsoft, Google, and Amazon have zero interest in eating UiPath's lunch. It's expensive (in people-time-dollars) and custom per customer. And ultimately, it's a long-tail game.

Microsoft's play is to trivially link together new deployments or migrations (i.e. to O365), then continue adding customers as more migrate to them.

Why pay to chase the customer, when they're already running towards you?

(FWIW, I think UiPath realizes this, which is why most of their new products / features are pivoting to become an Appian-esque rapid app platform. AA and BP? Less clueful)

These are some excellent points. I think the big takeaway here is that RPA isn't what it used to be, and the rapid changes in this space help explain why RPA is gaining traction (seemingly inexplicably, if one still assumes that RPA = screen scraping mainframes).

RPA products are increasingly becoming integration products. For example, and vendors like UiPath increasingly provide native API integration capabilities where possible. I've even seen integration products that formerly would have fit into the "iPaaS" space market themselves as RPA solutions, even though they are primarily providing what is essentially an API abstraction layer, and they have no roots in "true" RPA.

I think this is happening due to the hype around RPA, and how effective the terminology is with the target audience.

I agree that "traditional" RPA is already a legacy solution, but at the same time, RPA vendors are rapidly pivoting to support API integrations (see UiPath's recent acquisition of Cloud Elements).

I hate the muddiness, but I've also had to take a step back and re-orient how I think/talk about RPA products due to how quickly the space has evolved.

Source: Also work in the RPA and Integration Platform space, primarily on the Product Management side.

How is this conceptually any different from InfoPath + SPD Workflows?

And if it's not conceptually different, what's going to make it work this time?

Aside - it's probably been discussed ad nauseam, but the Teams vs. Slack graphic is highly misleading because of the way it's bundled and distributed. It'd be like comparing the install base of Notepad vs. that of Notepad++.

It very well could be.

I think where MSFT gets mixed up is that they are obsessed with their products being able to solve *everyone's* use-case. Which means if they're talking to the business then it's a friendly "Low-Code" platform that any citizen developer can use. However, when they're talking to IT it's an amazing CI/CD tool for developing powerful enterprise applications! What's something that corporate IT is obsessed with? Making sure the business isn't creating shadow IT and developing enterprise applications.

I think you're right and I may be a little too hard on the RPA vendors here. I wouldn't put it past UIPath or one of the smaller vendors being able to expand what they consider "RPA" into competing directly with what would be API orchestration with the likes of MuleSoft, Appian, Power Automate, etc.