Microsoft's low-code strategy paints a target on UIPath and other RPA companies
infoq.com
infoq.com
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.
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.
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)
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.
* Person in the business area implements RPA. Business area is happy.
* Person who implemented RPA moves on to greener pastures.
* RPA breaks, business area calls IT.
* IT is horrified at the unsupportable mess that's just been dropped in their laps.
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”.
/soapbox (Sorry)
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?
> 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.
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.
The more serious players shadow Windows events.
The real stuff does process injection and directly shadow copies / modifies in-memory data structures.
In simple cases, it's clicking a button.
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.
And long tail, accreted one weird customer at a time things are definitely a moat.
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.
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....
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.
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.
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 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.
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.
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.
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.
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.
Not sure about legacy. Modern glorified ducktape to make legacy stuff play nice is more like it imo
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 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.
Another use-case could be the cloud probably – like scraping your salesforce apps. And this is just .... sad?
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.
An example is a SME which wants to download the billing information of 100 employee from ATNT’s customer port
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).
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.
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.
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.
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.
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.
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.
Also we had a falling out since then, so shrugs.
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...
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.
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.
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.
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.
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...
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.
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.
If you didn't mean to paint such a picture, I'm sorry for misunderstanding.
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.
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.
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.
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.
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 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.
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.)
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.
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.
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.
https://res.infoq.com/articles/cloud-vendors-low-code/en/res...
If you are a small company and use Teams internally. Fine, but it simply does not work in an enterprise environments.
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.
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.
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.
>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.
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.
You also still need to solve the things like CI/CD, CM, dependencies, data modelling, correctness, resilience, security, compliance, integrations and so on.
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=27362708I have seen departments fully managed with APEX applications.
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.
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.
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
If any company can solve the extensibility question, I think Microsoft has a better-than-average shot at it.
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.
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.
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.
Application system? Perhaps you meant admission system?
Is there publicly available info where one can read more about it?
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.
(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.)
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."
Take off. Microsoft are chasing revenue and aim to lure you into their walled garden.
Wouldn'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..."
You had made it sound like some sort of coordinated astroturfing operation.
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..."
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++.
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?
- 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.
1. Common code format across the Power platform, and
2. the branding MS was using to describe everything that would be put under source control.
I have some doubts about whether the second point is true.
This article (https://docs.microsoft.com/en-us/power-platform/power-fx/ove...) discuss PowerFX stored as YAML files under source control.
And this article which predates the PowerFX announcement (https://powerapps.microsoft.com/en-us/blog/source-code-files...) discusses UI YAML files under source control.
But nowhere does it say that they are branding the UI YAML files under the PowerFX moniker.
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.