Unified comms means a unified technical approach

The very nature of unified communications (UC) with its many component parts – voice, video conferencing, audio conferencing, presence and so on – means that when it comes to scoping implementations from a technical perspective, requirements will necessarily cut across different disciplines.

Precisely for this reason, it shouldn’t be dealt with as just a communications project, or an IT collaboration project, but rather it should embrace the two. If the business is organised around different domains in terms of technical specialisms – networking, server infrastructure, email management, business applications and so on, any scoping exercise will need to draw in the relevant people from these groups. In the absence of this, it will be near-impossible to ensure that all the technical bases are covered.

The underlying architecture is critical to the technical scoping. UC, even the telephony parts, works much better when founded on a converged IP platform that deals with voice, video and data. If the network isn’t optimised for UC, and doesn’t deliver a sufficient level of quality, it will undermine the viability of the whole implementation.

We know that when users have a bad initial experience it can be very hard to recover credibility in the solution. The videoconference industry provides a good example of this. Although it is now carving out a respectable position in the business, the poor user experience in the early days had a lasting impact, and for many years videoconferencing was dismissed by the mainstream as inadequate or irrelevant in a mainstream business context.

Cross platform compatibility with existing systems can also be a potential major concern. As well as paying attention to the core network, consideration needs to be given to any integration points.

UC might be led from one specific domain, but it will need to cross various others, such as email and collaboration tools, with other applications potentially in the mix, if we are talking about more of a structured, process-oriented business context. In addition, it almost, although not quite, goes without saying that UC will need to integrate with the server and storage infrastructures.

In order for these integration challenges to be met and overcome, the company will have to deal with the political and practical challenges that exist in getting the people responsible for each of these areas working together. If this is encouraged to happen, however, it may act as a catalyst to help drive UC forward into the future. It could even help foster relationships and collaboration that may deliver benefits down the line in entirely unrelated areas, as convergence continues to be the watchword in so many areas of IT.

Implicit in this is the necessity to ensure that technical considerations are tied into company needs and goals. This requires knowledge of who will be accessing which systems, for what purpose and from where, as these criteria will have a direct impact on what is needed from a technical perspective. More specifically, it will require segmentation of users into groups, and understanding the usage profiles of those groups.

For example, does a group need to access systems remotely? If so, how frequently, and what level of criticality is placed on quality of service (QoS) for that group. Such information will drive the technical underpinning of the project. Device identification will form a key part of this assessment, and decisions will need to be taken around device refresh or upgrade.

As with any new implementation, issues will arise in certain situations. And while it isn’t possible to anticipate every single one of these, it is worth identifying likely areas, and assessing how these might be dealt with. It may well be possible to address some expected issues as part of the scoping process. A good example could be putting in place more bandwidth to a remote office.

For those issues that are identified but that can’t easily be dealt with, it will give the business the opportunity to prepare, perhaps through extended help desk support, and drawing up a strategy for managing user expectations.

At the end of the day, the enterprise will be working with a new and broader technology set, and failure to properly scope the UC project will, as Murphy’s law so clearly tells us, create weak links in a chain that, once broken, may be hard to repair.

If you’ve deployed UC, what technical challenges did you come up against, and how did you deal with them? If you’re moving forward with UC now, what does your technical planning look like?

Content Contributors: Josie Sephton