I think this article misses the mark of the actual move Microsoft is making here, but I think MSFT also gets their own messaging wrong. Microsoft's "Low-Code" strategy is not RPA, nor is it enabling the development of enterprise applications with "Low Code" development tools. RPA is already a legacy solution in it's current form, and increasingly only useful with regards to mainframe emulators and applications that don't offer an API, which are rarer and rarer with the move to cloud everything. Enterprise applications should only exist as applications, not as components/products of another enterprise application.
Microsoft's Low-Code "strategy" is providing tools for business process applications, they're just really bad at messaging that. Enable original data to get into their ecosystem (Power Apps), transform, evaluate, and move it around (Power Automate), and then provide understanding and feedback (Power BI). If every part of their ecosystem -*including their productivity suite and OS*- has an API backing it up (which it does) then their real play here is not providing "Low-Code/No Code" tools for building *applications* but rather for API integration and orchestration. This is the "new" RPA.
Why would one need to build an RPA "bot" or enterprise application if one can just generate a form with Power Apps, use Power Automate to reach into your Outlook, Excel, SharePoint List, OneDrive, or Windows file system, and then crap out the desired product in the system of record or a Power BI dashboard?
Source: I've worked in the RPA space for over 5 years now as a SWE, Tech Lead, and Architect.
> 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)
100% agree. The real value of these RPA solutions is their orchestration capabilities, but that's not how they sell it. They will start bleeding customers as those systems they're automating are replaced with those that provide more surfaces to interact with (like API).
The real utility RPA solutions are supposed to provide to the enterprise is cost savings. These savings should then be put toward upgrading those legacy systems that required the RPA solution.
I have never seen a company disciplined enough to direct those savings in that way. RPA companies have been so caught up in being a "hot item" and classified as a sub-category of AI (for whatever reason) that they don't seem to realize they've been selling their own demise.
Maybe I'm too cynical, but my experience with RPA via automation-anywhere is that the primary audience isn't IT or Engineering, but frustrated Line-of-Business middle management who are tired of waiting for IT to build them a solution and can't get budget-approval for a third-party to do it for them.
Couple that with woo like "self-healing", "insights", and "big data", etc along with dog whistles like "People will be scared you're automating them out of a job. You need to use discretion when implementing solutions".
I feel like the way RPA is sold to big corporations is analogous to how health-food stores sell muscle supplements to teenage boys.
You're not cynical, that is their strategy. It's why most IT organizations label RPA as "anti-pattern" and want nothing to do with it. It's sold in a way that explicitly calls into question ITs own utility, if not out-right calls it the problem! It's certainly not helpful. The only successful ROM (robotic operating model) implementations I have seen are ones that have the full-throated support and participation of IT.
The most beneficial model I've come up with was a cooperative one, where RPA is the wireframe / prototype of business automation requests to IT.
IT promise to business: "You can use RPA if we tell you we can't build a thing in time."
Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution."
And then be very particular that business needs to have documentation of their RPA in order to implement in production (business process / ask, notsomuch technical).
This accomplishes a few positive things: (1) takes {insert dumb / hard / bad ROI business request off IT's priority plate}, (2) forces business to think about what they actually want, (3) forces business to document what they actually want, (4) provides business the flexibility to change their automation, when the realize they don't want what they thought they wanted, & (5) burns not-developer time learning all the intricacies and quirks of {legacy software / website / data}.
In the end, when IT comes back around knocking, their business counterparts actually have gasp documentation. And furthermore, documentation that's actually been battle tested and seen prod systems & data.
(It's an admittance that most IT projects fail not for lack of technical feasibility, but for incomplete or shifting specs)
>IT promise to business: "You can use RPA if we tell you we can't build a thing in time."
>
>Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution."
This is the _whole_ life-cycle of a correct RPA implementation. The only successful RPA automation is the one that gets turned off because it has been solved for in the enterprise application level.
I’ve seen it happen with excel, access sql-server; and RPA. Some some Frankenstein’s monster is cobbled together to solve a problem whose best solution would be “stop producing the report that nobody looks at” only to have it slowly decay out of orbit.
The other major flaw with RPA is non-engineering LOB employees (in my experience) are incredibly myopic and implement solutions to get shit done now without thought about future consequences of their decisions. They try to replicate the 800 steps they take to make something work instead of asking “more steps adds opportunity for failure; what is the minimum I need to do to reach goal”.
That's why the documentation prod gatekeeping is critical to long term company health.
You're not going to stop them doing things -- because there's never "enough" IT / they always have Excel.
So what's the next least bad?
IMHO, give them something flexible enough (RPA) that they don't have to go outside of the box + require they leave a documentation trail of what / why they built. (Oh! And teach them about SLAs and SRE best practices!)
Then come down like a ton of bricks if they don't follow the latter. Carrot & stick.
Cheaper pressure release valves (RPA), not expensively overengineered containers (hiring more engineers).
---
Ironically, the hardest conversation at (insert F500 I designed an RPA practice for)?
"Business users shouldn't be able to use IT change control tools!"
Wait... isn't this exactly what we're always griping they don't do?
> "Business users shouldn't be able to use IT change control tools!"
> Wait... isn't this exactly what we're always griping they don't do?
This is something I hate. In IT, we use change control processes - change requests which have to get approved, discussed at the change advisory board, etc.
There are a lot of questions to answer before something goes into Production: Was it tested internally? Did the business area test it and sign off on the change? Is there evidence of said testing? Was code review completed? Is there a backout plan?
I've never seen the same rigour applied to configuration or processes that are managed by the business area, even though their configuration can do quite a bit of damage. Change the inactive customer purge time from 2 years to 2 days? Oops, virtually all of the customers have been purged.
Sometimes the solution is also "Get IT to fix the thing that you're working around"
There was a delivered process to do a particular job, but it didn't work. Nobody thought to tell IT that it didn't work, instead they built a Ruby+Selenium script and ran it on a spare computer. Which worked great until it didn't.
How is legacy compatibility a moat? Any RPA engine, certainly Microsoft's is going to cover the same stack. That's one of the consequences of RPA - when you integrate at the UI layer, you get compatibility for free.
In real practice, it's triggering some esoteric sub-event the developer hooked, or returning coherent data tables from whatever not-table thing a developer cobbled together.
Example from current work (US government system, Oracle Forms / Java based): a scrollable "grid", actually composed of individual, carefully-lined up text boxes, containing 12 rows, which moves / updates the contents of each box as the user scrolls.
Most of them look for window events. I've not seen an RPA tool that actually reads the screen like a human, even though that's how you're thinking about it.
As a fellow SWE who's been in the RPA space for a few years now, I'll offer an alternative perspective.
Traditional RPA is here to stay, and only getting bigger. By "traditional" I mean screen-scraping and click bots. It's not only for legacy apps. It also addresses two development pain points that will never go away: (1) complexity and (2) missing features.
On (1), I've worked with companies whose APIs are so convoluted and poorly supported, and distributing your client in their ecosystem is so complex, that I've thrown up my hands and gone, "Forget it, I'll implement this with a service account." An RPA process logs into the front end, clicks around, scrapes some data, outputs it to the next process in my pipeline, and it's done. I've written processes like this that have been running for years with basically no maintenance due to stable-enough UIs. UI changes are still a risk, but if you have a mature UI, it's a great, simple alternative to a more complex process.
Regarding (2), APIs don't always expose all the features of the UI, and sometimes vendors won't, or can't, add them in a given budget or time frame. I worked with a partner whose API had essentially one read-only endpoint. Their product was fantastic and they had other integration methods; they just hadn't prioritized API development, which they could afford to do because they delivered so well in their niche otherwise. We had to get creative in how we would pull the data.
I know where you're coming from, but if the ROI is there, it doesn't matter if the first iteration is fragile.
Just make sure your monitoring and support are rock solid. If the RPA stumbles, someone needs to know right away, and they need to be there to catch it. And it should never be designed in a way that it could cause critical issues in the meantime.
I would add, RPA isn't as fragile as its reputation sometimes suggests anyway. Sure, using it on a top-500 site is going to be a problem because of frequent UI changes. But we've successfully used it on systems in less "move fast and break things" industries that have been there twenty years, and they're going strong.
Using it to monkey patch "features" onto external vendors is huge.
Sometimes, it's because the feature cuts against the vendor's business model (e.g. Verint's terrible CCTV server appliances / software client not allowing bulk export).
More often, it's because it's not a priority (e.g. mass-updating on a system that only allows a single update at a time).
Think a dedicated account in an old 3-tier architecture meant for a bot to login rather than a human. You're not making API calls though (at least not as we typically describe API calls), you're making HTTP requests to pull down a web page and then screen-scraping within the resulting HTML/JS.
Without a dedicated account your RPA bot needs to essentially impersonate a human or let the human login first and then drive the dashboard until the bot completes and the human can resume using their desktop seat. Very inconvenient for the human, and problematic for logging of who's really doing what.
Were it an internally owned application that's a legitimate course, but more often than not it's to grab data from third-party provider applications where DB is not an option, i.e. banking sites
ok, but normally banking has established protocols? If this is the main use-case of RPA-startups, Microsoft does not compete in any way. I don't see a lot of reasons (name one for me) for a legitimate business to pay an RPA-startup over the bank for automated data acquisition.
Another use-case could be the cloud probably – like scraping your salesforce apps. And this is just .... sad?
> but I think MSFT also gets their own messaging wrong.
Or, is it possible MSFT knows that when selling to "enterprise", it works a lot better to say you've got a better version of "thing they know", instead of a brand new thing that will replace "thing they know".
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.
MSFT is just doing so well at getting "enterprise" lock-in, that I'm reluctant to conclude they are getting anything at all "mixed up" in their messaging to decision-makers. At present they seem to be doing it exactly right for their business goals.
I have worked at and know of so many place that are "no, you can't spend money on that product, you have to use the equivalent from MSFT that is already included in our deal." Which is one reason it might be in MSFT's benefit to convince you that their thing is in the same class as some other thing you could spend money on, or may already be spending money on. And also, yeah, they are indeed convincing decision-makerse that they meet everyone's use-case and is whatever you want it to be, it's working....
I work in an enterprise and use flow and other Power platform stuff. The sense I get is that management look at the headline features and see it as essentially safe. But Microsoft have included some features that will be exploited in unexpected ways that create a maintenance and security problem.
A good example is that Flow/Power Automate can be triggered using an API end point. That can then be configured to provide a http response (including headers). It makes it super easy to setup APIs that have no security and expose corporate data.
I think the Power platform is like a modern Excel. Simple and inoffensive at first glance. But full of features that let unskilled users do risky things that will quickly become business critical. But the convergence of Office 365, SharePoint, Flow, PowerBI and dynamics is unstoppable.
> But full of features that let unskilled users do risky things that will quickly become business critical.
Isn't the answer the same as it has always been? That is, maintain a relationship with the business where you are trusted.
When IT and the business units trust each other (to some extent) then you see better feedback cycles. This is an infrequent occurrence because of the attitudes of IT. When trust exists, the business areas will share information on their apps and partake in exercises to properly productionize apps.
IT break trust in multiple ways often simultaneously. They try to stamp out apps without giving the business an interim solution, fail to communicate well, implement security policies which aren't grounded in good practice, etc. These are just a litany of missteps that you have to unravel when you are asked to recover situations like these.
> What's something that corporate IT is obsessed with? Making sure the business isn't creating shadow IT and developing enterprise applications.
Though with Power Apps and Power BI all of that starts showing up on IT's dashboards (Azure Portal; Microsoft 365). Microsoft hasn't been great about messaging that, but unlike hidden Excel files in random network shares or VB+Access apps in PCs in cupboards, that "amazing CI/CD tool for enterprise applications" also means that it can't just live in the shadows and will get seen by IT.
If anything, I've seen "citizen developers" turn away from Power BI/Power Apps precisely because their M365/Azure admins are too micro-managing to use the tools for what they were intended for and such people just go back to that Excel+VBA macros on a network share in a broom closet.
Which yes, gets back to Microsoft is trying too hard to meet everyone's use case and in forcing Power BI/Power Apps into M365/Azure they've trapped out some of the "I just need to get stuff done" "citizen devs" because some IT departments are so scared of shadows that they are preemptively blocking one of the tools they could use to keep an eye on it better. It's a lovely irony.
> I've seen "citizen developers" turn away from Power BI/Power Apps precisely because their M365/Azure admins are too micro-managing
I've been on both sides of the IT gatekeeping story, and enjoy the irony that we've gone full circle from the mass exodus of business users to SaaS to circumvent gatekeeping only for the success of those tools to introduce centralized management to appeal to more IT organizations.
Deleted a comment above where I posted exactly what WorldMaker said. Agree 100%!
IMHO, the key is change control.
Programmatic change control (and CI/CD when more evolved) should be an organizational tool, not an IT tool.
"We found a user doing wrong" should be an opportunity to ask "What would this user need to do it right?" rather than simply telling them no. Because oftentimes they literally can't do things "IT-correct" (because of permissions, job title, org location, etc).
It seems maladaptive to blame users for not using tools & processes they haven't been allowed to have.
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.
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.
Can you explain some of the terms you use a bit more?
You say that Microsoft's strategy is not about enabling the development of "enterprise applications". Then you say it's about providing tools for "business process applications". What's the difference?
Then you say it's not about providing tools for "applications" but rather "API integration and orchestration". Are you trying to say that the latter is about building headless processes without a UI? Don't a lot of processes require forms and human input? Aren't those "applications"?
I'm sorry, yes, re-reading it I do conflate some terms.
Enterprise applications are those that are built for, enable, and underpin enterprise sized concerns.
So for your financial department you want and enterprise application that owns, orchestrates, and audits the work of finance.
However most if not all business processes cannot exist solely within an enterprise application, so you want to give them "tools for application to the business process". That's probably more high-handed than it needs to be, but eh :D
So in this what I'm arguing is that MSFT here isn't trying to position Power Apps/Automate as a tool for developing enterprise applications, but rather high-grade capabilities (I'm remiss to say "enterprise grade" as people will then conflate that too) that allow the business to tie all ends of their business process together. The best way to do this is by giving everything outside of the enterprise application knowledge and reach to each other via API.
To your point, yes, this could require the business to build applications for their own processes, but these aren't enterprise applications, simply process specific applications.
Traditionally these were macro enabled Excel workbooks and Access apps that were squirrelled away deep in so many Network Drives, underpinning vital business process functions but wholly unknowable to leadership or those maintaining the enterprise application itself.
I wouldn't say API orchestration is the "new RPA", though. It's rather the "old BPM", and "current IPaaS". That is, we already have tools for API orchestration. It's nothing new. RPA is something different entirely.
And it's benefit isn't just for automating legacy systems. Automating the UI they're already familiar with is a much more intuitive experience for lots of people than going out of band to integrate with APIs.
That's the thing MSFT is trying to solve for with things like Power Automate and Apps.
Sure, getting an API schema and then writing a GET request in C#, Node, etc to get invoice data out of your financials system is out of band for a business user, selecting the action "Get invoice by number" from the "IBM Cloud Financials" connector in Power Automate is well within band.
That's easier than writing a GET request, but the easiest would be never leaving your native application, which AFAIU, RPA lets you do in theory (though practice is a different story).
The promise of universal API is overrated. It has some truth thatthe RPA brings the best bang for buck for mainframe etc., but in local on premise ecosystem the application API especially cross vendor is a hit and miss. The real promise is in the cloud where API becomes a mandate.
I've recently been dipping my toes in the RPA space (with Kofax RPA) and what you wrote validates my first impressions. The partner firm I'm working with insists that they have been seeing "insane and growing" demand for RPA solutions, which I kind of find hard to believe.
RPA is a financial services buzzword right now. I’ve worked on an RPA library that manipulates a web application…which the company already provided full API access to.
The RPA library requires those working with it to examine the page HTML in order to hook into it, since it’s highly dynamic: you have to see what form fields are available and their internal IDs in order to interact with them. Meanwhile, the API layer gives access to all the same CRUD, and maybe with better documentation (I have not seen it).
If you don’t have a human user, just use the APIs! That’s what they are there for!
That's interesting as I figured Kofax would be an operation that would really nail RPA and then move on to providing a very robust API middleware solution, given Kofax's bread-and-butter is literally addressing use-cases that take data from outside the system (document processing) to inside the system (process and data management).
Yes, as a SWE when you actually see how these RPA solutions run they are not impressive. Heck, before they moved to the cloud most of them were simply providing a wrapper for Windows interop assemblies (COM, Office, what-have-you) and its native Task Scheduler capability.
As a piece of technology their real value proposition is the deployment, orchestration, & management of the automations. Even four years ago they should have included VMs/VM environments in that package, so that you're not just managing a "bot", but the whole kit-and-caboodle. This would have made their offering absolutely unique and more comprehensive.
If by "this space" you mean RPA, then no. RPA platforms integrate with the target app's UI. Zapier (which typically is considered IPaaS, not RPA) integrates with the target app's API. It provides it's own UI to facilitate this, but it doesn't integrate with the target app's UI layer.
Companies will always confuse these terms as they fight the marketing wars. UIPath, for instance, refers to any RPA solution that includes API integration as "end-to-end RPA". But the substantive difference between RPA and IPaaS is whether or not the API or the UI is the point of integration.
Microsoft's Low-Code "strategy" is providing tools for business process applications, they're just really bad at messaging that. Enable original data to get into their ecosystem (Power Apps), transform, evaluate, and move it around (Power Automate), and then provide understanding and feedback (Power BI). If every part of their ecosystem -*including their productivity suite and OS*- has an API backing it up (which it does) then their real play here is not providing "Low-Code/No Code" tools for building *applications* but rather for API integration and orchestration. This is the "new" RPA.
Why would one need to build an RPA "bot" or enterprise application if one can just generate a form with Power Apps, use Power Automate to reach into your Outlook, Excel, SharePoint List, OneDrive, or Windows file system, and then crap out the desired product in the system of record or a Power BI dashboard?
Source: I've worked in the RPA space for over 5 years now as a SWE, Tech Lead, and Architect.