What do Juniper and Nokia have in common, besides the obvious fact that both are network equipment providers? The answer may be that the two are both trying to gain traction by making generalized SDN products more mission-specific. “Laser focus?” Juniper has announced a multi-cloud application mission for Contrail, and Nokia’s Nuage SDN product is getting a lot of operator traction as an SD-WAN platform.
What do they have in common with the major operator focus? Apparently not much. At this very moment, ETSI has formalized its zero-touch automation initiative, which appears to be aimed at broadening the architectural target of automation. Is this “laser unfocus?” Is there something going on here that we need to be watching? I think so.
If you’ve followed the path of SDN and NFV, you know that both concepts burst on the scene to claims and stories that were nothing short of total infrastructure revolution. Neither of the two has achieved anything like that. SDN has had success in cloud data centers and in a few other applications, but has had no measurable impact on network infrastructure or operations so far. NFV has been adopted in limited virtual-CPE applications and in some mobile missions, and in both cases has achieved these limited goals by narrowing its focus. For vendors who need something to happen, this is a reasonable thing.
The common issue with SDN and NFV is one I’ve blogged about often. “Transformation” isn’t a half-hearted thing you can tiptoe into. The definition of the term is “a thorough or dramatic change”, after all. If you apply it as network operators have for a decade now, it means a revolution in the business model of network operators, created and sustained through a comparable revolution in infrastructure. In short, it’s big, and in the interest of making progress, neither SDN nor NFV have proved big enough.
Big change demands big justifying benefits to achieve a reasonable return on investment, and the problem with both SDN and NFV is that they have too narrow a scope to deliver those benefits. In particular, both technologies focus on the infrastructure, not the total business model, and that’s where transformation has to start. That decision by ETSI to launch a new zero touch automation group (properly called “Zero touch network and Service Management Industry Specification Group” or for short, ZSM ISG) is an acceptance of the need for a wider swath of realizable benefits, and also I think of the fact that the current processes, including both the ETSI NFV ISG and the TMF, are not going to achieve that goal fast enough, if at all.
Vendors aren’t going to throw themselves on the fire, though, so you’d have to assume that there was buyer receptivity for narrower missions, and there is. Operators want transformation at one level, but at another level they also want to, even have to, do something right now. Vendors, who are already seeing SDN and NFV take on the trappings of multi-generational abstract research, are certainly interested in making their numbers in the coming quarter. It’s these two levels of behavior that we’re seeing in the news I cited in my opening, and the “right now” camp is resonating with vendors with that same short-term goal.
That leads to the question of whether an architecture can even work at this point, given the mission-focused, disconnected, progress. In past blogs, I’ve pointed out that it’s difficult to synthesize a total service automation solution from little disconnected pieces. Yet, we are seeing one camp moving toward bigger architectures and another moving to smaller applications of current architectures. Surely having the goals rise while the applications of technology sink isn’t a happy situation.
The need to unify architectures and missions created the “proof-of-concept-low-apple” view of transformation. You sing a broad and transforming tune, but you focus your attention on a set of limited, clearly useful, impact-conserving pieces of the problem. The theory is that you can apply what you’ve learned to the problem at large. We know now that isn’t working; if you focus on small things you tend to design for limited scope, and transformation (you will recall) is revolutionary by definition. Hence our split, with vendors specificizing even the already-limited-in-scope stuff like SDN and NFV, and operators looking to a new and broader body to handle the real transformation problem.
Is either of these things going to end up in the right place? Can we, at this point, address the broader goals of proving “necessity and benefit of automating network and service operation in next generation networks”, as the ZSM ISG white paper suggests? Will vendors, seeking quarterly returns through limited applications, be able to later sum these limited things into a glorious whole?
Those who won’t learn history are doomed to repeat it, so the saying goes. The operators have now accepted the biggest problem with their earlier NFV initiative—it didn’t take a big enough bite out of even the low apple. We can assume, since their quote demonstrates the correct scoping of the current effort, that mistake won’t be repeated. Vendors like Juniper and Nokia should see that enterprises and service providers all want transforming changes, so we can assume that they will frame their local solutions so as to make them extensible. What we can’t assume is that operators won’t make a different mistake by failing to understand the necessity of a strong technical architecture for their transformed future. Or that vendors will somehow synthesize an overall approach from steps whose limited size and scope were designed to avoid facing the need for one.
Recall that we have, in the industry today, two camps—the “architecture” camp and the “mission” camp. Whatever you think the balance between the two should be, there is one crystal truth, which is that only missions can get business cases. You can’t talk about transformation without something to transform. What is less accepted as a truth, but is true nevertheless, is that absent an architecture, a bunch of mission-specific advances advance to mission-specific silos. That’s never efficient, but if what you’re trying to do is transform a whole ecosystem, it’s fatal. The pieces of your service won’t assemble at all, much less optimally, and you’ll have to constantly convert and adapt.
Right now, we have years of work in technologies for network transformation without comparable thinking on the question of how to combine them to create an efficient operational ecosystem. We are not going back to redo what’s been done, so we have to figure out a way of retrofitting operations to the sum of the needs the missions create. This is a very different problem, and perhaps a new body will be able to come at it from a different direction. It’s not an easy fix, though. The mission guys don’t speak software and the architecture guys can’t understand why we’re not talking about abstract programming techniques and software design patterns. The two don’t talk well to each other, because neither really understands the other.
So, do we do kumbaya songfests by the fire to introduce them? No, because remember it’s the mission guys who have the money. If we want to get a right transformation answer out of the ZSM ISG, then software people will have to learn to speak mission. They’ll have to talk with the mission people, frame a set of mission stories with their architecture at the center of each, and convince the mission people that the approach makes the business case for their mission. Not that it makes all business cases, not that it’s the superior, modern, sexy, way of doing things. That it makes the business case for each buyer and still, well-hidden under the technical covers, makes it for all and in the right way.
Is there a pathway to doing this? If there is, then getting on it quickly has to be the goal of the ZSM ISG process, or we’ve just invented NFV ISG 2.0, and vendors will be carving out little missions that match incomplete solutions.