I’ve been hearing the term Shadow IT quite a bit recently.  According to the Fount of All Knowledge, Shadow IT refers to networks and systems built inside organizations without official approval.  I found it curious that people started referring to this almost five years ago, yet a cursory search for “shadow IT” turns up a *ton* of articles written in the last six months.  At first, I wondered if the trend of BYOD had finally petered out a bit.  After all, once you’ve assaulted the populace with a headline every day for at least two months, they kind of grow accustomed to it and get bored seeing it all the time.  Then I wondered why a five-year-old concept should be hot now.  Then it hit me.

I’ve never heard of Shadow IT because it was never a “thing” for me.  The idea that a lab computer or a non-production testing system might be moved into production work wasn’t an obstacle to the way that I’d done things in the past.  As a matter of fact, it’s the way I’ve done things for the most part my entire career.  In order to replace our aging 3Com NBX phone system, I installed Cisco CallManager in a lab and let the sales folks use it to make conference calls one week.  They were so impressed with the quality of the call they made me rip out the old and put in the new the following month.  The whole virtualization strategy around here grew out of one box running ESX standard for a VM migration test.  After people discovered how flexible things were inside of a virtualized environment, naturally our server strategy going forward was focused around our brand new ESX cluster.  Even our network was a series of cobbled-together parts scavenged from the four corners of the globe at a time when the engineering staff needed gigabit connectivity and we had no budget to accomplish it.  Slowly, one piece at a time, we assembled our entire setup without direct authorization and formal approval.  While it was nice to called to a meeting about a new feature and be told, “Yeah, we’ve been running that for the last three months” there were huge weaknesses in the plan.

With a hodge-podge network assembled over the course of months or years to address tactical problems, you have huge support headaches in the event of failures.  Untangling the knots of interconnected systems becomes a lot harder when you keep uncovering devices you knew nothing about.  That new awesome voicemail server?  It’s running on ESXi on a new server that was originally provisioned for lab use.  All well and good until I’m out of the office and someone needs to restart it after a power failure.  Worse still when they have to remember to connect via VMware Client to restart the VM itself.  Extra pain and effort introduced because of the need to move quickly to implement something.  That’s just the side of things from the lab.  Let’s not talk about things like Dropbox or GMail.  Even though I know it’s not technically the right way to do things, my job is quickly reaching the point where I’m dependent on Dropbox.  I keep notes and firmware images in mine that sync between all my systems.  My presentations go in there.  So do PDFs and software images.  If someone decided to block Dropbox tomorrow, I’d be screwed.  I avoid keeping sensitive data in there as a matter of habit, but just about every other important thing is either in a Dropbox or has been copied there at some point.  GMail is another method used frequently to avoid large attachment size limitations or mailbox quotas.  That’s under the best of circumstances.  I’ve used GMail to test incoming and outgoing mail and a number of sites.  I use it to test mail routing and NAT translations of mail servers.  That’s just the legitimate uses.  Think about the number of IT people that use GMail as a way to skirt eDiscovery rules and Freedom of Information actions.  I’ve seen that several times.

BYOD has caused people in management to start looking at their networks and systems a bit closer than they have in the past.  What used to be the big, dark hole where data entered and information came out is now being scrutinized with great fervor because of the possibility of exposure.  Now, instead of turning a blind eye towards the IT department with a mantra of “just make it work,” management must now take into account that running insecure devices or non-tested configurations can lead to trouble down the road.  Trouble that someone occasionally has to answer for, either in the press or in a court of law.  That makes management skittish.  That explains why this is now an important point of contention in IT.  Rather than taking the easy road of results, we now instead must focus on  the whole process.  Ample documentation must exist at every step of the way not as a record of implementation, but instead as a way to show liability and protect people.  In essence, that’s really what Shadow IT is about.  Never mind the challenges of creating systems from untested technology.  It all comes down to who gets the blame when things go wrong and how that can be proved when the yelling starts.

I’ve already made a commitment to do my best to avoid the kinds of last-minute solutions that are implicated in the Shadow IT movement.  I’m not going to do away with my lab or with piloting solutions before implementing them.  What I will do is make sure there is a clearly defined plan in place in the event that the lab solution needs to be moved into production.  I’ll also be sure that all the involved parties agree on the best course of action before the solution is put in place so there can be no arguing or finger pointing after the fact.  The easiest way to get rid of Shadow IT is to shine the Light of Documentation on it.  Then those of us in IT aren’t looked upon as the crazy vigilantes of networking and systems and instead we can get back to being the harmless recluses that our secret identities portray.