Rethinking IPT/UC ArchitectureRethinking IPT/UC Architecture

Evaluate both centralized and decentralized models, as well as options for hybrid approaches.

Forty-three percent of companies rely on a centralized architecture for IP telephony and unified communications systems, meaning that IP-PBXs largely sit in the data center (or data centers), versus in regional clusters in major geographies, or distributed servers at most locations. This dominance of centralized approaches mirrors consolidation in recent years of other applications into the data center to save money, improve resiliency, simplify management, and ease integration. From a IPT/UC perspective, centralization offers simplified system management, better support for application optimization, and the ability to tie IP-PBX resiliency architecture into disaster-recovery plans. Having IPT/UC servers co-located with other application servers can ease integration challenges as well by taking WAN bandwidth limitations and latency between servers out of the equation (though it adds to the need for WAN performance management).

Another key driver leading to centralization is SIP trunking. As companies look to deploy SIP trunking to reduce PSTN access costs, they often find it easier to centralize those trunks at the data center, where they can leverage existing high-speed access circuits, or minimize the infrastructure, such as session border controllers, needed to meet SIP trunking security requirements. We’ve seen a direct correlation between SIP trunking and desire to move to a more centralized model for VOIP/UC infrastructure. Drivers here include the ability to save money by removing PSTN access connections at each location in favor of a centralized trunk, the ability to centralize dial plans to improve management or implement a company-wide dial-plan, and the ability to leverage a SIP trunking service provider to load balance incoming calls between major locations. Longer term, several IT leaders told us that they believe that the centralized model lends itself to secure B2B connectivity in the future.

Drivers for centralization are often are a chicken and egg situation. In some cases server centralization initiatives drive trunk centralization, while in others trunk centralization drives server centralization. In one example, a national professional services firm saw value in consolidating its numerous, independent IP-PBXs into the data center to reduce management costs and more easily support a roll-out of enterprise-wide UC by relying on a single presence and feature server for the entire company. In another example, an organization with large in-bound call flows to multiple global data centers centralized toll-free in-bound access into their primary data center to enable intelligent call routing over their WAN.

As companies centralize their architecture, they often look to more closely tie SIP trunking service procurement into their overall WAN strategy. Indeed we advise our clients to consider a matrix approach for their WAN RFPs, giving each service provider a table to complete: services (e.g. MPLS, Ethernet, SIP, wireless) on the left, regions across the top. This allows procurement managers to easily determine what services a particular provider can deliver, and where. By dangling the "carrot" of a wider array of potential services, we find buyers can achieve lower overall contract values versus procuring services independently.

Another benefit to centralization is that it prepares the organization for the eventuality of moving IPT/UC infrastructure to virtualized servers (see my recent post on UC and virtualization). A centralized architecture also sets the stage for potential future migration to hosted services since remote locations are already set up to connect to a remote call/feature server. Adoption of hosted VOIP services has climbed to over 13%, up from around 5% in 2009, and we continue to hear of a growing interest in evaluating hosted services to reduce infrastructure investments and ongoing maintenance costs as the key benefit of a hosted model.

So what keeps architects committed to a distributed or regional deployment model? The two biggest factors IT leaders cite are:

* Greater organization-wide resiliency by not having all their IPT eggs in one basket. A server failure only impacts the location(s) dependent on that particular server, minimizing impact.

* A desire to minimize capital costs--a distributed model allows you to add infrastructure only as you need it for more sites, rather than committing to building out capacity for thousands of users prior to migration.

Finally, it's important to remember that there are hybrid approaches thanks to SIP session management or various capabilities offered by individual vendors. For example, one regional financial services told us of their desire to leverage distributed servers to keep infrastructure costs lower, while they centralized access to the PSTN through their data center. Their IP telephony vendor easily allows them to route calls to remote locations, even though each location has its own call processing server. Thus the choice between centralized and distributed isn’t always one or the other.

Enterprise telephony/UC architects should evaluate alternative deployment architectures, paying special attention to requirements including cost minimization, resiliency, application integration, support for server virtualization, and future plans to leverage hosted services. Evaluate both centralized and decentralized models, as well as options for hybrid approaches.