UC Insights Logo
UCI Bannner

Other insights into UC>>

A Definition of ‘Unified Communications’


by Russell Bennett, UC Insights

October, 2010

Leave a comment

There has recently been a lot of debate among the Unified Communications (UC) community on the topic of how to define UC.  The contention is that UC vendors define UC as being whatever it is that they are currently selling.  UC vendors have moved into the UC space from a range of disparate technologies so, as a consequence, their definitions do not align.  I think we can all agree on that.

An internet search on ‘definition of unified communications’ reveals several attempts to resolve this debate, notably in Wikipedia, the International Engineering Consortium, PC Magazine and others.  However, since I have worked in this ‘industry’ for over 10 years, I thought that I should know what it is that I have been doing (or trying to do).  This exercise also seems to be particularly timely as I embark on my new career as a ‘UC consultant’ – so here is my first attempt at defining my terms.

Parsing the term ‘Unified Communications’

“Unified Communications” is a simple phrase, so a dictionary definition based on the component words seems like a good place to start.  According to Merriam-Webster the definition of ‘unify’ is "to make into a unit or a coherent whole: unite".  I think that we all understand that the things being unified are two or more communications modalities, i.e. voice, video, email, etc.  The most apt definition of ‘communications’ is "a system (as of telephones) for communicating".

So if we take the plural definition of communication and add in the definition of unify (converted to an adjective) we get ‘a multi-modal system for communicating, operating as a unit or a coherent whole’.  Once again, I think we can all agree on that.  However, the heart of the debate is in how to define what constitutes ‘a unit or a coherent whole’.

Sticking for the moment with the dictionary approach, I turn again to Merriam-Webster for the definition of ‘unit’: "a piece or complex of apparatus serving to perform one particular function".    So now we turn to the definition of the word ‘coherent’: "logically or aesthetically ordered or integrated: consistent".

So this leaves us with:

'A complex of apparatus providing a system for multi-modal communications, operating as a logically integrated whole’.

Now that I have (hopefully) made my English teachers proud of me – let’s see what my Computer Science professors would have me say about this.

What makes a ‘UC system’ integrated and coherent?

All of the marketing pitches for UC talk about the integration of the silos of communications (i.e. email, telephone, video, instant messaging, etc.) therefore I suspect that there is little debate about that.  So let’s examine what makes a communications silo a ‘silo’.

A communications silo could be defined according to the communications modality that it serves, i.e. voice/telephony, video, instant messaging, data collaboration etc.   By definition, a single modality system can, at best, interoperate with other systems of the same modality (e.g. a voice call from one vendor’s PBX system to another) but it is unlikely to be able to interoperate with a video conferencing system.  While there are some single and multi-vendor multi-modal systems in existence (e.g. voice and video capable PBXs) they are nevertheless silo systems because they don’t share commonality below the communications plane.

Another definition of a communications silo (and the one I propose) is one that has its own distinct mechanisms below the communications plane for authentication, administration, compliance, routing, failover and storage.

Authentication

Authentication is the act of verifying user identity, usually via a credentials challenge, normally at system or session initiation or user sign-on.  Some legacy systems, particularly telephony, did not include this function as the telephone end-point was assumed to be either physically secure or sufficiently ubiquitous that authentication did not make sense.   In any case, the user’s voice usually gives a strong indication to the other user of that person’s identity; if not who they are, then at least who they aren’t.  While personal identification is even easier with video, it is not the case with text based communications such as email and IM and these systems usually require authentication.

The notion of an integrated UC system suggests that there should be a single repository for user credentials and that single-sign on to the entire system should be available, and be mandatory, where that makes sense.

Administration

System administration is clearly an expensive and complex task, especially in a large and physically distributed system.  A unified system should provide the ability to manage configuration profiles, numbering plans, routing rules, ‘moves / adds / changes’, etc. across the entire system, and even remotely (as required) in order to reduce the Total Cost of Ownership of the system.   This concept is closely related to that of centralization – even if the centralized system is actually deployed in a physically or geographically distributed form.

Therefore, an integrated UC system should be capable of being administrated from a single system console from a single location, if required.  The idea of having to separately manage the various UC modalities and to have those management attributes stored in separate repositories seems to be at odds with the notion of the system being unified.

