Fred Knight and Marty Parker have had a bit of a debate last month on UC adoption and whether or not there's really any "there" there (See What's Really Hot in UC). I thought I would weigh in given that I've spent the better part of the last six months managing a project to benchmark enterprise adoption of UC that involved our team of analysts conducting in-depth interviews with almost 120 end-user organizations on their UC adoption plans. (I provided some early insight in last month's post; see The State of Unified Communications 2008.)
Fred Knight and Marty Parker have had a bit of a debate last month on UC adoption and whether or not there's really any "there" there (See What's Really Hot in UC). I thought I would weigh in given that I've spent the better part of the last six months managing a project to benchmark enterprise adoption of UC that involved our team of analysts conducting in-depth interviews with almost 120 end-user organizations on their UC adoption plans. (I provided some early insight in last month's post; see The State of Unified Communications 2008.)In reading through the back-and-forth discussion I'm not surprised to see the same points raised that we continuously hear when we talk with enterprise IT executives about their own UC adoption plans; namely confusion over what exactly UC "is", and what are the business benefits. While I think we can all agree that a growing number of businesses are adopting the "elements" of unified communications, the jury still appears to be out on whether they are actually adopting UC.
I think the fundamental problem is there really isn't a "one-size-fits-all" definition for UC. Vendor definitions vary, sometimes, driven more by the need for product marketing pitches to include "UC" as the hot buzzword of the moment. And from the enterprise perspective, there still exists a great deal of confusion over what it means to adopt UC. To some, UC still equals unified messaging. To others, it equals presence, to many, there really isn't a good solid definition.
Absent a single solid definition for UC, we're left with a mish-mash of terms, services, applications and systems claiming to be UC. How can an enterprise know whether or not it is adopting UC if they can't even define UC in the first place!?!?
For me, every discussion around UC lately starts with setting some ground-rules of defining what UC is, and perhaps more importantly, what UC isn't. In my view, UC isn't a product or set of products, rather it's an architecture that integrates products and services into a common framework, sort of like SOA for communication and collaboration. Using the architectural model as the basis for approaching a UC definition, the core component of UC is presence. You can't unify various applications and services unless there is some mechanism for sharing of presence information. The exchange of presence information should be via open protocols such as SIP/SIMPLE or XMPP. Presence can include information such as whether or not someone is currently engaged in a conversation, available for discussion, or even physical location. Specific features continue to vary by product and service, but the unifying theme is that presence should be available across all applications.
Surrounding this presence "cloud" are the applications themselves; voice, video, instant messaging, web conferencing, unified messaging, calendaring, audio conferencing and so on. In a best-case scenario, real-time communications dashboards enable integration of features and control, allowing access to any feature from a common set of desktop, web, or mobile interfaces.
Furthermore, the UC cloud requires integration with external applications, perhaps via gateways such as the numerous communications-enabled-business-process platforms now on the market, or via APIs, or exposed web-services interfaces, all to enable external applications to access communications and collaboration services.
For many organizations, reaching this goal of UC adoption is as much an organizational challenge as a technical one. Implementing this UC architecture that I've defined requires breaking down of silos around application management, telecommunications services, and application developers. It means a great deal of difficulty in establishing the policies, procedures, and approaches to enable an organization to develop a business case for UC adoption. Thus, as we saw in the aforementioned debate, a lot of organizations are implementing the components of UC, while few have reached the level of UC deployment I outlined above.
Only once presence and control integration are established, can one say they are "doing UC." Until then, they may have deployed the components of UC. They may be implementing UC based on a vendor's UC marketecture, but they aren't realizing the real benefits that unified communications presents to break down walls around applications, unify information sharing and user control for both internal and external communication, and tie business process and control applications into communications and collaboration, and ultimately, reduce operational costs, improve efficiency, and contribute a positive return on investment.
