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

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&#x27;s &quot;Low-Code&quot; strategy is not RPA, nor is it enabling the development of enterprise applications with &quot;Low Code&quot; development tools. RPA is already a legacy solution in it&#x27;s current form, and increasingly only useful with regards to mainframe emulators and applications that don&#x27;t offer an API, which are rarer and rarer with the move to cloud everything. Enterprise applications should only exist as applications, not as components&#x2F;products of another enterprise application.<p>Microsoft&#x27;s Low-Code &quot;strategy&quot; is providing tools for business process applications, they&#x27;re just really bad at messaging that. Enable original data to get into their ecosystem (Power Apps), transform, evaluate, and move it around (Power Automate), and then provide understanding and feedback (Power BI). If every part of their ecosystem -*including their productivity suite and OS*- has an API backing it up (which it does) then their real play here is not providing &quot;Low-Code&#x2F;No Code&quot; tools for building *applications* but rather for API integration and orchestration. This is the &quot;new&quot; RPA.<p>Why would one need to build an RPA &quot;bot&quot; or enterprise application if one can just generate a form with Power Apps, use Power Automate to reach into your Outlook, Excel, SharePoint List, OneDrive, or Windows file system, and then crap out the desired product in the system of record or a Power BI dashboard?<p>Source: I&#x27;ve worked in the RPA space for over 5 years now as a SWE, Tech Lead, and Architect.

This is addressing a market. I have seen it first hand more than once. Highly driven and competent individuals that are not programmers for whatever reason and that create a monstrosity that works (using some low code solution). It’s ugly and buggy but gets a job done. This works for as long as they don’t hit a technical limitation then call devs like myself in to replace it. It was a great phase 1 and made money.<p>They earned a project with developers. Yes it will cost more to rewrite it but the old system is still making money while the new one rolls out.<p>At this point a low code solution makes no sense for me as a dev - believe me I have tried them.<p>Kudos to MS.

I&#x27;m currently porting a slackbot to Teams. Even with the backend logic and architecture mostly re-usable, the Teams bot is already taking at least 3x as long to code, simply because their documentation is so obscure. It feels like detective work, correlating data from 4 different tangentially related sources (AzureAD, app authorization flows, Graph, BotFramework). I&#x27;ve never had so many tabs open at once in my life. At one point, I gave up on their documentation, and just traffic-sniffed the library used in one of their example apps in another language, to figure which endpoint to call and which json format to send it. The jump from Slack to Teams feels like the difference between Rails and (Java) Spring - the former makes web-apps, the latter is a framework and dependency injection container, which can be used to make various apps and services, among them web-apps.<p>Long story short, MS is a master at making you appreciate the difference between &quot;technically possible to achieve&quot; and &quot;easy and realistic to achieve&quot;. If my experience with them is any indication, MS still has a looong way to go before they can make their ecosystem of services accessible to &quot;normal&quot; people.

If this works, Microsoft is going to hit a long-term retention jackpot. Low-code ecosystems are sticky and excel in ARR as their model is usually consumption based. Moving away costs companies millions. Every employee is automating their work on this platform. I working with a consulting firm and one of our customers (+50,000 employees) has onboarded power-platform for every individual to automate their work.<p>If ever a change is proposed, the change management team is going to shoot this down or will be forced to create a 5 year migration plan.

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&#x27;re all cavemen rubbing two sticks together.

The most mind-blowing part of the article was the Teams vs Slack screenshot.<p><a href="https:&#x2F;&#x2F;res.infoq.com&#x2F;articles&#x2F;cloud-vendors-low-code&#x2F;en&#x2F;resources&#x2F;1figure-1-tweet-1622199580963.jpg" rel="nofollow">https:&#x2F;&#x2F;res.infoq.com&#x2F;articles&#x2F;cloud-vendors-low-code&#x2F;en&#x2F;res...</a>

Who has actually seen a success story with this sort of thing?<p>We arrived at &quot;low-code&quot;, but by way of actually solving our problem domain through many hellish iterations and figuring out what all of the various points of configuration <i>should be</i>. As far as I am aware, this is not something that Microsoft or any other vendor can determine for your business ahead of time.<p>I am sure that there are a lot of types of smaller needs that can be addressed with these sorts of tools, but the big tasks of integrating multiple unique&#x2F;legacy business systems together into a single logical process with its own internal state is not ever feasible with these tools. You can always get close, but its like a siren song in my experience.

There has been a huge push for low-code over the last couple of years. The idea that anybody can setup a business flow is compelling and easily sold. But low code means a lot of config and these systems are nothing new and over time they will sooner or later become limiting. If you have everything in code any problem can be solved.<p>You also still need to solve the things like CI&#x2F;CD, CM, dependencies, data modelling, correctness, resilience, security, compliance, integrations and so on.

I&#x27;m surpised there is almost no mention of low-code and the excellent product that Microsoft killed off, in Visual Foxpro <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;previous-versions&#x2F;visualstudio&#x2F;foxpro&#x2F;mt490117(v=msdn.10)?redirectedfrom=MSDN" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;previous-versions&#x2F;visualstu...</a>

I would guess the RPA hype wagon will slow down on its own accord soon. The big users will start to see the downsides now that their implementations have been up a while. Scraping is brittle. And I imagine it&#x27;s not experienced developers writing (or point&#x2F;click generating) the scraping code at the customer locations.

