One of the recurring points I make in my blogs about SDN and NFV is the need for a business case. Most are aware that “business case” means a financial justification of an investment or project, but I’ve gotten some questions from some who’d like to understand a bit more about the process of “making” one in detail.
At the high level, a business case starts with the return on investment for the project, which is the net benefit divided by the investment (roughly; you have to include other factors like cost of money). This ROI is compared with a corporate target set by the CFO, and if it beats the target the project is financially justified. This whole process is fairly well understood, and it’s been applied by enterprises and service providers for decades.
What makes business cases challenging for technologies like SDN and NFV is the notion of “net benefit” when it’s applied to either cost savings, revenues, or a combination thereof. Revenue-based benefits are always challenging because you have to quantify how much revenue you would gain, and also explain why you hadn’t already gained it. Cost-based benefits are challenging because you have to consider the total impact on costs, which is not only larger than “capex” alone, it’s actually larger than total cost of ownership.
On the revenue side, let me offer an example. Suppose you have a thousand business customers for a carrier Ethernet service that includes some firewall and other CPE-based features. You determine that you can accelerate the provisioning of these services by a month. How much revenue have you earned? A month’s worth? Perhaps, but probably much less than that. The reason is that you’ll gain time-to-revenue for new deployments, and we didn’t identify how many of them there were. We also don’t know whether a given customer would actually take the service a month early or would delay ordering. If a new branch office opened on September first, would your enterprise say “Heck, if you can light up my Ethernet a month before anyone even moves in, that’s fine?”
On the cost side, suppose we could replace that Ethernet CPE with a cloud-hosted equivalent. The box costs two grand today, so do we save that? Not likely. First, you need something to terminate the service on premises, so we would simplify the box there but not eliminate it. Second, we are making a potentially fatal assumption by assuming the only cost is capital cost. The operational environment associated with cloud-hosted functional elements is surely higher than for a single box. Even if we don’t know that for sure, we’d have to validate the assumption it wasn’t. Then, we’d have to look at the question of whether we would impact other costs, like customer support calls to inquire about the status of a service. You need to understand the impact on all costs to determine the benefit, or lack thereof.
When CFOs look at SDN or NFV projects, or at other network projects, these are the things they look for. What has made things difficult for SDN and NFV sales is that the trials and tests that have been run on the technologies have not addressed the range of cost and benefit qualifiers I’ve noted here (which are only the most obvious ones). A CFO is presented with a comment that they could save 25% in capital cost by replacing multi-feature physical devices on premises with a combination of basic service termination and hosted functionality. OK, says the CFO, what will it cost to operate this? In nearly all cases, the CFO won’t get a complete response.
Then the CFO says “What will the impact be on service availability and customer support? Will I have to credit back for outages because I missed my SLA? Oh, you can’t tell me what SLA I can write? And if the customer calls and says the service is out, you can’t really be sure whether it is or isn’t?” You can imagine how well this sits in a financial review.
The cost of a router or a switch can be higher than the cost of a virtual one in a capital outlay sense, but you can see that even traditional total-cost-of-ownership metrics won’t fully address the “financial cost” challenge, and that’s what you need to determine a business case. Operators know what it costs to run networks based on legacy technology. Yes, it’s too much. But they can’t accept a statement that SDN or NFV will make it better as proof that will happen, and that’s what they’re asked to do if a given SDN or NFV trial doesn’t validate operations impact to the point where opex cost comparisons with the legacy network can be made.
There’s also the question of “risk premium”. If you give a buyer two choices—one known and the other unknown—to solve a problem, they will pick the known approach even if the unknown one has a slight advantage. They don’t want to face a risk unless they have an ample justification. With SDN and NFV, operators are not confident that the business case is easily met, so they can’t presume enormous financial benefits. Thus, they have to reduce that risk premium, which means they have to answer some of the knotty questions like “How many servers do I need to achieve reasonable economy of scale?” or “What is the MTBF and MTTR of a virtual-function-based service chain?” They may even have a basic question like “What happens if I start deploying this and it doesn’t work at scale?”
Sellers can address the risk premium problem by demonstration, meaning that they can propose and run tests that show what can be expected of SDN or NFV operations at various levels of deployment. They could also discount or make other commercial concessions (loan equipment, etc.) to address this premium, but they can never simply propose that it not be imposed. They can never expect operators to buy without an adequate ROI, either.
In rough terms, operators are saying that SDN or NFV deployments that save less than about 20% in costs are not going to fly because they can achieve those levels of savings by pushing vendors for product discounts on legacy equipment. The need for better benefits is one reason why operators (and therefore vendors) have moved from pure capex reductions to capex/opex/revenue benefits for SDN and NFV. But capex is nice because you can apply it to a box. When you start to talk opex and revenues, you’re talking now about service infrastructure as a whole, and that’s what is making things complicated now.
So you’re an SDN or NFV vendor and you want to “make a business case”. What do you do? First, you have to identify the specific impact of your approach on revenues and costs, overall. That means running at least some credible tests to establish either that operations of the new infrastructure is completely equivalent to the old, or what the differences would mean in cost terms. Second, you have to point to specific proof points that would validate your tests, and finally you have to work with the operator to devise a trial that would demonstrate behavior at these points.
The big hole in all of this is operations, which is what it was from the first. Because we don’t have a mature management model for either SDN or NFV, we can’t easily validate even basic infrastructure TCO much less total cost impact. Most of the purported SDN or NFV vendors don’t have a management solution at all, and those who do have been constrained so far by the limited scope of trials. It might be a slog to make a limited trial big enough, to include enough, to make a business case, but it’s nothing more than applying a process that’s been in place for decades, and we don’t have a choice.