Well, it depends. But incorrect assumptions or fear of complexity should not be a reason to avoid considering Lync for your next voice solution.

Microsoft Lync is often accused of being complicated. But in fact, Lync is no more or less complicated than comparable UC solutions. The challenge becomes taking the time to understand the various solutions sufficiently in order to conduct a fair comparison.

My colleagues Dave Michels, in his Lync Licensing: Effective Confusion article, and Matt Brunk, in his Understanding Lync article, have focused on some of the complications that may be encountered when trying to implement a Lync solution. As a counterpoint, I wanted to explore the perceived architectural complexity of Lync.

I spend a good portion of my time helping organizations assess and determine the best communication and collaboration solution according to their specific needs. Over the past year, this almost always has included comparing a more traditional voice solution from Cisco, Mitel or Avaya to Microsoft Lync.

In order to perform a fair comparison, you need to determine your critical business requirements and then look at a variety of viable solutions, and assess which best can meet these same business requirements. I have previously outlined a detailed approach you can adopt to complete this comparison process, in the article The Goldilocks Approach: 7 Steps to Get to "Just Right". The key element, if you intend to compare Lync with other solutions, is that each solution reviewed must be configured to meet the same business requirements.

If someone is trying to push a more "traditional" voice solution, it is easy to confuse the issue by repeating partial truths about the large number of physical servers a Lync solution requires. While this might drive the sales efforts, it is often not accurate nor does it serve the end customer. Often Lync solutions are said to require more servers because the Lync solution is architected to provide more functionality than the solution to which it is being compared.

A complete Lync voice solution (aka PBX-replacement) for a small office can be deployed on a single physical server. This single server (physical or virtual) would run the Lync Front-End Server role and would also run the Lync Mediation Server role. This server could then be connected to the PSTN via a SIP Trunk. Even this simple single-server Lync deployment offers more UC features than many traditional PBXs: instant messaging, presence, audio/video/web conferencing.

Best practices would dictate that adding voice mail to a Lync voice solution would require an additional physical server. This server would need to run Exchange roles and the Exchange Unified Messaging role, which provides voice mail.

If you choose to use PRI/T1 connections to provide connectivity to the PSTN, you would require a separate physical hardware gateway on which to terminate the physical PRI connections. This is not required when using SIP Trunks, although for other reasons (e.g. security or scalability) you may choose to use a gateway device even when using SIP trunking to the PSTN. Various vendors manufacture Lync-compatible gateways including AudioCodes, NET, Dialogic and others. See the Microsoft Unified Communications Open Interoperability Program website for further information. Many of these gateway devices allow you to run the Lync Mediation Server directly on the gateway, should you choose.

The Lync edge server role also is required in order to support remote users and to federate with other organizations who run Lync or OCS. Federation is a key feature that many organizations choose to implement when deploying Lync, and quite frankly one of Lync's most compelling features. Federation allows you to share IM, presence, voice, and video communications with key partners, suppliers and customers. I recently declared 2012 as "The Year of Federation" (see 28:00 time mark) and noted that recent efforts at The Lync Federation Project by Matt Landis and www.lyncdirectory.com provide an indication of the thousands of organizations worldwide who are encouraging and supporting federated communications. Best practices for security would have the Lync edge server role deployed on a separate physical server in the DMZ (the perimeter network). Note that this requirement for a separate server/device would be also be present in the case of a Cisco solution.