Does SQL qualify as Low-Code? A lot of technical non-programmers are very successful using SQL.

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&#x27;t care for solution design or future planning?<p>Or will it be new employees hired with just this skill set?

I&#x27;ve tried to buy into this philosophy and ecosystem in my company (I&#x27;m the CTO). We have a lot of inneficient processes and I thought that by creating a few flows as an example and giving some training to business people they would become automators. I was wrong.<p>For starters, my company&#x27;s business people are not curious. This is not necessarily bad, but curiosity is a powerful accelerator for programming and automation tools. They weren&#x27;t impressed nor motivated to adopt and extend the example flows. In the end, I had programmers creating flows for business people to use, and it was frustrating for the programmers and an uncertain black box for the business people. We even managed to create custom connectors to simplify a few flows. It failed and we gave up.<p>Regarding the specific tools of the &quot;Power Platform&quot;, Power Automate has a horrible UI. It&#x27;s slow, clunky and buggy. Sometimes you try to save your flow and it will give you a weird error. Then you refresh the page, the flow remains exactly the same, but now saving works. It&#x27;s messy.<p>Power Apps has a bizarre billing&#x2F;licensing issue. The idea behind the product is appealing, but when you start using it, it&#x27;s a weird mix of a no-code design app with some legacy Microsoft Dynamics app. User management is confusing and tied to Dynamics. &quot;External&quot; users will cost you a lot more in licensing. You keep bouncing between old Dynamics pages and newer Power Apps ones. Even if you want to pay for the highest tier, it&#x27;s incredibly difficult to find out how to do it. And if you don&#x27;t pay for the highest tier upfront, Microsoft will create limitations for you on every corner (like accessing a database or using a given widget).<p>I didn&#x27;t have any motivation left to try Power BI, but one of my interns told me that a _viewer_ of my dashboards would also need a license to have access to it.<p>I won&#x27;t revisit these tools anytime soon.

Low Code is the modern version of &quot;Write Once run Anywhere&quot;<p>It is pipe dream that will cost companies millions in Vendor Lockin, rewrites, and all of the other problems that come with non-developers &quot;developing&quot;<p>See the nightmare that is Excel Workbooks, the fact they are modeling FX on Excel Function is a horror I do not even want to think about

If Microsoft were serious about &#x27;low code&#x27; we would be looking at Visual Basic 7.

I know somebody that spent a few days setting up a bunch of these things to handle contact forms on landing pages and that kind of sloggy boring projects. They work fine when they work, but things wig out with them often enough, or they decide that they haven&#x27;t been run in X days, and are going to be reclaimed, that it&#x27;s become a hassle that keeps somebody busy about half the time. Job security, if you introduce these low-code solutions, I suppose...

How much of the differentiation here is because Microsoft is innovating better versus simply their size and ability to use existing sales pipelines and bundling to push these types of features&#x2F;products? This article even includes a Teams versus Slack graph in it - I can&#x27;t help but feel sorry for smaller players who will see a gigantic incumbent unfairly eat their lunch without performing the hard work of innovation in the first place.

I really hope open source tools like: Budibase <a href="https:&#x2F;&#x2F;github.com&#x2F;Budibase&#x2F;budibase" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Budibase&#x2F;budibase</a> NocoDB <a href="https:&#x2F;&#x2F;github.com&#x2F;nocodb&#x2F;nocodb" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nocodb&#x2F;nocodb</a><p>Take off. Microsoft are chasing revenue and aim to lure you into their walled garden.

This is the kind of article that I believe would benefit from authorship identification&#x2F;stylometry. I would like to know how much of the conversation occurring in this comment section is real, and how much of it is part of the recently revealed work that Microsoft has being doing in swaying opinion on hacker news.<p>Wouldn&#x27;t that be an interesting tool for press releases like this?

I&#x27;ll admit, I&#x27;m being a hater. But how is this different from Sun Studio of yore, Adobe Flex Designer View or anything else?

Excel spreadsheets, and now low-code platforms, are how non-coders write functional specifications.

Microsoft has always had the best developer tools. This is an exciting step forward for low-code

I bet Microsoft&#x27;s &quot;Low Code&quot; turns out to be &quot;Slow Code&quot;.

The article looks like a paid ad in disguise.

How is this conceptually any different from InfoPath + SPD Workflows?<p>And if it&#x27;s not conceptually different, what&#x27;s going to make it work this time?<p>Aside - it&#x27;s probably been discussed ad nauseam, but the Teams vs. Slack graphic is highly misleading because of the way it&#x27;s bundled and distributed. It&#x27;d be like comparing the install base of Notepad vs. that of Notepad++.

It&#x27;s interesting that the article&#x27;s thesis is almost entirely about about PowerFX, but the 140 comments here so far don&#x27;t even mention it.

I searched the comments for some of the big-name RPA “solutions” I’ve had to work with before, and none of them show up at all (Blue Prism, mentioned in the article, was one of them). Not surprising, since ALL of their documentation on how to use the damn things or even how they work on a technical level is paywalled.<p>As someone who’s had to support them for an org’s clients in the past, that lack of access is extremely frustrating. How can I develop a library that lets clients access the web app through RPA if the vendors refuse to tell me how to make things accessible to them? Waste all around. Good riddance. Not that I’m any more confident about Microsoft’s offering here.

All said with a straight face and no mention of proffering a lollipop...