Copyright © 2007 Unified-View, All Rights Reserved Worldwide
September 25, 2007
Why UC Needs “Hyperconnectivity”
Art Rosenberg, The Unified-View
Let’s face it! UC is not simple. It is more complicated than just voice telephony or any one particular form of messaging, because it is really a “mix and match’ of multimodal communication capabilities that individual end users will selectively exploit depending upon their personal needs. For person-to-person contacts, this means that both contact initiators and contact recipients will have choices in how they want to (or have to) communicate at any given moment in time.
UC, and it’s unified messaging components, is also forcing the convergence of wired and wireless network communications, because timely communications requires personalized, location-independent, mobile accessibility. This convergence is having a disruptive impact upon how business organizations support their end user UM/UC communication needs with a combination of internal technology and external services. It is also creating a lack of terminology to properly describe new communication infrastructure problems and their solutions. So, I was happy to see Nortel come up earlier this year with a good descriptor for the network problems that UC (and mobility) will be generating. They called it “hyperconnectivity,” which they define as the “state in which the number of devices, nodes, and applications connected to the network far exceeds the number of people using the network.”
This emphasis on providing adequate network capacity for the flexibility that UC will offer end users is probably one of the reasons that Microsoft has strategically partnered with Nortel, because network hardware management is not Microsoft’s cup of tea. They are more interested in the operating systems, business applications and user interfaces that will feed network traffic, and will leave network technology management to the likes of Nortel, Cisco, and other network infrastructure providers.
The “Chicken and the Egg” – What About “UC Traffic?”
While it is indeed necessary to plan for adequate network resources to handle the different types of converged communication traffic that will be flowing between people and application processes (let alone directly between applications), I have to agree with the concerns voiced by UC consultant Nancy Jamison in her latest comment on UCStrategies.com about ”What I Didn’t Hear Much of At VoiceCon.” Apparently there was a lot of emphasis on the future of UC applications and features, ROIs, and interoperability, etc., but little discussion of the impact of “UC traffic” upon network resources and how that will be handled.
To make matters even more complex, because the flexibility of UM/UC will really pay most importantly for mobile users, network resources will have to support all forms of wired and wireless connectivity between different kinds of user endpoints. However, because individual mobile end user communication needs will be dynamically affected by personal activities, their choice of contact modalities (i.e., real-time vs. asynchronous messaging, voice vs. visual text), may fluctuate wildly. This will affect end user behavior as both contact initiators and as contact recipients and change the kind of network traffic they will generate.
This is the problem domain that Nortel is addressing with it’s focus on “hyperconnectivity,” but, no matter what you want to call it, it means that IP networks will have to be device independent, very flexible as to what kinds of communication traffic they will handle, and as to how much capacity and priority they can provide to the various forms of voice and video communication contacts.
The flexibility of UC to enable users to easily choose any method of contact initiation vs. what contact recipients will choose to, can change network usage in two ways. Escalating the response to an asynchronous email or voice message by a “click-to-call” action will increase network demand, while downgrading a voice call attempt to an IM exchange or a voice/text message will reduce network demand. Similarly, converting a voice message to text will make message retrieval and storage more efficient, both from a user productivity and system resources perspective. Listening to a text message via text-to-speech will be convenient for eyes-free mobile situations, while preserving the efficiency of the original text message.
So, how much network capacity will be required to support all of the above? How can the enterprise plan for unknown future network traffic without first learning which users will be doing what with UC capabilities?
UC Applications – Increasing “Speed of Contact” vs. “Ease of Use”
Although the success of UC will be very dependent upon simplifying the user interface for managing multimodal communications, “ease of use” alone will not be enough for efficiently completing business contacts. For example, everyone looking at UC is excited about using a simple visual interface, i.e., “click-to-call,” to initiate a phone call, that is not enough to insure contact. It has always been pretty easy to initiate a telephone call (if you knew the number), but that didn’t mean the call attempt would be successful; in fact, the old statistics that around 70% of business call attempts “fail” might get much worse because it will be easier to initiate call attempts to people who are just not available. With mobile phones, call screening is also contributing to that increase of failed real-time contacts because users who are mobile don’t want to be interrupted by low priority contacts.
As UC industry attention increasingly focuses on satisfying the end user with easy-to-use application interfaces and simple procedures, the importance of “real-time” contacts has not diminished. This is especially true for contact initiators who now have plenty of non-real-time messaging options and will (hopefully) use real-time contacts more selectively when really necessary.
Presence management, along with the single contact approach of UC (“one number”), will be effective mechanisms to facilitate more efficient real-time contacts. This will be true for “person-to-person” contacts (phone calls, “push-to-talk,” or IM), or “instant” group conferencing by voice, video, or IM. This technology approach doesn’t necessarily make the calling procedure easier, but it will speed up successful call connections, vs. failed attempts, particularly for person-to-person call attempts. That, in turn, will increase what I will call the “speed of use” of IP telephony.
Increasing “Speed of Use” for Caller Messages
Legacy voice mail systems emulated telephone answering machines at the recipient’s end of the phone line, because there was no other way to quickly know the availability of the recipient without actually making a call. In addition, there was no good way to send a location-independent message before electronic messaging. (Remember the handwritten pink telephone message slips?)
One of the severe limitations of legacy voice mail systems, however, was that outside callers did not have the same privileges for initiating a voice message to a subscriber’s voice mailbox as another subscriber on the same voicemail/phone system. For one thing, outside callers could not directly access a voice mailbox without first attempting to make a phone call attempt through a voicemail auto-attendant or to a DID number. One would think that with new multimodal “smartphones,” universal email addressing, IP telephony, UC, and presence management, it’s time for a change!
Now that everyone is (1) already using electronic messaging, (2) will increasingly be using multimodal desktop or mobile “smart phones,” and (3) will soon be able to check a recipient’s (call) availability status with federated presence management, there is an opportunity to increase the “speed of use” for caller messaging too. Why should the “smart caller” continue to be at the mercy of a recipient’s “dumb” voice mailbox? Why can’t contact initiators quickly and easily create and send any kind of message as soon as they find out that the recipient is unavailable for a voice conversation?
Because short voice messages are easier and faster for callers to create, especially when they are mobile, voice will remain a convenient form of contact forever. This also applies to the ability to send voice messages as attachments to an email message, rather than typing text. However, retrieving and managing voice messages is still not so efficient for the recipients, and using mature speech recognition technology to convert voice to more manageable text messaging is becoming a new, more efficient “call answering” service for busy users.
Technology developers like CallWave, SpinVox, TalkText, and SimulScribe are driving consumer market interest in voice-to-text messaging through service offerings that provide greater personal productivity efficiency to contact recipients. However, as I pointed out in a previous article, it won’t be long before enterprise organizations will also want to exploit such services to minimize the drain on internal voice messaging resources.
What Do You Think?
You can contact me at: email@example.com or (310) 395-2360.
White Paper on UC ROIs and Transition Strategies
I authored a recent white paper describing UC ROIs and practical approaches to enterprise transition planning that highlight Microsoft’s UC product positioning for simplifying the challenge of evolving to UC. Rather than start with replacing existing wired desktop phone systems, the UC evolution can start with adding IM/presence management, unified messaging, mobile devices, and IP softphones. You can download a copy of the white paper by going to the UC Strategies web site at: