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)
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.
> 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".
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.
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"?
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.
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.
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...
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.
>>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...
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.
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.
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"?
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.
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.
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.
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.
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.
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
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?
[+] [-] ajcp|4 years ago|reply
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.
[+] [-] ethbr0|4 years ago|reply
> 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)
[+] [-] brushfoot|4 years ago|reply
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.
[+] [-] jrochkind1|4 years ago|reply
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".
[+] [-] haswell|4 years ago|reply
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.
[+] [-] mgummelt|4 years ago|reply
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"?
[+] [-] bitcuration|4 years ago|reply
[+] [-] enraged_camel|4 years ago|reply
[+] [-] monkeydust|4 years ago|reply
I have always felt RPA was the ' poor mans' option for automation.
[+] [-] Havoc|4 years ago|reply
Not sure about legacy. Modern glorified ducktape to make legacy stuff play nice is more like it imo
[+] [-] quyleanh|4 years ago|reply
[+] [-] tootie|4 years ago|reply
[+] [-] dnndev|4 years ago|reply
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.
[+] [-] codingdave|4 years ago|reply
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.
[+] [-] LeifCarrotson|4 years ago|reply
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...
[+] [-] asdfman123|4 years ago|reply
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.
[+] [-] jlarocco|4 years ago|reply
[+] [-] syshum|4 years ago|reply
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...
[+] [-] stuaxo|4 years ago|reply
[+] [-] m12k|4 years ago|reply
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.
[+] [-] ajcp|4 years ago|reply
[+] [-] thrower123|4 years ago|reply
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.
[+] [-] omk|4 years ago|reply
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.
[+] [-] jerf|4 years ago|reply
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"?
[+] [-] akudha|4 years ago|reply
[+] [-] ajcp|4 years ago|reply
[+] [-] trixie_|4 years ago|reply
[+] [-] filoeleven|4 years ago|reply
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.
[+] [-] ajcp|4 years ago|reply
[+] [-] ARandomerDude|4 years ago|reply
https://res.infoq.com/articles/cloud-vendors-low-code/en/res...
[+] [-] paxys|4 years ago|reply
[+] [-] geonic|4 years ago|reply
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.
[+] [-] Spooky23|4 years ago|reply
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.
[+] [-] _jal|4 years ago|reply
[+] [-] tacticalDonut|4 years ago|reply
[+] [-] AtNightWeCode|4 years ago|reply
[+] [-] bob1029|4 years ago|reply
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.
[+] [-] AtNightWeCode|4 years ago|reply
You also still need to solve the things like CI/CD, CM, dependencies, data modelling, correctness, resilience, security, compliance, integrations and so on.
[+] [-] OrvalWintermute|4 years ago|reply
[+] [-] tyingq|4 years ago|reply
[+] [-] jeff-davis|4 years ago|reply
[+] [-] Graffur|4 years ago|reply
Or will it be new employees hired with just this skill set?
[+] [-] haolez|4 years ago|reply
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.
[+] [-] syshum|4 years ago|reply
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
[+] [-] jimnotgym|4 years ago|reply
[+] [-] thrower123|4 years ago|reply
[+] [-] throwawaysea|4 years ago|reply
[+] [-] foxbee|4 years ago|reply
Take off. Microsoft are chasing revenue and aim to lure you into their walled garden.
[+] [-] fartcannon|4 years ago|reply
Wouldn't that be an interesting tool for press releases like this?
[+] [-] x86_64Ubuntu|4 years ago|reply