Fear and loathing in Shadow IT

Shadow IT-it sounds like a really cool specialty, doesn’t it? “I’m a DBA, what do you do?” “It’s classified. I’m from Shadow IT.” But Shadow IT is anything but cool. If you have never run into it before, you’re lucky. Shadow IT is a phrase used to refer to information technology projects and solutions that a business unit deploys on their own without the involvement or approval of the information technology department. They might build their own system, or contract out with a SaaS provider, or bring in a consultant, but the one thing they don’t do is work with IT to deploy, and that has all kinds of bad implications.

Furthermore, the costs related to Shadow IT are often “AFTER” they have been consumed.  These range from unreturnable CPU cycles “Dude, you used it, now you have pay” and “Oops forgot to shut off my Dev, Staging and Test environments for the month” to maintenance calls billed by the hour because the resources internally do no match the knowledge to maintain whatever software was available. The only ones who end up seeing these costs are the Finance people – who end up paying for the submitted “small” expenses via credit cards.

So why can’t the marketing department go off and do their own thing in IT? Well, let’s take a look at all the ways things can go wrong with Shadow IT deployments.

Compliance

If you have any compliance requirements at all, whether they be from laws, or contracts, or requirements to accept payments, you have to ensure all IT deployments comply with the relevant requirements. You may even have a department whose sole purpose is to ensure compliance, and you definitely have to perform audits to prove compliance. A Shadow IT project deployed outside the normal processes will almost definitely fail compliance from a simple lack of understanding regarding what is required. It will also cost more to assess and audit since it is external to the central IT processes.

Standardization

Standardization is good. It provides for repeatability, predictability and a regular way of doing things which, in an environment where downtime equals lost revenue, is a really big deal. Shadow IT almost always goes down a different path from how the corporate IT does things, perhaps specifically because of that, but without standards the shadow IT project can experience significant downtime, challenges interconnecting with existing systems, and can be much more difficult to support.

Compatibility

Related to standardization is compatibility. Shadow IT projects can be deployed quickly in part because they don’t need to worry about compatibility with the mainstream systems, but what happens when they then need to be? Something as simple as SSO becomes a huge challenge if the Shadow IT project wants to leverage users’ existing logon system, and could cost twice as much if it needs to be retrofit to the existing systems. Costs could be even higher if IT needs to deploy federation to enable SSO. Data standards are also critical for compatibility if the Shadow IT project needs to pull from or update to existing systems.

Costs

Shadow IT may seem to be less expensive than going through the normal IT channels, but that may just be on the surface. If, for example, the marketing department hires a third party to do something, but then has to rely upon that third party for ongoing care and maintenance, perhaps even signs a long-term contract with that third party, and updates and revisions are charged on time and materials going forward, that cheap and fast workaround may prove to be neither.

Supportability

This is the crux of the matter from my point of view, namely because the first time I learned about Shadow IT was when the CEO of the company a colleague worked for called him up on a Saturday night wanting to know why he hadn’t fixed the Sales Team’s new website. Apparently it had been down since last week, and they told him that they were having problems with support, without mentioning that the support was a third party and NOT the IT department. He quickly went from demanding my colleague fix it to begging him to see if there was anything he could do, which in this case (and amazingly), there was.

 No, this colleague of mine is not a supergeek. They just never asked for a DNS record to be put in and that was actually a pretty easy fix. Of course, their third-party didn’t think to ask them if they put in the DNS record; never checked to see if DNS was right, and had been banging on for days.

The bottom line is this. When a business unit goes outside of the IT department, they are taking a huge chance. When they come to you for help, it’s not wrong if you want to make them squirm a little bit. You’re not a bad person if you refuse to support something that wasn’t deployed by your department. Just make sure your boss backs you on that stance!

Make a deal with your other business units. IT won’t give themselves raises, hire and promote their own people, secure bank loans, sell products, or sign leases on their own, provided the HR and marketing and sales and all the other business units involve IT in their technology needs. That way, everyone gets to focus on what is important, ensure both compliance and compatibility, and IT can actually support them when things go wrong. It’s a win-win for everybody. It may take a little longer up front, but that will be time well-spent.