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.
> 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)
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.
Maybe I'm too cynical, but my experience with RPA via automation-anywhere is that the primary audience isn't IT or Engineering, but frustrated Line-of-Business middle management who are tired of waiting for IT to build them a solution and can't get budget-approval for a third-party to do it for them.
Couple that with woo like "self-healing", "insights", and "big data", etc along with dog whistles like "People will be scared you're automating them out of a job. You need to use discretion when implementing solutions".
I feel like the way RPA is sold to big corporations is analogous to how health-food stores sell muscle supplements to teenage boys.
You're not cynical, that is their strategy. It's why most IT organizations label RPA as "anti-pattern" and want nothing to do with it. It's sold in a way that explicitly calls into question ITs own utility, if not out-right calls it the problem! It's certainly not helpful. The only successful ROM (robotic operating model) implementations I have seen are ones that have the full-throated support and participation of IT.
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 order to implement in production (business process / ask, notsomuch technical).
This accomplishes a few positive things: (1) takes {insert dumb / hard / bad ROI business request off IT's priority plate}, (2) forces business to think about what they actually want, (3) forces business to document what they actually want, (4) provides business the flexibility to change their automation, when the realize they don't want what they thought they wanted, & (5) burns not-developer time learning all the intricacies and quirks of {legacy software / website / data}.
In the end, when IT comes back around knocking, their business counterparts actually have gasp documentation. And furthermore, documentation that's actually been battle tested and seen prod systems & data.
(It's an admittance that most IT projects fail not for lack of technical feasibility, but for incomplete or shifting specs)
>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.
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 without thought about future consequences of their decisions. They try to replicate the 800 steps they take to make something work instead of asking “more steps adds opportunity for failure; what is the minimum I need to do to reach goal”.
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?
> "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.
Sometimes the solution is also "Get IT to fix the thing that you're working around"
There was a delivered process to do a particular job, but it didn't work. Nobody thought to tell IT that it didn't work, instead they built a Ruby+Selenium script and ran it on a spare computer. Which worked great until it didn't.
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.
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.
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.
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.
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.
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).
Think a dedicated account in an old 3-tier architecture meant for a bot to login rather than a human. You're not making API calls though (at least not as we typically describe API calls), you're making HTTP requests to pull down a web page and then screen-scraping within the resulting HTML/JS.
Without a dedicated account your RPA bot needs to essentially impersonate a human or let the human login first and then drive the dashboard until the bot completes and the human can resume using their desktop seat. Very inconvenient for the human, and problematic for logging of who's really doing what.
Were it an internally owned application that's a legitimate course, but more often than not it's to grab data from third-party provider applications where DB is not an option, i.e. banking sites
ok, but normally banking has established protocols? If this is the main use-case of RPA-startups, Microsoft does not compete in any way. I don't see a lot of reasons (name one for me) for a legitimate business to pay an RPA-startup over the bank for automated data acquisition.
Another use-case could be the cloud probably – like scraping your salesforce apps. And this is just .... sad?
> 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".
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.
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 deal." Which is one reason it might be in MSFT's benefit to convince you that their thing is in the same class as some other thing you could spend money on, or may already be spending money on. And also, yeah, they are indeed convincing decision-makerse that they meet everyone's use-case and is whatever you want it to be, it's working....
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 a http response (including headers). It makes it super easy to setup APIs that have no security and expose corporate data.
I think the Power platform is like a modern Excel. Simple and inoffensive at first glance. But full of features that let unskilled users do risky things that will quickly become business critical. But the convergence of Office 365, SharePoint, Flow, PowerBI and dynamics is unstoppable.
> 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.
> 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 CI/CD tool for enterprise applications" also means that it can't just live in the shadows and will get seen by IT.
If anything, I've seen "citizen developers" turn away from Power BI/Power Apps precisely because their M365/Azure admins are too micro-managing to use the tools for what they were intended for and such people just go back to that Excel+VBA macros on a network share in a broom closet.
Which yes, gets back to Microsoft is trying too hard to meet everyone's use case and in forcing Power BI/Power Apps into M365/Azure they've trapped out some of the "I just need to get stuff done" "citizen devs" because some IT departments are so scared of shadows that they are preemptively blocking one of the tools they could use to keep an eye on it better. It's a lovely irony.
> 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.
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.
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.
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"?
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.
I wouldn't say API orchestration is the "new RPA", though. It's rather the "old BPM", and "current IPaaS". That is, we already have tools for API orchestration. It's nothing new. RPA is something different entirely.
And it's benefit isn't just for automating legacy systems. Automating the UI they're already familiar with is a much more intuitive experience for lots of people than going out of band to integrate with APIs.
That's the thing MSFT is trying to solve for with things like Power Automate and Apps.
Sure, getting an API schema and then writing a GET request in C#, Node, etc to get invoice data out of your financials system is out of band for a business user, selecting the action "Get invoice by number" from the "IBM Cloud Financials" connector in Power Automate is well within band.
That's easier than writing a GET request, but the easiest would be never leaving your native application, which AFAIU, RPA lets you do in theory (though practice is a different story).
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.
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.
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!
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).
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.
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.
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.
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.
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.
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...
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.
Usually significant low code stuff is more reflective of organizational politics than anything else.
Individual or small team productivity is one thing, the bigger low code monstrosities are usually a way for a vendor to weasel in and sell services under the IT peoples noses. The power automate bullshit cements whatever legacy junk it is feeding into and makes Azure the happy path for modernization.
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.
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.
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.
"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.
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.
Neither VB, VBA, VBScript nor VB.NET are "low-code" or "no-code", they all were rather code heavy... Some VBA 'apps' relied heavily on their hosted application object-model (Excel, Word, Visio, etc) - but there was still quite a bit of code that the average corporate Excel-wizard was never truly comfortable with.
In the Microsoft space, historically the true "no-code" solutions were Access Web Databases (no VBA allowed - of course they axed that whole service in 365, as they could not monetize it as well as SQL Azure), or web-capable Excel workbooks that rely exclusively on PowerPivot/functions (no VBA allowed), or web-enabled InfoPath Forms (also... no VBA allowed).
In their modern universe their equivalents are; PowerApps, PowerAutomate/Flow, LogicApps and PowerBI - just as the article states.
>>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...
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.
My counter, and anecdote, to this is the IT Dept recation is not so much a "slippery slope fallacy" but rather a reaction to past actual experiences
it is ironic that you bring up Access because that is one the tools I despise the most, our helpdesk is routinely indated with requests from people that pass around Access Databases with custom data links either to Excel files, or ODBC connections that are not standard but rather customized by the "power user" that created the database, then they share the database and it generates all kind of errors that the non-power user can not fix so IT gets roped into spending our time fixing not only users system to establish the needed data links, but also moving things around and reconstructing the databases so it actually works in way that is shareable
The IT Dept has also spent countless hours correcting Access Database connection issues, and schema issues when we move servers, upgrade platforms, or do anything on the prod system that end up breaking the Excel and Access "Low Code Applications" that consume data from these services because the end user lacks the technical ability to fix them often because they were created years ago by people that have left the company or retired.
Sure it's work. But is it really more work than developing an entire new system from scratch? Because that is incredibly labor intensive, if not one of the most expensive endeavors in IT you can undertake imho. It's easy to think IT will create the perfect system that has no support issues but TBH there will probably be just as many.
So you'd ban MS Access? Why do people use it as opposed to an "IT Sanctioned" tool? If you IT dept does not have time to provide the tools people need to do their jobs, and you take away one of their tools, what/who fills the productivity gap?
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.
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.
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.
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.
I apologize if my comment upset you or was offensive to you in any way. I only meant to notice that your comment paints a picture of all such projects being awful, and this may not be a faithful representation of reality.
If you didn't mean to paint such a picture, I'm sorry for misunderstanding.
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.
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 difficult to reinsure policies in the capital markets.
edit : * and package, according to a tremendous variety of fiscal requirements and risk appetites. And naturally covering the most extreme conditions liability payments is historically a fascinating insight into how we developed our world across and binding together such tenuous links.
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).
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.
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.
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.
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.
The thing is, until very recently, Bot Framework was the only game in town for Teams.
Doing something as simple as sending an outbound message to a user from a bot, if the user didn't initiate the conversation, was stupidly convoluted.
There's some stuff added to Graph API for sending messages now, but on the whole, the development experience is very, very far from what I would expect from Microsoft.
There's still no good way to sign in on behalf of a user to Teams, which makes writing load-testing tools to test a Teams bot a PITA - you can use Direct-Line, but then it isn't really testing how the bot would act against Teams...
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.
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"?
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.
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.
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.)
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.
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.
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.
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?
This is a late reply, and I think I misunderstood your meaning.
I don’t have good answers on how to drop layers from the stack, they all seem pretty necessary. Storage is obvious, backend is needed for authentication if nothing else and powers the API layer. Front end could be replaced by APIs, and often is in products, but someone ultimately has to write a view for humans if humans will use the system.
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.
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.
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.
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.
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?
How do you get notifications from all tenants at the same time? How do you even check the other tenants when you are in a Teams meeting? I mean, the client disconnects from the meeting if you try to view other tenants. How can you see which channels across five tenants have new messages?
If you are a small company and use Teams internally. Fine, but it simply does not work in an enterprise environments.
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.
"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.
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.
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.
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.
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.
On the flip side, some of those spreadsheets that reach the "would be easier to manage with a proper codebase" status never would have gotten off the ground had they started as a development project.
It really is full-circle with excel. You can start there, then wind up using it again once you realize its still an excellent data interchange mechanism.
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.
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.
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:
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?
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.
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
> 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.
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.
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 general rule, if these are such important projects, the business should expand its development org and improve internal processes to better react to business needs.
But it seems like an almost universal problem (especially outside of tech) that this just does not happen. There is often very limited appetite to take on the risk of a big dev project without understanding its value. You could argue that building a business case is a better way to prove that value, but on the other hand, if you can build a business case by literally implementing a solution, and bring data to leadership that clearly says "this is worthy of investment, and here's a v1 already working to prove our point", this appeals to the risk averse management types since it proves the need.
I don't think this is a great mode of operation, but I think it helps explain why we see such investment and growth in these tools.
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.
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.
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.
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.
Having done more than my share of coding in VB3-6, I can tell you that VB in any incarnation has never been "low code". If you think that WinForms or XAML in Visual Studio is any less RAD or somehow "more code" than the VB<=6 IDE, you are wearing some amazing nostalgia goggles and I wish I could believe in a world you seem to think existed.
No, that's what "RAD" means. "Low Code" means systems like Excel where "formulas" aren't exactly seen as "code" and nearly everything can be wired up visually. Power Apps and Power BI are "Low Code". Access and Excel are "Low Code". VB was never "Low Code", it was "RAD".
(And yes, today's WinForms and XAML editors in Visual Studio are quite "RAD", and exactly as "RAD" as VB <= 6 was, if not more so. VB.NET was never less "RAD" than VB <= 6 from the standpoint of visual tools. It just shifted component/plugin ecosystems and left an impression that it was less "rapid" to develop with because of sharp new learning curve, but the "rapid" never meant "no learning curves", it meant WYSIWYG designers, which VB.NET still had in spades.)
None of these terms have widely accepted precise definitions, but there are plenty of platforms considered "low-code" that still require quite a bit of traditional programming. Outsystems, for example.
Those that only offer formulas with no escape route to traditional programming, as you describe, are more commonly considered "no-code".
This distinction from wikipedia is pretty accurate:
"No-code platforms are accessible to any end-business user while low-code platforms require professional developers who can work within the platform's constraints."
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...
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.
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?
"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..."
Thanks! Hard to read much into that call other than Microsoft folks 1) Read Hacker News and 2) Are targeting it as an audience for which they would like to be more popular in.
You had made it sound like some sort of coordinated astroturfing operation.
"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..."
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
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...
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++.
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.
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?
PowerFX is MS's name for the standard code format. I believe their ultimate goal is that:
- business users build apps using a graphical low-code interface,
- these then convert to PowerFX source code that goes into the enterprise's source control system.
- The enterprise IT team tests the code, re-writes key components and deploys.
- And these changes are then reflected back into the low-code app development environment.
This allows business users to contribute domain expertise and IT to maintain their quality and governance role.
Needless to say, this is non-trivial from a tech perspective but, in my view, is a better approach than an enterprise having a separate deployment and governance framework for low-code/RPA apps than for their other custom applications developed in Java/C++ etc.
Where are you seeing that it's a standard code format? I've skimmed this: https://powerapps.microsoft.com/en-us/blog/what-is-microsoft... and it seems that it's just a simple expression language, not a standard format that an entire PowerApps app would compile down to.
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.
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.