Almost two and a half years ago I wrote an article about the changing face of recruiting engineers and how vendors were talking about automating the configuration of networks. I had some doubts at the time but things have moved on from there.

This week I’ve been attending the Oracle Communications Customer Advisory Board in Paris. Quite apart from the usefulness of the sessions and availability and access to a variety of people from engineering through to PLM, it’s been an interesting insight into the future direction that Oracle is taking and what Tier 1 communications providers are talking about. In particular, the things I spoke about in my original article now have a name – Network Function Virtualisation, or NFV. Oracle have been clear in this conference that NFV is coming and that they want to have all of their products in an NFV architecture. A lot of people will have a knee-jerk reaction to this and say that it’s impossible – that there components which have to stay as hardware or purpose-built systems. Equally, I’m seeing people take the exact opposite position – everything will have to be software, there will no longer be any purpose-built hardware. Oracle however, is clear that there is room for both – a good example is an SBC. AcmePacket systems were always purpose-built hardware to provide acceleration in silicon. Although that hasn’t changed with the acquisition by Oracle, there is equally a commitment to provide a virtualised SBC alongside the purpose-built hardware. The point that’s clear here is that NFV doesn’t exclude purpose-built hardware, or at least it mustn’t if it is to succeed. There is room for a hybrid approach from an architectural point of view as well as from a commercial migration point of view.

One question in this morning’s session caught my attention though. The question was asked “Who is going to manage your NVF architecture?” A number of options were proposed from splitting the stack to horizontal components much as it is now, or having a specific team manage the whole stack.  The discussion was varied and there was some brief discussion about whether the IT team or the Application team should be responsible for the stack.

The conversation sadly missed the point entirely – the technology that is being proposed is fundamentally different to anything that’s in place today. As a result, we have to approach this in a different way.

First of all, to have multiple teams managing the NFV stack isn’t useful – as a systems integrator we see too many problems categorised as “grey” problems – issues with integration which two vendors will point at each other and both say “It’s their fault”. This is one of the benefits of getting support from SIPHON on multiple products – by supporting the solution as a whole, we accept responsibility for the grey problems and manage the vendors appropriately. In an NFV architecture where the stack is potentially fully automated with multiple vendors, this will happen more frequently. So it’s critical that companies look to provide a single team that manages if not all then a significant majority of the stack. Who then?

The team that manages your NFV stack will work best if you have a team of generalists or a multi-discipline team. With this approach, every individual should have a good working knowledge of every part of the system right up to and including the application. NFV means that you’re providing a framework that places multiple components in close proximity and with complex systems of this type, you’re going to have elements that impact other elements – the system is inter-dependent to some degree and decisions you make will need to take into consideration the whole system.

That’s not to say that you don’t need specialists – I think it’s likely that what we’ll see is multi-disciplined teams of generalists who can either draw on specialist teams or who each have one or more specialist areas. It’s also possible that the team will depend on an outsourced specialist team much like some of our customers do already with SIPHON’s engineering team.

This new architecture is a fundamental change in how the stack works so we need a fundamental change in the operational model to support it and it’s time that operators realise this and look forward to a positive change.