Digital Transformation is the name of the game these days across all major industries – Health, Finances, Mining, Manufacturing, etc. It’s pretty safe to say that those companies who don’t go through digital transformation will probably get left behind and will eventually die out in a natural selection process.
It’s hard to define exactly what Digital Transformation means in each of these sectors so I’d like to focus on the Digital Transformation occurring in the Telecom sector today. This may come as a surprise since Telecom is considered one of the slowest sectors to adapt and continues to rely very heavily on legacy systems for long after their official end-of-life dates., However according to reports and studies the Telecom sector is in quite a good place in terms of transformation efforts compared to most other existing companies in other sectors. You can find the latest numbers in current reports such as ‘The State of Digital Transformation in Telecom’ by Heavy Reading.
The main drives behind the wave of transformations we’re beginning to see in the Telecom industry can be attributed to several key factors: Over-The-Top (OTT) threat, emerging NFV and SDN technologies, cloud concepts embraced by the industry, concrete standardization efforts by leading standards organizations with support of CSPs and vendors, use of open source technologies in the industry which had been a complete no-no up until just a few years ago, as well as several industry giants taking initial steps, really experimenting and then sharing their efforts and lessons learned.
On a personal note, I tend to attribute most of these to software taking the lead in an industry which has always been hardware-based. The emergence of cheaper technologies that can do the same as hardware but on the software plane has been the main drive to all of the above. Software in Telecom has led to vast changes, not only in technologies such as NFV and SDN, but also ramp-up of the personnel in CSPs to become better acquainted with SW skills or DevOps, and lastly becoming more open to use of open source code and having the ability to more rapidly than ever test and experiment with new ideas as dependence on long HW cycles is a thing of the past.
So, what would a transformation use-case look like in the coming years? We can break it down into several parts and recommendations based on already learned experience and know-how:
- Go by use-case: don’t just rush ahead and convert your entire network, pick a few use-cases with viable business cases, market demand and proven technology and start creating a use-case by use-case transformation project
- Pick the new vendors specific for the use-case: these might be VNF vendors to replace some legacy PNF function, a next-gen OSS vendor to unravel the complexity of some of your old OSS/BSS legacy systems, or an end-to-end solution provider for a specific use-case such as SD-WAN where you can get the necessary HW, SW and controller parts from the same vendor.
- Plan and implement the migration path from existing state to the desired state. Do this smartly to prevent the entire project from collapsing inwards.
As one of the leading, DevOps-enabled, model-driven Network Discovery and Automation framework around and being truly vendor-agnostic, NetACE® is the prefect transition enabler. There are key steps to realize each transition use-case, but they must always begin with a real and profound understanding of the network that includes a clear view of what’s in the network, the various connections and resources used, the utilized and under-utilized links, verification of presumed service path chains and so forth. Without this step, going forward could mean suicide since the service provider will just jump headlong into unknown waters trying to make complex changes to the network without realizing the intricate details of what’s actually there.
After analysis and optimizations which can be done following the network understanding step, the second most important factor is to automate the transition as much as possible. Here you should rely on models that allow discovery of existing brown-field services (parts of which you might want to transition to new technologies) and automate the migration in a make-before-break, network-transaction-guaranteed fashion. Migration can be done by moving one part/end-point/block of a service chain from one PNF to a new deployed VNF, or by replacing several network functions with new ones, etc. Regardless of the specific use-case, it is important to rely on advanced modeling to instruct the automation engine on how to migrate the configuration from the old to the new.