To solve some if its orchestration and automation issues, AT&T developed ECOMP, which included 8 million lines of code, and later put most of ECOMP in the Linux Foundation to help create ONAP. In parallel, ETSI has developed its own Open Source MANO architecture and code. ETSI MANO was often called the light version of ECOMP, as there was not concept of assurance or closed loop assurance incorporated. All of which, according to Lean NFV, made NFV more complicated.  

Service providers and vendors were caught up in almost-endless developmental cycles to make NFV work, but instead NFV made things even more complex. The ECOMP successor ONAP made a lot of waves with different versions—known as Amsterdam, Beijing, Casablanca—and, according to critics, none of them had a successful production story. With the introduction of Lean NFV, however, there is hope that newer technologies such as Kubernetes may be able to help streamline the processes.

The term AI (artificial intelligence) is being widely used by marketing, sales, CTOs, and CEOs deliberately to raise the bar for the next generation of intelligence. As an old machine-learning (ML) academic and veteran myself—and basing my perspective on many discussions with experts across our domain—I offer the conclusion that most so-called AI would be better classified as digital intelligence (DI). What is being called AI today constitutes mostly digital decision trees that can make decisions for us versus a fully independent intelligence that can decide which decisions it wants to make. 

The fact is that ML and DI (but not AI) could make a lot of things better for us. But this isn't a mature product category. We still have to obtain training data sets to make use of it and teach our algorithm to run. Without the underlying data and training, not much can be done today. In many future challenges for the telecom industry—for instance, the distributed edge—a ML/DI distributed intelligence would be very handy. But again, there can be no machine learning without the underlying data sets, and ergo the approach isn’t viable as it currently stands. The data needs to be gathered and ML-trained, and new products must be rolled out for individual use cases. Customers and suppliers have to provide input based on joint venture and DevOps methodologies to master these challenges.

The transition of OSS from voice to digital will not happen overnight. We still need experts to provide us with standards and best practices to build comprehensive solutions. The TM Forum, with their eTOM, did a great job in the past to provide guidelines on how to categorize different products into different groups based on categories and a suggested architecture. Today we have many groups and institutions that are undoubtedly experts, making many different suggestions, depending on which groups they belong to. And opinions differ. For example, some ETSI MANO experts suggests to hold an information model at the orchestration layer and diminish the value of inventory systems—and potentially even create some inconsistencies with inventory.

The Future of Digital OSS

At Ziotis, we are looking forward to the future and building a highly scalable, data-driven OSS that can enable real-time hyperautomation by leveraging open APIs, and that can act autonomously by using DI and other automation technologies such as robotics process automation. This is what is needed now, and it represents the future of OSS.