Why DevOps, UC&C Need Each Other
UC&C can both benefit from, and support, DevOps initiatives, improving likelihood of success.
In my early years in IT, I held a variety of network operations-related positions. The primary purpose of my job, aside from keeping the network running, was pointing the finger elsewhere whenever we received a trouble ticket indicating that "the network is slow or down."
Our typical process involved a series of network health checks: Ping remote sites to determine reachability and latency, check dropped packet counters, and look at network optimization platform logs to see if we could identify the fault. Ideally, we would find no network issues and then forward the ticket to the appropriate application owner. Never did we treat the network, and the applications that ran on it, as a holistic system. Rarely if ever did we receive advanced warning of new application rollouts, or get ourselves involved in the design and development of applications. No, our job was always to figure out a way to show the network wasn't at fault.
This operational approach has been commonplace in IT for years. It relies on a plan-build-run model with clear lines of demarcation, and, more often than not, little communication between silos. It's also, if you are paying attention to high-level IT trends, going the way of the dinosaurs. This is thanks to the advent of DevOps.
DevOps, as its name implies, treats application development and operations as a holistic system, managed as a unified entity. DevOps encompasses both organizational strategies that integrate application development and operations groups, with tools to support rapid deployment, feedback, and optimization of code. It is both a cultural and a technical approach to reorganizing IT around desired outcomes rather than specific job functions.
DevOps offers the opportunity to restructure UC&C rollouts radically, better align initiatives with user needs, and ensure that areas like network performance, security, and governance are addressed early on in the process. It enables rapid and continuous improvement, enabling teams to add features and functionality based on identified user needs and to modify them quickly based on usage and user feedback.
As an example, suppose our organization needed to upgrade its telephony platform. In the traditional approach we'd gather and prioritize end-user requirements, create a request for proposal (which would often run way too long), solicit and score responses, pick a couple of finalists, turn up a test tab, conduct pilots, conduct a large-scale rollout, and then maybe in a few years we'd upgrade (assuming we didn't pick a cloud-based solution offering continuous upgrades).
The end result is that we deploy a platform that met the needs of our users when we started the process, but might not do so anymore. We also spent a great deal of time and effort to implement a platform that might not be easy to upgrade to support unanticipated requirements. And we'd cross our fingers when we deploy and hope that we don't break the network. Along the way, we might find out that our security and risk management policy doesn't allow a feature that we planned to implement.
In a DevOps approach, we would have built a scrum team (borrowing a concept from Agile software development) that consists of end-user representatives, app developers or managers, network and data center operations staff, and maybe even security specialists. We would have worked as a team, with a clear set of common goals and well-defined processes for feedback, continuous improvement, and automation. We might have quickly evaluated a number of solutions and picked a few to trial, without an arduous RFP. We would have gotten immediate input from our security team, and a feedback loop would have allowed for the agility needed to add new features or change direction to meet evolving business or end-user requirements or opportunities.
Perhaps more importantly, the introduction of a new app wouldn't surprise network operators. Instead operations would be tightly integrated into the development process.
The second intersection of DevOps and UC&C comes in fostering collaboration of DevOps teams. I often say during my public presentations that if your DevOps team is using email to collaborate, you are doing it wrong. DevOps initiatives require contextual and workflow-based collaboration and often are the forces that drive adoption of team chat/messaging apps like RingCentral Glip, Atlassian HipChat, Slack, and Cisco Spark. They often require co-authoring tools, and they are likely to require file sharing across desktop and mobile devices, with internal and external team members.
DevOps may not be for everyone, and to date we have rarely seen organizations that use it for all IT processes. But it offers application developers/managers and network/data center operators a way to better align toward a common goal and work with the flexibility and agility necessary for rapid response to changing needs and opportunities.