Software-Defined UC: Way Overdue

Thrown around a lot lately, the term "software defined" has come to mean many things to many people. It's been applied to networks, data centers, WANs, and other IT areas. But to unified communications? Not so much.

Among the multiple descriptions for software-defined whatever are a couple of points of commonality for each of these scenarios. They are:

• Separation of control and hardware. At a high level, software-defined means having the ability to extract the control plane from the underlying hardware platform. Historically with IT infrastructure control tied directly to the actual box. If a network manager had wanted to make a change to 100 routers, he would have needed to log into each of the devices one at a time, making the same change over and over and over. With software-defined networking (SDN), control of routers and other network devices is abstracted up a layer.
• Centralized control and management. One of the many benefits of having things run in software is that the application can run virtually anywhere -- locally, across the network, or even in the cloud. One of the key principals of SDN is that the control, now extracted from the hardware, is centralized for easier management. In the above example, instead of having to touch all 100 routers, wouldn't it be ideal if the network manager could apply a single command at a central for propagation everywhere? Many vendors have developed a physical controller for the centralization of control, but that isn't necessary. As two examples, Avaya's Fabric Connect and Aerohive Networks' HiveManager for wireless LAN management provide centralized control absent a physical box. Rather, the centralized control is distributed across the network, giving IT a "virtual" controller. In either case, centralized control is the key.
   
• Automation and orchestration of configuration parameters. There's no point in software defining anything unless the system has automation and orchestration capabilities. Manual configuration processes are slow, laborious, and error prone whether they are centralized, embedded in the hardware, or software based. The system should be able to interpret business logic, create a policy, and then apply it to the various systems in an orchestrated way.

In the UC market, the lack of a software-defined model creates big headaches in large environments. Most of the UC vendors have done a great job in enabling centralized control for many operational tasks, including provisioning phone and quality of service (QoS) settings on the network. However, enterprise communications managers still have to handle hundreds of tasks in a repetitive manner, particularly when migrating from legacy systems.

When it comes to migrating from an existing system, legacy or otherwise, to a new UC solution, the process can be overwhelming because of the amount of data involved. Users with multiple devices require multiple configuration settings that cut across voice, video, messaging, presence, chat, mobility and other systems. I've talked to engineers who have done large-scale migrations that end up entailing well over 200 configuration settings per user with data spread across a dozen or so systems. Now add in multivendor environments and cloud UC, and you can readily see how UC management can get exponentially more complex.

If all of these functions could be abstracted up from the underlying core systems, then the provisioning and orchestration of the features could be fully automated – the very definition of "software defined." Ideally, the platform would take in business inputs as a way to build the policies that are then used to configure the system.

Read the rest of the article on No Jitter.