I think you're taking the intent of "low-code" too literal, or have not worked in an organization of sufficient size for its value proposition to be evident. It's not to solve a solutioning problem; it's to solve an organizational one.
While any "low-code" is marketed as a WYSWG, business friendly solution platform, what it actually is is a way for the business to get access to capabilities IT otherwise gatekeeps as "domain expertise", but fails to actually produce with.
Case-and-point: IT quotes an organization $75 million for 30 projects in fiscal year 20nn. By 20nn+1 IT has completed 5 projects for $75 million. Sick. Org gets "low-code" on their own dime for $1 million, hires a couple "business systems analyst" for a little less, and in 20nn+1.5 has completed 25 projects. In 20nn+3 IT looks incompetent, gets pissed, cries foul, the "business systems analyst" are ingested into IT and taught Java and CRUD circa 1998, and the life-cycle continues.
My experience of apps built by "the business" is 13 years in UBS and Bank of America. "The business" cannot be trusted to understand regulatory and privacy concerns, they cannot test their apps, they do not concern themselves with vulnerabilites in their dependencies or the licence terms therof. For those reasons, and more, the ability for the business to deliver apps more cheaply than IT is illusory.
That doesn't stop a cyclical swing towards RAD/no-code/AI when people forget this and then a swing back when we remember.
I have heard this before. But before we assume incompetence, first we need to understand what the IT is producing. Anyone in IT can also build the application in a very short time. What the business do not fully understand is the effort required to implement all the other non-functional requirements they need but they don't know yet. Once the quick and dirty solution is done, and they are happy that the feature are done, they realize it is not compliant. Now they spent some effort for compliance and after that they realize that there is no backup. If the data is corrupted, all is lost. So then they call up their business analyst to implement that. And after a few such iterations they give up and hand it over to IT. Now IT has a shitty application that is not secure, partially compliant and terrible disaster recovery. So it has to be rebuilt. Now it costs much more than if IT had implemented it in the beginning.
The costs of the IT department exists because we have experience on the real costs of implementing production grade software.
For minor throwaway apps, there is always excel and MS access.
100% this! In some companies the 'simple app' that is described in this post will get some ridiculous quote from central IT/tech ('it will take our team 4 sprints') and then never get signed off. IT will also ban anyone spinning up their own servers due to support issues.
No code platforms manage to get around this.
Another use case - I work for a 'non-tech' consultancy. Clients typically won't like paying us to spin up some flask/django/rails app, but are happy to pay us to spin up some sort of no-code thing for them (perception is that it will be easier to self-support, which is also probably the reality compared to me developing some sort of rails app and then leaving the company).
In my experience you are right - IT will always deny these requests, so you need to build the solutions in a way that avoids accessing existing DBs.
Usually it’s replacing a spreadsheet, so either the information can be manually keyed in or can be imported from various reports. Sometimes you even get into screen scraping, sometimes scheduled reports that are getting dumped to a drive and getting imported… basically any way that avoids needing to get permission from the IT team.
Writing the code is NOT the problem with these enterprise project failures.
Usually decades of problem-solving have led to an absolute mess of blurry ownership and accountability.
This in turn leads to corner cutting and a road completely covered in Chesterton fences…
Tearing arbitrary fence down leads to consequences out of project scope, no one can answer questions, and no one can prioritize - this is a business problem, and no amount of fancy code (lo/hi/full/lo/left or right) will help.
If you run a bigger company and rely on IT and ERP flows, well, it’s a part of your core and you’d better treat it as such!
From your first sentence it is implied you have some working experience with this. What are your thoughts on end user computing and the longer term effect in the business?
One of my very first jobs was taking tools that were developed at the team/dept level and scaling them up org wide if they were useful. Honestly it was great to have end users already deeply thinking about what’s needed by building prototypes themselves. This business was much better for it. Looking back I was very fortunate to land in a large business who embraced technology as a key differentiator very early on.
While any "low-code" is marketed as a WYSWG, business friendly solution platform, what it actually is is a way for the business to get access to capabilities IT otherwise gatekeeps as "domain expertise", but fails to actually produce with.
Case-and-point: IT quotes an organization $75 million for 30 projects in fiscal year 20nn. By 20nn+1 IT has completed 5 projects for $75 million. Sick. Org gets "low-code" on their own dime for $1 million, hires a couple "business systems analyst" for a little less, and in 20nn+1.5 has completed 25 projects. In 20nn+3 IT looks incompetent, gets pissed, cries foul, the "business systems analyst" are ingested into IT and taught Java and CRUD circa 1998, and the life-cycle continues.