Shadow IT: Lessons from the front line
September 26, 2013 —
(Page 1 of 2)
Related Search Term(s): DevOps, IT
In many large enterprises, software developers are in a tough situation. On one hand, business units demand new applications and services at the speed of market change. On the other, they work with central IT, whose limited resources and focus on system administration make it difficult for developers to get the infrastructure and platform resources they need in a timely manner. As a result, developers often can’t deliver quickly enough to address new market opportunities, and more agile competitors snap them up.
At the end of the day, developers just want to code and test and innovate. With the support of business units happy to hand over a credit card, many development teams have turned to shadow IT—contracting with public cloud providers for resources—as an easy release valve for the pressure from business units. Having spent years in a management role, where we regularly incurred a greater-than-US$10,000-per-month AWS bill because I couldn’t get what I needed from IT for infrastructure and other resources, I can categorically say that this is no way to operate.
Developers should not have to circumvent central IT in order to operate with agility. Development teams who leverage shadow IT are often seen as mavericks, which may be unfair given the organizational constraints they encounter. However, shadow IT poses serious risks to any large regulated enterprise. At a time when many enterprises face growing, nimble competition from around the world, it is crucial that enterprise IT, development teams and business teams gain operational agility and fluidity of resources to stay competitive. Or else, they will face margin compression, loss of market share, or even extinction.
And they must do this while maintaining central IT’s ability to control governance, compliance and security, which cannot be done with rampant shadow IT.
It is central IT’s manual, approval-based operating model that inhibits the allocation of developer resources. In my case, these slow processes and cost justifications meant there was no way we would have been able to obtain the resources we needed in a timely manner. I took a risk by using my corporate procurement card, and was able to leverage on-demand, cloud-based services from AWS, which enabled my team to pay just for what we used and to avoid latency in our development and delivery process.
Central IT did not have the sense of urgency we required, and the procurement process and planning overhead to stand up a single VM would take weeks. Fortunately, my expenses for shadow IT were never kicked back. I consider myself lucky to have learned a few key lessons that I’d like to provide in a constructive public forum for this conversation to move us all forward in working together to stay competitive and get the job done.