November 2004

Defining Needs: Step Two To Convergence

BY Tony Rybczynski

Enterprises are embracing convergence at the network, communications, and application levels as their business directions, targeting benefits of cost reduction, revenue generation, and productivity enhancement. The starting point in developing a plan for convergence is to clearly identify objectives, either driven by business benefits uncovered in the first step (and discussed in last month’s column), or by explicit triggers such as obsolete switch replacement, new site construction, or Centrex contract termination. The next major step is to define the requirements of your first phase implementation.

Scope the project.
You need to define the scale and scope of the project. Are you targeting some or all users at one, some or all sites? As a result, does your convergence project impact only certain LANs, only certain WAN links, and/or ISP access for remote user access? Answering these questions allows you to size the activity and to understand what parts of the IP networking infrastructure need to be assessed and possibly upgraded. For example, some enterprises focus their toll bypass initiatives on high-cost international links. Rolling out a new site is a local LAN-only initiative. Teleworking initiatives impact only those sites, where gateways between the Internet and the enterprise voice network are required.

Identify implications on organizations with whom you partner for success.
It is now absolutely critical that your project be undertaken with the inclusion of the various IT voice, data, and operational departments, your security prime, and with impacted user organizations. For teleworking projects, for example, the human resources group may be an important stakeholder if teleworker compensation plans are required.

Identify Client Requirements.
Whether you work with a preferred vendor or partner or plan to go through a formal RFQ (Request for Quote) pro-cess, you’re now ready to identify and document your key re-quirements, starting with those of end users. You will need to assess which users should be equipped with wired or wireless IP phones or continue to use analog and digital sets. The general advantage of IP phones is plug-and-play connectivity largely eliminating the costs of moves, adds, and changes; new functionality such as Web data access, through a secure application gateway or phone-based browser; and desktop convergence, making your PC and telephone act as one for enhanced collaboration. Some vendors provide desktop convergence for traditional phones as well. Also ask yourself for which PC and PDA standard operating systems you require soft clients, and whether collaborative multimedia capabilities are needed on top of IP telephony.

Identify Communications Server Requirements.
Communications servers, the heart of any IP telephony system, can be centralized for the lowest cost of ownership or distributed across the network for increased resiliency and performance. In any case, you will need to look at providing site survivability in case of major network disruptions. Communications servers can be standalone, an evolution of your existing PBX or integrated into an office-in-a-box platform (supporting telephony, routing, security, and applications). An important parameter from a security and reliability perspective is whether the communication servers are built on a real-time operating kernel or on general-purpose operating systems with many application hooks and communications interfaces.

Identify Gateway Requirements.
No IP telephony or multimedia system is an island! You therefore need gateways for network access to traditional PBXs and to the public network. These interfaces, often based on ISDN, need to comply with any country-specific requirements. Gateways to existing PBXs should be co-located with these PBXs to avoid T1 backhaul charges, while gateways to the local PSTN are typically distributed to avoid toll charges. With long-distance charges being increasingly distance insensitive, there is a growing case for centralizing the interfaces to long-distance carriers. A question you may ask yourself is, “which users have access to the public network and under what conditions?”

Identify Application Server Requirements.
The fourth component of most IP telephony systems is the application servers. These provide a range of services such as unified messaging, conferencing, SIP-enabled collaborative applications, and customer contact applications. Once again, these can be centralized or distributed across the network. For example, centralizing voicemail can reduce your administrative costs; virtualizing your contact center may allow you to meet customer demands more effectively; and software-based conferencing facility can lower your audio conferencing costs.

Identify Incremental Networking Requirements.
Even before you undertake a detailed network assessment, it is important to identify incremental networking requirements that have an immediate capital impact. For example, Ethernet hubs are a no-no and need to be replaced by Ethernet switches. Switches, routers, and WLAN access points that can’t support quality of service (QoS) also need to be replaced. You’ll have to include the cost of power over Ethernet and backup power for those users that cannot tolerate power outages. If you’re serious about WLAN voice roaming, you’ll have to make sure that WLAN coverage is consistent with this goal. Another area is the WAN: additional bandwidth to support voice and multimedia traffic needs to be identified. Finally, don’t forget new test equipment and the need to ensure that telephony service management tools are provided, including proactive end-to-end voice quality monitoring.

Plan, Plan, Plan… Then Execute.
As you move towards your first convergence project, it pays to plan... and plan some more. Just because you can converge everything, doesn’t mean you should! Understanding where the biggest bang for your convergence dollar allows you to identify and scope your needs appropriately. Now you are ready to execute! This includes assessing your network readiness, choosing a vendor, undertaking a phased deployment (for larger projects) and assessing the results after project completion.

Tony Rybczynski is Director of Strategic Enterprise Technologies at Nortel Networks. He has over 30 years experience in the application of packet network technology. For more information, please visit www.nortelnetworks.com.

If you are interested in purchasing reprints of this article (in either print or HTML format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at [email protected] or by phone at 800-290-5460

[ Return To The November 2004 Table Of Contents ]