Here we are: the first quarter of a new year, and in many cases with a new outlook on life — and work. No one will argue that this is very typical this time of the year, when resolutions and good intentions take precedent — at least for the first month or so of the year.
While many resolutions fall by the wayside before February, I do believe this is the year of the new network focus. Jumping off the headlines of 2018, I think this will be the year of all-that-is-5G. This will no doubt have companies focusing the majority (or at least much) of their resources on building out the networks required to support the 5G juggernaut, and their quest to be first and best.
This should be very good news for the fans of ISE magazine. However, it is imperative that everyone keep in mind the fact that there are a lot of customers riding on the existing wireline networks despite continued cord-cutting trends. The trick for companies will be maintaining, or improving, service to this customer base without pulling resources from the aforementioned 5G efforts.
Luckily companies have a tool at their disposal that can help with this effort — and that tool happens to be the Network Transformation (NT) efforts that we discussed throughout 2018. (How’s that for a tie-in?)
At this point in our journey I do not think anyone can argue with the benefits of moving customers from a costly, somewhat antiquated (from a current market demand perspective) infrastructure. Better service, greater resiliency and expanded capacity for things like faster broadband are all givens at this point. Yet despite this I still feel many companies hesitate to push their NT strategies into the next higher gear.
I believe this is due to the fact that many companies continue to struggle with the demands (i.e., work) associated with migrating the right customers. As a result, when it comes to allocating resources, the new and shiny stuff gets the glory while older networks fade into the background.
Unfortunately, this fade can be costly in and of itself. It can also be very noisy in that people using these networks have, in many cases, no real alternative for their needs, so when things break, they start screaming.
So, the question is pretty clear. How can we drive down the overall costs associated with NT?
In our last column, we focused on one NT partner’s focus on streamlining the OSP processes and equipment in an effort to optimize efficiency and thus accelerate NT capabilities. Thankfully, there are many other equally qualified partners focused on improving things, so I think this end of the NT world is in great hands. (BTW, this also helps with the construction of 5G networks, so the work of these partners produces many benefits.)
Unfortunately, I’m not sure that this is the case when it comes to internal or back-office carrier functions — all the things that help to identify the right universe of customers ripe for NT migrations.
As we discussed last year, NT is a very manual, labor-intensive process, with NT teams working tirelessly to not only identify the right customers, but to also ensure that these customers enjoy a smooth, seamless transition. It is a lot of work cleaning up databases and writing service orders, and it ain’t easy.
But why is this so manual, given all of the advances over the years?
To figure out why this is, I think it’s necessary to look backwards a bit to see what drove all of this. Lucky for me, I happened to be talking to Bill Doyle, CEO of Dexter Systems. Bill is one of the sharpest people I know, and he’s helped me figure out things like this for long time.
Bill believes that all of this can be tied back to a software evolution concept known as Technical Debt. In particular, Bill was talking about one of Manny Lehman’s and László Bélády’s 8 laws of software evolution: Law 2. “Increasing Complexity”, dating back to 1974.
Lehman and Bélády believed that as IT systems (i.e., software) evolve, things become more complex unless work is done to maintain or reduce the complexity.
This makes perfect sense to me because while I’ve seen great advances in the IT world over the years, most if not all of this work has been focused on the future — that is to say, it’s pretty rare to find companies devoting a ton of resources to yesterday’s systems.
In addition, I think we all have to admit that while the aforementioned advances have been great, some of the changes we’ve seen over the years have been a little less than perfect. (How many bug fixes are issued for even the best of software platforms these days?)
Unless this lack of perfection is immediately addressed, the resulting issues are compounded over time.
When you take this and add in human frailties (i.e., things like fat fingers) you inevitable wind up creating work for the future. For example:
• Imagine it’s Friday night at 5:00 p.m., and a tech hustles to get a customer back in service but doesn’t update the records on a pair swap. If the tech fixes the records on Monday — no harm, no foul. But if the records never get updated, the company will incur a Technical Debt that the company will pay, plus interest, the next time the customer goes out of service.
• A customer orders a special feature via a service order, but for some reason the service order never completes. Translations may be manually adjusted when the customer calls to find out what happened to their feature, but the customer service record is never fully revised. What happens next time that switch is updated? The feature drops. More Technical Debt.
Sound familiar? I’m sure that everyone has encountered something like this along the way.
Imagine then the complexity of looking at an entire wire center of customers (and issues) when you’re trying to migrate them off of their old facilities onto new ones. This is where the NT teams earn their stripes.
Unfortunately, this can all be very costly if you plan on ramping NT activities — hence the dilemma.
In our next column I will look at what one company is doing to eliminate a good chunk of this Technical Debt while simultaneously addressing the underlying issues, many of which have been festering for years.
Lehman’s laws of software evolution. Law 2: “Increasing Complexity” — as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it.  Lehman, M. M. (1980). “On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle”. Journal of Systems and Software. 1: 213–221. https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution#cite_note-laws1-5-4.