Re:Protein interface – how to change aproach to building sof...
by catinblack on Sunday October 16, 2022 @01:05PM
(#33225230)
It's not even that they are supposed to use some solutions without the approval of the IT department. The IT department could, for example, prepare some sandbox for people to play with. They can create separate systems and with their consent and approval people could "play" with ideas. I feel under the skin that there is huge room for innovation.
Re:Protein interface – how to change aproach to building sof...
by csours on Sunday October 16, 2022 @01:20PM
(#33225346)
I don't dispute that at all. This could happen. It should happen.
IT has an allergic reaction to Shadow IT because they know about the times they had to deal with it. Understanding what IT has had to do in the past to fix things helps you understand why they don't think in these terms.
Re:Protein interface – how to change aproach to building sof...
by ok_dad on Sunday October 16, 2022 @01:27PM
(#33225404)
Shadow IT happens when the user isn’t getting what they need. I wrote software in excel at one job that did the priority planning for incoming inspection, because we didn’t have anything we could use to do that other than SAP and I wasn’t going to engage with that system due to effort required.
Re:Protein interface – how to change aproach to building sof...
by clcaev on Sunday October 16, 2022 @04:32PM
(#33226952)
Shadow IT could be seen as ignoring externalities such as security, operational resilience, and process coherence in order to "get things done". Eventually the bill comes due (security incident, key employee exit, incorrect results). Questions are: can you recognize failure? who pays to fix it? what happens while it's being fixed?
The hell-sewer is real, but banning shadow IT is not the right answer.
---
Above is the answer to your question, but it raises the question - what is the right answer to shadow IT?
The problem with this question is that it sounds like ONE question, when in reality it is a many segmented question. You need a way to characterize the shadow IT in question so that you know what approach you should take.
If shadow IT overlaps with governance, then it should not be shadow IT.
If shadow IT does not, then it's probably fine to stay that way or be replaced at some point by a MVP.
---
That answers the question I raised, but now I've raised another question: WTF does "overlaps with governance" mean???
And this is where the nightmares begin!