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

https://www.infoq.com/articles/cloud-vendors-low-code/

by tlochhead • 5 years ago

215 193 5 years ago

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

radicalbyte• 5 years ago

Sharepoint 2.0

_pmf_2• 5 years ago

Also: Lotus Notes

bob10294• 5 years ago

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 smaller needs that can be addressed with these sorts of tools, but the big tasks of integrating multiple unique/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.

CharlesW• 5 years ago

Do you consider Excel a low-code solution?

bob10294• 5 years ago

That depends on how you use excel. Lots of formulas, et. al. would probably become easier to manage as part of a proper codebase at some point.

MangoCoffee• 5 years ago

We have a Microsoft "Access app" build by a ex employee. it was used by a lot of people and now in process to be rewritten into a web app. i guess that's a success story(?).

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

i'm fine with that. when they hit a problem that no Microsoft "connector" can solve. you charge them 10x to implement a real solution.

tyingq2• 5 years ago

"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 non-tech folks that the IT department never knows about.

Graffur3• 5 years ago

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.

mywittyname• 5 years ago

This stuff is really prevalent. I'm a programmer and I'll happily build out some low-code solution in Google Sheets or whatever.

Since it takes out of the equation a whole host of potential workloads (deployment, environment maintenance, source code control, etc), these low-code solutions offer rapid deployment of prototypes. Often times, these little prototypes end up being used by 100s of people within a company.

I love it because I bill out like $x0k for a few days of work. Once it's done, I pretty much never have to support it, since Google is managing that for me.

Clients love it because development is done in a few days and they never seem to have to contact anyone for support. The successful ones always lead to more business. Especially with megacorps with lots of brands. Brand X will show off their new dashboard, and Brand Y wants their own version and will happily pay pretty close to the original price for basically a copy-pasta job.

myohmy2• 5 years ago

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.

dnndev2• 5 years ago

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.

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.

At this point a low code solution makes no sense for me as a dev - believe me I have tried them.

Kudos to MS.

MattGaiser• 5 years ago

I think low code works for smaller more routine projects where hiring devs is just not all that feasible.

asdfman1233• 5 years ago

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 job, and even if you do tackle them, IT is probably not going to give you direct database access.

I had a friend like this, who was bored as shit as an accountant. I convinced him to migrate his career to software and now he's in a data science master's program.

syshum4• 5 years ago

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

Or more likely they leave the company, it breaks and no one knows how it worked, how it was suppose to work, or anything about it so they need to call in someone either from Internal IT, or and outside consultant to figure out what broke, and how to fix it...

brixon3• 5 years ago

No difference than Excel Macro apps today. When Excel Macro wiz kid leaves the department or the company and it either breaks or needs new features then it goes to IT and they don't work on Excel so they will push to rewrite it into a web app.

The plus is that the use case and value for the program is already proven, so IT is not wasting time creating things people will not use.

F_J_H2• 5 years ago

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 reason than the "slippery slope fallacy" that "if we allow this, we could potentially have a big mess to sort out one day". And in doing so, summarily kill a ton of innovation and productivity.

One anecdote I remember - a regulatory change created a major issue for a billing department. They went to IT to get their help to address it, and were told "sorry, no time to even talk to you right now. Come back in six months. Actually, make that 8 months." So, a tech. savvy person in the billing dept. built something in MS Access that solved the problem. They were thrilled. When IT heard about it, they tried to get the guy fired. Billing Dept. manager had to go to bat to make sure that didn't happen.

asdfman1233• 5 years ago

Yeah, this is pretty much the use case for low-code solutions like Access. Being a developer is an exception, rather than the rule, and there are a lot of smart BAs out there who know software could improve their lives.

I feel like if AI gets really good, low-code is the future. In the future we won't eliminate software engineering but it will become increasingly less technical until software devs and BAs merge as one profession.

But that's decades off if it comes at all.

stuaxo• 5 years ago

