“It’ll soon shake your windows
And rattle your walls
For the times they are a-changin’.”
– Bob Dylan, “The Times They Are A-Changin’”
There are winds of change blowing in the communications industry, and with them are coming major changes in not just the network itself but also in how you need to manage the network, and the accompanying OSS components. Many will set this aside and say, “But the industry is always changing, and always has. We have managed so far, and we will continue to do it the way we always have!” Those are the people that are going to have some major issues in the next 5-10 years when SDN and NFV…and who knows what comes next…become a reality in our networks. Then there is the the next group that will say, “Heck, we have 10 years to worry about that. I think I’ll wait a little while before I put too much into it.” I am here to tell you that the time to move on this is today, or at least in the next 12-18 months, give or take one budget cycle.
Why, you may ask, do I need to worry about this when SDN and NFV are at best proof of concept experiments in my lab right now, and at worst something we haven’t even thought about (shame on you!)? The reason requires a bit of a journey, let’s examine some of why SDN and NFV are so important.
Customers today are expecting a little more out of service providers than they are getting for their money. We live in a dynamic world where businesses frequently see the need to do radical pivots of their business direction, which plays havoc with their infrastructure. We see the Facebooks and Googles of the world building their own infrastructure for just this reason. Most of the initiatives they undertake are things that many of you like to think you provide very effectively for your customers. So, why didn’t Google come to you to cover those needs? It is because Google, and increasingly your customers, live in a fast-changing, dynamic world that service providers just don’t get. Where a Google may need something done in 6-10 weeks, we are used to things happening in 6-12 months, or longer. We, as an industry, just can’t keep up right now with the performance our customers need and expect.
Along come SDN and NFV. We are entering a world where we will be building elastic networks. Virtual elements will be created/deleted on the fly as demand ebbs and flows across the network. Instead of months to years long projects to develop a product, put network in place, and launch…just to find that we spent millions on something nobody wants anyway…we will have product launch cycles of weeks to months. We will be defining a product, releasing it in a market, study the results, and then making Go/No Go decisions on a wider launch many times per year, at a fraction of the cost. We will have programmable networks, not manually configured components that we make talk to each other. Velocity and agility will be the watchwords of the future. Who would have thought it would be possible to refer to a service provider as fast and nimble? It’s coming, or at least for your sake it better be!
In order to realize this view of where we are headed the OSS must evolve to not be static and unyielding, much like the network it represents. With every change to the network to inject speed and nimbleness, the OSS will require a corresponding injection of speed and nimbleness. This impact will start with those OSS components closest to the network, but don’t think it ends there. Event/Fault Management will have to know how to monitor and manage a network that could look very different on a daily basis. Issue Resolution will need to know how to “self-heal” the network with no human interaction. Inventory will have to be able to accurately model and manage the network components that will now be a mixture of physical and virtual elements that appear and disappear as needed. Even Billing is going to need to be able to charge for that service that somebody dreamed up last week and wants to pilot in your Eastern Region next week…just because they can. In short, as the network itself becomes real-time and dynamic, the OSS must become real-time and dynamic as well.
This means lots of things, including:
- Event Management, which has spent 15+ years trying to minimize data hitting its backend through correlation and filtering, will have to pivot to maximizing this data so that things like Predictive Analytics can become a reality. We can’t sit back in a truly dynamic network and be reactive. Catching problems before they happen will become paramount.
- Inventory, which has spent a lot of the same period trying to consolidate disparate data sources into a single network inventory, will also have to pivot to one of federation, discovery, and integration. To manage an ever changing network it will be vital to see what the topology of the network is at that very moment. To see what elements exist in the network, both physical and virtual, at that very moment. To see the configuration of an element, at that very moment. You see, in this coming dynamic world seeing what it was yesterday just won’t cut it anymore!
- Issue Resolution today is the act of opening a ticket to a highly skilled NOC technician and letting them figure out how resolve it within the list of 4-5 other issues on their plate…on top of the other 10-100 things they are supposed to do on a day to day basis…all while praying a major fiber cut doesn’t raise its ugly head. Tomorrow it has to be OSS that sees an issue, hopefully before it happens, and can take action on the network to head that off. With the programmable nature of the coming network this will be a reality, not a pipe dream. Only the truly major issues should ever get to a technician to handle.
There are tons of other examples, but I think you get the point. The times are a-changin’, so it is time we get about the task of a-changin’ ourselves and our OSS.
Tags: No Tags Available