Wisdom of the CloudWisdom of the Cloud

What I've settled on, at least for now, is that "Cloud," at least as relates to telephony/communications, is only about make vs. buy, and not about technology at all.

Dave Michels' current feature over in the middle column is entitled, "How to Cloud Telephony," and the first thing I grappled with when I edited it was the headline: Is “cloud” the verb in that headline, as in, "how to make telephony more cloudy?" And does rendering telephony cloudier represent a promise—moving to this new architecture--or a threat, as when a particular prospect is said to be "clouding the horizon"?

Ultimately I decided to leave the ambiguity because the topic is still pretty ambiguous. "Cloud" is just like "unified communications," in that it’s a hot term that is so vague that it truly can be defined any way the speaker chooses, and can be applied to whatever the speaker happens to be selling. It is almost empty of meaning, as far as I am concerned, and so Dave’s attempt to define the term "cloud" is valuable not for its potential to attain such an end, but for the ideas that get thrashed out in the process.

What I've settled on, at least for now, is that "Cloud," at least as relates to telephony/communications, is only about make vs. buy, and not about technology at all. Dave may well disagree with me here, and probably a lot of you out there will disagree too, but to me that’s ultimately the only part of the concept that matters for enterprise decision makers. If a service provider, VAR, manufacturer, carrier, SI or anyone else comes to you and wants to provide you with certain functionality that doesn’t require you to purchase the infrastructure and software that hosts/runs that functionality, it's cloud. And when they come to you with that offering, you don't really care where they might be using virtualization, how many servers they've got, what their datacenter looks like. As long as you can get an SLA that promises metrics that meet your needs, and as long as you're persuaded that they can meet that SLA, then it’s a pure build/buy decision.

And I think that's one reason why these services have been slow to catch on in the communications sector, either among providers offering them or enterprises demanding them: For simple services, the build/buy decision was won by premises systems, and in more advanced, complex services, the reliability threshold hasn't been met.

In plain-vanilla voice call control, the IP era's clear winner was the PBX; Centrex, whether IP- or TDM-based, is effectively a non-factor any more. The build/buy equation was purely a cost calculation, and PBXs won.

But one reason that Centrex was only a cost decision is that Centrex, whatever its faults, could at least deliver on its SLAs. For the next generation of services, that reliability has not yet been proven. The question enterprise managers will have to ask themselves is what level of assurance they can have about reliability of the next-gen communications service they’re looking at. We learned first-hand, from talking to end user attendees at VoiceCon Orlando in March, that the risk is widely considered unacceptable today, and will continue to be viewed as such until proof to the contrary is offered.

Then, assuming the reliability hurdle is cleared for newer advanced services, you’ll get into the cost discussion, which will be a conversation about internal resources vs. external costs, capex vs. opex, various manifestations of vendor lock-in, and where business value is located in your enterprise.

That’s all in the realm of "public cloud." Separately, you have the issue of "private cloud." I would suggest that "private cloud" is a completely meaningless term. The term that Dave might use for this viewpoint of mine might be “cloud purist,” but it’s not out of devotion to some holy vision of the "cloud" that I make this distinction. Instead, it’s out of a desire to clear out some of the mess that's been created with this term. "Cloud" is a useful way of describing the public, provider-owned infrastructure in which new types of services will live. Ideally, its internal mesh of connections and its exact contents should be as nebulous and hidden from an enterprise person’s view as the technology’s namesake. That's why we've always drawn the network as a cloud--it's a bunch of stuff that swirls together, the individual strands of its connections eventually proliferating to the point where you couldn’t make out a single strand. And yet it kept an overall coherence with definitive boundaries--demarcations, in old telco-speak.

And so if the provider earns your trust—and that's a big if--it's fine for you if they look like a cloud. Hopefully, your private network doesn’t look like a cloud to you.