I'm sure a lot of projects would never make it to developers if somebody out in the field wasn't trying to solve a problem like this in the first place.

LeifCarrotson• 5 years ago

Yes, no-code solutions almost always become ugly, buggy, monstrosities, and there are technical limits that mean it needs wholesale replacement, but pragmatically I too have seen them getting jobs done. I'd also wager it will not cost more to rewrite it, especially if you deeply discount the non-developer resources that were used to create it (often salaried employees' time, and even then those individuals likely came out ahead compared to the tedium of doing it manually). Consider it a prototype. Also, the functional spec of "do exactly what the domain expert made this convoluted Excel spreadsheet do for the last 2 years, but with better validation of inputs" is often far more accurate than some daydreamed RFQ.

The part that confuses me is why this makes sense as a separate enterprise product. Had the original author been interested in learning a new tool, they'd have probably been better off starting with Python. I recognize that non-developers are silently building their own tools, some of which will be a hit and later need replacement by developers, but are there really sales teams going around to big enterprises suggesting that they buy licenses for all their employees to be able to build their own tools using their particular low-code solution that will eventually be replaced? Seems like a difficult thing to sell IMO...

nightski2• 5 years ago

Not everything is a large ugly, buggy monstrosity that needs to be rewritten into "real software". There are may business processes served quite well by excel which might be enhanced with a low code solution like this and could stay that way for over a decade.

tolstoshev• 5 years ago

On the flip side, there's plenty of ugly, buggy, code monstrosities that have to be rewritten or refactored. This just means the professional developer gets to start with a clean codebase with the UI & processes already laid out as an example. Almost like the no-code is a working prototype in place of a requirements doc.

bigger_cheese• 5 years ago

In the last 6 Months my workplace has started heavily using Power Apps. The first impression I got was 'holy crap, this is MS Access on steroids'. My workplace heavily(ab)used Access in the 90's and we got bitten very badly when support for Access was discontinued. We also had a lot of VB6 code which was similarly orphaned.

In the mid 2000's someone in our IT department decided all new business apps were to be written in Java I believe this decision was made partially as a reaction to what happened with Access and VB6. The result was everything stagnated our in house apps became massively bloated, buggy and almost no one did anything 'to fix things. Any changes had to go through external contractors because no one knew Java or how to support these apps. If they had mandated Python like the post I'm replying to suggested I am sure the results would have been the same. Probably worse because harder to find cheap contractors to work on business apps in Python.

You are not going to get HR people, you are not going to get Finance Accountants, you are not going to get commercial team or legal to learn a full on programming language. That is why these products have such a niche in large Enterprise orgs.

Yes you get buggy monstrosities but you can also very rapidly develop working tools that solve real business problems.

I think what makes Power Apps attractive is the whole Azure ecosystem Microsoft have built around it. There is a whole suite of tools that all talk to the same common backends, Power Automate, Azure Databricks, Azure ML, Power BI, Power Apps etc. From what I've experienced as all of this stuff has been rapidly rolled out across my org is it all "just works" and seemingly solves real problems.

My real fear is that 5 years down the line it will have all be abandoned and we'll be left with MS Access 2.0 and a bunched of orphaned unsupported apps again. I hope Microsoft have learned from what happened with Access but at the moment it remains to be seen.

golergka3• 5 years ago

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.

dnndev2• 5 years ago

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.

jlarocco• 5 years ago

"Low Code" is a new (to me) buzzword, but Microsoft has targeted that niche for a long time. Specifically I'm thinking of the older Visual Basics (3-6) and the advanced scripting and database features in Office.

pjmlp2• 5 years ago

I have seen first hand on some lifescience consulting gigs how VB.NET takes away people from R, Python and similar tools.

It is the Excel experts that have outgrown the macros and VBA capabilities, and get IT to install Visual Studio with VB.NET on their computers.

