You walk into your office and look at your network PoR (Plan of Record) for the week. There are 40 software updates in your core network alone. Each of these must be installed and tested, then rolled into production- ensuring not a single dropped call as a result. Shudder to think what happens if the element goes down altogether! There are two net new network functions that need to be brought into operation – for which marketing has already created a campaign (that goes out this week of course!) with features that depend on these functions. Oh, and this happens to be the week that operator benchmarking is occurring in your region and you’ve been trying to chase down a recurring- but apparently mysterious- issue that is affecting jitter in video calls. Sound familiar!?
Telecom Review sat down with Ricky Boyle, SVP of transformation solutions for Reailize to explore a paradigm shift in running telco networks and to begin to answer how we might operate differently:
- If you could trust that your software updates could happen with an app store like transparency, errors resolved before users became aware, and flow through- how might that change operations?
- If you had an automation chain that would allow the same curation experience of net new functions as is now common in the traditional software devops world- how would that impact your time to market (TTM)?
- Now, what if the answer to the two questions above could also create an IQ repository that allowed continuous automation and tuning of the network such that problems could be proactively caught and brought to the attention of the appropriate engineers- or even resolved without human intervention? Where could you redirect your highly skilled engineers?
CI/CD has accelerated software delivery, but does nothing to accelerate quality assurance – how do you accelerate the rest of the operation to keep up?
Indeed, software lifecycles have accelerated and the days of scheduled release windows are behind us. And, while we are now able to develop and deploy software rapidly, validation and certification of these platform and network function changes still occupy an immense amount of time from our most skilled engineers. The reason is that the process is highly dependent on in-depth domain knowledge, which until recently has seen very little automation.
This is where we have focused our attention – utilizing advances in ML and AI to commit the specific domain knowledge of telecom into trained models that allow the network evolution process to run end-to-end uninterrupted. Now, CI/CD is used to deliver software, we’ve developed continuous testing (CT) pipelines to automate the test execution and data curation, and continuous validation (CV) functions that address the validation and troubleshooting processes and ensure the quality of software is certified prior to launch through AI.
The build vs. buy is an age-old question, what is your position on telco investment to develop in-house vs. buy?
I would say that today’s network is not only increasing in complexity, but also that the complexity is increasing at an accelerating pace. Partnering with 3rd parties who not only have pedigrees in network operations, but also software management, whose global practice drives continuous innovation and evolution, and who grow teams of specialists- such as Data Scientists, just make sense. This allows the operator to offload rote and often manual tasks to their partners, while focusing on value add activities to their business.
End-to-end network automation obviously requires comprehensive observability and data accessibility. What constitutes the biggest barriers for telcos in this domain today?
Every telco is at a different stage of their evolution in terms of their data maturity. Networks seem to be one of the last places where good data practices are being implemented. As an industry, we must move to break down the information silos so common to our operations - such as core vs transport vs edge. In addition, to cop an old hacker phrase, “information must be free”, we can no longer afford to allow our network elements to encode data with proprietary algorithms, but instead insist on open standards and data accessibility.
What is your core tenet as a company in regards to driving network automation?
We have been adopting promise theory as a driving philosophy when we architect our solutions. Promise theory is defined as the “voluntary cooperation between individual, autonomous actors or agents who publish their intentions to one another in the form of promises”. In other words, we’re implementing the “trust but verify” concept in the form of applied automation.
We understand that there are silos, divisions, and domain separations that are either difficult, or impossible, to eliminate in the telecom space. Everything from the multi-vendor, multi-technology technology stacks, to business process demands at scale contribute to this. However, decomposing the operational challenges, especially repeatable processes, into defined, addressable, candidates for automation, and implementing the right integration, checks, and balances in between these autonomous “agents” as defined by promise theory, creates a paradigm that addresses cross-functional processes without disruption to defined roles and responsibilities.
In short, if each moving part in my network evolution can be verified to meet its promise (compatibility, integration, functional, and quality), focus can be shifted on process optimization and value creation rather than hardening individual links in the chain.