Compliance

‘Compliance’ is a complex issue with different ramifications in different national and industry regulatory environments.  The earliest communications compliance issues emerged in telephony from legislation to support law enforcement (e.g. CALEA) as well as industry regulations that mandated the recording of certain telephone conversations (e.g. in the finance industry).  After physical documents were largely replaced by electronic ones; and after email became a mainstream communications modality, then email also became subject to compliance requirements.

Clearly, those who wish to avoid being monitored regularly resort to non-monitored (and difficult to intercept) communications such as IP telephony.  So the requirement for all communications modalities to support ‘compliance’ functionality is self-evident in an integrated UC system.  Although legislation and implementation is lagging in this area, the requirement for an integrated UC system to have a single compliance system for all communications modalities will make regulatory compliance much easier to achieve.

Routing

System-wide routing management is covered in ‘Administration’ above.  However, user-defined routing can change from hour to hour and is effected in silo systems via functions such as ‘forwarding’.  Self-evidently, a UC system function for user-defined routing should apply to all applicable modalities, including the enablement of ‘unavailable’; ‘unavailable in this modality’ or ‘out of office’ indications.   (However, for more on this, see ‘Presence’ below).

Storage

Much of the functionality discussed above (e.g. administration, routing, etc.) requires persistent storage of various attributes and every silo system has a separate storage function.  In many cases, each individual instance of a silo system has a separate storage function.  To be considered an integrated UC system, the features themselves must be unified; therefore the storage function must also be unified.

Centralization and Resilience

Resilience and centralization are separate concepts – each can be applied independently and apply equally to communications silos as UC systems.  However, the trend towards centralization is occurring in parallel with the trend towards unified communications and the extent and complexity of a UC system requires centralization if the TCO and ROI value propositions can be realized.  Once a mission critical system (such as communications) is centralized, then resilience becomes essential: a centralized outage can impact a far greater number of people than a localized outage.  Therefore, UC systems cannot be allowed to fail without incurring significant business impact.

The maintenance of the communications capability in a failover situation is dependent on a dynamic routing system as well as the replication of all data attributes; especially routing attributes (see Storage above).  Dynamic data replication is a complex and computationally intensive task and must be addressed in a coherent way by an integrated UC system.  Above all, the centralization of UC systems mandates the implementation of a coherent failover strategy.

Modality Switching

At the communications plane, there are specific challenges that have emerged with multi-modal communications that clearly separate a set of communications silos from an integrated UC system.

The earliest communications modality was the human messenger, subsequently replaced by the postal service.  Since then, we have seen the emergence of new communications modalities at an ever increasing pace; each of them developed as a silo, e.g. voice, data collaboration, instant messaging, etc.  As each modality became an essential part of daily life in specific situations, we wondered how we ever did without it.  While these various communications modalities are indispensable in given situations, if the situations of two individuals who are trying to communicate are not aligned or a different modality better suits the situation, then there is a need for modality switch.  For example:

  • You and I are on the phone, but to facilitate our conversation we want to share a presentation or another software application.

  • I am in my office and I want to speak to you; you are in a meeting and can’t take calls, so we switch to instant messaging.

  • I try to start a video conference, but you only have access to audio.

In these scenarios and others, a modality switch, or the integration of two or more modalities is required.  As discussed above, communications silos cannot interoperate; or where they can, this has been implemented as an afterthought and the user experience is awkward and unreliable.  A coherent UC system treats all communications modalities as a ‘session’, with the only variation being the type of media being employed.   The integration of modalities by design in a UC system enables not only modality switching, but also the associated challenges of authentication, routing and the implementation of user preferences during the modality switch.

[For now, I am going to pass on requiring the integration of mobile phones into the mainstream UC user experience.  I believe that the challenges of integrating the products of disparate infrastructure vendors, device vendors and network operators are too great for this to be a realistic proposition – albeit that the mobile UC is very compelling.  Suffice to say that no such offers exist today, and there has to be a good reason for that.]

Presence – the binding agent between modalities

One of the greatest recent innovations in communications (in my opinion) has been the advent of ‘presence’.  The ability to proactively publish one’s willingness and ability to communicate has eliminated ‘phone tag’ and provides an essential function in facilitating situationally appropriate communications in the shortest possible time.  Although presence emerged primarily from the instant messaging space, it is now a key feature that integrates all modalities of UC systems.  

While it is possible to implement a stand-alone presence system that can subscribe to and publish presence information from silo systems – merely displaying presence does not utilize the full power of this feature.  For example, a PBX may have been enhanced to publish ‘off-hook’ status to a presence system to show that a given user is ‘in a call’.  However, it may not be able to consider an ‘out of office’ status coming from the presence server as an instruction to immediately route inbound calls to voicemail, rather than first attempting the customary ‘6 rings’.

I contend that presence, tightly integrated into the user experience and routing rules of every modality, is a hallmark of a UC system.

The UC Platform

The arguments presented above strongly indicate that a UC system must be designed from the ground up, which also seems to remove the potential for multi-vendor UC systems.  While the better UC implementations currently in the market are single vendor systems, the canonical definition of a UC system can probably be summarized as follows: a UC system is built on a coherent platform.   So what is a ‘UC platform’?

  • Is it an operating system?

  • No - because no single operating system works across all components of a UC system – take the desktop phone vs. the PC as an example.

  • Is it a single-vendor implementation?

  • No – because there are UC components in the market from single vendors that don’t interoperate natively and are not built on a single platform; whereas some vendors who have collaborated to implement multi-vendor interoperability by design.

  • Is it one or more UC system sub-components such as a ‘SIP stack’ or ‘media engine’?

  • No – there are many cases of such components from various OEM vendors interoperating well when integrated in different vendor’s systems.

The definition of a UC platform is probably best described as the set of centralized functions that allows:

  • Authentication

  • Administration

  • Compliance

  • Failover

  • Presence

  • Routing

  • Storage

So, does the UC platform have to come from a single vendor?  Certainly, the ones currently in the market that provide the functions described above are, in the main, single vendor.  However, there remains the opportunity for multi-vendor UC platforms to be created from components that present a standard interface, for example:

  • Scalable storage systems with replication (choose your favorite RDBMS vendor).

  • Remote administration systems (choose your favorite System Management console).

  • Single-sign-on systems (choose your favorite LDAP vendor).

Can UC systems be delivered by multiple vendors?

Single vendor UC systems (as defined above) have been the first to market for all the obvious reasons.  However, if UC is to be widely adopted, multi-vendor environments will become the norm:

  • Customers have deployed multi-vendor environments that they aren’t going to ‘rip and replace’.

  • There are already multi-vendor systems in deployment that pass many of the tests described above.

The current challenges to multi-vendor UC systems are:

  1. The absence of a set of standards that result in easily implementable interoperability.

  2. (Note that I am not saying that there is an absence of standards – I refer to that old joke about the great thing about standards being that there are so many to choose from.)

  3. That the pace of innovation in this new space is going to continue to outstrip the creation of standards.

A good example of the latter challenge is the requirement for real-time media to pass through firewalls and NATs.  Clearly this is a general security requirement as well as a common communications requirement.  Yet, other than a set of IETF internet drafts that expired in May 2008, no standards exist and the only solutions available that address this issue are proprietary.

Conclusion

My dictionary-derived, single sentence definition of a Unified Communications system is:

A complex of apparatus providing a system for multi-modal communications, operating as a logically integrated whole.

Digging a little deeper into the problem, a UC system need not be the product of a single vendor, but it does need to be able to exhibit the following attributes:

  • It is built on a platform that provides centralized:

    • Authentication

    • Administration

    • Compliance

    • Failover

    • Presence

    • Routing

    • Storage

  • Routing and session initiation are based on presence.

  • Modality switching and integration is possible without impacting the user experience.

Note that I am not saying that all of these attributes must be exhibited now for a communications system to credibly claim to be a ‘unified communications’ solution.   However, if any missing attributes are not on the product roadmap, it is unlikely that the solution will gain broad mind-share or market share.


If you liked this article, please comment, share and/or rate it below.   If you didn't like it, please comment!

Comments powered by Disqus+