I have found it to be a bit of a struggle to put this posting together, as I have witnessed considerable variability in the degree of convergence that has taken place across enterprise customers. Of course, the migration to Voice Over IP, although not complete, is mostly well under way, and has brought significant change to the traditional corporate Telecom role as voice moved onto the shared data network infrastructure.
For one, it brought about a necessary degree of required collaboration between Telecom and other departments in the IT organization--most notably those responsible for the network infrastructure. And as functionality evolved and access to corporate communications extended out beyond the walls of the business, collaboration with security infrastructure people was required.
But the actual back end servers running call control, media processing and other related UC applications were by and large dedicated to voice. They may have been sitting in the data center rather than the old "Telecom Closet," but they were still dedicated and largely purpose built, providing a level of comfort and "confidence-of-reliability" to those managing the telecom infrastructure.
So here we are now, looking at the migration to Virtual Infrastructure, and discussing even more convergence--not just shared network infrastructure, but also shared server infrastructure and shared storage infrastructure. CIOs and IT Directors get this--it means more cost savings, and more efficiency through integrated operations processes and business continuity plans. And since they are working within much tighter budgets, this certainly perks up their ears!
So, if you're a Telecom manager/administrator responsible for the voice infrastructure (and perhaps to a lesser or greater degree the UC applications), what does it mean for you? Well, virtualized voice and UC applications are going to be sitting on even more shared infrastructure--servers and storage in the data center. The initial setup of the Voice/UC applications will be under the direction of the Data Center department, perhaps with part of that under the control of a separate Storage group.
This equates to more cross-departmental collaboration as you work with these different groups to carve out the requirements to ensure the Voice/UC applications are properly set up with the resources they need on that shared infrastructure. It also means more up-front planning with those groups to understand how Service Level Agreements (uptime) for Voice/UC will be maintained on that shared infrastructure.
As the virtualized voice/UC applications are now on shared infrastructure, it does mean letting go of a certain level of awareness and knowledge of where your Voice/UC applications live--that they could be moved ("vmotion'd") from one host to another without necessarily any awareness on your part--either manually for reasons of server maintenance, or in an automated fashion with management tools that look to optimize host power consumption (e.g. Distributed Power Management) or look to balance out workloads during peak use times (e.g. Distributed Resource Scheduling).
For day-to-day management of the Voice/UC infrastructure, there is not necessarily any change to any of the Voice/UC application-layer administrative interfaces that are used to manage moves/adds/changes, access system maintenance tasks, view alarms, and diagnose system faults. They are all still accessible through the application's existing web management portals, text-based consoles, and system APIs. Of course, some of the maintenance and diagnostics functions must now be coordinated with the Data Center/Virtualization prime (lead person) as opposed to being able to do hands-on server diagnosis.
On the flip side, there are significant benefits. You can shed some of those otherwise time-consuming tasks and responsibilities associated with managing dedicated appliances and servers, and managing uptime to meet SLA commitments. Perhaps it also implies some cost savings depending on how intra-departmental budgets are tracked. Virtual voice/UC frees up your time (and perhaps budget) to focus on increasing the application (communications) value that can be brought to your consumers (the corporate employees).
In addition, it presents the opportunity to pick up great new skills such as being trained up on the latest that virtual infrastructure technology has to offer. That in turn opens new doors--from simply having the confidence to directly manage and control that subset of the virtual infrastructure carved off to host your voice/UC applications, to opening the horizon to new career opportunities.
I recall an interaction with a large customer at one point where the introduction between the customer's telecom prime and the customer's data center/virtualization prime was made on the call with the vendor. After the vendor introduced the concept of virtualized voice/UC, confirmed the viability of virtualizing real time communications, and the associated value, most of the meeting was spent getting the customer's telecom prime up to speed and comfortable with virtualization, and on the flip side introducing the data center/virtualization prime to the key characteristics and attributes of a voice application. The two worlds meet. Perhaps this "first time" encounter is becoming less and less typical, but it is still somewhat telling of the challenges and opportunities that lie ahead.
In the next couple of postings, we'll talk about two very interesting aspects of offering virtualized voice and UC. One of those will be on Virtual Appliances and how delivering voice/UC applications as Virtual Appliances can significantly reduce installation and configuration time, getting you to first call in minutes rather than hours. The next entry will focus on leveraging virtual infrastructure availability and business continuity solutions to provide an even more reliable voice/UC solution.
