8 Best Practices For Reliable UC
Erratic connectivity will sink your unified communications project. Here's how to succeed.
October 19, 2011
![Network Computing logo Network Computing logo](https://eu-images.contentstack.com/v3/assets/bltde8121fc52c5c8f3/blt3f3d0318f746b1c2/65a530e4187606040a1d8b8c/placeholder.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
Get our report on
Best Practices: Reliable Unified Communications,
free with registration
>> See all our Reports <<
Enterprise UC platforms rarely fail outright. They just stink to use: Voice quality is choppy, and videoconferencing looks like a bad VHS tape. Who wants to talk to customers that way? Nobody. So IT's carefully crafted ROI models are out the window, and the CIO is left in the embarrassing situation of having equipment worth tens of thousands of dollars sitting idle while employees use Skype.
If you're in this predicament, you can make it right. And if you're just starting on a UC project, you can put safeguards in place. Keeping a good UC project from going bad requires a mix of both strategic and tactical steps.
We'll outline some of our best practices here; download our full report for the rest of the story.
Strategic Steps
1. Buy redundancy: If you have to choose between an additional application or a redundant application, choose the redundant one. The primary goal of UC should be that all basic features work well, all of the time.
2. Consider outsourcing: We're 100% behind the cloud model for UC. We see many midsize companies with a few main offices and up to 100 branches or retail sites trying to manage a massive, redundant UC infrastructure and huge IT costs. For what?
3. Define success: What are you watching for with your UC project? How do you define good service? We're talking brass tacks here: allowable latency, maximum dropped calls.
4. Set reasonable expectations: You can have UC success on a modest budget, but don't set yourself up to fail by letting people think they're going to get more than is reasonable.
Tactical Steps
1. Map it out: Want to be amazed? Do a packet capture in front of one of your telephony servers or videoconferencing bridges and let it run for a day. You won't believe all the applications, ports, conversations, and protocols in use. How are you coping?
2. Don't use a separate network: No, really, don't. You'd be undoing a decade of work on converged networks while making your life much more difficult. Believe us, vendors are happy to sell you more switches and routers, and your carrier will be happy to push another circuit on you. Resist.
3. Simplify your QoS: One reason organizations move toward a two-network approach is the presumed complexity of quality of service within a single network that can support UC. It doesn't have to be that difficult. There are some basic steps that will lead to QoS success, such as establishing trust boundaries. Don't be cute; be consistent.
4. Know thy enemy: Before deploying UC of any kind, get very clear numbers from your vendor about the appropriate service levels required for each flow within the application--SIP, Web services, SQL replication, everything that might be part of the end user's experience. You need to know if you're what we call "out of phase" going in. It may mean changing resolutions or getting a different carrier, but know it before you get started, and set expectations accordingly.
Jeremy Littlejohn is president of RISC Networks, a consultancy specializing in business technology analytics. Write to us at [email protected].
InformationWeek: Oct. 31, 2011 Issue
Download a free PDF of InformationWeek magazine
(registration required)
You May Also Like
Maximizing cloud potential: Building and operating an effective Cloud Center of Excellence (CCoE)
September 10, 2024Radical Automation of ITSM
September 19, 2024Unleash the power of the browser to secure any device in minutes
September 24, 2024