DevOps principles can help telcos evolve from a highly architected and reliable, yet fixed environment, but it requires significant cultural change.
The cultural demands of DevOps
DevOps principles can help communications service providers (CSPs) evolve from a highly architected and reliable, yet fixed environment to new ways of cross-functional collaboration – but only if they are willing to embrace significant cultural change.
DevOps is as much about culture as it is about processes and tools. In an Agile development environment, the cadence of software development is radically different from traditional waterfall methods.
Fixed, sequential processes give way to an iterative style, with the emphasis on frequent, short development phases called sprints, and the regular delivery of functionality and working prototypes on which the business could provide feedback. While this provides significant benefits in development, much of the gain in speed and agility are wasted when testing and deployment are disconnected from the design and development process.
The DevOps movement seeks to extend this agility right through the software lifecycle, by creating shared responsibility for producing working software across development and operations teams. This is enabled by feedback loops at every stage of the lifecycle which allow for continuous improvement, learning and experimentation. The desired result is a continuous flow of value from business to customer.
This is achieved by breaking down the solid wall between development and operations, automating as much as possible of the development-to-deployment continuum and enabling collaboration by all stakeholders in delivering a quality service.
The use of DevOps goes hand in hand with the shift to cloud native platforms, which require modern development architectures. In a cloud native environment, the emphasis is on decomposing an application to a set of granular functions or microservices, which communicate via APIs. Each runs in its own container which can then be deployed into a cloud environment (whether public, private or hybrid).
From a development perspective, each microservice can be built, updated and deployed to its own cadence, removing much of the dependency between individual pieces of the application and enabling the continuous development and delivery process espoused by DevOps.
Containers are then managed by orchestration software that takes care of deployment, scaling and management of the running application, with Kubernetes as the de facto standard. For many CSPs however, the journey to cloud has been slow and problematic.
For new applications such as digital experience and the creation of new lines of business, it makes sense to adopt a cloud native model from the outset. However, for backend functions the business case is less clear. The process involves either modernizing legacy operational and business support systems (OSS/BSS) or simply “lifting and shifting” them to the cloud, but there has not been pressing need for change. Since digital applications and projects have been relatively self-contained, IT has often operated in a two-speed model, and organizations have shied away from undertaking the wider business and IT transformation and modernization that is required to take full advantage of cloud.
Encouragingly, more than 80% of CSP respondents to TM Forum’s fifth annual Digital Transformation Tracker survey in 2021 were either committed to a cloud native approach for all IT workloads, or preferred to take a cloud native approach where possible.
DevOps uptake varies by domain DevOps adoption in telcos varies widely both within individual CSPs and across the industry. For each company, adoption can be classified against three domains: