Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

infoq.com

Post reply on HN
Print view View original

191–198 of 198 posts

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

#191

Post by pkilgore »

fartcannon wrote: post #101
pkilgore wrote: post #70

Earlier quoted context omitted.

> recently revealed work that Microsoft has being doing in swaying opinion on hacker news I'd love a link. Unfortunately "microsoft and hacker " get's swallowed up in search results by recent attack news.

https://sg.finance.yahoo.com/news/microsoft-corp-msft-q1-201... "In fact, this morning, I was reading a news article in Hacker News, which is a community where we have been working hard to make sure that Azure is growing in popularity and I was pleasantly surprised to see that we have made a lot of progress..."

Thanks! Hard to read much into that call other than Microsoft folks 1) Read Hacker News and 2) Are targeting it as an audience for which they would like to be more popular in.

You had made it sound like some sort of coordinated astroturfing operation.

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

#192

Post by ajcp »

mgummelt wrote: post #187
ajcp wrote: post #184

Earlier quoted context omitted.

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 app…

Ah, I see. 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 integ…

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.

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

#193

Post by F_J_H »

syshum wrote: post #148
F_J_H wrote: post #106

Earlier quoted context omitted.

Yes this happens...sometimes. And, other times, (as reflected in comments ITT), there are many cases where a low-code solution built by a non-dev have brought huge benefit. (I've seen this myself - see below - MS Access apps that saved hours and hours of work, but which IT had not time to look at.) I've also seen the sentiment in your comment lead to an outright ban by IT dept. of all low-code tools, for no other rea…

My counter, and anecdote, to this is the IT Dept recation is not so much a "slippery slope fallacy" but rather a reaction to past actual experiences it is ironic that you bring up Access because that is one the tools I despise the most, our helpdesk is routinely indated with requests from people that pass around Access Databases with custom data links either to Excel files, or ODBC connections that are not standard b…

So you'd ban MS Access? Why do people use it as opposed to an "IT Sanctioned" tool? If you IT dept does not have time to provide the tools people need to do their jobs, and you take away one of their tools, what/who fills the productivity gap?

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

#194

Post by mgummelt »

hudgeon wrote: post #190
mgummelt wrote: post #189

Earlier quoted context omitted.

Where are you seeing that it's a standard code format? I've skimmed this: https://powerapps.microsoft.com/en-us/blog/what-is-microsoft... and it seems that it's just a simple expression language, not a standard format that an entire PowerApps app would compile down to.

Hmmm. Good question. I was using standard format to mean two things: 1. Common code format across the Power platform, and 2. the branding MS was using to describe everything that would be put under source control. I have some doubts about whether the second point is true. This article ( https://docs.microsoft.com/en-us/power-platform/power-fx/ove... ) discuss PowerFX stored as YAML files under source control. And thi…

Even then, if the YAML files can only be interpreted by Power Apps, then they can't be portably deployed.

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

#195

Post by mgummelt »

ajcp wrote: post #192
mgummelt wrote: post #187

Earlier quoted context omitted.

Ah, I see. 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 integ…

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).

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

#196

Post by fock »

ajcp wrote: post #139
fock wrote: post #132

Earlier quoted context omitted.

if it's just scraping data: why don't hook it directly into the DB then?

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?

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

#197

Post by Mandatum »

fock wrote: post #196
ajcp wrote: post #139

Earlier quoted context omitted.

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?

Your assumption of "normally banking has established protocols" is wrong

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

#198

Post by filoeleven »

trixie_ wrote: post #174
filoeleven wrote: post #113

Earlier quoted context omitted.

Better tooling for data-oriented interfaces is the answer. Everything CRUD does is at the interface layer. If you improve the semantics and discoverability of the interface, you enable better tools and products to grow from that. https://www.destroyallsoftware.com/talks/boundaries This talk encapsulates (heh) a lot of the ideals that I agree with. Strong guarantees at the interface layer are good, and foster better t…

Not sure what this has to do with the immense amount of code that needs to be written across various layers in a stack to do the simplest task. Can you translate this into some real and actionable?

This is a late reply, and I think I misunderstood your meaning.

I don’t have good answers on how to drop layers from the stack, they all seem pretty necessary. Storage is obvious, backend is needed for authentication if nothing else and powers the API layer. Front end could be replaced by APIs, and often is in products, but someone ultimately has to write a view for humans if humans will use the system.

Post reply on HN