Update: I’ve sheathed my sword a bit and toned down parts of this post because I was a bit of a fire breathing dragon.
Chris Norman has written a fantastic post over on his blog titled Lync Native Features Versus Plugins: Where Does The Real Complexity Reside?. It’s squarely aimed at third-party Lync call control applications like Cisco’s CUCI-Lync (Cisco Unified Communications integration for Lync) and Avaya’s Microsoft add-in built on their ACE (Agile Communication Environment) development platform that take away out-of-the-box voice and video functions from Lync and cripple the product.
Having deployed CUCiMOC first hand and seen it and CUCI-Lync in action, I can say that this type of integration scenario causes infrastructure and client management problems not to mention user experience issues.
I’m going to focus on the Cisco integration in this post, I’m going to pull a few references out of my Cisco Integration Scenarios document I wrote earlier this year here to wax lyrical about this for a bit.
Why would I want to deploy CUCI-Lync?
I’ve done the due diligence and cost/benefit analysis before, and I do appreciate why you’d want to use a PBX vendor provided client side integration scenario. Here’s a few reasons:
- Utilise your existing investment in Cisco Unified Communications Manager, not to mention the large estate of Cisco handsets you probably own.
- CUCI-Lync provides remote call control of Cisco handsets without Cisco Unified Presence Server (CUPS) – a typically difficult piece of kit for even a seasoned Cisco Voice professional to deploy.
- Utilises Instant Messaging and Presence functionality provided by Microsoft Lync Server 2010.
- Doesn’t require Lync Plus CALs for voice functionality.
- Gives the end user the option whether to use a soft phone (Cisco IP Communicator – part of CUCI-Lync) or their Cisco desk phone to make and receive calls.
Adding Unnecessary Complexity
Everything in that bulleted list looks like awesome, low hanging fruit doesn’t it? Get all the cheap benefits of Lync and still use Cisco for voice. Thumbs up right, game on?
The reality here is that there are a bunch of sacrifices you need to make to achieve this. Like these:
- No native remote user access capability – CUCi-Lync requires VPN connectivity to log in and cannot leverage the Lync 2010 Edge Server to allow for remote voice use.
- Adds an additional application to your desktop image to maintain and contributes to the suite of applications your helpdesk team must support.
- No central management methodology – settings for CUCI-Lync are configured client side manually via the Windows registry or using Group Policy.
- Cannot federate media with external organisations. Federation is only available with IM/Presence via the Lync Edge Server.
- If you want audio/video/web conferencing, you need Cisco Meeting Place for this (another licensing cost).
- Finally, the user experience is confusing.
Luis Ramos has another good review here of CUCI-Lync from his lab. From what I’ve seen and from what you can tell from the screenshots, the plugin looks and feels buggy, and doesn’t respond as snappily as Lync does.
The User Experience is Paramount
Weighing up everything that the PBX vendors harp on about not having to pay for Lync Enterprise and Plus CALs, utilising your existing PBX investment etc.. at the end of the day the key to the success of your UC deployment is the satisfaction of your users.
You’re deploying Lync to receive the benefits of a robust, clean and functional UC solution. If you introduce an additional user experience layer on top of that that requires users to learn slightly different ways to achieve different things, written by different companies, you will encounter significant resistance.
And what do we know about user experience? If it’s terrible, users will throw your solution back in your face. Which means your project has been a failure. That money you saved not buying Lync Enterprise or Plus CALs doesn’t matter now.
Has anyone actually heard of this being deployed in production at a company? Let me know in the comments.