As we move into a new year some things have become very clear. Some of these are things we have known for a while, some are revelations from working with clients, and some are things we SHOULD have known all along.
There are many efforts going on within service providers and enterprises alike at the moment. There is the work to maintain legacy operations and service offerings under the weight of declining, or at best stable, revenue with a constant, and sometimes increasing, cost of maintenance. There is the effort to introduce new service offerings in an increasingly competitive market, and then trying to operationalize these items with a very immature set of management tools. Lastly, there is the need to look ahead at what is next, weeding through all of the promises and vendor speak of how great the newly emerging tech is going to be…if you go with THEIR solution.
In the world of legacy products, services, operations, and the OSS tools supporting those items these are the same challenges that have existed for 10+ years. Inaccurate inventories, too many tools that don’t integrate with each other, and too many vendor elements in the network that require you to have adapters and “resource drivers” in untold numbers to be able to automate management of them. The sheer number of integration points that grew over the years prevented the dream state of “zero touch provisioning” from ever becoming a reality for more than a few isolated corner cases. This resulted in providers just throwing people at the problem and having large provisioning centers to manage their networks via brute force.
Now, those legacy products are evolving in some cases, and about to be retired in others. This process will take years to happen, and companies are not necessarily willing to keep investing the human cost it takes to maintain these products and services.
Add to that the introduction of new services made possible by the “information age” and the ability to access networks anywhere, at any time. These are, many times, being implemented and heaped on top of this rickety old OSS architecture that can’t adequately automate what it is already responsible for, much less be flexible enough for these new services. The issues above are just compounded by this extra load.
Lastly, by now every service provider at least has NFV/SDN “science experiments” going on in their labs that will not only accelerate the introduction of new, more complex services, but will also introduce fundamental changes to the networks themselves. These “science experiments” are being carried out by organizations that have no concern over how to operationalize these new technologies, which further escalates the potential disaster facing providers if something isn’t done. Not only will these new services further stress an already tenuous OSS situation, but in some cases introduce technologies that legacy OSS has no clue about how to manage…at all.
So, is there an answer? Is doom and gloom the only possible outcome ahead? Do we need to throw in the NFV, SDN, and virtualization towel because the weight of it is impossible to bear?
No, of course not!
There is something that has to be done. Networks have to become programmable. Management systems have to become dynamic. OSS architectures have to become capable of adding and removing tools in a seamless and non-disruptive to the user manner.
Legacy tools are not going away, so there needs to be a platform put in place that will federate the data and capabilities of these tools. This platform MUST consume southbound capabilities and data and present it to users in such a way that they are abstracted from the underlying sources of those capabilities and data.
This platform must also allow for the addition of new tools as they are introduced to handle the new NFV/SDN based services to come. The platform must allow removal of legacy tools as the technologies they manage go away. None of this activity should be noticeable to platform users.
This platform must be model based, whether that be housing of models within its own database or federation of models from southbound systems. As next generation OSS tools emerge more and more of them are model based tools. They are utilizing standards such as YANG, TOSCA, and YAML-based models in things like HEAT templates for OpenStack. Due to the various standards, and extremely valid reasons for each of them existing, it makes much more sense…and is much more efficient…for the platform to federate models from these new tools.
This platform must integrate to an orchestration layer that not only works with the new NFV/SDN based network elements, but also brings a level of programmability to legacy network elements to allow a path toward operational convergence of virtualized and legacy network management. The platform, working with the orchestration layer, should tear down operational silos and allow a consolidated view and management of the network and services the traverse that network.
All of this must be easily managed, dynamic in how it manages data…meaning as real-time as possible, and must chip away at the number of tools in place today…over time.
Itential has our story of what this answer is. The tools exist. The need is overwhelming. The time to start fixing the problems is now.
Tags: No Tags Available