They then double down on their VBA skills and somehow get to produce something in Windows Forms, or an Excel AddIn for the task at hand and then get going with the actual work.

Then one lands on the lab and it is full of such small utilities.

codingdave• 5 years ago

I've been working in and supporting low-code environments off and on since the 90s (Lotus Notes -> Sharepoint -> Salesforce, if it matters) I've been the guy who does those re-writes when needed. I can confirm that the biggest and worst of them need re-writes, but most just need a little cleanup. Most are like you said, a non-programmer does something unwise. I spent much of my time giving people a "Dev 101" course to help them do it better, and they'd build heaps of apps that never needed re-writes.

Even when they did need taken over by IT because they scaled to a level of being business-critical, they rarely needed a full re-write, they most often just needed enhanced. Adding in validation, data integrity, backups, UX, testing, and simply streamlining the app with features that needed "real" code. And once a decade we'd re-platform them all as the underlying platforms become outdated and were eclipsed by something new.

It was amazing how well the non-programmers could do if given a weekly opportunity to just come in and show their work, ask questions, and get advice. Some of the people I coached even went on to learn how to code and have become successful software engineers in their own right.

If you ever end up supporting such environments again, I'd recommend considering yourself a mentor to new developers more so than someone who is going to clean up someone else's mess. People might surprise you with how much they are capable of.

leejoramo• 5 years ago

100% agree with you.

I really enjoy supporting people who have already built their own tool, but need a programmer to take it to another level. Such projects tend to be well scoped, and the project owners are heavily invested in and understand their actual needs.

In 20+ years of professional programming, projects that started with the end user solving their own problems have nearly a 100% success rate.

omk• 5 years ago

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.

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.

akudha• 5 years ago

I think it will work, especially if Microsoft can also build self hosted version of some of these tools. There is a huge market for such tools (look at how much attention self hosted Airtable alternatives are getting). Between self/cloud hosted versions, their sales machine and deep integrations, Microsoft has a huge advantage over Google and Amazon.

WorldMaker7• 5 years ago

At BUILD this year Microsoft announced Azure Arc which runs on any Kubernetes cluster (including ones you spin up on AWS, GCP, or a laptop on a desk somewhere) and supports running a surprising number of Azure services already (Azure App Services, Azure Functions, Azure Logic Apps, and supposedly growing). Administration can happen in the regular Azure Portal and it just looks like you are deploying to a custom datacenter region in the Portal.

It's really slick. It's also pretty obvious that many of the services they've focused on at first are some of the underlying foundations of their Low Code efforts, so I would be surprised if Power Apps and Power BI also eventually wind up on that list of Azure Arc supported.

Azure Arc seems like a really interesting "compromise" on "self-hosted" (depending of course, on which reasons you have to need "self-hosting").

(Azure also has Azure Stack which is the entirely self-hosted datacenter version too. I don't think that yet supports these Low Code tools yet either, but it's probably even closer to having the foundations for that in place.)

jerf• 5 years ago

I don't know if they're pursuing this, but Microsoft also has the opportunity to create low-code solutions that more gracefully transition into conventional solutions, because unlike a pure-low-code play, that doesn't have to mean they are losing a customer. They aren't incentivized to lock you in to low code as long as one way or another you pay Microsoft on the way out, too, via either being in the conventional Microsoft developer ecosystem or being on Azure.

Given that they seems to be acquiring they way into this market, I'm sure it's nowhere near this integrated yet, but could you imagine being able to take any individual component of the system, or the system as a whole, and getting a "Click Here to create a Visual Studio Project" that completely replicates the low-code solution into Visual Studio, ready and waiting for you to start modifying it? Probably with some sort of automatic "Click Here to Deploy Your Changes Into Azure"?

WorldMaker7• 5 years ago

That's very much Microsoft's goal here. It's a lot of why they started pushing everyone to stop calling it "No Code" and moved to the name "Low Code".

