I got a laugh at a conference back in the past when I commented that to the media, any new technology had to be either the single-handed savior of western culture, or the last bastion of international communism. Anything in between wasn’t going to generate clicks on the pieces, and it was too complicated to write in any case. Clearly we’re at that point with NFV. Two months ago it was a darling of the media. Apparently the honeymoon is over, and the focus of the disillusionment is the difference between “workable” and “makes the business case.” What’s interesting is that the points are valid even if the emphasis on them is a bit belated.
A Light Reading piece quotes the BT rep on the NFV ISG as suggesting “Shouldn’t we take an end-to-end process perspective and understand how they’ll work logically and then map that back to the architecture?” with respect to how NFV should have been architected by the ISG. Well, yes, it should have and I know that I raised that point often, and so did others.
The original vision of NFV was that it would be valuable to substitute hosted software and commodity servers for high-priced purpose-built appliances. That is absolutely true on the face. Over time, the NFV community realized that this simple value proposition wouldn’t generate the benefit case needed to offset the technology investment and the risk. As a leading operator said two years ago, referencing the 20%-or-so savings that could be obtained from capex reduction, “We can get more than that by beating Huawei up on price!” Huawei by the way was in the room for this.
The operators who launched NFV updated their vision of benefits over time, to focus more on service agility (by which they told me they meant automated service lifecycle management) and operations efficiency. By this time, though, the basic model of NFV as we see it today had already been established. BT is right in suggesting that the detailed cart got before the end-to-end horse. They’re also right in the implication that the business case would have been more easily made had the body started at the top, with functional requirements.
The current situation is reflected in yet another Light Reading piece that starts with some Vodafone complaints and includes a response from a vendor, HP. The complaint was that vendors had showed no initiative in establishing open interfaces. Is that complaint valid?
Vendors have, on the whole, pursued their own agenda in the NFV ISG, as they do in all standards bodies. Some of that was because vendors tend to dominate standards processes on simple numbers alone, but some was also a lack of foresight on the part of the operators. The E2E model was written by an operator, and the fixation with APIs and the confusion that exists on the role of the blocks in the diagram stem from that original picture and its lack of a clear link to functional requirements and benefits. The interfaces that were described in that early E2E model guided the rest of the process.
Vodafone also complained about the PoC process, saying that the PoCs didn’t reflect the issues of a commercial deployment. Also largely true, but again it’s probably unfair to single out the vendors for the failure. Every PoC had to be approved (I know, I submitted the first one). The problem with PoCs lays partly with the architecture that was supposed to be the reference, and partly in the fact that the initial ISG meetings declared operations, end-to-end management, and “federation” or creation of services across domains as out of scope. All of these are first essential in making a business case for commercial deployment, and all of these are areas where operators now want open interfaces. It’s no wonder that HP’s spokesperson, who is in my view the best NFV expert out there, expressed some frustration.
Operators aren’t blameless here, but neither are vendors. This isn’t anyone’s first rodeo here, and vendors have ignored the problem of the business case for NFV from the first. At the least, they went along with shortsighted planning of the ISG’s efforts, the bottom-up approach. Even vendors like HP, who has in my view the very best solution available today, hasn’t put together a compelling business case according to my operator contacts. No wonder operators are frustrated.
We even have to go back and implicate the media. How many stories on “NFV announcements” have we read? There are by my count approaching 50 vendors who’ve announced something regarding NFV, and at least 20 who claim to have an “NFV solution.” Of this, perhaps six have the actual features needed to make a business case. Why, then, don’t we talk about the fact that most NFV vendors could never hope to make a business case and have useful products (at best) only when they fit into someone else’s story?
Within the ISG and in the media, we’re starting to hear about the pathway to fixing all of the early shortcomings. The solution lies in modeling, or more precisely the way you model. Intent models describe what you want, your “intent” or the end-state. Implementations based on intent models translate intent into resource commitments, which is the most general and open approach. If the key interfaces of NFV were defined in intent-model terms they’d be open by definition. Intent models make federation across domains easy, so it would be easy to build NFV at the operator level even if you had some implementation silos. In fact, it would be fair to say that intent models make silos (as we normally use the term) impossible. Intent models can translate into NFV, SDN, or legacy resource commitments. If they are used to define how NFV relates to operations, they can address all the elements of the business case. They even map pretty nicely to the TMF structure.
The problem today is that we are trying to address early errors in process, scope, and focus even as we’ve approved almost 40 PoCs. Are these useful? Yes, in that they prove conditions under which NFV can work. The complaint that they don’t lead to commercial deployment is as much a complaint about the PoC standards as the PoC execution. We went down the wrong path, and I know my own complaints about that were heard by operators as well as by vendors. With the ISG work focusing way down in the depths of detail without the proper functional foundation, it will take years if the problem is addressed the way that the ISG has addressed developing the specs in the first place. Open-source efforts linked to the ISG won’t be any better. We have to change something.
OK, so let’s stop the blame game and focus on what could be done.
The first key step for the ISG to take is to have the operators lay out the basic framework needed to realize the benefits that could justify NFV. Specific PoCs on each would be a start, and having ISG leadership bend the media to focus on the points would also be helpful.
The second step would be to explore what the other SDOs might contribute, through existing liaisons. The TMF, OASIS, the IETF, and the OMG, all have credentials in the space. Can they step in to be helpful and make some quick progress?
Maybe, but in the near term at least and perhaps for a very long time, this is going to depend vendor initiatives. This industry has sunk a boatload of money and effort into NFV and there’s no question that it’s at risk. I know that most vendor salespeople and many vendor executives know darn well that the picture I’m painting here is accurate. The year 2016 is absolutely critical, and so I think that vendors would serve their own best interest to try to fix what’s un-fixed and get this all moving. And yet, perhaps because of the lack of media attention on the real problems and lack of operator push on specific paths to making a business case, even the vendors who can make the business case don’t present their wares effectively enough to prove that.
There is little that needs to be done here. We have at least five and probably six implementations of NFV that can do what’s needed. Media: Herald this group. Make them famous, household words (well, perhaps, boardroom words). Competitors, either ally or truly compete and offer a full-spectrum solution that can really make the business case. And back to the media, call out those vendors who claim revolutionary advances when they’re not moving the ball at all.
And now you, operators. Get your house in order. You need the CIO and the CFO engaged on NFV and you need to operationalize and justify it. The scope of the current PoCs is what you’d expect given the process is driven by standards and technology people. I don’t believe that all the vendors doing vacuous crap would keep that up if operators put their feet to the fire whenever they made some stupid claim or failed to make a case beyond “believe me.” BT, Telefonica, and some other vendors are now spending on development to try to take up the slack. Others need to do the same. It’s your revenue/cost curve that’s converging, after all.
The problems of NFV can be fixed in six months or less. Fix them, all you stakeholders. It will be less costly than inventing another revolution and surviving until it succeeds.