Troubleshooting Integration in a Hybrid UC Ecosystem
Before jumping into hybrid cloud, check the dial plan functionality you need.
There are three general types of cloud technologies: hosted, UCaaS, and hybrid. In a hosted cloud environment, the cloud-based UC control system is dedicated to the enterprise, while the endpoints remain under the control of the enterprise, consisting of desk phones as well as softphones on PCs. With unified communications as a service, the entire UC control system is within the cloud provider's infrastructure. The UC system itself is designed to be multitenant, which provides the cost savings that makes this sort of approach attractive to enterprises. As with a hosted model, with UCaaS, endpoints remain within the enterprise, and are often softphones or mobile devices.
For a hybrid model, you get a combination of the above approaches, with a few major enterprise sites using on-premises UC control systems and branches relying wholly on the UCaaS service. A hybrid cloud approach to UC could also be the integration of a calling system with a messaging and video system. For example, consider a scenario in which Cisco Spark is used with Microsoft Skype for Business and WebEX, all integrated with LDAP.
The hybrid UC system is an interesting combination because it uses multiple contact systems that must work together. But with more interworking parts, there is more complexity to manage.
Dial Plan Support
If you're contemplating a hybrid UC implementation, check out the type of dial plans that are supported and whether they will integrate well with your current dial plan. For example, do you depend on four-digit extension dialing within the enterprise? Then you will want to make sure that the cloud implementation also supports four-digit dialing.
In a recent blog, Josh Blalock described Microsoft's Skype for Business Tenant Dial Plans capability, a recent addition to the Skype for Business portfolio that enables businesses to create custom dial plans. He noted that in the initial Skype for Business Online implementation, Microsoft seemed to want users to place calls by identifying the individual, not by dialing a number. The dial plan only supported E.164, or 10-digit dialing. It's an interesting idea to decouple the person from phone numbers. It seems an attractive idea to have the system call by softphone if the parties are on supported networks and call by phone number not. But people have been using phone numbers for so long that we're conditioned to rely on them. Maybe someday we'll be calling by name, and the connection methodology and number, if any, is determined by our phones.
The SFB experiment tells us that we can't ignore dial plans if we want to have features like four-digit extension dialing within the enterprise. That means that we need to check the cloud UC functionality to make sure that it integrates with the enterprise. We also need to make sure that information in one system can be easily accessed by the other systems to create a seamless system.
Everything is great when the integrated UC system works, but there are always times when it doesn't. How do you diagnose problems for those times when it doesn't work? Access to call detail records (CDRs) provides basic call information, and call maintenance records (CMRs) can provide information about problems -- both are useful for diagnosing problems. Make sure the vendors you use have reports that identify voice calls with low MOS (Mean Opinion Score) values. It is very handy to be able to do a "Top-N" report of the top calls that have the lowest MOS value. Equally handy is the ability to show the geography of endpoints with low MOS values. It is very useful to be able to correlate problem endpoints with network topology to indicate a systemic problem such as a missing QoS configuration or a link with high errors.
Can the systems create alerts when something is not working correctly? You don't want to have multiple monitoring systems, one for each product. Ideally, each system should be able to send an alert via a common network management protocol like syslog. Once an alert is identified, a vendor-specific diagnostic tool can be used to complete the diagnosis.
Maintenance, Monitoring, and Management
Don't forget about MACD (move/add/change/delete) workflows. Can one process be used to update the control systems of multiple products? Like the call reporting tools, you don't want to have to repeat a similar process on multiple systems in order to perform MACD functions. There are third-party tools that interface with multiple vendors' systems to provide a single interface for maintenance.
Then there's the problem of integrating reports from multiple systems. You don't want to have three different system reports, delivered only in PDF format, which corporate management insists should be integrated into one report. A manual integration process is definitely not a good process. Insist that the vendors work together to produce the necessary report as part of the acceptance process.
Make sure you understand how to create custom reports. Each system will likely have its own reporting system. Third-party tools may be useful for this function, too. Look for the ability to integrate custom reports from multiple vendors into a single overall report.
A multi-vendor hybrid cloud is a complex system. Spend time to understand your requirements and you'll spend less time working with vendors for things you initially overlooked and potentially settling for a system that's not quite what you envisioned. The savings from integrating multiple products into a hybrid solution should not be offset by increased maintenance, monitoring, management, and troubleshooting costs.