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

131–140 of 198 posts

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

#131

Post by WorldMaker »

jimnotgym wrote: post #63

If Microsoft were serious about 'low code' we would be looking at Visual Basic 7.

Visual Basic was never "Low Code". It certainly was "RAD" ("Rapid Application Development"), but VB was always a heavier weight language than people thought it was.

There was a Visual Basic 7. The current compiler for "Visual Basic 2019" is version number 16.0 and the version numbers carry directly through. The VB team moved on, even if if so many of the users didn't. You can get pretty RAD with WinForms (or WPF) on .NET 5 with VB in Visual Studio right now today. It's not the same ActiveX mess of the 90s but that's a good thing in its own way.

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

#132

Post by fock »

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…

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

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

#133

Post by ffhhj »

aparsons wrote: post #59
ajcp wrote: post #34

Earlier quoted context omitted.

Coming up in the time when MSFT was the "big evil" it's almost depressing to see myself now as an actual fan-boy.

The thing is, even when they were big evil, they had the best developer tooling by a mile. Visual Studio, MSDN, etc were novel and leagues ahead of other platform providers’ equivalents

Visual Studio is a copy of Delphi from the 90's.

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

#134

Post by mgummelt »

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…

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"?

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

#135

Post by myohmy »

Graffur wrote: post #118

Who will actually build and maintain these low code solutions? Will it be over qualified SWEs who will lose their skills over time if they work on this stuff? Or will it be citizen developers who were actually hired for some other skill set and won't care for solution design or future planning? Or will it be new employees hired with just this skill set?

Its not a good space for high performers. Regular programmers don't give a fuck. The paycheck spends the same.

Management doesn't give a fuck either, so yeah they'll hire for this limited skill set and probably pay less too.

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

#136

Post by myohmy »

bob1029 wrote: post #3

Who has actually seen a success story with this sort of thing? We arrived at "low-code", but by way of actually solving our problem domain through many hellish iterations and figuring out what all of the various points of configuration should be . As far as I am aware, this is not something that Microsoft or any other vendor can determine for your business ahead of time. I am sure that there are a lot of types of sma…

Low-code has been a success in my org, because it's driven by programmers with business analyst acumen. Its not for everyone, but for the right person, it just clicks and they can sit down with a client and come up with something great in very little time. It works very, very well as a rapid prototype or MVP tool.

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

#137

Post by mgummelt »

tootie wrote: post #90
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…

Would you say that Zapier is in this space? That seems to be the kind of use cases I see in my org.

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.

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

#138

Post by mgummelt »

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…

What do you mean "implement this with a service account"? Aren't service accounts just a way to authenticate to APIs?

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

#139

Post by ajcp »

fock wrote: post #132
brushfoot wrote: post #108

Earlier quoted context omitted.

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…

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

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

#140

Post by mgummelt »

ethbr0 wrote: post #42
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…

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.
Post reply on HN