The first thing that struck me about the comment on Robin Gareiss's recent No Jitter post, "Evaluating Cloud UC Costs," was the signoff, which began, "Respectfully ... ." Clearly, I thought, this guy doesn't know how commenting is supposed to work on the Internet.
Then I shucked my cynicism and actually read the comment, which of course was very detailed, specific, and intelligent, as was the subsequent rebuttal that Robin, who is president of Nemertes Research, posted. The two positions boil down to this: Does moving to cloud UC save you money by letting you reduce IT staff, as is claimed by cloud providers like 8x8 (for whom our commenter, Mike Reinhart, was quite open about working)? Or, as Robin writes in her post, based on Nemertes data, will you actually increase costs and keep your IT staff busy managing the new cloud deployment and relationship(s)?
Robin's post makes intuitive sense for the reason that my Enterprise Connect colleagues and I have been hearing for years now, when we ask why enterprises have been slow to move to cloud UC: risk.
"I'm putting my reputation at risk going to the cloud," Robin quotes an IT director as saying. Her analysis: "They took a risk convincing upper management, legal, and the security team to move to the cloud. Consequently, the rollout needed to be flawless." To guarantee that flawless rollout, Robin says, "IT leaders are devoting an abundance of resources to the rollouts." That keeps costs higher than they'd be if IT tried to slash headcount, but the risk in the latter case is unacceptable.
I've written recently about how cost may be less of a factor than agility when it comes to driving discrete cloud projects. I think this trend favors cloud providers with a platform-as-a-service (PaaS) model, like Twilio and Genband. Going to the cloud to quickly deploy a specific feature or function, while still controlling the enterprise's core communications service, is less of a risk than porting your whole communications infrastructure to a cloud provider -- especially if the move to a full hosted system is accompanied by an assumption that, in the short term, you're expected to make major cuts in headcount now that an outsourcer is running your network. Adding a feature here or there risks neither the stability of the entire communications system, nor the adequacy of the staff support levels.
When Zeus Kerravala, founder of ZK Research, and I moderated a plenary session on the cloud at Enterprise Connect last month, Zeus ribbed Bryan Martin, 8x8's chairman and CTO, by suggesting that 8x8's hosted-PBX/UC model represents a "transition" to the PaaS model of fellow panelists from Genband and Twilio. Bryan of course pushed back against that notion, and he was right to: Among other things, there's no reason a company like 8x8 can't offer both models -- hosting the full UC system, as well as offering hosted APIs for enterprises that only want to do more limited integrations.
And looking at the cloud market overall, I have to think there will be demand for both: Some companies are finding a justification for moving their entire PBX/UC system to the cloud; within that model, some may be going with the belt-and-suspenders approach that Robin describes when it comes to staffing levels, while others may have been able to reduce staff, as our commenter Reinhart suggests. Still, when you look at the research houses' projections for this market, they don't get too far above the traditional 10% share that we know from Centrex days. Then the PaaS players will take another chunk of the market. Altogether, at some point, a majority of enterprises may be hosting some piece of communications functionality in the cloud.
But positioning cloud as winning or not winning is a religious dispute, or semantics. It's a tool in the toolkit, one that enterprises are increasingly interested in trying out. How much they use it, and whether it radically changes the composition of the internal staff that supports communications, is likely to vary with the enterprise.
Follow Eric Krapf and No Jitter on Twitter and Google+!
@nojitter@EricHKrapf
Eric Krapf on Google+