At BUILD they released some of the first big VS Code plugins for some of the Low Code systems. (Power Apps is represented mostly as a lot of YAML files, if you were curious.) Most of the Low Code systems already use Azure CI/CD and git under the hood and editing Low Code projects in VS Code and VS seems easy enough for "conventional" developers.

ajcp21• 5 years ago

Couldn't agree more. By providing tools that allow you to "reach in" to every part of their ecosystem, from their OS to their productivity suites to their cloud offerings, they're creating a very comfy lock-in that would be hard to justify your way out of.

syshum4• 5 years ago

Low Code is the modern version of "Write Once run Anywhere"

It is pipe dream that will cost companies millions in Vendor Lockin, rewrites, and all of the other problems that come with non-developers "developing"

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

shadowgovt• 5 years ago

The relevant question, I think, is extensibility. If the low-code solution, upon hitting a wall, can be extended instead of rewritten, it's going to be a great solution for small companies to prove out ideas without the cost of general-purpose developers and custom software stacks built from general-purpose software.

If any company can solve the extensibility question, I think Microsoft has a better-than-average shot at it.

haswell4• 5 years ago

will cost companies millions in Vendor Lockin, rewrites, and all of the other problems that come with non-developers "developing"

What many folks miss here is that companies still willingly proceed despite these drawbacks because of the value that the end result provides.

These tradeoffs are often less apparent when coming from a software development background or working for a company that builds software. But if you're in a different type of org - say financial services - these solutions are often the difference between launching a new product/capability, or putting structure around a paper process...or accomplishing absolutely nothing because development is currently tied up for the next two years.

Not all companies have IT/Dev orgs that are capable of meeting the demands of the business. Some orgs are transforming their businesses (the "digital transformation" buzzword), and don't have a dev team at all. At best, they have some centralized IT department that is capable of rolling out point solutions.

You might be right that these solutions are inherently inferior from a technical perspective, but if you look at this from a business outcome perspective, those tradeoffs are often worthwhile.

syshum4• 5 years ago

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

There should be some kind of middle ground, likely starting with proper, actual training and restricting access to low code solution to people that have at least some technical literacy which often does not happen.

rchaud• 5 years ago

My university's application system is a set of workflows based on drag and drop Salesforce components. It processes tens of thousands of multi-step, multi-page applications without any issue.

ayewo• 5 years ago

My university's application system …

Application system? Perhaps you meant admission system?

Is there publicly available info where one can read more about it?

aparsons2• 5 years ago

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

ajcp21• 5 years ago

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

aparsons2• 5 years ago

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

tyingq2• 5 years ago

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's not experienced developers writing (or point/click generating) the scraping code at the customer locations.

jeff-davis• 5 years ago

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

golergka3• 5 years ago

Using SQL to get reports and analyse existing data, or to actually create schemas, change data, maintain transactions over related changes and so on?

bob10294• 5 years ago

We started leveraging SQL very heavily in our application so that business people can customize app behavior without bothering developers. We are getting close to 100% config-only coverage using SQL.

We tried rolling our own scripting language and other ideas, but we decided that we weren't ever going to catch up with the level of testing & validation that SQLite has achieved with any amount of in-house resources.

Once we embraced SQLite, we found an entire universe of capability. Here is one of the comments I made just yesterday about this kind of thing:

  https://news.ycombinator.com/item?id=27362708

brixon3• 5 years ago

Yes since it is describing more what you want and less how to do it, but SQL is not an end-to-end solution.

pjmlp2• 5 years ago

Pure SQL no, but when coupled together with language extensions and frontends like APEX, it surely is.

I have seen departments fully managed with APEX applications.

ajcp21• 5 years ago

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 don'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/products of another enterprise application.

Microsoft's Low-Code "strategy" is providing tools for business process applications, they'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 "Low-Code/No Code" tools for building *applications* but rather for API integration and orchestration. This is the "new" RPA.

