IT spending, especially among business units, has been a heated topic at every organization I've ever worked with. Projects that division managers consider high-priority aren't regarded highly by corporate IT, or, worse, are completely ignored by IT. This, in turn, drives these managers to other means to accomplish their IT goals -- what I like to call "Shadow IT."
While the term sounds super-sexy, it really isn't. Shadow IT simply refers to projects implemented by business units without the support (and sometimes without the awareness) of the larger corporate IT structure. It's a very real problem for any organization operating at the enterprise level. Forrester Research Inc. estimates that as much as 15 percent of an enterprise IT budget is spent in shadow IT projects -- usually without the CIO's knowledge.
Here's how I've seen shadow IT typically evolve. First, the pressure for business growth and transformation makes IT staff say "Leave me alone" until a large IT project (like an ERP implementation) is finally completed. Business units are now on their own to procure and deploy their solutions. While not a true IT free-for-all, this results in some fairly significant downsides for the business as a whole, including:
- Limited systems integration
- Redundant functions across various business units
- Orphaned custom code and applications
Once corporate IT pulls its head out of the proverbial sand, it's left with a maintenance nightmare. This results in the next step of the Shadow IT evolution -- "The Iron Fist." At this point corporate IT calls in enterprise architects to clean up the mess created by the business units' pet projects. Then it lays down the law, requiring that all software development and application purchases be procured and delivered by the corporate IT team. In addition, it erects stringent guidelines around architecture and standards.
The Iron Fist rationale is based on the notion that when we are done we will have a tremendously flexible, well designed corporate architecture that can respond to new requirements really quickly. The problem is that until we reach this nirvana, the business keeps piling on requests, which take forever to get delivered.
I have seen VPs cry with despair while they wait for relatively small portal changes that would increase revenue by millions if only they didn't get delayed year after year while the new SOA architecture is being deployed. These are the VPs who swallow it up and wait. More aggressive VPs start up truly rogue IT projects, which -- while meeting their business needs -- do not conform to any corporate policies or standards. This results in sheer technology-based chaos and the proliferation of truly disconnected "mushroom" applications.
So how do you break this vicious cycle? Until recently there was no obvious way out of this dilemma. If you wanted flexibility you gave up control. However, a new way of doing things, based on an upcoming generation of cloud-ready platforms, holds promise. With these platforms you can implement a federated model of enterprise software development, where IT pushes the specs gathering and initial application development to the business units. This eases the burden of managing every single new project, allowing the IT department to maintain centralized control on security, global enterprise architecture, and operations, through a standard cloud infrastructure definition.
You can expect some of these applications to grow rapidly and become strategic for the enterprise, because software should change at the speed of the business it supports. When this occurs, an advantage of the federated model is that IT can smoothly take over the maintenance of the apps that are becoming strategic, without having to rewrite them and stopping the flow of change.
This approach makes it easy for corporate IT to foster development at the local level, while still exercising governance and control over these projects. An example might be IT making the same centralized service available to all business units and encouraging their development teams to reuse this service for themselves.
In the end, the federated model doesn't really end shadow IT -- it legitimizes it and brings it into lockstep with the rest of the IT process. In essence it keeps IT in sync with the business. Individual business units feel their needs are being met, while corporate IT retains the governance and control it needs to keep the business running smoothly.
Or, to say it another way: You can take IT out of the shadows by moving it into the cloud.