Does DevOps help or hinder shadow IT?

Shadow IT is...

“any technology (application, person, or device) deployed within an organization without approval from IT management”

Shadow IT is a widespread problem and occurs in many IT departments. It's not as serious a problem as others that can occur, but, depending on its extent and type, it can still cause serious problems.

Shadow IT in the enterprise

Why enterprise? Well, shadow IT can happen in any kind of organization, big or small, but it's the size and complexity of enterprise companies that makes it especially likely. It's not malicious. As Peter Bendor-Samuel says, "enterprise IT simply doesn’t operate at the speed of business" and it's true - often, IT approval takes a long time and can place a huge (and boring) burden on the employee. The traditional IT department aims to protect the interests of the company, not make life easy for employees. As a result, when policies are being drawn up and decisions made, user requirements aren't always considered or addressed.

Over on the users' side, new technology is exciting - and very easy to access. Bear in mind that shadow IT isn't just apps - it can also be people and, thanks to services like Fiverr, these human resources are also easy to access. Users want one thing, and the decision-makers prioritize another. A mismatch in expectations results and a decision to use unsanctioned IT is taken, not out of malice, but out of frustration.

What's the problem with shadow IT?

There are multiple reasons companies should avoid shadow IT. In many departments, the people checking for vulnerabilities are not the people who have installed unsanctioned apps, so they don't know to look for problems in tools and services they don't know exist. Likewise, when it comes to compliance, the people checking may not even be aware that they have apps or tools that need licences, leaving them legally vulnerable in the future.

Big problems in any business

The main problem with shadow IT, however, is that it is untested. This can lead to problems, especially when used in conjunction with existing tools or infrastructure. Configuration management falls under this category - the new apps don't get much compatibility testing in shadow IT situations and that can cause problems too. If the shadow IT app stores or sends large amounts of data, system inefficiencies can arise when that data is stored and used in multiple infrastructure locations.

Once shadow IT starts to slip in, it's not unthinkable that, in the longer term, it can become part of the default system. If an app or tool does such a good job that a system becomes reliant on it, it can quickly become cost-prohibitive when it needs to scale or go "legal". That can cause departments to become stuck between an app they really need, but conditions they can't really support.

Finally, we have the classic shadow IT situation, and one that many readers will have experienced personally. Shadow apps and tools get lost in the system when the people that first installed them move on or lose the password. The services, which become subtly embedded in the system, then break and since the person who first installed them has moved on, there's no one who knows enough to confidently fix it and no official "reference point" from which to get help. 

Not convinced? In 2016, Gartner predicted that by 2020, one-third of successful attacks experienced by enterprises will be on their shadow IT resources. If that's not enough to spur you into action, nothing will!

Shadow IT in DevOps - does it happen?

But since DevOps is modern and forward-thinking, you say, does shadow IT really happen in a DevOps-first organization?

Yes. And sometimes, the impact can be even worse!

The needs of DevOps-driven teams can change rapidly. If DevOps isn't truly organization-wide, the rest of the IT department might not move at the same speed as the DevOps-led part and, if their needs aren't met quickly, workarounds will be sought. Bottlenecks between devs and IT shouldn't be happening, but we all know that they can, despite everyone's best intentions.

And how is it worse? When everyone was working on physical servers, shadow services could only build to a certain scale before being noticed and tackled. These days, however, SaaS and cloud services can operate securely and subtly at scale, and no one might notice (until it's too late!).

BUT...

...does that mean that all is lost? Of course not. In an ideal DevOps-first organization, shadow IT won't happen, but even in a more realistic version, every step you take towards "DevOps done right" can outcompete the shadow IT threat.

Limit the risk of shadow IT right now

Offer your team members a fast, efficient and varied choice of apps. If they feel able to use the best app for the job from day one, they won't have to install it themselves - in theory. As you move closer to DevOps, teams, processes, and execution times should speed up and become more streamlined, which will help get the right tools for the right job at the right time.

Help the IT department work towards self-service provisioning, which will further this goal. It will have a double benefit - it will help devs get the tools they need faster, and will also free up the IT department from routine but time-consuming ticket requests. With appropriate permissions and limits, IT departments can offer really agile choice, without worrying about systems - or costs - getting out of control.

Break down silos - another DevOps holy grail - should also help keep shadow IT at bay. As communication improves and teams feel better able to interact, they will hopefully find it easier to find solutions to their challenges without resorting to unapproved apps.

Assess, prioritize, and mitigate threats when they are found. Not all threats are equal and don't all require a heavy-handed reaction if discovered. Instead of banning the tech and punishing the perp, try looking to the process and seeing where the holes are. After all, a person uses shadow IT because they feel it helps them do their job more efficiently, and that isn't something we really want to discourage.

In summary

In an ideal world, there wouldn't be any shadow IT - provisioning and tooling would happen at the speed of light after efficient, bidirectional communication that perfectly expressed every dev's specific need.

Unfortunately, it isn't quite like that - yet. Even so, every step you take towards a DevOps-first IT department is an opportunity to get rid of shadow IT - not by stamping it out, but by creating the circumstances so that it never needs to happen in the first place.

Work on rolling out automation, eliminating silos, and encouraging communication between team members. Ensure that tech team members have appropriate forums to air their concerns and needs. You might not always be able to give them exactly what they need exactly when they want it, but you can make sure they feel heard and understood, and that alone will go a long way.

So bite the bullet and get DevOps rolling in your org.