Tuesday, March 2, 2010

Going rogue, cloud computing-style: what you can learn by going around IT

I have to say, the San Francisco Cloud Club (#sfcloudclub on Twitter) is a great place to hear good ideas get batted around.

For the uninitiated, the group is a bunch of cloud computing experts, thinkers, and doers from around the Bay Area who occasionally give up an evening for a good discussion/argument or two about what’s happening in this market. (I wrote up one of the previous lively, cloud-filled conversations this group hosted in an earlier post: “Two cloud computing Rorschach tests: ‘legacy clouds’ and the lock-in lesson” for those who want to get a taste for the group’s content.)

As the group is getting ready for an expanded meeting of the minds connected with the upcoming Cloud Connect conference in Santa Clara (March 15-18), I realized that I’m still mulling over an idea or two about the psychology of cloud computing adoption brought up about the during the group’s MLK Day get-together in January.

Big companies will adopt cloud computing very conservatively, right?

Back at that meeting, we spent a bit of time on how companies are actually adopting cloud computing. The difficulty that big companies currently have with the public cloud has been covered extensively. It’s worrisome for them, thanks to things we’ve all heard about, like security, performance and reliability, and lock-in worries. At Cloud Club, we discussed how many orgs, as a result, are (officially, anyway) saying that they want to work on private clouds instead.

But most interestingly, we also discussed the truly amazing tendency that people in even in the most conservative IT organizations have to, well, “go rogue.”

In some of the most locked-down IT environments, folks try innovative stuff on their own, even when it doesn’t meet all of their strict requirements. Why? To help them get their job done in a much better or faster way.

Now that’s interesting.
Several of the Cloud Club attendees talked about “innovation on the edges” of organizations, but even when a company’s party line is to take this cloud thing one step at a time, there are people in the middle of it all trying some pretty aggressive stuff. I’ve heard the story many times of how the developers at Fill in Big Company Name Here had each been racking up independently huge bills (totaling in the millions of dollars if you believe some stories) for services like Amazon EC2 without an official mandate to do so. In fact, in some cases ignoring an official policy not to do such things.

Ah, cloud people do the darndest things.

Despite the rules, cloud computing just might seep in to organizations

After hearing this same story from a bunch of sources, I’m coming to the conclusion that this is the way the adoption of cloud computing is really going to go. It’s going to seep into organizations, like many other compelling technologies and approaches have before it.

A now-old-school example (and the one that I had the most direct connection with) of this organic, under-the-radar type of adoption was the way the BEA WebLogic app server found its way into organizations in the late ‘90s. It was picked up by people (developers) who found it the most useful way to get their concept from idea to working app. BEA and Java rode that wave quite some distance.

And, of course, that approach isn’t unique; open source is all about this. The “freemium” approach requires this same groundswell of interest up front to have a set of targets to upsell.

Is “going rogue” in IT good or bad?

Are “mavericky” installations something to be encouraged – or rooted out? With these projects, you certainly have a chance to apply a very specific solution to a very specific problem. I’ve generally found that to be the best way to see if something works or not.

So, then, the real question will be how organizations deal with these “rogue elements” after the fact.

Some of the rogues will be business owners who wanted to get something that they perceive they cannot currently get from central IT. Others will actually be IT folks themselves, knowing what their restrictions would be if they did things the “right” way, who were trying either an end-run in hopes of getting results that would make people take notice or who actually had at least some sort of tacit approval.

As CIOs and central IT work to get ahead of the issues that cloud computing is bringing, they will have a choice. They can bring the hammer down and punish those who went around the letter of the law to use cloud computing in unsanctioned ways. This has the very real possibility of crushing not only the entrepreneurial spirit of those who tried the new approach, but also discrediting the results they achieved (even if they are impressive in terms of either cost or agility).

Andi Mann’s EMA Responsible Cloud survey talked about this (I can still talk about the survey he ran while at EMA, even though he’s now a CA employee, right? For the record, I’m very happy to have his expertise onboard here and still have great respect for the EMA team). The EMA survey said that these unauthorized “skunkworks” cloud computing implementations showed “all the positive aspects of the pioneering spirit of the wild west cowboy” and can highlight “a valid use case, and help to advance the organization as a whole.”

These rogue implementations “can provide exceptional early stage experience and value. Practitioners attain skills, mistakes provide lessons, and experiences provide a basis for building an enterprise approach.”

How to rein in the cloud computing cowboys

To deal with them, then, EMA noted, “the key…is to recognize when such use cases happen, understand why they happen, be prepared to both take advantage of these opportunities, and be able to pull them back into a Responsible Cloud model when required.”

In my interview with Andi from a couple months ago, he suggested this approach that I liked: over time, these cowboys can potentially become important contributors in a new cloud group within IT, with a mandate to experiment -- to go outside the box. They can start with non-disruptive systems and experimental applications at first, but over time can start to apply their approach to more important systems, too, if and when that makes sense.

“Certainly stomping them out is not the answer,” said Andi. “Instead, by finding out what they are doing and why, you will learn what is broken and how to fix it.”

It’s a delicate balance, but one that can have some interesting pay-offs as organizations experiment – secretly or out in the open – with cloud computing.

If you’re interested in a literal snapshot into the San Francisco Cloud Club discussions, Gary Orenstein posted pics from the January gathering here. You’ll notice I keep my usual very low profile.

1 comment:

William M. Toll said...

Good Points - The groups that move fast have always reached out to outsourced providers. Hopefully they choose reputable companies that bake security into every system and process.