Why would one need to build an RPA "bot" 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?

Source: I've worked in the RPA space for over 5 years now as a SWE, Tech Lead, and Architect.

quyleanh• 5 years ago

The original article is brilliant but your correction is much more valuable. Thank you.

ajcp21• 5 years ago

Thank you and it's my pleasure!

ethbr08• 5 years ago

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 tech stack does your RPA engine cover?

Microsoft Active Accessibility? Excel? Excel + VBScript? Legacy Windows native? VB6? Early Java with custom UI grid classes?

The point the author should be making is that Microsoft, Google, and Amazon have zero interest in eating UiPath's lunch. It's expensive (in people-time-dollars) and custom per customer. And ultimately, it's a long-tail game.

Microsoft's play is to trivially link together new deployments or migrations (i.e. to O365), then continue adding customers as more migrate to them.

Why pay to chase the customer, when they're already running towards you?

(FWIW, I think UiPath realizes this, which is why most of their new products / features are pivoting to become an Appian-esque rapid app platform. AA and BP? Less clueful)

ajcp21• 5 years ago

100% agree. The real value of these RPA solutions is their orchestration capabilities, but that's not how they sell it. They will start bleeding customers as those systems they're automating are replaced with those that provide more surfaces to interact with (like API).

The real utility RPA solutions are supposed to provide to the enterprise is cost savings. These savings should then be put toward upgrading those legacy systems that required the RPA solution.

I have never seen a company disciplined enough to direct those savings in that way. RPA companies have been so caught up in being a "hot item" and classified as a sub-category of AI (for whatever reason) that they don't seem to realize they've been selling their own demise.

mgummelt16• 5 years ago

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.

jrochkind12• 5 years ago

but I think MSFT also gets their own messaging wrong.

Or, is it possible MSFT knows that when selling to "enterprise", it works a lot better to say you've got a better version of "thing they know", instead of a brand new thing that will replace "thing they know".

ajcp21• 5 years ago

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 obsessed with? Making sure the business isn't creating shadow IT and developing enterprise applications.

haswell4• 5 years ago

These are some excellent points. I think the big takeaway here is that RPA isn't what it used to be, and the rapid changes in this space help explain why RPA is gaining traction (seemingly inexplicably, if one still assumes that RPA = screen scraping mainframes).

RPA products are increasingly becoming integration products. For example, and vendors like UiPath increasingly provide native API integration capabilities where possible. I've even seen integration products that formerly would have fit into the "iPaaS" space market themselves as RPA solutions, even though they are primarily providing what is essentially an API abstraction layer, and they have no roots in "true" RPA.

I think this is happening due to the hype around RPA, and how effective the terminology is with the target audience.

