Irwin's post below is a really great analysis of where enterprises are in confronting the issues around Unified Communications. I think he's spot-on when he writes that, "The biggest roadblock we've seen to UC isn't technical, it's organizational."
Irwin's post below is a really great analysis of where enterprises are in confronting the issues around Unified Communications. I think he's spot-on when he writes that, "The biggest roadblock we've seen to UC isn't technical, it's organizational."The task of bringing "voice" and "data" people together pales by comparison. At least in that generation of technology challenge, there was general agreement about what had to get done: You had to get voice traffic running correctly on the "data" network. The challenges had more to do with personalities--not to underestimate how hard such challenges can be, but fundamentally the question was whether the two sides could overcome whatever mistrust might exist and work togther. And in some organizations, that mistrust wasn't even there--the organizations were already functionally merged, or relationships were good or there were people who immediately grasped what had to be done and saw that it was in the best interest of their careers as well as their enterprise to do it.
In the case of UC, the task is a lot more ambiguous. In some ways, the "unifying communications" portion of UC is fairly straightforward: You have the opportunity to combine communications technologies like voice, IM, email, voice mail and video, adding a mobility component as well. This is even likely to become a routine part of the replacement cycle--at some point, you'll simply require that whatever IP-PBX you purchase integrates with Outlook and/or Notes, and it'll be on the users to take advantage of the capabilities (or not). This is not to minimize the potential technical challenges in getting this done, but I don't think the primary goal is difficult to understand.
The other half of the technology that we're calling "UC" has to do with Communications-Enabled Business Processes, or CEBP, which is what Irwin devotes most of the second half of his post to. The issue is which Business Processes do you Communications-Enable, and how do you cost-justify that effort? This is the area where, as Irwin explains, you need a better understanding of what your applications teams do and need.
This may turn out to be tricky because of the shifting dynamics of power and budget in the enterprise technology world. In one of the last issues of BCR, Tom Nolle wrote about the declining influence of the networking folks relative to other areas of IT.
However, I'll go out on a limb here and say that real-time communications has the potential to, if not reverse this trend, at least change its dynamics. If business-critical applications begin to rely on communications, and communications rely on a bullet-proof network, the networking folks take on a new importance. Maybe you're not writing applications, but maybe your role becomes analogous to the role of network security (in the broadest sense of security): A gatekeeper whose vigilance and talents are indispensible to keeping the doors open.
