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

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

#111

Post by geonic » Wed, Jun 02, 2021, 10:18 PM UTC

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

I‘m not a Microsoft user, haven’t been for over ten years.

Recently I had to install and register for Teams at work. I haven’t seen an application as clunky and messy as this in a long time. Nothing in its UI makes any sense to me.

On top of that the login process is extremely wonky and unstable.

To me this Microsoft doing again what it does best. Pushing some crappy software into the market by leveraging its market position.

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

#112

Post by ajcp » Wed, Jun 02, 2021, 10:19 PM UTC

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.

Certainly, I believe any of those API "middleware" tooling should be treated as the "new" RPA. IFTTT, Zapier, MuleSoft, Appian, etc

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

#113

Post by filoeleven » Wed, Jun 02, 2021, 10:19 PM UTC

trixie_ wrote: post #94

We really need a revolution in the low code space. The amount of code we write - database, backend, api, frontend, etc.. to do the simplest CRUD task, makes me feel like compared to future programmers we're all cavemen rubbing two sticks together.

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 tools and products, whether they are low code or not. If you know with great specificity what is required at the boundaries, it crystallizes most things inside of any app. It’s not a silver bullet! But it limits the damage we can do and steers us in the right direction.

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

#114

Post by Graffur » Wed, Jun 02, 2021, 10:34 PM UTC

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…

Building fragile solutions for missing features is a bad road to go down. It may be your only solution but good luck in the future..

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

#115

Post by spydum » Wed, Jun 02, 2021, 10:34 PM UTC

ajcp wrote: post #84

enraged_camel wrote: post #66

Earlier quoted context omitted.

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.

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

Pretty sure kofax road is just KaPow acquisition, but yes.

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

#116

Post by tialaramex » Wed, Jun 02, 2021, 10:36 PM UTC

haswell wrote: post #78

syshum wrote: post #74

Earlier quoted context omitted.

I agree somewhat, the problem with "business outcome perspective" likely means very short term thinking, get it done now, deal with the rest later. The people that cause the mess are not likely the ones that have to clean up the mess, people like me are. I prefer to greenfield things but instead I spend the majority of my time untangling the bad choices people made years before coming at it from a "business outcome p…

I tend to agree with you in most situations, but I do think there are some counter examples. The recent rollout of various COVID tracking apps for large companies come to mind. There was no way to predict the need, and low code tools were leveraged heavily to spin up quick solutions. e.g. I believe SalesForce products were used for some of the "Vaccine Finder" types of sites that spun up in my state. That aside, as a…

The CCADB https://www.ccadb.org/ is built out of SalesForce. Its purpose is to mechanise the paperwork needed to manage the relationship between the major Root Trust Stores and the Certificate Authorities.

Its members are Mozilla, Microsoft and Google (in principle you could imagine Apple choosing to join some day, or then again maybe not, likewise perhaps Oracle). Clearly any of those entities could build a web site, they already own several web sites, and if this was rocket surgery (and it isn't) they employ rocket surgeons already. But they chose to use SalesForce.

And I've always supposed that one big reason is that you clearly can't let the other guy write the system you'll both use, and yet you also definitely don't want to waste your resources on working together to write it, that's usually even more expensive than either of you writing it alone.

But low code as a matter of principle also makes sense in this space. This is "just" mechanising some paperwork, it shouldn't need to be complicated. There shouldn't need to be a Mozilla engineer working on the CCADB.

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

#117

Post by Graffur » Wed, Jun 02, 2021, 10:37 PM UTC

tyingq wrote: post #31

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…

"Who has actually seen a success story with this sort of thing?" Citizen development stuff is usually more successful than an IT department knows. They think it's failing because every time they hear about it, it's because of some mess. The thing is, they don't hear about all the stuff that works fine. There's typically a ton of MS Access, Quickbase, Excel, Google Sheets, Salesforce, etc, "apps" written and run by no…

This stuff is a tactical solution that fills a gap in poor business solutions. Give it 5, 10 years and these non-IT solutions will be a nightmare for everyone involved.

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

#118

Post by Graffur » Wed, Jun 02, 2021, 10:39 PM UTC

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?

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

#119

Post by Mister_Snuggles » Wed, Jun 02, 2021, 10:48 PM UTC

ajcp wrote: post #100

ethbr0 wrote: post #93

Earlier quoted context omitted.

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

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

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

#120

Post by brushfoot » Wed, Jun 02, 2021, 10:49 PM UTC

Graffur wrote: post #114

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…

Building fragile solutions for missing features is a bad road to go down. It may be your only solution but good luck in the future..

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.