Is Avaya Doing Something Interesting?
Virtualizing UC components isn't, by itself, a breakthrough; but Avaya could make a bold move toward the cloud--if it wanted to.
Avaya is pretty well-known in the UC/UCC space as a market leader, but hardly as a leader in innovation. Their recent announcement of virtualization support for their Aura applications is hardly leading the charge for UC virtualization either; competitors have been doing that for ages. But there's something important suggested by the Avaya announcement, and it may (and I stress the qualifier with good reason) even be something Avaya actually plans to do.
Virtualization is really less interesting to buyers of UC tools than the cloud. Running UC on a virtual machine offers some advantages, but running it in a more flexible hybrid cloud would mean a lot more. In my own surveys for the fall, less than a quarter of business users of UC said that virtualization was their infrastructure target for UC/UCC, while almost three-quarters said the cloud was the target.
There is still a major barrier to cloud UC in the Avaya story because Aura runs only on virtualized servers dedicated to UC. That kind of resource specialization makes it harder to use public cloud or even private cloud resource pools; all resources in the pool might not meet that "dedicated" restriction.
Which is what brings up the interesting point in the announcement. What kind of stuff is needed to make cloud UC/UCC not only real but optimal? It turns out that's a question that is being asked by network operators about the broader set of network features. A consortium of operators has created an initiative called "Network Functions Virtualization" to identify and standardize on tools and practices that would allow offloading of network features from purpose-built appliances, and host them instead on generic servers. The interesting thing is that they're speculating that a control tunnel would link the virtualized functions to real devices that would perform the in-network tasks like forwarding and packet inspection.
Think of what this model could bring to cloud UC! There are obviously gadgets associated with PBX/KTS and call-center activity that need to be on premises. If we thought of various voice adapters and other tools as being minimalist devices whose functionality had been migrated to the cloud via control tunnels, then we could eliminate any need to have specialized VMs hosting UC/UCC elements. The hosted elements could contact the associated hardware via the control tunnel.
The same model could make it easier to add capacity; if you needed additional software power you could spin up cloud resources in the geography where you really needed it. That could be a boon for distributed call centers and even for enterprises with multiple regional or national facilities where lots of workers were concentrated. Even if you needed special hardware interfaces for additional connections (to wireline for example) you could add the devices where the wireline connections were cheapest and just tunnel to the control logic in the cloud.
If there were a standard interface for the control tunnel used in this model, then vendors could develop devices to link to the cloud logic. If there were standard APIs used to link the cloud components of the UC/UCC product, developers could build to those standards and extend the UC system. It sounds like a win for UC/UCC buyers and for the market overall.
What makes all this "sounds like" and "Avaya may be planning..." necessary is that this picture may not be seen as a win for the vendors themselves. An open UC market, like any open market, diminishes account control for the leaders, like Avaya. If leading players don't hop onto standard models for structuring UC systems from multiple vendors and multiple components, then who pushes for it? Buyers can ask all they like, but without sellers willing to answer, nothing useful happens. So what might break this logjam?
One possible answer is that group of network operators looking at Network Functions Virtualization. Network and cloud operators have leverage with even the largest vendors, and if those large vendors still don't budge, the interest of a community of giant customers could still be heard by smaller vendors, even startups. A failure of the big vendors to respond could create a cottage industry in truly open UC. We have Asterisk already; if we added in an open solution for cloud-linking specialized UC hardware, we'd have all the tools needed.
That this could actually happen isn't as farfetched as it might seem. Software Defined Networking seeks to centralize the functionality of routing/switching by combining hosted features and simple devices linked with an open protocol (OpenFlow). That protocol couldn't support UC, but it's clearly possible to develop one that could.
Avaya might not have as much to lose in supporting, even driving this sort of effort as it thinks. Yes, open markets don't let vendors pursue high margins and locked-in customers, but it's pretty clear that UC/UCC is already becoming less closed. At some point you have to stop sticking your finger in the dike and focus on swimming with the tide.
I think Avaya has not only reached that point, it's possibly past it. Microsoft's integration of Lync and Skype make it clear that cloud hosting and even cloud-based communications are part of UC's future. Avaya could easily build custom devices to support unique UC interfaces and services, just as it builds "Pods" to provide UC-in-a-box. Why not get bold, really bold, and have a go?