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)
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.
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.
An example is a SME which wants to download the billing information of 100 employee from ATNT’s customer port
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.
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.
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"?
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.
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!
I have always felt RPA was the ' poor mans' option for automation.
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.
Not sure about legacy. Modern glorified ducktape to make legacy stuff play nice is more like it imo
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.
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.
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.
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...
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.
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.
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.
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...
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.
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.
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.
https://res.infoq.com/articles/cloud-vendors-low-code/en/res...
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.
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.
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.
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.
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.
>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.
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.
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"?
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.
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.)
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
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.
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.
If any company can solve the extensibility question, I think Microsoft has a better-than-average shot at it.
Application system? Perhaps you meant admission system?
Is there publicly available info where one can read more about it?
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=27362708Wouldn't that be an interesting tool for press releases like this?
I'd love a link. Unfortunately "microsoft and hacker<anything>" get's swallowed up in search results by recent attack news.
"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..."
I'm deeply sceptical this is real because the risk would be high and the reward miniscule. Source?
"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..."
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.
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.
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.
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.
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.
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.
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?
Or will it be new employees hired with just this skill set?
Management doesn't give a fuck either, so yeah they'll hire for this limited skill set and probably pay less 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...
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++.
You also still need to solve the things like CI/CD, CM, dependencies, data modelling, correctness, resilience, security, compliance, integrations and so on.
Take off. Microsoft are chasing revenue and aim to lure you into their walled garden.
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.