The last few weeks I’ve read several articles stating that telecom operators are losing their initial rush of excitement about SDN and NFV. Reality is catching up the nice promises. There are several causes for this, but in this post I’ll focus on a specific one that I have been discussing with some leading representatives from the sector: not adapting the way you manage the network and infrastructure. SDN and NFV is all about software and thus should be managed differently than traditional telecom infrastructure. Software engineering and a good software architecture are critical.
There is no silver standard bullet
The telecom world heavily relies on standards. Operators typically wait for the incumbent vendors to implement these standards before adopting new paradigms and technologies. And they keep an eye on the large operators to see which choices they make. Reducing the risk of making the wrong investment is the name of the game. A wrong investment typically means being on the wrong track for the next 5 years or having to invest a second time to fix it.
However, the SDN/NFV landscape is so diverse, with many standards groups, open-source initiatives, vendors and operators having their own vision, especially on orchestration. How do we manage these software-defined networks and network functions? What kind of orchestrator do we need? How should it fit into our organization? Not surprisingly, as every stakeholder has a different business case and business model, a different scale and/or a different technology in mind when thinking about SDN and NFV.
It is very unlikely that we suddenly will find the silver bullet. Converging all the different views and concerns is impossible. And definitely not in the form of a standard that can be applied to all the needs and scenarios of every operator. There is and will be no standard or reference architecture that will cover everything. And if it does exist, it’s not going to solve all your problems.
The transformation towards a more software-defined approach aims for more flexibility, and to adapt to the specific needs of the operators as well as their customers. So the solution itself should also be flexible and not strictly defined. You will have to fill in the blanks yourself. That’s also part of the digital transformation.
Software architecture to the rescue
In a software-defined world, you have to design your network services the same way as other software applications. Every operator should design its own architecture for its specific needs. Such a software architecture provides higher abstraction layers and views, so that different stakeholders can discuss at their level about the telco services, while abstracting away irrelevant details.
The nice thing about software architecture is that you start at a high abstraction level, and while you gather more (specific) requirements, you can start detailing the architecture. Between the highest level of abstraction and the actual implementation, there are a lot of iterations of gathering requirements and filling in the details. Evidently you can reuse frameworks like ETSI NFV, as part of the puzzle. But only reusing pieces from others, will not make your specific puzzle.
Key to a software architecture are the non-functional concerns: performance, availability, etc., but also security and reusability. It forces you to think about your specific requirements and intents in an end-to-end manner. A generic architecture will not deliver the performance, security and other requirements that you really need for some type of services. Another operator has other requirements, and will translate them differently.
Flexibility or adaptability is also one of those non-functional concerns in the software architecture. Typical software vendors have to do the same, because a one-size-fits-all solution doesn’t work. Software can provide this flexibility, you only have to design and use it in the right way.
In the end, you have a detailed architecture that enables you to reason about it, using the different views (e.g. a functional and deployment view). Ideally you can use it as input (i.e. high-level model) for your orchestrator that has to deliver the service.
Conclustion: embrace software engineering
To really make operators faster and more flexible, they have to look outside their traditional (telecom) world. Software engineering is critical to succeed with SDN and NFV. Currently, the telecom operators as well as the incumbent vendors are clearly lacking this knowledge. Pick your partner(s) wisely and you will pass already an important barrier to SDN and NFV adoption.