I came away from the session I moderated on Cloud-Based Communications with a useful, concise definition of the difference between "private clouds" and "public clouds."Like so many other definitions of emerging trends in this industry, this one may not stick and it may not even be something that people outside our session room choose to adopt, but it worked for me. The question before my panel--George Humphrey of Avaya and Paul Liesenberg of Cisco--was what exactly the term "private cloud" means in the context of a discussion of cloud computing. What's the difference between a private cloud and the old-fashioned term, a WAN?
Paul made a nice distinction: A "public cloud" service is one in which every element of the service resides in and is owned by a service provider--applications as well as network infrastructure. In contrast, Paul's definition of a "private cloud" is one in which the enterprise retains control of the WAN infrastructure, but is accessing services and/or applications from a public service provider. I guess that would make a "private cloud" somewhat close to the term we included in our session title alongside "cloud communications," namely, "Communications as a Service."
The need for these fine distinctions arises, of course, because the cloud is a hot technology trend overall for the enterprise. Interop has been chock-full of Cloud programming this week, and my panelists agreed that the cloud would affect your communications--in fact, said Paul Liesenberg, "The ship has already left the port. It's happening."
One problem is that what's happening, right now anyway, is a lot of ad hoc use by individual employees or maybe departments; George Humphrey used the example of how sales departments started using Salesforce.com without really getting anyone's permission, as a model for what's happening in communications. Right now, that doesn't mean your employees are going out and using a cloud service to replace the functionality of your PBX, but it does mean they're using Skype, and they're using social networking, which is a cloud-based service that can and will be integrated with communications systems.
"We haven't taken social networking seriously, because it looks like a toy," Paul Liesenberg commented. That will have to change.
Cisco clearly has a lot to gain if cloud communications takes off--"For Cisco, there could be nothing better than new applications using the network," Paul remarked.
However, he was quick to admit that real-time applications, especially video, are not particularly well-suited for delivery over the cloud, or at least over any cloud that includes an unmanaged portion, i.e., the Internet. George and Paul both agreed that if and when cloud-delivered real-time services emerge, your job will be to monitor SLA compliance, rather than delving into the guts of the how the provider cloud actually delivers the service.
Ultimately, the model for most enterprises is going to be some sort of hybrid, George Humphrey predicted--you'll retain control and ownership of those elements of the infrastructure and application layer that make the most sense for you, while using cloud-based services either to augment this architecture, or perhaps as a proving ground for new applications, as a way to get a service up and running quickly, or to shift a particular communications capability into the opex category and away from capex.
We had a very engaged audience, and several of the questions dealt with internal organizational issues for enterprises that explore cloud-based communications. One audience member asked if using cloud-based services introduces yet another layer of organizational challenge, as the telecom and IT people now also are likely to have to interact more directly and effectively with those who procure telecom services. The answer to that question clearly is yes, that will be a new challenge, and our panelists encouraged greater cooperation among all of these enterprise folks, as well as the application development teams. The problem is, that's really about all you can do, is tell people to work together better. Whether that happens or not is likely more of an execution and personality question for the particular enterprise.
Another questioner asked whether moving from CPE to cloud based communications would mean just trading one form of vendor lock-in for another--i.e., once you start building your business processes around one vendor's product, the cost and pain of changing to a new vendor often renders the change unappealing if not impractical. Won't that be just as true if your processes are built around a packaged service provider cloud communications service, as it was when you committed to a PBX vendor? Once again, the short answer is yes, and the slightly longer answer is that, while this certainly is a risk, it's hard to really predict how to deal with it since cloud offerings are still in their infancy.
