Unified Communications and Disaster Recovery/Business Continuity

One of the key issues in the transition from legacy phone networks to those based on the Internet protocol (IP) is that of reliability. Before organizations began making the jump, they insisted that the new network is at least nearly as dependable as the legacy network.

Business continuity and disaster recovery (BC/DR) is closely related to reliability. The key questions: If there is a significant problem on the network -- be it natural or man made -- what technology and accompanying policies and procedures are in place to keep communications operational? And, if services do go down, what is the procedure for bringing them back online as quickly as possible?

The next step is to consider these issues in the context of unified communications. The question is logical: UC platforms, at some level, tie together most or all of an organization’s communications infrastructure. Thus, an emergency potentially threatens a poorly architected system more than if the services exist in separate and discrete silos.

Questions exist on two levels. The first is whether that premise – that a UC mesh is inherently more susceptible to problems than a standalone – stands up to expert scrutiny. If the answer is yes, the follow-on question is what organizations should do to protect themselves.

I put the question to several companies in the DR/BC sector. The first answers are below. I invite others to offer opinions in the comments section or by e-mailing me.

Specifically, I asked what questions an organization should ask a UC vendor in terms of BC/DR:


Wayne Masoner, unit manager of vRescue, Weidenhammer Systems, offered five areas for discussion:

1. What are the communication needs in the event of a disaster? Are full services required? If not, what services are needed (e-mail, voice, voice messaging, unified messaging, fax, presence, instant messaging, audio conferencing, video conferencing, Web collaboration, single number reach, automated attendant, automatic call distribution, etc.)?

2. Does the DR environment need the same look and feel as the production environment (extension, caller ID, user interface, Automated Attendant, etc.)?

3. How will users access the DR systems (backup physical site, SOHO endpoints, soft phones, etc.)?

4. Will PSTN numbers be redirected to backup sites? If so, how?

5. Are the performance and scalability requirements the same, higher, or lower during a disaster?


Scott Douglass, VP Business Recovery Services for IT-Lifeline, had four areas of concern:

 1. In the event that your primary data center is rendered inoperable (fire, cut communications line, localized disaster, etc.), what is your intent (explain):

a. Failover of critical UC systems and redundant communications that are already pre-provisioned?

b. Fail back to a nonintegrated solution that has the necessary standalone components?

c.  Other

2.  When new systems are implemented, are they planned from the beginning to have redundancy or failover capability?

3.  Are there legacy applications currently deployed in your organization that would not be able to be replicated or recovered? Is there a roadmap to migrate away from them?

4.  What technologies are you currently using for replication?
 

Louis Hayner, the Chief Sales Officer at Alteva, had four main questions: 

1. How does your service provider ensure geographic diversity of their UC platform?

2. How does the service provider handle physical redundancy from their site to their NOCs or cloud?

3. How many upstream tier 1 service providers are they currently utilizing? What type of interconnects are present?

4. Does the service provider separate the call control (SIP protocol) and audio path (RTP protocol)?