Top Task for 2010: Defining Unified Communications
As the year winds down to its final hours and the deal making and product introductions momentarily pause, it is a good time to revisit what is becoming my favorite topic: What is unified communica
As the year winds down to its final hours and the deal making and product introductions momentarily pause, it is a good time to revisit what is becoming my favorite topic: What is unified communications?
Mark Bath, blogging earlier this month at Global Crossing, put this vital issue in stark terms by juxtaposing his definition against the one used by IDC. Bath -- the carrier's IP Product Director -- writes that IDC defines UC “as software infrastructure platform that consolidates directory, routing, and management of communications across a growing set of applications.” Bath, conversely, defines UC as “the use of software to create more efficient communications for a positive business impact.”
Bath may not be aware that he just laid out the dual approach that the UC sector faces -- and that could be a big problem down the road. IDC offers a definition that is rooted in technology and process, while Bath's is based on a result. This is a huge difference. There are processes that could be defined as UC by IDC but not by Bath, and as UC by Bath but not by IDC.
Suppose, for instance, that an IT shop cobbles together a mobile platform that enables an executive to easily communicate with the sales force in the field from within the application. But suppose that the platform is limited to a single form of communications and lacks access to management functions, presence and escalation capabilities. Would it be UC, or just a handy app thrown together by IT?
Similarly, suppose the firm goes out and buys a glitzy bells-and-whistles application – but that it proves to be an inefficient mess that fails from day one. Is that UC? Not according to a strict interpretation of Bath's definition.
Of course, there is a lot of gray area when the technology actually is deployed. But the difference in approach between the two sides – call them the "process side" versus the "deliverable side," for lack of better terms – is more than a matter of semantics. If the distinctions are not recognized and the subtle schism not addressed, the UC category will remain a rather jumbled and imprecise catch-all. (This could also happen to VoIP, which itself is an elemental part of UC.)
My view is that this is a very important question to have on the table, but not one that one side must “win” for the overall category to be healthy. There can be two working definitions of UC. One could be built on a fairly stringent list of tools and processes and the other on a freer approach that simply says that at the end of the day whatever is in place must build communications. As long as everybody knows that the two exist side by side, no problem need exist.