The architecture to enable enterprise voice within Microsoft Lync is unique in the UC landscape. More like Broadsoft and Asterisk, less like Cisco and Avaya, the plumbing for Lync involves hardware and software components from various manufacturers. This article outlines some of the pros and cons and the best practices to mitigate risks of this open model.
Microsoft's Architectural Model
More choices, faster innovation, lower cost, freedom from lock-in. The same drivers mentioned by Bill Gates and Jeff Raikes at the OCS 2007 launch are still the case today. Office Communications Server was a software platform, running on VMWare or HyperV, on hardware from Dell, HP, and the like. Choices abounded. Server professionals embraced it, and virtualization-savvy CIOs were intrigued enough to give it a shot.
Six years later, with Lync 2013, Microsoft has stuck to that initial vision. Microsoft develops Lync software for PCs, Macs, and mobile phones, and they created some IP phone software for the first generation of "Lync-optimized" phones. But that's the extent of the major development out of Redmond. Microsoft has left servers, gateway infrastructure, endpoint devices, and complementary software to third-parties--equipment from multiple vendors is necessary in an end-to-end Lync solution.
Minding the Gap
To replace a full phone system (regardless of the vendor), a PSTN gateway and IP phones must be procured and managed. In sophisticated scenarios, third-party contact center, call recording, and reporting solutions may also be necessary.
The natural tradeoff of such a model is that there are multiple throats to choke. Many enterprises want to save money on better communications, but when there are issues, they still expect premium support. Avaya and Cisco customers have a single vendor to deal with and turn to for support of their gateways, phones, patches, contact center software--and in Cisco's case, the IP network infrastructure as well.
With Lync, Microsoft business partners play the role of the one-stop support shop. Enterprises using Lync for dial tone work through a certified support partner as tier 1 to triage and troubleshoot issues. The partner escalates to the appropriate manufacturer (Microsoft, AcmePacket/AudioCodes/Sonus, Polycom/snom, etc.) when needed.
Is the Model Really that Different?
How different these two models really are depends on your frame of reference. The model is new to the mainstream IP-PBX market, but it's common to those who are used to dealing with Microsoft and other software companies. It's the same model of openness that enables Microsoft customers to choose from a variety of third-party solutions for their other applications. For years, you could buy anti-spam/AV for an Exchange environment from Symantec, Barracuda, or others. You can shop around for SQL reporting tools, Windows Server management tools, and desktop monitoring software. ISVs compete for business on cost, innovation, and service levels.
Enterprises' differing frames of reference have led to varying adoption patterns for Lync voice. Enterprises driven by dial tone and contact centers have tended to adopt a much slower transition to Lync voice than those driven by email, cell phones, and text messaging.
Lync can enable IM/Presence, Audio/Video/Web Conferencing, and Enterprise Voice in the same software image. In theory, all these applications could run within a single image and on a single VM, but most organizations install Lync on multiple VMs for high availability. Microsoft doesn't brand the gateways and phones themselves, but does perform significant interoperability testing with interested third parties. Cisco and Avaya can offer the same A/V/Web/Presence capabilities, but in multiple hardware form factors and installation packages. Avaya and Cisco put the same brand name on all the components, but still have various licensing and support risks because the components are quite different.
We would contend that, when a company embraces the full suite of Cisco or Avaya products, the breadth of skills needed to understand and manage the various components is only slightly smaller than the breadth of skills needed in a Microsoft environment. An Avaya Communication Manager expert is not immediately a Session Manager or Avaya/Radvision video conferencing expert. In the same way, a Microsoft Certified Solutions Expert (MCSE) is not immediately an AudioCodes or Polycom expert.
The bottom line is that, to proceed down the UC path, some fundamental experience and cross-training in the various component parts is necessary for an enterprise to succeed. Furthermore, often missed in the heat of the troubleshooting moment is the fact that the UC software and plumbing aren't always the root issue--it may be the surrounding environment. In such cases, the same fundamental issues (power, telco, IP network) are just as likely to cause service-affecting issues in a Cisco or Avaya IP-communications environment as they might in a Lync environment.
All of that said, while the logos on the boxes and CD-ROMs may be different, Lync's architecture is the sum of the same parts that make up an Avaya or Cisco infrastructure, and can be handled similarly.
Next page: Best practices for multivendor architecture
Best Practices for Supporting Microsoft Lync's Multivendor Architecture
Before deciding upon Lync voice:
1.) Understand the moving parts. Not only are gateways, phones, and third-party apps important, but more fundamentally, the IP network, DNS, firewalls, and Active Directory are relevant as well. Get comfortable with the unfamiliar by pounding on phones and gateways in a lab or pilot.
2.) Develop and share your UC strategy for the future. If the Cisco experts within your enterprise think CUCM is the future, while your Microsoft experts think Lync is the future, then unless there is some common management direction that all parties buy into, they may point fingers in a pinch and decrease the solution's efficacy and uptime.
3.) Decide whether to self-manage or outsource as a managed service. Get outside help if you're moving fast and/or currently lack the skills. If you're self-supporting, keep reading on to the next points below.
4.) Get your experts aligned. Retain experts in each aforementioned technology, but pull them together to provide a shared "service" for the end users. Just like in the electricity business during a storm, the linemen repair downed lines, the engineers plan grid reroutes, and operators answer phones to ensure customers that help is on the way. Realign your teams, or at the least, break down the silos amongst Subject Matter Experts. They should commit to providing 99.999% service no matter what the root cause.
5.) Pick your systems integration partners carefully. Picking an SI with a broad portfolio and deep experience ensures your next decisions and investments will be future-proofed. Using a general Systems Integrator who handles Windows, VMWare, and Exchange may be a mistake.
6.) Select the surrounding hardware/software components wisely. No less than five gateway manufacturers have at one point entered the market. Three remain. Even prior to Nortel being acquired by Avaya, the LG-Nortel IP phones were being discontinued. Ensure that the SI partner offers a broad range of gear and offers advice on who is exiting the market and who is investing.
7.) Develop custom SOPs. The first-tier help desk should not always call the Lync expert if there's an issue impacting Lync, because the issue may well be the Hypervisor, the LAN/WAN, or telco trunk. Furnish the help desk with a script and train them to qualify issues and triage them to the correct tier-2 expert (WAN engineer, PC tech, Server SME) to improve resolution time and satisfaction rates.
8.) Get comprehensive, custom training. Effective Lync training for systems administrators is hard to come by. You can find installation/administration training on the market, but once a system is installed, half the training is not applicable. Consider bringing in an expert to help your team understand how to diagnose and resolve issues relevant to your production system, not a lab environment.
9.) Maintain a lifeline to a Systems Integrator that can help in a pinch.
Showing UC solutions to end-users is like giving candy to a kid...they'll smile and ask for more. But the day the service becomes unavailable is the day the dream becomes a nightmare. Whether the issue stems from some multivendor component or an underlying infrastructure issue, using the practices outlined here should get the UC utility back in service quickly and without finger-pointing. If you skip these steps, beware of user satisfaction issues when migrating from a current, dial-tone only system.
