Suppose you’re a network operator and you want to run an NFV trial. You need to make a business case to justify a considerable NFV program. Given all of the difficulties that you know others have faced, what do you do? This is a nice question to end a week on, so let’s look at it in depth.
The first step is to identify your specific benefit goals that, if met, will drive the deployment you plan. The three classes of NFV benefit are capex reduction, opex reduction, and improved revenues. Your project should address them all, and here are some quick guidelines:
- For capex reduction, be sure that you look at total cost of ownership and not just at capital costs, and be sure that you consider how big your “positioning deployment” to offer services will be, and how much (if any) write-down of existing equipment you’ll have to cover in costs.
- Opex reduction will depend on your introducing a lot of new service automation, and the biggest problem prospective NFV users face is having insufficient scope to do that. Services typically involve more than NFV, they use some legacy gear as well. Can you automate deployment and management there? Also look at just what your operations integration will require, by looking at two cost areas—deployment of services and ongoing management. Also be wary that you don’t establish an NFV deployment so complicated that it’s operationally inefficient.
- Service revenue gains need to be based on three things. First, what are your specific prospects for the new service, the buyers who will supply the revenue? Second, what will your sales/marketing plan look like? How will you reach and sell these people? Finally and most important, how will NFV contribute to the success? Generally there are three ways it could happen—faster time to market, lower price created by lower NFV cost points, and creation of features not easily provided except through hosting. For each of these ways, outline explicitly what you expect.
The next step in your NFV process is to defend your benefits by aligning them with technical requirements. If you need a certain capex reduction, size up the new and old infrastructure side by side and look for places where your “NFV cost” could be suppositional or downright wrong. If you count on opex, look at the target services and current costs and ask what specific steps will have to be taken, then how you can prove that NFV can take them within your trial. For new services, customer surveys and competitive reviews are invaluable, but don’t neglect asking “Why wasn’t I selling this before, successfully?” and then ask what specific things NFV will do to make things different.
You’re now ready to look at the trial overall. Your trial has to prove the technical requirements that defend your benefits. When the CFO asks “Where does this number come from?” you have to be able to pull out you results sheet and show the derivation. Generally, the technical requirements will group themselves into three areas:
- Virtual Network Function requirements. You need VNFs to host in order for NFV to deliver anything, so know what your VNF source will be, and in your trial be sure to include the process of VNF onboarding, the introduction of a VNF from a third-party into your deployment framework. Watch for VNF pricing and licensing model issues here. Early cost management favors pay-as-you-go, but this can impose a large uncapped cost down the line. Also watch for the hosting requirements for VNFs; if you pick a set that need a lot of different platform software (OS, middleware, etc.) you may create operations cost problems or fragment your resource pool.
- Network Functions Virtualization Infrastructure (NFVI) requirements. You will need server hardware, virtualization hypervisor or container software, a cloud management or virtualization management system, and operating system (or systems). One fundamental thing your trial must establish is just how many VNFs you can run per blade/core or whatever measure is convenient. This will generally mean the number of containers or virtual machines, which depends on processor performance and (most often) network interface performance. Users who have tested NFVI report that different platform software performs very differently, and that hardware and software acceleration of network performance is almost sure to be critical in meeting VNF density requirements. Test your density assumptions carefully and insure that you’ve made the optimum choices in software components for NFVI. Also, be sure that your NFVI vendor(s) provide an Infrastructure Manager that links their stuff with the rest of the NFV software.
- Management and Orchestration. This is going to be the hardest part of your trial planning because it’s probably central to making the business case and it’s very difficult to even get good data on. There is no such thing as a “standard” implementation here at this point, so the most important things to look for are openness and conformance to the technical requirements that defend your benefits. Look for:
- Support of whatever legacy technology you need to manage to meet your business case.
- A strong VNF Manager core functionality set so that VNFs don’t all end up managing themselves and creating management silos that will make efficient operations difficult.
- Integration with operations systems to link all this efficiently to OSS/BSS tools and processes. Make sure that you understand what’s needed from the OSS/BSS side, and cost that out as part of your justification.
- Service modeling and how it relates to VNFs. You should be able to take a service through a complete lifecycle, which means defining the service as an orderable template, instantiating it when it’s ordered, deploying it, managing it during in-life operations, and tearing it down. Service automation automates this, so be sure all the steps are in place and that automation tasks are clearly identified.
The next step is picking vendors, and there are three main options to consider here. First, you can select vendors in each of the areas above—a “best-of-breed” approach. Second, you can select a key vendor who is most connected with the technical requirements that make your business case, then let that vendor pull through tested partner elements. Finally, you can get someone to act as an integrator and assemble stuff on your behalf.
Operators have had some issues with a “one-from-column-A” model. Because the standards for NFV are far from fully baked, it may be very difficult to even get things to connect at major interface points. It’s even harder to get vendors in this kind of loose confederation to own up to their own roles in securing your benefits. The best approach overall is likely to be to find the vendor who can make the largest contribution to your benefit case and have them run the show on your behalf.
The “prime vendors” most likely to make the whole thing tick are at this moment Alcatel-Lucent, Ciena, HP, Huawei, Oracle, and Overture Networks. Where integrators come in is when you like one of these vendors as your central NFV framework but don’t want them to take responsibility overall, either because they’re small or because you have no experience with them. If you have an integrator you can trust, this is a good place to get them involved. But get your integrator to contractually validate your plan and benefit trajectory, or agree on an acceptable set of changes before you start the project.
Now you’re ready to start the trial, and here the most important point to remember is to keep focused on your plan and defend your benefits. Your trial should test every assumption that must be true for your benefit case to be valid, and it’s very easy to get distracted or gloss over points. It is desirable not only to say “I can make this particular benefit work” but to be able to show the range of value of key variables under which it will still work. If you assumed 20 VMs per host, will your case work at 15, and how much better might it be at 25? Most successful trials do this kind of sensitivity analysis on their key variables.
Your trial should also, as a part of its results, recommend the next step. The general progression you see is lab trial to field trial to limited deployment to full deployment. In most cases you should assume that a successful trial sets the parameters for the next normal step, but there may be situations where you either want to skip a step (you blew away the benefit case) or you need to go back to a prior step (into the lab, for example) to work out a wrinkle in your approach.
Operators tell me that a good lab trial will take about nine months to complete, and a field trial can vary from six months to a year or even more. Everyone agrees that good planning and organization up front will shorten the trials without increasing risks. They also tell me that some “NFV vendors” are declining to do a trial under some conditions, claiming that the approach is wrong or whatever. In a few cases they’re right, but in most it’s because the vendor doesn’t want to devote the resources or doesn’t think the results will favor them. Obviously you need vendors to do NFV, but you may have to play hard ball with some to prevent them from hijacking the process and creating a trial that won’t make the business case.