Deciding What Hybrid Cloud Communications Means to You

I have come to believe that technology jargon has a higher purpose; it gives IT folks something new to banter about. When the term “Cloud Computing” arrived, immediately the definition was stretched, vendors rebranded products and were then accused of “Cloud washing.” Cisco got in the game by declaring systems with processes dependent on the endpoints to be “Fog Computing.” Let’s not count the “cloudy” weather forecast analogies used for predicting trends in the cloud! Fortunately, there are concise, standardized definitions of cloud service models: Private Cloud, Community Cloud, Public Cloud, and Hybrid Cloud. This extends itself to the subject at hand, cloud communications.

Private cloud communications are usually just UC systems that are sold to an enterprise for use in its own data centers, often extended to branch offices. Most scalable on-premises UC systems use this architecture. Public cloud communications can be deployed as a single hosted instance of a communications system, or a shared tenant UC system with many enterprises subscribing to the unified communications system as a service (UCaaS). Hybrid Cloud Communications is trickier. The National Institute of Standards and Technology (NIST are the folks who gave us the three service deployment definitions) says the standard definition of a hybrid cloud is a “composition of two or more distinct infrastructures that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability.” This definition works for survivability and resiliency, but out in the trenches, there are much looser definitions being presented to the Enterprise customer as hybrid cloud communications. This is not disingenuous because it accurately reflects communications solutions that are deployed on more than one infrastructure. For business decisions, I propose categorizing the hybrid models based on the main requirements that drive a hybrid business communications decision process: Logistics, Survivability, and Functionality.

Logistics drives the service model decision when there is a blended combination of locations or resource requirements. Often an enterprise headquarters may already operate a data center and have the internal expertise necessary to support customer-owned equipment. However, remote or global branch locations are not easy to support and are better candidates for hosted or public cloud services. The usual strategy has been to deploy a private cloud solution and extend business communications to the branches from the company data center, giving the enterprise the “phone company” role. This is no longer the only available option. Many public or hosted cloud providers can tie on-premises UC systems to a CaaS deployment at a branch.  The advantage is that the branch is no longer dependent on the central data center as their phone company. This can reduce the need for redundant branch equipment and local backup services. Since the branch is a CaaS solution, break/fix support is no longer dependent on centralized IT staff with limited visibility to the issue and time zone delays.

Survivability as a cloud service model requirement drives a hybrid solution when there are critical communications that require either limited or complete survivability on premises. Often it is not cost effective to replicate advanced processes on premise, including reporting or speech recognition, but it is simple enough to provide dial tone and call routing with a subset of the UC system functionality. This most closely represents the NIST definition of hybrid cloud computing as applied to cloud communications. Survivable equipment can be the best and worst of both worlds. An enterprise can still maintain dial tone and critical services, assuming the local Telco is not also impacted by the outage incident. The tradeoffs are additional efforts to synchronize the systems, additional equipment that sits dormant during normal production and additional Telco services. Survivable hybrid systems add another layer of resiliency but take away some of the agility that customers seek from cloud services.

Functionality-based cloud decisions are driven by a blend of functional business communication requirements that are served better or more economically in diverse service models. For example, you do not need an artificial intelligence knowledge domain or natural language processing for your break room phone (at least not yet), but you do need to be able to dial 911.   There are cases where the on-premises telephony system works fine, and many large enterprises are reluctant to pay for unused features for every endpoint of their system. In other cases, integration with a non-voice SaaS application or small point solutions make it more effective to deploy a CPaaS (Communications Platform as a Service) solution to deliver advanced features. Large organizations with smaller contact centers are a classic example of this. Sometimes the public cloud system is tied into on-premises UC, and other times the enterprise is content to operate the systems independently. Text messaging is yet another example; with the ability to now have a different carrier of record for your voice networks vs. SMS, it is no longer necessary to migrate Telco services to a vendor that provides both services.  A separate service provider can SMS-enable the same phone numbers in use on a legacy telephony system. 

Many enterprises are a long way off from having no core equipment on premises and there are a good number that will never operate without some data being managed within their own infrastructure. Conversely, very few enterprises will have zero applications deployed in a non-private cloud environment. For Business Communications, this “requirements first” approach to developing a cloud strategy is an effective way to leverage the best that each service model has to offer.