The concept of consumerization of IT, Bring Your Own Everything (BYOx) and self-service technologies has amplified the amount of ‘Shadow IT’ in development shops. Developers can procure, setup, and start using new components, and developer tools in hours. This is a trend that lurks in the dark. C-suite executives can either ban the trend altogether to stay on the safe side, or venture into new waters and embrace innovations that open doors to unforeseen opportunities, efficiencies and productivity standards.
Prevalent Darkness – The Problem
Modern software development implies that changes to the IT governance structure are mandatory. Especially in the world of DevOps which aims to transform IT from a rigid system, into an ecosystem where change is part of the flow, teams should be able to iterate over process challenges just as they do code. The idea is to eliminate performance bottlenecks and yield positive business results.
Containing this pace and level of growth is challenging when measured against the formal approval process of core IT. Allowing developer-focused solutions that conveniently shorten release cycles is a must. But they need to deliver desired results without risking security, compliance and product performance in order to sustain growth. Devs will continue to address their tooling requirements without these considerations as the pressure on them is high. They need to ship code, and are usually behind the gun with their backlog. Developer ISVs have also shifted focus from IT executives and tend market their products by bottom up trials with developers, instead of approaching company executives only via RFPs.
Devs are inherently fast adopters of technology and their requirements can be a moving target. Inadequate change management policies and slow traditional processes of approving enterprise tooling inhibit the adoption of technologies that are legitimate and needed yesterday.
At the same time, Devs object to their limited authority and contribution in deciding which tools to support in the corporate network. From the perspective of IT executives and financial decision makers, accommodating multiple evolving and virtually unlimited Dev request for enterprise solutions create a quandary as software quality is a must, but so is business continuity.
Turning the Lights On – The Solution
Acknowledging the trend of Shadow IT is the first step toward reducing its impact proactively. Employees may inadvertently risk security and compliance even by using technologies such as BYOD devices allowed at the office. It is not malicious, it is their job, and aligns with the DevOps results focus. From the Devs perspective, creating reasonable means to standardize the process of rapid approval and availability of the required tooling is crucial to address the issue of shadow IT.
IT should look at Shadow IT as a roadmap, not an enemy
To create the balance IT needs to be a facilitator to developers, and focus on being a service provider, not a police. In some organizations this is called Shared Services. A branch of IT that provides a library of tools to developers. They are responsible for vetting tools quickly, and adding them to the library, ideally before the need arises.
Creating libraries with an array of tools and establishing open channels where Devs can request the tools they need can streamline the approval process. To ensure effectiveness of these initiatives, IT executives and financial decision makers will have to devise a roadmap that enables flexibility to deploy additional tools without compromising security, compliance and performance of end-products.
Stronger communication between Devs and IT departments is also required to ensure everyone is upfront about tooling requirements for each project, as well as the risks inherent with the requested tools. And socializing the risks associated shadow IT practices, such as potential risks of sharing sensitive business information via cloud-based apps, and vulnerable to security attacks will encourage Devs to remain cautious while following the organization’s approval channels and systems in place to provide the necessary solutions. After All a serious outage or security exploit will fall on developers hard should it happen. So it really is in their best interest to mitigate this.
Shadow IT is not an enemy. It is an indication of how fast the team is moving, and the flow to positive results and faster software delivery. But it should be protected under a shell of IT who wants to support the new tooling, and finds a way to be a service provider of it. There will be hiccups and occasional bottlenecks, but done correctly they will not drastically impact developers ability to ship code.
