Sometimes, the world changes quickly.
Six or so months ago, in a conversation with some fellow travelers in IT organizational effectiveness consulting circles, someone (ahem) raised the question of shadow IT and how best to support it. “I can’t imagine any circumstances in which we should even consider allowing it,” someone said, receiving near-unanimous support from the assembled multitude, yours truly being the reason it was only “near-.”
Last week I attended MIT’s CIO Executive Forum. In a table discussion at lunch, and also among many of the panel discussions, it was unanimous: Support for shadow IT is an increasingly important IT responsibility.
Which, as I’ve been advocating for shadow IT in some form or another since 1996, is gratifying. For you, it means advocating this no longer makes you a heretic.
If you’re a skeptic, consider the Transportation Security Administration (TSA).
Not its use, disuse, abuse, or quashing of shadow IT, about which I know nothing. What I do have is extensive experience waiting in TSA queues, and how it relates to process cycle time improvement.
Cycle time is the time needed for one item to move through a process from start to finish. When you’re waiting in the TSA line at the airport, total cycle time is measured in psychological months and chronological minutes.
Cycle time has two components: intrinsic cycle time and queue time. In TSA terms, queue time is how long you have to wait until you have to undress, empty your computer bag, and put your toothpaste and other non-solid toiletries on display.
Intrinsic cycle time is what elapses from the moment your first piece of luggage hits the conveyor until you get everything back on the other side of the machines subjecting you and your belongings to various indignities.
With TSA, intrinsic cycle time is actually quite short — no more than two minutes. Almost all of the wait we’ve all grown to detest has nothing at all to do with how long it takes TSA to determine who among us is or might be a threat. It’s queue time that tries our patience.
And interestingly enough, intrinsic cycle time isn’t the only factor driving queue time.
Capacity drives it too. If there’s just one inspection line open and the queue gets too long, TSA can and does fix the problem without any process improvement. It simply opens up a second inspection line and queue time is instantly cut in half, even though it hasn’t even nudged the dial on intrinsic cycle time.
What does this have to do with shadow IT and why you want it? Everything. Because the most important business benefit to be had by embracing, encouraging, and extending shadow IT is its impact on queue time, where its impact is little different from TSA opening the second inspection line.
Only in the case of shadow IT, the business is multiplying its application implementation capacity by maybe 1,000 percent, so long as IT doesn’t do its best to slow it down to industrial-strength IT speeds.
See, shadow IT has two natural advantages over industrial-strength IT. The first is that the trusted cadre known as we is responsible for all of the design decisions, where with industrial-strength IT, we in IT fall into the nasty group of untrustworthy ne’er-do-wells known as them. This is particularly true of the various trade-offs that are unavoidable in any design, but no more desirable because of their unavoidability.
The second advantage is that with shadow IT, most of the analysis and design work takes place inside a single person’s head.
Here’s why this is relevant. A lot of the reason we need methodologies when developing business software is because we have to coordinate the work of multiple specialists, each of whom understands a part of the problem; none of whom has the complete picture. Shadow IT doesn’t usually suffer from the need for all of this overhead. It’s pretty much one person’s show, front to back.
Meanwhile the single biggest argument against allowing shadow IT projects has pretty much fallen apart. That’s the contention that shadow IT frequently ignores the principles and practices required to implement properly secured systems.
This argument fell apart when Target, and Home Depot, and Humana all experienced major data breaches, all of which penetrated their properly secured systems … systems designed, built, tested, and implemented by IT professionals.
Conclusion: We’re over the hump with respect to IT recognizing the need to support shadow IT.
All that’s missing is a clear picture of what that support should look like.
When I worked for Arthur D. Little, Inc. I guess I was my department’s “Shadow IT.” It started when my Secretary came to me crying that she had wiped out the hard drive on her PC. We were running DOS in those days on commodity PCs with most files stored on 3-1/2″ floppy disks. She had accidentally typed FORMAT C: rather than FORMAT A: and without any further a-do, it did precisely that. If she had complained to the IT department, she would have received a black mark on her next review. I was the local PC Geek who knew how to restore DOS and WordPerfect so she could resume her work. I also replaced the FORMAT command with a FORMAT macro that would only format floppy disks. I installed this simple macro on all PCs in our department. Then I suggested it to the genius’ in the IT Department – who of course ignored my suggestion. However, they allowed me to pioneer Windows when I needed to. I also pushed them into getting an Internet domain, which they had never heard of. The major problem of Shadow IT is that there are no rules of succession – when that person leaves, the “department” is gone.
You ostensibly seem to be addressing the “Shadow IT is insecure” argument by instead standing up a straw man argument saying “Industrial IT is insecure”. And you make the latter point by pointing out all of the worst, most public, recent failures in IT. I’m not going to defend industrial IT in that regard. I’ve worked in the industry for years and seen fan too many people willfully ignore sound security (and other) practices. However, saying that “industrial IT security is already so bad, we may as well use shadow IT” is still not the same thing as “shadow IT is secure”. It is still weaker security by design, and when you factor in its integration with the already weak industrial security, that’s a recipe for nearly guaranteed failure. I am not necessarily opposed to “shadow IT”. I think there are some use cases where it can be done right. However, your earlier argument about it being better because “it’s all in one person’s head” is also not necessarily helpful either. One person acting alone can make some very poor decisions that are then not sanity checked by people with more experience. I would contend *that* is the most likely reason why “industrial IT” projects go bad, not because the process is flawed, but because you end up with individuals who skirt “the process” because they think they know better.
I don’t have the solution, and I am not firmly in either camp, but I think your arguments here are a little disingenuous.
See above comment: It isn’t that shadow IT is secure, or even as secure. It’s that the pot rarely does well calling the kettle black.
The high-profile data breaches make it unconvincing for IT to claim shadow IT is just too risky to allow – all the more reason to provide proper support.
Your point assumes the people saying “Shadow IT is insecure” are the same people who prop up these failed environments (ala Target, Home Depot, etc.). There are IT professionals who are quite competent at assembling secure internal infrastructures, who have both the skill and experience to point out exactly why and how “Shadow IT” is a non-trivial security risk in many cases. Lumping the whole IT industry in with the folks who have failed so publicly is a disservice to those who do the job well, whose companies you never see in the news.
While anyone making a blanket statement of “Shadow IT is not secure” is clearly short-sighted, “shadow IT” does carry with it increased levels of risk, because you’re expanding the threat horizon outside of what can be physically secured. I’ve witnessed “shadow IT” implementations by people in too big a hurry for “corporate IT” that involved uploading documents containing things like SSNs to Google Docs on their personal accounts. I’m sure the guy that had a job to get done thought it was a good idea at the time, and that decision was “all in one person’s head”. The common adage that security is inversely proportionate to convenience still holds true.
If your point is that IT should’ve been involved in situations like the one I noted above, then the person would’ve been told to wait on normal processes. Does that cost the company money in terms of missed opportunities? Perhaps. I’d argue that in such cases IT investment is lagging behind where it needs to be.
Well, actually my point is that because of Target et al, IT has lost its credibility when arguing against shadow IT. Is that fair? Doesn’t matter.
Bob – one of the best pieces on shadow IT I’ve read, particularly the observation that most of the analysis and design take place in a single person’s head (and, implicitly, that single person working directly and iteratively with the people who will be using the output).
Bob, I’m going to start by acknowledging that shadow IT is not going to disappear, and every organization needs to determine how to deal with that fact. However, there’s a fallacy in your position about why the biggest argument against shadow IT has fallen apart. You argue that because the professional systems have been hacked, therefore we don’t have to worry about the fact that shadow IT doesn’t necessarily follow proper security practices and principles. I respectfully disagree – the organization as a whole does have to worry about security, and adding potentially unsecured points of entry makes that harder and heightens potential liability. How do you deal with that challenge? If I had a hard and fast answer, I wouldn’t be doing what I do for a living.
No, not arguing that at all. IT needs to provide a proper environment for shadow IT for all the reasons you mention. My point is that the arguments for stomping out shadow IT have fallen apart, because it doesn’t appear to be any riskier than formal IT.
One objection I hear is that “we don’t have a budget” for supporting shadow IT. I suspect that means neither dollars nor hours. That seems easily solved by budgeting some SWAG fraction of our budget for supporting innovative, not-invented-here, shadow IT. Excuse me while I go sell that idea to organizational leadership.
“We don’t have a budget for this” means “The business as a whole doesn’t consider this a priority.” It also probably means the IT strategic plan didn’t cover this topic.
The solutions: Include support for shadow IT in the IT strategic plan, and in IT’s budget proposal. There probably still won’t be a budget for it, but at least it will be a conscious decision.
I don’t understand how your analogy of the TSA queue functions in a discussion of shadow IT. The analogy seems to be like that of a call center: Industrial IT sets up all the data and computing aspects of the call center, and then the call center management increase or decrease the number of call-takers as necessary. There’s no shadow IT involved. Similarly in the grocery store – you have a row of identical cash registers, and then they are left empty or staffed as customer volume dictates.
Actually a better analogy might be a grocery store that on its own, without consulting Industrial IT at corporate hq, decides to install self-checkout register stations. That’s not duplicating the existing process, as in your TSA example, but introducing a new different/modified process.
Thanks for your interesting article, as well as the thoughtful responses of readers. For some reason, it really brought home to me the impact of wait time in the delivery cycle for IT. It seems that wait time has huge consequences for IT, politically and in necessitating that shadow IT exist for users.
I hope IT begins to widely use your cycle time paradigm to help explain and justify support and development budgets. I suspect that wait time has a huge, but largely invisible impact on organizations with high utilization of computers.
I know you are not a big fan of Gartner’s – how does shadow IT relate (if at all) to their concept of “bimodal IT” where mode 1 applications are efficient and safe and where mode 2 applications are flexible and delivered quickly? They propose that both modes can operate in a “new” IT environment with different teams focusing on each. Looks like you are saying that it is impractical if not for that to work.
There’s no one answer to this. Too much depends on the organization’s starting point, and how much it’s willing to invest in metaphorically re-plumbing and re-wiring an old house. In some situations, I’d advise making an important part of IT’s job providing safe APIs to access the “mode 1” environment for both IT and shadow IT dev teams to use, along with an architecture that supports rapid prototyping/development.
In other situations, a more unified architecture with appropriate additional “firebreaks” to address the risks of rapidly developed solutions … again, either from internal IT or shadow IT … until they’re more thoroughly tested might make more sense.
I’m sure there are other architectures worth exploring as well – this is a big, complicated question with multiple contextually logical answers.