Yesterday I blogged about the current state of our technology-side revolutions in telecom—SDN, NFV, and the cloud. All three of these have taken a bottom-up approach to solving the problems of the industry, and while it’s premature to say that any have failed it’s certain that none have succeeded either. The reason why, I suggest, is that no matter where you start the problem of “border crossing” remains, and I’d like to dig a bit deeper into that problem today.
I dug up an old presentation by Jochen Hagen of T-Systems, given at a public Juniper event in 2008. It lays out some problems, makes a statement on what will solve them…all the stuff you see today. The solution back then was “IP Transformation” but the problem set was so close to what you’d hear today from operators that you could stick the slides into a current deck and they’d make perfect sense.
What this proves is that despite my personal penchant for top-down approaches, top-down transformation hasn’t worked well for the telecom industry. The reason for that, I believe, is that telco planners/executives can articulate what they want and need, but at some point they have to assign those wants and needs to a solution that can be defined and purchased and installed. That hasn’t worked. Transformation documents are like fiction—interesting but not representing reality.
The bottom-up process isn’t a shining example of success either. SDN and NFV are networking-centric recent “technology revolutions.” We know how to do, and to buy, both of them. The challenge for both technologies has been they have to be able to align their technology capabilities to benefits of sufficient magnitude as to fund a network transformation. That hasn’t worked. That’s the challenge that SDN and NFV trials and PoCs now face.
Why is this “border” between technology and business so difficult to cross? The answer lies in part in the fact that we’re looking for revolutionary changes in a multi-trillion-dollar industry. It’s unreasonable to expect that you’d revolutionize automobiles by changing a bolt on a bumper, and similarly unreasonable to assume that a small “manageable” change to a network is going to bring about a 25% across-the-board reduction in costs or a similar increase in revenues (or both).
You can see the effects of this in both NFV and SDN, where everyone seems to be making a point to think small. Look at the leading NFV PoCs for example, and you find virtual CPE and virtual IMS/EPC. Both are attractive but operators have been having a problem proving a big benefit case for SDN or NFV in either, largely because in both cases the operational implications of the new technology are proving difficult to assess. But even if we had a business case, how much of networking can we touch with both of these? Don’t SDN and NFV have to be useful on a much larger scale to be worth the effort and risk? If so, why are we not exploring all of the boundaries?
You can also see the border-inhibiting impact on top-down transformation plans, even the most recent. I’ve seen a number of them that lay out the benefit requirements very effectively, and thus set the requirements for technology projects that would meet the benefit case. The problem has been that when you look at the result of these plans, you see a sweeping transformation of network and operations, sales, customer support, and so forth. It touches a hundred vendors, a dozen major technology areas. It’s like giving somebody a giant pile of parts and asking them to build a car from scratch.
So how does this get fixed? I think there are two possibilities. First, we could actually work to better define our “benefit/technology border” so that crossing it from either side would be facilitated. That would let projects involving SDN, NFV, and the cloud take a more convincing shots at benefits, and let transformation projects more readily align with our revolutionary technologies. Second, we could forget both our current approaches and follow the money. Since the first of these options is what most vendors and operators favor, let’s look at it first.
The biggest problem with the benefit/technology border is a lack of a holistic architecture that unites business goals with technical elements. If you believe (as I do) that the transformation of operators will involve an application of SDN, NFV, and the cloud to their business, then there should be some sort of architecture diagram possible that shows where these pieces fit in the overall picture. Such a diagram, if complete, would be aligned with business goals from the top (as requirements to be met) and with technology options below (as features to support requirements and realize benefits).
NFV had the unique opportunity to frame the whole diagram by taking a truly end-to-end view of a service and at the same time supporting a complete service lifecycle process. That’s because NFV could have addressed services, functionality, operations, and network resources in the same model. It has not realized that opportunity, nor is it likely to do that in time to drive the market. We have no credible process in place elsewhere to do what’s needed either. We have operations processes, management processes, and network technology but nothing that really unites them. That’s why I said in my last blog that it was up to the vendors to extend NFV and envelop the cloud and SDN to create that border-crossing architecture. But vendors have become very tactical and that may be hard for even the largest to swallow.
The other option is the “empirical” approach. Forget technology revolutions. Assume that SDN, NFV, and the cloud are just new pieces from which cars can be built. Focus the efforts of all three where there’s the largest number of buyers, the greatest level of natural investment and change. Based on this approach, for example, you’d reason thusly: “Right now, most profit comes from metro services and most investment will flow incrementally to metro. Therefore, support metro in SDN, NFV, and cloud capabilities, and you’ll be available to build what’s getting built.” You could argue that this is what the MEF is doing; fix “orchestration” for a service that’s getting invested in and you can do at least something.
The problem with this approach is the classic death by a thousand cuts. If you focus on incremental projects where SDN, NFV, or the cloud can be applied without looking at any of these technologies as a whole (much less as a combined ecosystem) then you risk creating silos that will do what silos always do—undermine efficiency, agility, and economy of scale.
The solution to these issues comes back to vendors in my view. A vendor with a fairly comprehensive strategy for NFV could spread it out over enough infrastructure and service landscape to insure that key areas would be implemented and operationalized the same way even if they were driven by service-specific projects.
What technology element is critical? The answer is orchestration of everything. You have to be able to orchestrate virtual functions, SDN enclaves, cloud components, operations processes, management tools, customer interactions—everything means everything. Orchestration could be what unifies everything at the border, that turns fleeing mobs into orderly lines. It’s also something that vendors could do, directly through standards (like OASIS) or simply through the complete articulation of an architecture that’s open but beyond the scope of current standards.
Every operator on the planet has a transformation timeline that goes no further than three years out. We are three years from inception of NFV as a project and far further than that with SDN and the cloud. There’s every reason to fear that we’ll diddle around here long enough to make the work irrelevant. As I’ve said, operators have a timeline set by their business problem and they’re going to meet it, even if they have to start a new and different revolution.