(c)iStock.com/AzmanL
A recent article on CA examined how DevOps is spreading across industries to accelerate deployment in Agile environments. What stood out was the unexpectedly high adoption of DevOps within telecommunications. CA reports that telecoms are almost twice as likely to be using DevOps (68%) compared with the overall average (39%), and that 88% of telecom companies either use DevOps or plan to, versus an aggregate of 66%. The pressure on telecom firms to continuously deliver new services makes DevOps an attractive approach to speed delivery.
Different challenges for vendors and operators
For many internet service providers and mobile operators that introduced Agile methods years ago, DevOps adoption is a natural extension. These operators are moving toward webRTC, web services and HTTP/REST to support value-added services; their platforms increasingly resemble IT environments where services run in browsers or virtualized containers. Since DevOps originated in IT alongside Agile, it makes sense that organizations converging with internet platforms adopt DevOps tools and practices.
However, this IT-centric view only captures a subset of telecommunications. A large portion of the industry consists of network equipment manufacturers and infrastructure vendors. Beyond the largest vendors like Nokia (formerly NSN), Ericsson, Alcatel-Lucent and Huawei, thousands of mid-sized firms write and deploy software using Agile principles. Many have already moved from iterative-waterfall to Agile and use continuous integration, and in some areas even continuous deployment.
Unlike pure software services, these vendors deliver hardware that is expensive to commission and maintain over long lifecycles under strict SLAs. Their products cannot be patched as easily or continuously as cloud services. Tools like OpenStack, Puppet, Chef or Salt can help in IT environments, but they don’t directly solve the core problems of hardware-centric telecom systems.
When proponents describe DevOps as “a mindset rather than just a toolset,” the definition can seem vague. In practice, DevOps aims to improve collaboration between development and operations to speed delivery and reduce friction.
That said, hardware-intensive industries such as telecoms, automotive, aerospace or medical devices tend to be conservative. They are unlikely to adopt a pure DevOps model overnight, even when they already practice Agile development. Examples like “DevOps in a nuclear power plant” or “live upgrades to surgical equipment” highlight how unrealistic continuous deployment can be where safety and reliability are paramount.
Telecom equipment such as base stations or eNodeBs must operate reliably for thousands of subscribers. Failures can trigger severe penalties and reputational damage. Fixing onsite faults is slow and costly: an engineer visiting a site, log collection and analysis, and staged rollouts can take days or weeks. For that reason, early detection through formal methods such as Design Failure Mode and Effects Analysis (DFMEA) remains crucial for profitability.
Still, the DevOps mindset can benefit these conservative environments. To understand how, it helps to look at a representative use case showing how large equipment vendors typically develop and deliver products.
Use Case: ACME Corp
Consider ACME, a multi-billion-dollar vendor building network components for operators. ACME employs more than 1,000 engineers and moved from waterfall to Agile over the past decade. Engineers work in cross-functional micro-teams that form and disband as needed. Code ownership is feature-driven, and teams are distributed geographically with varying hardware and software expertise.
ACME runs continuous integration (CI) to give immediate automated feedback when changes are committed. The CI executes unit tests and system-component tests, sometimes simulating messages destined for the actual hardware. When CI flags issues, teams correct or roll back changes so the repository remains in a testable state. Approved changes are promoted automatically to downstream integration and test stages.
Downstream teams then select a promoted version from upstream CI and coordinate deliveries from other teams. Each downstream group typically has its own CI and test repository; they run tests on real hardware or specialized platforms and “promote” releases after passing their own checks. Multiple integration phases can exist, and each stage often requires different hardware platforms (MCU, DSP, OS kernel layers, physical interfaces, etc.). Eventually, binaries reach real hardware for end-to-end and interoperability tests before field trials and customer deployment.
Problems arise when faults cascade back from downstream to upstream. Determining which software package or branch contains the fault, merging fixes across branches, and coordinating corrections across teams consumes substantial developer time. Who investigates every fault if developers are focused on sprint goals?
Fault Managers and pre-analysis teams
To cope, many organizations rely on fault managers and pre-analysis specialists who triage logs and route issues to the likely owners. During critical trials this triage is essential: identifying which team must fix a problem immediately saves time. But when a faulty release has already been shipped and frozen in multiple branches, the same bug can reappear weeks or months in different contexts, creating repeated work and noise in the defect-tracking system.
Agile practices helped ACME become faster and more experimental—“fail fast” became the norm. Yet another bottleneck emerged: downstream teams remained functionally separate, treating integrations as external events. In effect, the delivery chain still contained a waterfall of integration and testing stages, each maintained by separate management and processes. Developers were frequently interrupted to clarify issues, and coordinators spent time shepherding communication between departments.
This is where DevOps can be most valuable for hardware-centric industries: not by promising magical new tools, but by integrating downstream test environments and operations closer to development.
Moving towards DevOps in these environments means reducing technical barriers so automated deployments and transparent APIs can flow all the way to target hardware. Integration teams often lack virtualization and scripting experience, and they rely on slow hardware interfaces (JTAG, USB, specialized debug buses) and manual processes. The further downstream you go, the less overlap there is with developers’ scripting and automation skills.
Consequently, teams duplicate test code, maintain overlapping test suites and re-test the same functionality multiple times. This redundancy wastes resources and creates avoidable context switching.
Practical steps to move toward DevOps
Adopting a DevOps mindset in hardware-focused companies is incremental and practical:
- Start with a gap analysis. Appoint a consolidation engineer or architect to review each integration and test department and identify overlapping tests and opportunities to automate deployment interfaces and APIs.
- Break down silos by encouraging cross-functional movement. Have developers spend one or two days a week working in downstream test teams, and rotate integration engineers into development periodically. Treat these people as ambassadors who bridge teams and diffuse knowledge.
- Provide incentives and recognition for staff who work across departmental boundaries to encourage participation and cultural change.
- Improve test coverage and trust in automated suites. When a bug reaches downstream, use it as evidence to expand test cases so similar failures won’t recur on any branch. Minimize the number of active branches to reduce complexity and context switching. If test coverage is insufficient, prioritize improving tests before relying on costly branch freezes or manual workflows.
Will fault managers disappear?
Roles like Fault Manager or Pre-Analysis will not vanish overnight. Think of them as interim managers who bridge R&D and operations during the transition. In organizations that have adopted Agile but not DevOps, these roles remain essential. As silos break down and processes change, the responsibilities of these roles should be redefined and redistributed across teams.
How long will the transition take?
Large organizations require both bottom-up and top-down support to break silos and adopt DevOps practices. Based on experience migrating from waterfall to Agile, that transition typically takes 1–3 years; moving from Agile to an integrated DevOps approach in hardware-heavy industries will likely take another 1–3 years. The core challenges are political and cultural, not purely technical. As Gerald M. Weinberg observed: “No matter how technical it looks at first, it’s always a people’s problem.”
Conclusion
- DevOps in non-XaaS and non-web industries is feasible, but it encounters more stakeholders, more complex delivery chains and conservative practices.
- Adoption will take longer, but focusing on interfaces and communication between silos reveals the same fundamental problems as in IT—just at larger scale.
- Many firms have already adapted Agile from IT successfully. Those internal silos often operate efficiently, but the friction between them remains. DevOps is the logical next step to reduce that friction.
- DevOps increases cross-functional skills and a shared understanding of issues across teams.
- By improving automation and trust in test suites, organizations can reduce reliance on expensive QA branches and politically difficult workarounds, enabling more reliable, faster delivery even in hardware-dependent environments.
Have you considered DevOps in telecoms? Let us know in the comments.