Everyone knows that the big over-the-top (OTT) players like Google and Microsoft (now with Skype) aspire to offer very UC-like services that are hosted in "the cloud". Everyone probably accepts that these services could be a major threat to UC. Similarly, everyone probably recognizes that mobile services and smartphones are creating device-side momentum for a new UC model that would also likely involve the cloud. It sure seems like the cloud is the enemy of UC. Not so. It might even save it.
Arguably, the OpenStack initiative--which is aimed at promoting a broadly supported open model of the cloud--is providing thought leadership in the cloud's evolution. One of the ways it's demonstrated that leadership is in defining an application program interface (API) to control the network services that support applications in the cloud. This API, called "Quantum", is based on a virtual network model that can then be provisioned (by special software shims and components) onto virtually any network infrastructure. This latter process, by the way, may be how software defined networking (SDN) hooks to the cloud.
There's more to Quantum than SDN, though. What's really interesting about it is the way it looks at virtual networks. The current state of the art, Quantum-wise, is that a cloud application's view of any "network" consists of a virtual LAN connecting the application components and also some hosted service processes. A LAN in today's IP world needs a router to connect it to the rest of the world--what IP calls the "default gateway". Quantum defines that element in a model. The virtual LAN also needs to have IP addresses assigned, so DHCP is part of a Quantum model too, and so is DNS for address resolution. The point is that Quantum extends the notion of a "network" from being simply a connection mesh to being a complete service framework.
So why not do this for UC as well? Couldn't we define a UC process as being one of Quantum's existing network models plus some UC-specific components? Could a "virtual LAN" be visualized as a department within an enterprise that has a set of internal rules for connection, linked to other departments in the company by a "gateway"? If so, isn't a directory of users something like DNS? Surely all of the functional elements of a modern UC system could be mapped to this network-plus-hosted-component model.
Doing that would be way more than just an intellectual exercise or a step toward "cloudwashing" UC as a concept. UC as a monolithic, static vision of communication and collaboration can't survive in a dynamic world. We have BYOD issues today, and as mobile devices are enhanced to suit the demands of that highly competitive market, their basic communications services will enhance too.
How are we going to integrate these new services into a monolithic, non-cloud-modeled, UC? We aren't, and a failure to do that sort of integration not only for mobile devices but also for cloud applications, telepresence, and even cooperative editing at the application level will wall UC off from the worker activities where UC's justification must be created and sustained.
This integration process has to start by visualizing UC in component terms--in cloud terms--and then specifying the interfaces by which each of these UC components can be accessed. Even the best of the UC vendors today don't really support an open-component model for their stuff, and there's no harmony at all in how the componentizing might take place. You can't build a cooperative system for UC in the cloud if everyone has a different vision of what the pieces are.
Why aren't we already doing this? Because UC is stuck in the basement, standards-wise. We're looking at low-level protocol specifications or simple application APIs and not at inter-component connectivity or at the hosting of open sets of UC components to be orchestrated on demand by users. I don't think there's even a standards group with the mandate to do something like this. I can't find any meaningful discussions on the topic online either, and vendors aren't pushing the idea in their product material. A few users have suggested to me that they've raised the component-model UC vision to vendors and find that the vendors resist it, preferring proprietary strategies to ones that could promote a user-driven mix-and-match deployment of multiple vendors' elements.
That's the kind of thinking that kills an industry. We are clearly being driven toward a future where all applications will be composed from hosted functional elements, elements that can include UC features if UC is willing to make itself compatible with the software direction overall. If current UC products and vendors don't conform to a cloud-component model, then linking them to more modular applications will be increasingly difficult and other players will step up to fill the gap. Google and Microsoft will certainly be happy to push their cloud UC services in a cloud-component direction. Apple will too, and maybe even Amazon. And then where will UC as we know it end up? A five-dollar app on Apple's store?
UC is a network service, a cloud service, in a conceptual sense. It's an element in getting work done, and as such it has to be framed in the same language as the rest of the application tools that support workers. We can still do that, by opening a discussion on a model of cloud UC. But we've only got a little time left.
