Contextual Services: Answering the Question, "What's That?"
The future is about contextual services, whether we’re talking about humans walking down the street or humans on the job. It’s about providing analysis of information in context.
What would you say if I told you that the whole future of networking; the value of SDN, NFV and even the cloud; the direction UC/UCC should take, could be wrapped up into the answer to a simple two-word question? I'm not asking for rhetorical reasons; I'm asking because it's true. The whole of everything relevant in our industry for the balance of this decade is linked to answering the question, "What's that?"
Someone is strolling down the street, and they see a crowd of people ahead of them. The natural question he or she asks is "What's that?" Is it a line to buy tickets they're interested in? A street riot? Congestion because of a closed sidewalk? Or maybe that same someone is working, checking piping manifolds in a big cabinet. There's a valve there with a tie and a ring that was once part of a paper tag. Nothing remains of the paper. The question that comes to mind is "What's that?"
As we migrate from using desktop systems for resources to using mobile devices to support our lives and our work, we move to a world where everything is contextual, just like the "What's that?" question. People in the world of UC/UCC thought that mobile users' "What's that" needs would be met by putting them in touch with others, so the question would drive UC/UCC adoption, but there are three fallacies at play here.
The first, and most obvious, is that it's far from clear that our worker would have any idea who to collaborate with to answer the question. Collaboration is probably useful in reaching some consensus about an issue, but most productive work doesn't involve that sort of thing. It's the lonely worker in front of the pipe manifold, bewildered by that missing tag. In any event, if we think about what would be needed to answer the question collaboratively, we would have to send a picture of the valve, in context, to somebody. If we have to send a picture, why not send the picture of the manifold to the worker, a picture with everything nicely labeled. You could even have the worker point to the valve and ask...well, you know the question by now.
The second issue that's less obvious is that collaboration is hopeless in our consumer context. Looking at the previously mentioned example of stumbling upon a crowd of people, do we propose to crowdsource the question via Twitter? How many answers will come from people in another part of the city, or another city? How much would it cost for whoever is providing service to zip the image of the crowd over to the population of possible sources of information? Given that, isn't it likely that we'd want to answer the question by drawing on knowledge and context, rather than on human opinion? The cell carriers know how many people are in a crowd and where they came from based on their cell GPS or triangulation technology. They know what's in that location, and they can easily know about things like accidents or riots or ticket sales. An analysis is what we need here, not just opinions.
The third fallacy is the most subtle and perhaps the most important. That "knowledge" and "analysis" is driving some very important trends - trends major vendors are validating. We all know about the big data craze; there's power in being able to sift through volumes of information. We all know about the Internet of Things; having a bazillion sensors tell us everything about our surroundings is the way of the future (after all, Cisco said it was, so it must be true!) How do you square the notion that there's all this knowledge being gathered and stored, and yet we focus communication on asking people stuff? If humans know all the answers and collaborative tools unlock them, why bother with sensors and big data? If sensors and big data know everything, then what's collaboration good for?
The future is about contextual services, whether we're talking about humans walking down the street or humans on the job. It's about providing analysis of information in context. Collaboration is valuable in context but it won't be the center of a worker process any more than it will be of the world of the casually strolling mobile user. That's the good news for the UC/UCC players because it gives them at least a model for enterprise communications in a contextual world.
Suppose our worker in front of the manifold asked "Can you connect me with the person who opened this last?" That starts with "Her-like" natural language processing. It moves to the question of what "this" is; answered presumably by GPS. It then involves doing a data dip for work orders to identify the last worker, and finally requires that worker be checked for connection presence and linked into some conversation. This means that for UC/UCC, the "composability" of communications functions, via API or workflow engine, may be more important than the features of a GUI or the "unification" model itself. But most of all, it means that UC/UCC is driven by work activity; it's not the driver.
That's going to be the hardest pill for the Avayas of the world to swallow. It's hard to develop a big, sticky, UC strategy when you're the tail 'way behind the dog. It's all the harder when the dog is still in its nascent stage. Imagine a UC/UCC salesperson trying to sell the Internet of Things, big data, mobility, and maybe the ability to send real-time queries to public safety databases or online ticket sales points.
But that's what we need for UC/UCC to work, and fortune favors the bold. There are still some UC/UCC players--Cisco and Microsoft come to mind--that could frame enough of contextual services in their own products to make a sales effort worthwhile. For the rest, UC/UCC may have to be more about non-traditional partnerships than business as usual.