Often those SMEs are data folks, and if they are allowed to develop in $TOOL_DU_JOUR, and that app becomes business critical, the IT folks will be stuck supporting it. And if that thing doesn't become well supported, or it isn't easy to find someone who can support it, that's a problem.
I've run into this quite a bit at my workplace. Some business group writes an app in Excel using VBA + an add-in and it becomes the core part of some workflow. But IT didn't know about it, nor did they know about the (for example) 32-bit ancient Excel add-in that it requires, which then breaks when an Office upgrade happens...
Now IT is stuck where a routine upgrade broke some weird edge case thing and needs to maintain a downlevel version of Office for a small group until they can re-develop their business-critical tool in something else.
Use-known-stuff rules up front -- in this case which may well be VBA -- alleviate a lot of these long-term problems.
In our case (and in the article), we wanted to collaborate with IT, code along-side them in a technology of their choosing. However IT explicitely told us that they would NOT allow us to do any coding whatsoever.
I, as an SME, am fully happy coding in C#, Java, Rust, whatever! As long as the language is turin complete, is pro-code and versatile enough, I'm all ready to go.
Do note that IT actively chose to develop the solution in Microsoft PowerApps, despite my advising that the solution would be better suited as a web app.
That's a great way to go, but unfortunately the reality is often the folks go off and write stuff in the non-supported way. The business gets dependent on it, and then years later -- because IT is there to support the company overall -- IT gets stuck supporting it even if long ago they said they wouldn't.
Sure, you can have an internal political fight, but it only goes so far when everyone there is supposed to be working for the company. So while there'll be strong incentive to move to something else, there's still a need to keep it working in the mean time.
If you can prevent this up front it's better all around.
I've been on both sides of that kind of situation, and IMO when an IT department gets that calcified, it's a sign that their days (or the company's days) are numbered. Either the non-IT staff will get fed up and replace IT, or the non-IT staff won't be able to get their work done efficiently and the company will fail.
The non-IT staff build those things because they've identified a way for the company to improve itself, but the process for getting what they want from IT is too expensive/onerous, IT has delivered disappointing results too many times, etc. Find a way to meet in the middle, or the non-IT staff are just going to build them in their own shadow cloud account and eventually make the IT department redundant.
There are tons of incredibly beneficial computing improvements that it doesn't make sense to spend IT resources on, because there are better ROI opportunities for them to focus on.
But! That doesn't mean the things they can't handle aren't valuable.
My preferred method is (1) require documentation (using a standard template) on all processes implemented by non-IT (what it does, how it does it, what value it delivers to the company, what the fallback manual process is, etc.), (2) store these process docs in a centralized location, which then becomes IT's backlog, and (3) any change control / regulatory requirements.
The grand bargain is then:
- Anyone is authorized to improve processes, if they generate the documentation
- IT has the authority to force decommissioned of an existing solution *after* they've delivered a working replacement
That seems to align everyone's incentives more clearly on "the good of the company."
True, but that's kind of like Twitter having to go back and rewrite their Ruby services in Scala down the line.
Getting a viable Minimum Viable Product is all important. If a non-developer can hack that together in Excel + VBA, more power to them.
Going back and rewriting it in a Proper Programming Language after the fact is an acceptable cost, once you have something solving an actual business need.
The issue I've most seen is that it never gets rewritten because the business side sees it as sufficient and just uses it. The techy/IT/programming folks never even hear about it until it breaks.
Most of these things are sheets which perform perfectly fine as-is, with their issues being around long-term maintenance. (Routine platform upgrade break the app, but the platform owners had no idea about the app until it broke for the users. The app didn't really even have an owner anymore because IT was never involved to assign it an IT owner and the author is long gone...)
Yes, it's the old-as-time problem of misaligned interests, but it's the reality in most corporate/enterprise IT and is a strong reason for prohibitions that may seem stubborn to devs.
I've run into this quite a bit at my workplace. Some business group writes an app in Excel using VBA + an add-in and it becomes the core part of some workflow. But IT didn't know about it, nor did they know about the (for example) 32-bit ancient Excel add-in that it requires, which then breaks when an Office upgrade happens...
Now IT is stuck where a routine upgrade broke some weird edge case thing and needs to maintain a downlevel version of Office for a small group until they can re-develop their business-critical tool in something else.
Use-known-stuff rules up front -- in this case which may well be VBA -- alleviate a lot of these long-term problems.