Telecoms have been automating their services for decade – albeit within “islands of stability” and at a component level. The result has been a slight productivity benefit offset by many different automation systems that don’t communicate with each other and thus can’t provide system-level automation.
Today’s telecom executive needs to think of automation at a system level that can help to build an infrastructure that enables faster deployment of new services.
Sure, cost-cutting and complexity management are important advantages of automation. But the fundamental benefit of automation is freeing network resources and creating an infrastructure that can convert customer needs into new production services in record time. That’s the conclusion of a new executive briefing report from STL Partners titled “Automation for Speed.”
We’re big believers in automation, having built automation into our Symworld product. We also have a track record of automation success roadmaps, embedding automation in service assurance and, most recently, in CBRS rollouts. The STL Partners report, released in June of 2023, further validates the benefit of transitioning to an automation-centric approach for telecom.
Two factors make automation and speed to market a C-level issue for telecoms: network complexity and competition. As networks grow more complex, new service roll outs take much longer. Also, the market is hyper competitive and CSPs that have embraced automation will leave their more manually-oriented competitors at a disadvantage without the flexibility to respond to new services quickly.
A network that can be automated must be cloud-native and have all the main characteristics of a cloud native network including:
Simplified hardware infrastructure: Many CSPs procure dozens – even hundreds – of different hardware platforms. The goal should be three:
Single data model: Proprietary systems come with their own data models, which makes coordinating changes time consuming. With a single data model, it’s possible to automate the system because one change request process can govern all systems.
Applications abstracted from hardware: this separation of infrastructure (Kubernetes) from application development allows app developers to design software to a known infrastructure thus keeping their developers focused on innovative new features.
Microservices: CSPs need smaller network functions where automation can trigger new software instances to grow the network function in parallel with growth in traffic. While cloud native networks are known for providing a foundation for microservices, it’s not mandatory. Telecoms must insist on microservices.
Auto-elasticity: Another scaling feature called auto-elasticity is the ability to scale network capacity at a granular level by tuning CPU clock frequencies to manage energy consumption.
Zero-touch provisioning: This allows for true plug-and-play installation of any network component with a configuration capability available through automated workflows upon connection to the network.
Break down IT/ network siloes: Building out an automation network means moving traditional network capabilities to an IT infrastructure. This is an opportunity to blur the lines between IT and network departments. Why is this important? Because IT teams have a mindset more in line with the need for automation as well as the skill set to pull it off.
After identifying how to rebuild your network to support automation, the STL Partners report also provides six key considerations for adopting automation. They are:
This post is a high-level overview of the report, which includes additional details, ideas and tier 1 case studies from TELUS and Rakuten Mobile.
The publication of the STL Partners “Automation: Need for Speed” executive briefing document underpins the need for CSPs to adopt an automated cloud-native infrastructure. Automation allows CSPs to wring the costs out of the operation of an increasingly complex network and to develop an infrastructure that supports new services. Download the full report for free.
