3 Comments

Summary:

Shadow IT, or dark ops, can be scary to IT departments, but there are reasons developers go rogue. Instead of fighting their urge to flea to the cloud, make it easy for them to use cloud resources in a responsible way.

You’re stuck in bumper-to-bumper traffic. No one’s moving. It’s hot, the air conditioner is busted and next to you is a tempting escape … a wide-open breakdown lane. Sure, you could move over and jump ahead. You’d get where you wanted to go faster, but you’d be breaking the rules.

Shadow IT projects crop up in much the same way. Gridlocked by the processes and protocols imposed by IT management, developers very often give in to the temptation of moving their projects outside where they can progress faster. These “shadow IT” or “dark ops” which happen when developers go outside the firewall — spinning up and provisioning their work on beyond-the-firewall cloud resources to support time-sensitive project delivery. These efforts typically happen without the knowledge of IT (or accounting) departments.

Dark ops: a symptom of impatience, colliding objectives

Dark ops emerge when dev/devops teams hit communication breakdowns, governance constraints, and resource limitations. The whole rationale for the devops movement — in which company developers and operations people — who often work at cross purposes — are encouraged to work together to build, then deploy,  incremental software updates and improvements. It sometimes doesn’t work that way, hence the rogue developer.  sometimes that’s because IT management has implied or stated outright that it doesn’t have the time, in-house skills, resources, or desire to deal with their projects. At the same time, developers are under pressure to innovate to keep the enterprise competitive.

The public cloud breakdown lane: tempting, but risky

Look at it from the developer’s perspective. Would you jump into the dark ops breakdown lane? Cloud offerings such as Amazon’s Web Services are tempting, quick options for developers looking for bandwidth, scale, and resources, without having to go through time-consuming IT channels. But without IT’s involvement, issues abound.

For instance, think of the “success-failure” scenario: What happens if the shadow project is a successful trial, and corporate end users demand broader rollout? IT has to integrate that shadow project back into the corporate network, connecting it to legacy applications, databases, and service frameworks. Trying to do that after the project is already under way is far more difficult and resource-intensive than if IT were involved in plans from the start.

Even worse: What if the third-party service provider suffers an outage or a security breach? IT is a corporate risk manager, and determines maximum tolerable failure windows, necessary protections against data theft/loss, and how often to back up data on-site. In addition, IT constantly measures corporate cloud utilization to avoid overage costs that can get out of hand. It’s not likely that a developer would consider these critical factors when purchasing immediately available public-cloud VMs. In most organizations, the developer’s understandable lunge towards Shadow IT can expose the company to risk and unnecessary expense.

So, how do you foster developer creativity and still maintain IT control?

1. Embrace dark ops culture

Resolve the culture wars being waged by your development and IT teams. In spite of their respective biases, developers and IT management share a common goal: to do what’s right for the company. If your devs are going rogue, review your deployment administrative processes. It’s a problem if they aren’t following the rules, but it’s a much bigger problem if your rules are hindering developers’ ability to innovate. Acknowledge the developer’s lament: “Don’t make me write another report! I’d rather be coding!” Then empower them: They want to be able to provision their apps. Take advantage of virtualization technologies to enable that.

2. Invest in the cloud

Instead of imposing arcane processes on the dev team, establish new infrastructure to support the best way for them to work. If your devs want to go to the cloud, give them a cloud to go to. If you need to keep data in-house, get a private cloud and give your devs control over their own piece of the sky. Otherwise, outsource your hosting to a public-cloud provider. The important thing is that your devs can spin up VMs and not have to wait weeks for approval to do so.

On the IT side, set up management and control procedures— as non-intrusively as possible—to make dev cloud work visible. Middleware in public or private PaaS models can provide sophisticated cloud management solutions for IT without burdening devs with overhead administration.

3. Collaborate

Hold a hackathon. Bring your teams together for a day or even a week to brainstorm on new ideas, build prototypes, and learn from each other. Make multi-day quarterly hackathons open to all employees and impose just one rule: work must benefit the company. Hackathons can get your teams thinking creatively, boost morale, and make your company and products better.

4. Open up your enterprise’s breakdown lane

With mutual respect established, virtualization options made available, and team collaboration under way, you’ll see positive changes in the enterprise developer/IT relationship. That unity will lead to faster, more cost-effective, and less-risky research and development. Open communication and mutual respect will focus your team on what’s important: moving the enterprise forward. You just have to open up that extra lane to get past the traffic.

Bart Copeland, CEO of ActiveState, a cloud software provider, will be speaking at GigaOM’s Structure Europe in Amsterdam later this month. 

Feature photo courtesy of Shutterstock user Viktor Gladkov

  1. This article covers a lot of good points. The cloud will always be more expensive in the long run though than hosting it in house. Especially for large enterprises who have hundreds of servers. Their incremental cost of adding new servers is low. For smaller companies though who don’t have large existing infrastructures, using the cloud makes a lot of sense, especially if they are rapidly growing and don’t know their exact needs long term. It is a lot easier to spin up some new servers in the cloud than to worry about buying a new SAN, physical servers, VMWARE licenses and everything else needed. Although these same benefits can hold true in large enterprises for new projects and teams who are moving quickly.

    The real benefit to the cloud is the PaaS (platform as a service) model. I love Windows Azure as a developer because it gives me things like caching, queuing, NoSQL and other things out of the box. If I had to setup all the infrastructure myself to do all of that it would be very time consuming and costly.

    Thanks,
    Matt Watson, Founder of Stackify DevOps
    http://www.stackify.com

  2. This can even be a marketing strategy if you want to target enterprise customers without needing to invest in traditional enterprise sales. Marketing directly to developers and making it easy for them to get started means they’re more likely to try it for personal projects and bring it into work. It’s easier to sell a license or support contract if the product is already being used by the engineering team.

    For low cost SaaS products, this is then a much easier sale and for more expensive licenses or support contracts, having a team hold the hand of the buyer helps the sale too.

  3. Reblogged this on stayNtouch and commented:
    Here’s a great post on how to fix the stiffness that exists with many hospitality software vendors (and sometimes to the fault of some of the hotel brands). While process is important, with current available tools, developers find their way around it. They use the tools to innovate and produce new ideas and products faster. Learn about 4 ways to alllow developers to “play” and get to some great new products or ideas, while doing it.

Comments have been disabled for this post