I agree that "traditional" RPA is already a legacy solution, but at the same time, RPA vendors are rapidly pivoting to support API integrations (see UiPath's recent acquisition of Cloud Elements).

I hate the muddiness, but I've also had to take a step back and re-orient how I think/talk about RPA products due to how quickly the space has evolved.

Source: Also work in the RPA and Integration Platform space, primarily on the Product Management side.

ajcp21• 5 years ago

I think you're right and I may be a little too hard on the RPA vendors here. I wouldn't put it past UIPath or one of the smaller vendors being able to expand what they consider "RPA" into competing directly with what would be API orchestration with the likes of MuleSoft, Appian, Power Automate, etc.

enraged_camel• 5 years ago

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.

ajcp21• 5 years ago

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

filoeleven5• 5 years ago

RPA is a financial services buzzword right now. I’ve worked on an RPA library that manipulates a web application…which the company already provided full API access to.

The RPA library requires those working with it to examine the page HTML in order to hook into it, since it’s highly dynamic: you have to see what form fields are available and their internal IDs in order to interact with them. Meanwhile, the API layer gives access to all the same CRUD, and maybe with better documentation (I have not seen it).

If you don’t have a human user, just use the APIs! That’s what they are there for!

monkeydust• 5 years ago

Nicely put.

I have always felt RPA was the ' poor mans' option for automation.

ajcp21• 5 years ago

Thank you!

Yes, as a SWE when you actually see how these RPA solutions run they are not impressive. Heck, before they moved to the cloud most of them were simply providing a wrapper for Windows interop assemblies (COM, Office, what-have-you) and its native Task Scheduler capability.

As a piece of technology their real value proposition is the deployment, orchestration, & management of the automations. Even four years ago they should have included VMs/VM environments in that package, so that you're not just managing a "bot", but the whole kit-and-caboodle. This would have made their offering absolutely unique and more comprehensive.

tootie• 5 years ago

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

ajcp21• 5 years ago

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

mgummelt16• 5 years ago

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.

Havoc• 5 years ago

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

m1sta_2• 5 years ago

Same diff.

brushfoot2• 5 years ago

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 convoluted and poorly supported, and distributing your client in their ecosystem is so complex, that I've thrown up my hands and gone, "Forget it, I'll implement this with a service account." An RPA process logs into the front end, clicks around, scrapes some data, outputs it to the next process in my pipeline, and it's done. I've written processes like this that have been running for years with basically no maintenance due to stable-enough UIs. UI changes are still a risk, but if you have a mature UI, it's a great, simple alternative to a more complex process.

Regarding (2), APIs don't always expose all the features of the UI, and sometimes vendors won't, or can't, add them in a given budget or time frame. I worked with a partner whose API had essentially one read-only endpoint. Their product was fantastic and they had other integration methods; they just hadn't prioritized API development, which they could afford to do because they delivered so well in their niche otherwise. We had to get creative in how we would pull the data.

Graffur3• 5 years ago

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

fock2• 5 years ago

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

mgummelt16• 5 years ago

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

meldyr• 5 years ago

And (3) external parties.

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

mgummelt16• 5 years ago

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

ajcp21• 5 years ago

I'm sorry, yes, re-reading it I do conflate some terms.

Enterprise applications are those that are built for, enable, and underpin enterprise sized concerns.

So for your financial department you want and enterprise application that owns, orchestrates, and audits the work of finance.

However most if not all business processes cannot exist solely within an enterprise application, so you want to give them "tools for application to the business process". That's probably more high-handed than it needs to be, but eh :D

So in this what I'm arguing is that MSFT here isn't trying to position Power Apps/Automate as a tool for developing enterprise applications, but rather high-grade capabilities (I'm remiss to say "enterprise grade" as people will then conflate that too) that allow the business to tie all ends of their business process together. The best way to do this is by giving everything outside of the enterprise application knowledge and reach to each other via API.

To your point, yes, this could require the business to build applications for their own processes, but these aren't enterprise applications, simply process specific applications.

Traditionally these were macro enabled Excel workbooks and Access apps that were squirrelled away deep in so many Network Drives, underpinning vital business process functions but wholly unknowable to leadership or those maintaining the enterprise application itself.

bitcuration• 5 years ago

The promise of universal API is overrated. It has some truth thatthe RPA brings the best bang for buck for mainframe etc., but in local on premise ecosystem the application API especially cross vendor is a hit and miss. The real promise is in the cloud where API becomes a mandate.

ajcp21• 5 years ago

That's what Microsoft is forcing here: there is no more "on prem only", even with Windows.

m12k• 5 years ago

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

Long story short, MS is a master at making you appreciate the difference between "technically possible to achieve" and "easy and realistic to achieve". 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 "normal" people.

ajcp21• 5 years ago

I can see that. I think you're best bet is to throw that BotFramework out. I'm not sure why they keep it around, but they've all but replaced it with Power Virtual Agents.

thrower1233• 5 years ago

Bot Framework is horrible. It's the most ridiculous IM platform I've built anything for, and I've covered a good bit of the spectrum.

They really need to expose a full-featured API for Teams, something at least as powerful as what you used to be able to do with the UCMA SDK for Lync/SfB.

I've given up on anything ever getting exposed through Graph API in a timely manner. It took two or three years before you could get online/busy/away presence information on a user without outrageous, unsupported hacks.

WorldMaker7• 5 years ago

Bot Framework was a good idea: one framework to write a bot for multiple IM platforms at once. But of course it immediately suffered the exact problems you would expect: lowest common denominator features, older target platforms falling into disrepair, new platforms never getting official support, etc.

Using Bot Framework to write just for a Teams bot is broken before you start. Using it to support both your Teams and Slack integrations sounds nice on paper, but probably doesn't work in theory as soon as you need platform specific features or do something "advanced". You still can't use Bot Framework with Discord.

I liked the theory behind Bot Framework, but the practical reality has so far been mostly a disappointment.

slumdev• 5 years ago

How is this conceptually any different from InfoPath + SPD Workflows?

And if it's not conceptually different, what's going to make it work this time?

Aside - it's probably been discussed ad nauseam, but the Teams vs. Slack graphic is highly misleading because of the way it's bundled and distributed. It'd be like comparing the install base of Notepad vs. that of Notepad++.

brixon3• 5 years ago

InfoPath is end of life and PowerApps is their replacement.

dboreham• 5 years ago

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

DonHopkins• 5 years ago

I bet Microsoft's "Low Code" turns out to be "Slow Code".

beckingz• 5 years ago

This is my experience. PowerBI especially is painfully slow even with tiny data.

_pmf_2• 5 years ago

Since the competition is Electron and JS, the bar is somewhere in the stratosphere.

throwawaysea• 5 years ago

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/products? This article even includes a Teams versus Slack graph in it - I can'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.

Tarucho• 5 years ago

The article looks like a paid ad in disguise.

fartcannon4• 5 years ago

It probably is. I already posted a link to it in another comment, but to reiterate, Microsoft's CEO admitted to 'working on' hacker news specifically to sway opinions on Azure. Not much of a stretch to assume they do that for other projects, too.

To quote, "In fact, this morning, I was reading a news article in Hacker News, which is a community where we have been working hard to make sure that Azure is growing in popularity and I was pleasantly surprised to see that we have made a lot of progress..." https://sg.finance.yahoo.com/news/microsoft-corp-msft-q1-201...

ARandomerDude• 5 years ago

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

_jal• 5 years ago

Seems like Microsoft feels threatened about once a decade and feels the need to demonstrate how comprehensively it can stomp on someone lacking a similar portfolio.

AtNightWeCode4• 5 years ago

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

AtNightWeCode4• 5 years ago

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.

bsg75• 5 years ago

I'm using Teams in a 10,000 person company with employees and external collaborators. Its our primary chat tool, and its used regularly for presentation broadcasts of over 250 people. Is this Enterprise enough?

paxys• 5 years ago

That graph really shows the (mostly automatic, forced) conversions from existing Lync/Skype for Business users rather than brand new Teams ones. Not exactly fair to compare it to Slack without including the existing user counts as well.

Spooky232• 5 years ago

Slack had to sell their new way of work. Microsoft just had to start turning off the components you already had.

A more real way to portray that market would be to show the 20 years of them fucking around with LCS/OCS/Skype for Business.

Even then, most teams deployments I’ve seen are Webex, iMessage and work cellphone displacements. The adoption of what people do with Slack isn’t there.

tacticalDonut• 5 years ago

I don't use Teams because I like it, I use it because I have to at my company...

geonic2• 5 years ago

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.

ffhhj3• 5 years ago

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

AtNightWeCode4• 5 years ago

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.

You also still need to solve the things like CI/CD, CM, dependencies, data modelling, correctness, resilience, security, compliance, integrations and so on.

jimnotgym• 5 years ago

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

ffhhj3• 5 years ago

It would be just another flavour of C#

WorldMaker7• 5 years ago

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.

mgummelt16• 5 years ago

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

fartcannon4• 5 years ago

This is the kind of article that I believe would benefit from authorship identification/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.

Wouldn't that be an interesting tool for press releases like this?

pkilgore2• 5 years ago

recently revealed work that Microsoft has being doing in swaying opinion on hacker news

I'd love a link. Unfortunately "microsoft and hacker<anything>" get's swallowed up in search results by recent attack news.

fartcannon4• 5 years ago

https://sg.finance.yahoo.com/news/microsoft-corp-msft-q1-201...

"In fact, this morning, I was reading a news article in Hacker News, which is a community where we have been working hard to make sure that Azure is growing in popularity and I was pleasantly surprised to see that we have made a lot of progress..."

iudqnolq• 5 years ago

it is part of the recently revealed work that Microsoft has being doing in swaying opinion on hacker news.

I'm deeply sceptical this is real because the risk would be high and the reward miniscule. Source?

fartcannon4• 5 years ago

https://sg.finance.yahoo.com/news/microsoft-corp-msft-q1-201...

thrower1233• 5 years ago

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't been run in X days, and are going to be reclaimed, that it's become a hassle that keeps somebody busy about half the time. Job security, if you introduce these low-code solutions, I suppose...

OrvalWintermute• 5 years ago

I'm surpised there is almost no mention of low-code and the excellent product that Microsoft killed off, in Visual Foxpro https://docs.microsoft.com/en-us/previous-versions/visualstu...

simonbarker87• 5 years ago

My last role had A LOT of VFP in the estate and it was still added to on a regular basis and all the main VFP devs kind of loved it.

trixie_2• 5 years ago

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.

ajcp21• 5 years ago

Perhaps, but our StickOps team is actually engaged since we moved to Sticks as a Service and implemented our MicroRubbing architecture!

filoeleven5• 5 years ago

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.

trixie_2• 5 years ago

Not sure what this has to do with the immense amount of code that needs to be written across various layers in a stack to do the simplest task. Can you translate this into some real and actionable?

spoonjim• 5 years ago

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

filoeleven5• 5 years ago

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.

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.

Graffur3• 5 years ago

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?

myohmy2• 5 years ago

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.

haolez2• 5 years ago

I've tried to buy into this philosophy and ecosystem in my company (I'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.

For starters, my company's business people are not curious. This is not necessarily bad, but curiosity is a powerful accelerator for programming and automation tools. They weren'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.

Regarding the specific tools of the "Power Platform", Power Automate has a horrible UI. It'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's messy.

Power Apps has a bizarre billing/licensing issue. The idea behind the product is appealing, but when you start using it, it's a weird mix of a no-code design app with some legacy Microsoft Dynamics app. User management is confusing and tied to Dynamics. "External" 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's incredibly difficult to find out how to do it. And if you don'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).

I didn'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.

I won't revisit these tools anytime soon.

mgummelt16• 5 years ago

Were you creating flows in Power Automate or something else?

haolez2• 5 years ago

Power Automate. We tried Zapier as well and it's much better, but the business people were already burned out when we tried it.

mgummelt16• 5 years ago

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

hudgeon3• 5 years ago

Thanks. As the article's author (and first time writing something that hits HN) it's been interesting seeing which parts of the article have struck a nerve and which parts have gone through to the keeper.

mgummelt16• 5 years ago

While I have you here, I have to say I still don't understand the connection you're making between PowerFX and compatibility with existing deployment systems. I understand that a low-code platform that spits out an app in some sort of standard format, like source code or a docker image, would facilitate that integration, but where does PowerFX come in?

foxbee• 5 years ago

I really hope open source tools like: Budibase https://github.com/Budibase/budibase NocoDB https://github.com/nocodb/nocodb

Take off. Microsoft are chasing revenue and aim to lure you into their walled garden.

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

Related Stories