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

161–170 of 198 posts

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

#161

Post by geonic »

ffhhj wrote: post #128
geonic wrote: post #111

Earlier quoted context omitted.

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…

Then feel fortunate if you don't have to install also Skype and Outlook.

Outlook is next on the list. It does replace Lotus Notus though which is why I believe it can only get better.

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

#162

Post by ethbr0 »

jwally wrote: post #160
Mister_Snuggles wrote: post #119

Earlier quoted context omitted.

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

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?

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

#163

Post by ethbr0 »

m1sta_ wrote: post #154
mgummelt wrote: post #140

Earlier quoted context omitted.

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.

The bit players simply map Active Accessibility / whatever MS calls it now (Windows Automation Framework?).

The more serious players shadow Windows events.

The real stuff does process injection and directly shadow copies / modifies in-memory data structures.

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

#164

Post by ethbr0 »

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.

"Integrate at the UI layer" is a can of worms.

In simple cases, it's clicking a button.

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.

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

#165

Post by ethbr0 »

meldyr wrote: post #158
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…

And (3) external parties. An example is a SME which wants to download the billing information of 100 employee from ATNT’s customer port

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

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

#166

Post by [deleted] »

7952 wrote: post #68
jrochkind1 wrote: post #52

Earlier quoted context omitted.

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

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…

[deleted]

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

#167

Post by ethbr0 »

tomnipotent wrote: post #153
WorldMaker wrote: post #122

Earlier quoted context omitted.

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

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.

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

#168

Post by zerkten »

7952 wrote: post #68
jrochkind1 wrote: post #52

Earlier quoted context omitted.

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

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…

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

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

#169

Post by Mister_Snuggles »

ethbr0 wrote: post #162
jwally wrote: post #160

Earlier quoted context omitted.

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

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…

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

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

#170

Post by asdfman123 »

Asymmetryk wrote: post #121
asdfman123 wrote: post #14

Earlier quoted context omitted.

A lot of people stuck in places like, say, the accounting department have the soul of a dev. They like technology and want to automate things. And often times when they do that, they actually improve their departments quite a bit with stuff like VBA and Access projects (as uncool as they may seem to some). It works because "real" programming environments have learning curves that are hard to tackle if you have a day…

if I may be so bold ( and presumptuous my suggestion is of any value) I wondered if your friend would like the risk and structured securities aspects of actuarial catastrophe risk markets. This pretty much has everything in it, from chaos theory to the statistics of the cadence of liabilities upon the different kinds of financial engineering structure that are used to distribute * the liability and fund the most diff…

Actually he's super into stock options and all that stuff. I think he majored in finance. I was the one who convinced him to do programming (although he's heading towards data science I guess now).

Also we had a falling out since then, so shrugs.

Post reply on HN