This article is based on analysis originally published on vanillaplus.com, drawing on commentary from Tony Gillick, VP Solutions Management at Openet.
The Transformation Pressure Facing Telecoms Operators
Telecoms operators have never been celebrated for rapid innovation. Despite running the infrastructure that powers the modern internet, most operators remain tethered to legacy Business Support Systems (BSS) and the proprietary vendors that supply them. This combination — ageing platforms and restrictive vendor relationships — has produced organisations that move slowly at precisely the moment when speed matters most.
The competitive irony is stark: the companies that built the superfast networks enabling on-demand streaming, ride-hailing and cloud storage are themselves struggling to compete with the digital-native businesses exploiting those same networks. Revenue is leaking to agile competitors better positioned to monetise the infrastructure operators paid to build.
Digital transformation for operators is therefore a two-front challenge. It requires overhauling internal BSS architecture and renegotiating relationships with vendors whose legacy products are as much an obstacle as an asset.
Why Microservices Matter for BSS
Microservices architecture decomposes a monolithic application into small, independently deployable services, each responsible for a discrete business capability. For BSS — the systems that handle billing, customer management, product catalogues and order management — this shift has significant implications.
- Customisation without risk: Individual services can be modified or replaced without triggering a full-system regression. An operator can update a charging engine without touching the order management system.
- Programmability: As networks become increasingly software-defined (NFV, SDN), BSS layers built on microservices can be wired into network functions programmatically, enabling dynamic service creation.
- Faster time-to-market: Smaller, decoupled components can be tested and released independently, shortening the cycle from concept to live service.
- Reduced vendor lock-in: Services built around open APIs and standard containers are easier to replace or supplement than proprietary monolithic platforms.
Internet-era companies — Dropbox, Twitter and Airbnb among them — adopted microservices early and credited the architecture with substantial improvements in release velocity and team autonomy. While exact figures vary by organisation and context, the directional evidence is consistent: decomposed architectures enable teams to ship faster and recover from failures more quickly than monolithic equivalents.
DevOps: More Than a Buzzword for Operators
Microservices architecture creates the structural conditions for faster delivery, but realising that potential requires a matching change in how software is developed and operated. That is where DevOps enters the picture.
In a traditional telecoms delivery model, development teams build software and hand it over a wall to operations teams to deploy and maintain. Release cycles measured in months or years are common. Defects discovered in production are expensive to fix because the gap between writing code and running it in anger is so large.
DevOps collapses this separation. By unifying development and operations responsibilities — supported by continuous integration, continuous delivery (CI/CD) pipelines, infrastructure-as-code and automated testing — teams can deploy software frequently, safely and with rapid feedback loops. For operators trying to match the release cadence of OTT competitors, this matters enormously.
Practically, a DevOps-enabled BSS environment might look like this:
- A new charging rule is developed, unit-tested and merged in a feature branch.
- A CI pipeline runs integration tests against a containerised BSS stack automatically.
- On passing, the change is promoted to a staging environment and validated against production-equivalent traffic samples.
- A CD pipeline deploys to production with a canary rollout, monitoring error rates before full traffic is switched.
- The entire cycle takes hours rather than months.
This kind of pipeline is routine at cloud-native companies. For telecoms operators, it represents a meaningful cultural and organisational shift, not merely a tooling change.
The Missing Layer: Industry Collaboration
Microservices and DevOps are necessary conditions for BSS transformation, but they are not sufficient on their own. Both practices depend on well-defined interfaces, shared standards and a willingness among operators and vendors to work in the open — qualities that have historically been scarce in the telecoms supply chain.
The growth of open-source technologies is changing the calculus. Tools such as Kubernetes for container orchestration, Kafka for event streaming and OpenAPI for interface specifications give operators a common technical vocabulary and reduce dependence on proprietary vendor implementations. When a BSS microservice is packaged as a standard container and exposes a documented REST API, it becomes genuinely replaceable.
Industry bodies are also playing a constructive role. The TM Forum has worked to define open APIs and reference architectures (including the Open Digital Architecture) that provide blueprints for interoperable BSS components. When operators and vendors align on these standards, the risk of repeating the lock-in mistakes of the previous generation is reduced.
Collaboration, in this context, means three things:
- Operator-to-operator sharing of implementation patterns, lessons learned and tooling, rather than treating transformation knowledge as competitive IP.
- Operator-to-vendor co-development within agile, DevOps-style delivery frameworks, replacing the traditional waterfall procurement model with iterative, joint delivery.
- Ecosystem openness — publishing APIs that allow innovative third parties to build on top of operator platforms, creating a network effect that proprietary systems cannot replicate.
From BSS Modernisation to Platform as a Service
The end-state that operators are working towards is not simply a modernised billing system. It is a composable, API-exposed platform that can attract external developers and partners, enabling new services and business models to be assembled rapidly from existing capabilities.
This Platform-as-a-Service (PaaS) vision requires all three elements to work in concert:
- Microservices provide the modular, independently deployable building blocks.
- DevOps provides the delivery machinery to keep those building blocks current and reliable.
- Collaboration — through open standards and ecosystem partnerships — provides the surface area that makes the platform genuinely valuable to external partners.
Without collaboration, a microservices BSS is still a closed system — faster to iterate internally, but unable to attract the external innovation that distinguishes a platform from a product. Without DevOps, the organisational capability to sustain rapid iteration simply does not exist, regardless of how clean the architecture looks on a whiteboard.
Key Takeaways for DevOps Engineers Working in Telecoms BSS
- Legacy BSS monoliths are a delivery bottleneck, not just a technical debt problem. Decomposing them into microservices is a prerequisite for meaningful CI/CD adoption.
- Container-based deployment (Docker, Kubernetes) is the practical enabler that makes microservices portable across operator and vendor infrastructure.
- API governance matters. Microservices only reduce lock-in if their interfaces are standardised and versioned. Adopt TM Forum Open APIs or equivalent standards where they exist.
- Cultural change is the hard part. Operators accustomed to annual release cycles need coaching in agile delivery, not just new tooling.
- Measure time-to-market explicitly. DevOps transformation in BSS should be tracked against concrete deployment frequency and lead-time metrics (DORA metrics are a useful framework), not just architectural diagrams.
- Treat vendors as delivery partners, not black-box suppliers. DevOps collaboration requires shared pipelines, shared observability and shared accountability for production outcomes.
Conclusion
Telecoms BSS transformation is not primarily a technology problem — it is an organisational and cultural challenge that technology enables. Microservices provide the architectural flexibility; DevOps provides the delivery capability; and industry collaboration provides the ecosystem conditions in which both can deliver lasting competitive value.
Operators that treat these three elements as independent initiatives will make partial progress. Those that pursue them as an integrated programme — changing architecture, delivery practice and vendor relationships simultaneously — are building the foundation for genuine digital transformation rather than an expensive re-skinning of the status quo.