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

151–160 of 198 posts

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

#151

Post by mgummelt »

WorldMaker wrote: post #147
mgummelt wrote: post #141

Earlier quoted context omitted.

Visual Basic is an overloaded term that can refer to both the language and the RAD IDE. The IDE was certainly low-code.

Having done more than my share of coding in VB3-6, I can tell you that VB in any incarnation has never been "low code". If you think that WinForms or XAML in Visual Studio is any less RAD or somehow "more code" than the VB<=6 IDE, you are wearing some amazing nostalgia goggles and I wish I could believe in a world you seem to think existed.

Low code just means using visual techniques to replace or augment code, so any WYSIWYG system, including VB or XAML, qualifies.

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

#152

Post by JohnL4 »

dnndev wrote: post #55
golergka wrote: post #29

Earlier quoted context omitted.

Isn't that survivorship bias in action? Good solutions that not only work, but work well and don't hit the tech limitations would never be seen like developers like you, because they would never need to be rewritten.

I am not sure how this comment contributes to the thread. It is a bias because I write my real-world experiences? What you are saying is true for so many things. Car that does not break does not need a mechanic. Of course, and nobody is disputing that. This comment just made me laugh so hard I had to reply.

THAT comment contributes nothing to the thread.

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

#153

Post by tomnipotent »

WorldMaker wrote: post #122
ajcp wrote: post #48

Earlier quoted context omitted.

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

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

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

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

#154

Post by m1sta_ »

mgummelt wrote: post #140
ethbr0 wrote: post #42

Earlier quoted context omitted.

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

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.

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.

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

#155

Post by m1sta_ »

Havoc wrote: post #105
ajcp wrote: post #27

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

> RPA is already a legacy solution in it's current form Not sure about legacy. Modern glorified ducktape to make legacy stuff play nice is more like it imo

Same diff.

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

#156

Post by nightski »

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…

Sure it's work. But is it really more work than developing an entire new system from scratch? Because that is incredibly labor intensive, if not one of the most expensive endeavors in IT you can undertake imho. It's easy to think IT will create the perfect system that has no support issues but TBH there will probably be just as many.

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

#157

Post by AtNightWeCode »

AtNightWeCode wrote: post #75
ARandomerDude wrote: post #57

The most mind-blowing part of the article was the Teams vs Slack screenshot. https://res.infoq.com/articles/cloud-vendors-low-code/en/res...

You get Teams accounts with pretty much any MS thing. Teams still can't be used for chat in enterprise environments. It is laughable.

Some MS person down voted this I guess. :) I have Teams accounts in at least a handful of tenants and it does not work for chatting.

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

#158

Post by meldyr »

brushfoot wrote: post #108
ajcp wrote: post #27

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

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

And (3) external parties.

An example is a SME which wants to download the billing information of 100 employee from ATNT’s customer port

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

#160

Post by jwally »

Mister_Snuggles wrote: post #119
ajcp wrote: post #100

Earlier quoted context omitted.

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

In my experience, the lifecycle is more like: * Person in the business area implements RPA. Business area is happy. * Person who implemented RPA moves on to greener pastures. * RPA breaks, business area calls IT. * IT is horrified at the unsupportable mess that's just been dropped in their laps.

1000% this.

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

/soapbox (Sorry)

Post reply on HN