Network Transformation: Caution – Extreme Conditions
Each day, as every skier knows, can present new conditions and a fresh set of challenges. The weather can be sunny, blustery or confront you with a whiteout due to heavy snow and wind. The slopes might be icy and hard-packed (recalling learning to ski in Eastern Pennsylvania), or you may be blessed with “champagne powder” (which we live for here in the Rocky Mountain West). Poor coverage can expose rocks, bare patches, and other obstacles.
I took the above photo at one of my favorite Colorado resorts. The “EX” at the top of the sign means this is an extreme expert slope.
Skier beware — know your limits.
Right about now you’re probably thinking “Andy, I see where this is going… metaphor ahead!”
I could get a bit heavy-handed and compare the challenging alpine environment to your network—and chair lifts to your need to manage traffic and capacity constraints. But I’ll keep it simple.
Recognizing and overcoming obstacles is crucial to the success of any network transformation program.
I’ve been part of numerous network transformations over a 30+ year career. I recall when ISDN was going to change our world. What I find most interesting now is the confluence of multiple trends and technology shifts.
We used to have the luxury to handle one major shift at a time – think PDH to SDH/SONET and then to MPLS and IP networks. On the mobile side, we’ve had the stepwise progression of ‘G’s. Of course, it’s not generally this clean. Each generation doesn’t readily give way to the next, rather there is often an awkward, inefficient, and expensive co-existence among technologies.
Consider the present era, and the transformational forces underway in the telecom industry.
Here is a sampling.
- Dedicated network elements to White boxes and virtualized functions
- Proprietary code to Open source driven by communities of interest
- SDH/SONET to IP networks (sometimes with CEM as a stop gap)
- 2G/3G to 4G (many developing markets)
- Network performance focus (3G/4G) to Enterprise use case focus (5G)
- Central offices to Web scale data centers
- On-premise computing to Cloud & edge computing
- Manual processes to Closed loop automation enabled by AI
- Internet for cat videos and Instagram influencers to Internet of Things & smart cities
I’m sure I’ve missed a few. What would you add to this list?
Here’s the scary news… the pace at which transformational forces will compete for our attention is only going to accelerate.
It’s inevitable. Wheels are in motion.
AI and automation are accelerating the pace of innovation. Companies must embrace innovation to compete and, indeed, survive. Historical transformational cycles of 5-15 years (depending on the technology) will soon appear to be almost continuous.
Ray Kurzweil, noted author and futurist, addresses this pace of change in his book The Singularity is Near. He argues that the rate of paradigm change is doubling every decade. In 2030, the paradigm shift rate will be 2x what it was in 2020. In 2040, the rate will be 4x, and so on.
This means if you are stuck in a planning cycle for your next network transformation or moving forward with acknowledged (or unknown) blind spots—a bad situation now could become insurmountable in the future.
So, let’s get back to those obstacles (moguls?) for transformational network change. What might get in your way? How can you ski smoothly over them without turning into a yard sale? (Sorry, a little ski humor.)
Falling prey to inertia
Consider legacy TDM networks. Many large, incumbent operators continue to run these networks despite aging equipment (with difficult to find spare parts), high energy and real estate costs, and a dearth of qualified technicians due to a retiring work force.
These problems will only be exacerbated with time.
Better to proactively retire old networks, reap the cost savings, and enable the operational benefits of IP networks and SDNs.
Not knowing your cost structures
Every significant move made by a telco requires a business case. One might know in principle that a certain project makes sense, but show me the numbers. Network transformation projects are generally not going to be exempted from such fiscal scrutiny.
I expect you already have access to certain costs—e.g., real estate, power, field force, Capex for network assets, etc. A best practice is to know your cost structure at a product and services level.
You’re not in business to build a network. You exist to delight customers with products they need and with competitive rate plans. If you know what it costs to deliver a service now and after a network transformation, your business case becomes easier.
The trick is to understand all your cost components. Most of your competitors only take educated guesses (trust me).
If you get this right, you will have a business insights edge that may be more valuable than your technology edge.
Examples of things you should know:
- What granular costs (Opex and Capex) should be assigned to each product and service?
- What are the margins for each product and service (including network costs)?
- What is the ROI of each of my sites?
- What is my return on assets?
- Which assets are underperforming?
- If I virtualize certain functions (e.g., onboard VNFs) will I trade Opex pain for Capex savings? This is really a separate discussion but thought I would fold it in. There’s no free lunch. While virtualization is certainly a growing trend, make sure you understand the costs of any operational complexities that arise when you replace the convenience of purpose-built OEM platforms.
Not knowing your network
You should have the data to know:
- What assets do I have in the network (what, where, when, and why)?
- What is each asset doing? What are the numbers? — Capacity, utilization, history/trends, contribution to revenue, etc.
- What is my network topology?
- How are services carried on my network and how do they map to my infrastructure?
There are many operational parameters you should know about your network which tilt more toward planning, optimization, and fault management. I haven’t listed them here since my context is on preparing for transformation but there is certainly room to consider many other types of data.
Migrating boxes, not services
There is a tendency to think about network transformations in terms of technology. For example, you will be replacing SDH/SONET network elements such as DACS and ADMs with routers and IP switches. In fact, many fixed line transformations have taken this approach—one box at a time.
This is inefficient and can show a lack of empathy for the customer.
Any transformation carries risk of disrupting customer services. Let’s consider the migration of a TDM network to IP. The recommended best practice for a TDM migration is to swing end-end services. This minimizes the risk of outages since each circuit is touched once during the migration, and the customer is taken into consideration during every phase of planning, execution and testing. This approach can also reduce cost and schedule by executing with an end-to-end view of the network.
As I write this, much of Colorado is settling in for an epic 2-day snow storm. I’m hoping for another ski day in my near future. But that will mean dealing with heavy skier traffic since everyone here will have the same idea. Alas, I-70 (the highway between Denver and ski areas to the West) is one “network connection” in serious need of transformation!
Are you prepared for your next transformation program?
Portfolio Head – Network Analytics
Andy has 20+ years of experience in engineering management, business operations and IT, primarily with Tier 1 operators including Level 3, MCI and GTE. His responsibilities included leading IT development teams that built mission-critical network management, provisioning and inventory systems with thousands of users. Prior to joining Subex, Andy was a Senior Manager overseeing a Data Governance organization at a major Internet Services provider. Andy graduated from the University of Pennsylvania with degrees in Electrical Engineering and Economics (Wharton). He holds an MBA from the University of Colorado.
Request a demo