Your inventory is broken. I know this, you know this (even if you won’t admit it), and everyone knowledgeable in the OSS domain knows this. Why do I feel so confident about that? Well, network inventory has always been one of the hardest things for service providers to keep up with at a level you could call anything other than “adequate”. It is commonly accepted around the industry that most companies network inventory is somewhere around 70% accurate, on average. I have personally seen that vary anywhere between 30-40% up to 80-90%, so my experience certainly backs up the 70% standard estimate. It is so accepted that this is the number that most providers will throw out there, regardless of whether they have any idea what the real number is.
It is all too common to see service providers complete automation projects and never quite get the ROI they expected. They always seem to wonder why. The reason is that almost without fail when these projects are being dreamed up there is the “should we fix our inventory issue first?” conversation. What follows is, “we’ll do it later” or “it’s too expensive”. Why does this happen? Automation is sexy, and therefore gets the bulk of the budget; inventory is not. Hence the reason that inventory is never as good as it should be, i.e. “broken”.
So what in the world does Software Defined Networking and Network Function Virtualization have to do with making this problem even worse than it is today? I am glad you asked; let’s dive into a couple of areas and see. The key areas I want to talk about are: physical elements, virtual elements, and services, all within the paradigm of an elastic, programmable network.
The first part is the good news, and that is that the physical elements in the network are never going to fully go away. There will be a physical element to the network until the end of time because you have to have somewhere to plug that cable. Even if you are talking wireless, you will have antennae to send and receive those signals. To manage these items we will be able to keep on keeping on with current systems in use today for inventorying routers, switches, fiber nodes, et al. We have all agreed this isn’t really done all that well today, which should be the first scary part of this picture. The key point here is, you have people that are managing to make do with what they have today, and that is not going away.
Current inventory systems are good enough at managing static elements that don’t change that often, if ever. That means that they can include certain configuration details about those elements, and even the services that traverse those elements, and there is no worry about something getting too out of sync with the live network. What happens when the network elements, applications, and services involved become very dynamic? In that world you can’t generate an engineering work order that is manually worked for every change that comes across. Virtualized elements will be automatically created and deleted as the network demands and I think it quickly becomes obvious that the current static management methods just don’t work in this emerging elastic world.
The future network will also have services that the customer can change on the fly with no order, at least not in the traditional sense. How will you manage service inventory in a system that requires an order when the customer may change that service on a daily/ weekly basis as their needs change? The answer certainly isn’t to hire enough people to keep up with keying the orders required.
The answer to all of this is not to scrap current systems and start over. The answer is to tackle the inventory issue on multiple fronts by implementing a federated solution that leverages your legacy systems along with the new systems that will be introduced with SDN/NFV implementation. In order to do this you need to introduce some central, federation engine that will reach into the legacy systems and can interface to the real time changes that will be happening in the network. One of the key components that will have to be in place to make this work is a centralized Network API that exposes the network topology and corresponding network elements to the inventory system. The details involved here will not extend to the physical attributes (you have those covered by your legacy systems), but will include the logical elements, configuration of each of those elements, and the services that traverse that topology, including configuration of those services.
The bottom line is that the physical inventory is not going away. You will still need your MetaSolv, Granite, Amdocs Cramer, etc systems to track the physical network. You will still need your GE SmallWorld, and similar, systems to track the physical assets of the outside plant network. What changes is that you will also need a real time OSS view of your network that automatically changes in line with the dynamic nature of your network, with a key phrase being “real time”.
Now making this happen…well, that is the fun part! Let’s tackle the how of this another time.
Tags: No Tags Available