Avoid "Bring Your Own Cloud" syndrome

Just as one-off spreadsheets and databases have created headaches for IT leaders for decades, so, too, will cloud applications forcibly introduce unplanned and non-integrated tools into the application portfolio.

With the advent of cheap, ubiquitous cloud services that require little more than a credit card and 30 minutes to provision, many IT leaders have experienced the moment of dread when they discover a business unit has adopted a cloud application unbeknownst to IT. Perhaps there was a help desk call for support of the application, or a sudden request for an interface or report.

"But we don’t use SuperCloud 3000," you might have quipped, only to matter-of-factly be told that not only does the company use it, but it has been deployed for nearly a year, with hundreds of users. Oh, and by the way, it’s now deemed a “business critical” application, and you are expected to support it without any additional resources.

Cloudy times

While the challenge of business units "bringing their own cloud" may seem new and frightening, it’s not unprecedented. Since the dawn of corporate IT, there has been a justifiable impression that IT’s gut instinct to all requests is to say "no." While there are varying degrees of the perception of IT as a "Department of No," there is some truth to the matter, since IT is an entity with limited resources that simply cannot pursue and fulfill every request from every business unit.

In decades past, business units would respond with whatever tools were at hand. That report request IT denied quickly became an extracted spreadsheet, which might evolve into an Access database, which is suddenly a relatively sophisticated application requiring IT support. With the advent of cloud services, this process has only accelerated. A business unit sees a legitimate need, knows IT lacks the resources to fulfill that need, and out comes the corporate card.

Your IT organization likely has had experience dealing with "homegrown" spreadsheets and one-off applications, and many of these same techniques can be applied to BYOC. Here are some suggestions:

Embed thyself

Perhaps the best way to avoid the scenario described above is to embed IT resources in key business units. The most likely suspects for BYOC are marketing and sales, areas rife with cool new cloud-based applications and high sensitivity to new market and technology trends. A monolithic IT organization located a building or even a continent away is unlikely to discover newly acquired cloud applications until they’re well entrenched.

Embedding IT resources in these organizations allows you to have a discussion about the pros and cons of cloud and become a player in the decision making process, rather than the support person called in months later when something breaks. These resources must have a working knowledge of the content area they serve, and should strive to work as consultants and trusted advisors, rather than “spies” from IT.

Get above the cloud

A complaint from many business unit leaders is that their IT counterpart is dragging their feet on offering a comprehensive cloud strategy for the organization. Rather than laying out a road map for how the company intends to integrate cloud technologies and starting the discussion, IT is perceived as behind the times and an obstacle to be worked around, rather than a legitimate partner in the discussions.

If you don’t already have a strategy around how cloud applications can and will be integrated within your organization, and procedures for rapidly evaluating and integrating a line of business cloud applications into your IT infrastructure, you’re effectively opting for a support role after the fact.

If you can’t beat them…

While cloud applications are not without risk, many offer compelling functionality that most companies simply cannot match. For IT, some of these tools present opportunities for cost savings, or even pushing traditional IT tasks (and the associated costs) back into a business unit.

While you may lose some element of control, helping a business unit adopt a cloud application, grooming resources to maintain it, and providing guidance and oversight may be far less costly than building and supporting an in-house application. If nothing else, IT should be experimenting with the latest cloud tools and have a position on how the major players could be integrated with the existing environment.

Just as one-off spreadsheets and databases have created headaches for IT leaders for decades, so, too, will cloud applications forcibly introduce unplanned and non-integrated tools into the application portfolio. IT leaders need to position themselves as knowledgeable, pragmatic businesspeople who can have a rational discussion about the pros and cons of adopting cloud applications. Should they offer only blanket prohibitions, they’ll end up saddled with support rather than guiding cloud strategy.