Even though your cloud UCaaS service may be a standardised managed service, you can’t ignore design. Below is 4C Principal Consultant Dave Mailer’s article on why design is important and how to get it right.
This year, I’ve some of the key aspects of a successful UCaaS project. These are the things that the salesperson assures you that you don’t need to worry about. But, mid-way through the project, you discover that you do! In February I addressed testing. In this article I’m going to consider design.
One of the pitches for a cloud-based service is that they are a fully managed service, so you simply need to sign up and start consuming services – you don’t need to trouble yourself with the complexities of design. From the provider’s perspective the design is simple – as simple as this!
All you need to do is connect your endpoints to the providers cloud and the job is done.
In my experience, this is only true for very small and very simple deployments. In reality, in an enterprise environment, your UCaaS solution will have multiple dependencies and cannot be considered in isolation of your overall IT environment and business processes. The design will probably look more like this:
Your provider will deliver their cloud and links to the public network, but the rest is down to you. What are the key design aspects that you do need to consider?
Consider what connectivity is required and how it will be provided. You will need connectivity for both data (signalling) and media, and these may not follow the same paths/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, both for security purposes and to assure availability and quality of service.
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 considerably different design inside your provider’s network.
Consider the resilience of all on-premise dependencies. If wireless telephony is necessary at your sites, then what level of resilience have you built into your Wi-Fi networks, and is the coverage appropriate for real-time mobile communications? For example, do you need coverage in stairwells?
Identity and Directory
How will your users be identified to the service and each other? You will likely wish to integrate with your existing directory service. Don’t assume that this will be trivial. In the worst case it may be necessary to re-structure 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 it is to be ported to the provider, ensure that you will retain control. You may need to take it back at some point in the future.
Security and Information Assurance
Ensure that you understand the security characteristics how they integrate with your environment. There is little point in you encrypting traffic if that is not honoured when it reaches your provider. Similarly, double encryption can result from using VPNs which may not be optimal. Consider how your users will sign in. Does the provider support your preferred SSO solution?
Don’t forget about information assurance. Make sure you are aware of what data will be processed by the provider and how/where they will store it. Ensure that your information management policies are updated accordingly.
Business Continuity and Disaster Recovery
Service availability and reliability make up only one aspect of your overall BC/DR strategy. Consider your use-cases and their criticality. UCaaS services generally offer strong BC 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 DR system retained on site, or the diversion of services to other locations.
In a large enterprise it is unlikely that your UCaaS solution will address all of your requirements. You may need to integrate to 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-premise systems, but others are specialist cloud services. Each of these integrations needs careful design, facilitating the conversations between your UCaaS provider and your colleagues or 3rd 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:
- Operations, Service and Support
I can’t address these in detail now but, in my experience, time spent developing, documenting and agreeing 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 are applicable to your deployment. 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 is in-service, with the resultant risk of disruption to users – and to your reputation!
To find out more, contact 4C Strategies today on 01858 438938, or email firstname.lastname@example.org.