UCaaS Design: 8 Tips to Make Yours Successful

My No Jitter articles this year will consider some of the key aspects of a successful UCaaS project. These are the things that a salesperson assures you that you don’t need to worry about during a project, but mid-way through, you discover that you do. In February, I addressed testing. In this article, I’ll look at UCaaS design.

 

One of the pitches for a cloud-based service is that they’re fully managed, so all you need to do is sign up and start using them – you don’t need to deal with the complexities of design. From the provider’s perspective, the design is straightforward – connect your endpoints to their cloud and the job is done (see image below).

 

In my experience, this is only true for small deployments. In an enterprise environment, your UCaaS solution will have multiple dependencies and cannot be considered in isolation from your overall IT environment and business processes. The UCaaS design will probably look more like this (see image below):

 

Your provider will deliver their cloud and links to the public network, but the rest boils down to you. Here are eight key design aspects to consider:

 

Consider the type of connectivity you require and how to provide it. You will need connectivity for both data (signalling) and media, and these may not follow the same paths or routes. Is using the Internet for connectivity to the cloud acceptable? In some cases, it may be (e.g. for home workers), but in others, you may want dedicated connectivity— for security purposes and to assure availability and quality of service.

 

Additionally, understand how your provider connects to public networks. In some instances, it may be necessary to keep control of your own carrier services.

 

What level of resilience should be built into each aspect of your solution? You won’t be able to influence the level of resilience (and service availability) inside your provider’s cloud, but the availability offered should be proportional to your requirement. On the surface, services with 99.9% availability and 99.999% may look the same but require a considerably different design inside your provider’s network.

 

Consider the resilience of all on-premises dependencies. If wireless telephony is necessary at your physical sites, then what level of resilience have you built into your Wi-Fi networks? Is the coverage appropriate for real-time mobile communications? For example, do you need coverage in stairwells?

 

How will you identify your users to the service and each other? You will want to integrate with your existing directory service. Don’t assume that this will be trivial. In the worst case, it may be necessary to restructure your directory to meet the needs of the UCaaS service.

 

If your UCaaS service includes telephony, you will need to manage and control your numbering scheme. Is it compatible with the provider? If the number must be ported to the provider, ensure that you will retain control because you may need to take it back at some point.

 

Ensure that you understand the security characteristics how they integrate with your environment. It’s pointless to encrypt traffic if that isn’t honored when it reaches your provider. Similarly, double encryption can result from using virtual private networks (VPNs) which may not be optimal. Consider how your users will sign in. Does the provider support your preferred single sign-on (SSO) solution?

 

Don’t forget about information assurance. Be aware of what data the provider will process as well as how and where it will be stored. Ensure that your information management policies are updated accordingly.

 

Service availability and reliability compose only one aspect of your overall business continuity and disaster recovery strategy. Consider your use cases and their criticality. UCaaS services generally offer strong business continuity characteristics that reduce dependency upon your own infrastructure and, in many cases, the resilience characteristics of the UCaaS service will be sufficient. For other requirements, you may even need to consider alternative arrangements. This could be a small disaster recovery system retained on-site or the diversion of services to other locations.

 

In a large enterprise, it’s unlikely that your UCaaS solution will address all requirements. Therefore, you may need to integrate into legacy systems. A current project for one of my clients requires integrations to around half a dozen third-party systems and services. Some of these are legacy on-premises systems, but others are specialist cloud services. Each integration needs careful design, facilitating the conversations between your UCaaS provider and your colleagues or third parties.

 

We’ve considered the technical aspects of your overall design, but there’s more to it than that. You will need to consider the soft aspects and professional services. For each major project I work on with my clients, we develop specific designs for:

 

 

I can’t address these in detail now. But, in my experience, time spent developing, documenting, and agreeing on these aspects with your provider will reduce issues further down the line.

 

Design is key to the long-term success of your UCaaS deployment. But you don’t necessarily need to apply the same level of detail to all aspects. Use the above as a checklist and decide which aspects apply. In some cases, it may be perfectly acceptable to adopt your provider’s off-the-shelf design. In others, you should take control and ensure that the solution adheres to your overall service and infrastructure standards.

 

Getting the design right is always time well spent and should reduce the likelihood that you will need to rearchitect your solution once it’s in-service, with the resultant risk of disruption to users—and your reputation.

---

"SCTC Perspective" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communications technology professionals serving clients in all business sectors and government worldwide.