Will the Moving Parts of Microsoft Lync be a Problem for Enterprises?
Lync Voice involves Microsoft, and also Polycom, and AudioCodes, and so on....
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