IT from the 70s holds the key to telecoms’ future

Written by on January 21, 2016 in Billing & Payments, Guest Blog with 0 Comments

Closeup of perforated punched tape on blue backgroundIn the 1970s and 80s even the idea of creating a flexible, multi-part, open ecosystem of software, hardware, network, and developers was just too far-fetched to comprehend. In those days we needed absolute control and structure.  We needed a way to model and simplify and constrain the problem space severely so that we could apply our scarce computational resources to solve the problems set in front of us. One of those problems for telcos was “inventory management and service fulfillment”.

In fact most of the world’s largest and most successful OSS Systems are built on and around the technologies and more importantly paradigm of these decades.  The key word here is SYSTEMS.  These systems were just that, well designed and engineered to do the jobs at hand.  If new jobs were required, they had to be coded into and in conjunction with the entire systems of systems and processes.

These systems have truly withstood the test of time and as such remain, by in large, intact and integral to the operations of the telco for their legacy services today.

The problem arises when we realize that these systems not only hold the inventory and business process for the legacy but that they also do so for all of  the physical infrastructure.  Sure, we all believe in a world of all-IP networking over mobile.  But we also know all too well that networks are physical entities with loads of locations, cables of all sorts, topologies, transport technologies and even copper access technologies all throughout them.  This is the state of the current art.  The world’s networks are still very much rooted in legacy transport and access technology built up and delivering services over many decades.

So what happens then when we need to create a new service that utilizes this physical, transport, or access infrastructure?  Hmmm…that’s a difficult issue that every carrier has and continues to face.  Many approaches have been taken over the years and many have struggled to deliver real value such as:

Model the new like the old: This approach simply took the perspective that we should manage all networks like we always had.  Assign, Design, fulfill, assure, etc.  The problems here are immense but mostly economic and time-to-market related.  We never really get the benefits of new technology if we wrap it in legacy operations systems and process. We get a more complex version of the solution we already have, with no real benefits.

Transform and replace:  This approach took the opposite point of view, due to many failed projects in the first category.  We should replace the current systems.  This too failed mostly as many decided to keep the process while replacing the systems!  With the benefit of hindsight, we can now see that all we got was a newer implementation of an old approach.

Federate everything and create the manager of managers:  This approach was novel but doomed.  To be able to federate all the systems you must create an uber-workflow that encompasses the underlying workflows.  All this multi-level workflow is fragile to any change and by the way, you must have an uber data model that allows your uber-workflow to act.  The inventory is mostly kept within the systems being federated so we have constant chat and syncing up and down the stack. Hardly efficient. Certainly complex.

Put it all in one system and create the unified inventory: The late 90s and early 2000s in OSS saw a fad for unified inventory projects. And despite some successes among Tier 2 and Tier 3 operators, efforts on a larger scale simply failed. Major issues with data migration, context, cleansing and quality ultimately toppled these projects [though typically only after hundreds of millions of dollars spent with a blue-chip integrator]. The vision just does not work on true carrier scale, even if it can work in a smaller scoped system for a service. The problem is that we tend to extrapolate this to be proof that the approach is valid for all services – and fail again on the same old issues.

Other variants:  Who knows, the approaches are as varied as the customers but my guess is that these too have struggled.

So where is the silver lining in this cloud of doom?

First – stop thinking that the systems themselves are at fault. They’re not. Evidence says they’ve done their job well; so well that they’re still there! (What other 30-year old tech are you still using?).

Second – how about encapsulating these systems of record? That is, representing the functions they provide to a carrier’s business as nouns and verbs.

Third – expose those nouns and verbs as a set of web services REST APIs that can be orchestrated from a Service and Resource Catalog. The important difference here between this approach and that of federated workflow is that the Catalog is defined in metadata, and consists of atomic resources and actions.  Actions or Verbs are associated with the resource for the purpose of fulfilling, using/consuming, and assuring.  No resource is aware of another resource.

So if you look at this from the point of view of the Order Management or Billing system, you see a set of orderable services.  If you look into the decomposition of the service, you see a set of components with associated workflows, charging, policy, assurance, etc models.  If you look below this you see a set of REST APIs. One step lower takes you to a broker sitting on top of a current system exposing the API and managing the complexity of the underlying system.

Finally, if you extend these concepts across the systems estates you now have a model for in situ transformation, modernization, reuse, and agility and you have a meaningful way to adapt the value of the systems from the 1970’s to the challenges and opportunities presented to the carriers of 2015.

I don’t claim that this is easy or without risks…but it’s the only way I can see to solve the real problems of Carrier OSS and BSS while enabling them to compete with their marketplace of competitors not as equals as is the case today…but on the basis of their unique and formidable assets.

Thanks all for the great response to my “open letter” blog…Its probably obvious to the reader but for the sake of clarity, I advocate an engagement model based on deep understanding and respect for the current power and even greater potential of the CSP.  The problem set is complex and the issues even more so.  I do not endorse a “sell another new SW product first” approach to solving the complex problem set described.  I do believe there is need and room for platforms to transform the CSP OSS/BSS estate but only in context and deep understanding of their current systems, business processes, and priorities.

This blog has just been some thoughts to get the conversation going on this critical matter.  A few former colleagues of mine have been wrestling with these challenges now for much of their careers as well. So much so that they have started their own business with the aim at pursuing the real and scalable solutions to the above challenges.  Check them out at

Tags: , , , ,

About the Author

About the Author: Adan is a highly energetic and experienced business and technology leader in Communications, Enterprise Software, Operations Support, Business Support, Media Delivery and related fields of study. He has worked as a senior executive, CTO, industry expert and thought leader, product manager, VP of Engineering and software engineer. Adan is also also a technical contributor to .


If you enjoyed this article, subscribe now to receive more just like it.

Subscribe via RSS Feed

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: