This is a topic I have written on a while back, but it is so important it seemed to deserve a revisit, with a slightly different view than I approached it from before. In the last few weeks we have been discussing with a client this very issue. This client is nearing the launch of a production trial of their NFV environment with a small group of friendly customers. We have worked with them on processes, the issues they can expect to see, and what they should do if/when each of these issues pop up. The one thing that has been asked over and over, but hasn’t been a settled on yet, has been just WHO would do each of these things once it moves beyond trial and into a market deployment for sales.
This client has the common structure with an IT Ops organization that typically handles all things internal that are related to servers, virtualization, etc. They have an Network Engineering organization that focuses on all things networking (focusing on backbone and data center networking), and a Service Provider Engineering organization that focuses on the access network and CPE. The challenge they are facing is that there are virtualized network devices, sitting on servers in the cloud, that are connected via the backbone network to the access network, with virtualized CPE providing the functionality to the trial customers. The overlaps in traditional roles is immediately obvious, and each organization has its turf to protect here…or do they?
Should IT Ops own the cloud, like they do currently for all things internal and used by App Dev? They have the server management expertise. They have the virtualization expertise, which Network Engineering has gained recently as well.
Should Network Engineering own it? They have been building and leading the proof of concept work and defining the trial, working with the Service Provider Engineering group. It is a networking product, so shouldn’t the networking people own it?
Should the Service Provider Engineering group own it? They own the current Managed Router service which has physical CPE put on site, and is managed by these folks. This virtualized version is a possible replacement of that in the future, so it is logical they own it, right?
The answer gets a little complicated, and will vary by company. Potential answers range from creating a “dotted line” relationship between key resources from each group and saying yes to all three of the paragraphs that precede this one. Another approach is to reorg these groups into the same organization and thereby achieve the same result as the last sentence, with a more concrete, structured approach. It is also conceivable, and possibly a much better plan for the future, to create a new group altogether. This NFV Engineering and Ops group would contain personnel with a mix of IT Ops, Network Engineering and Service Provider Engineering skills. Sprinkle in a little Dev Ops and App Dev flavor to this group and you have created a future ready organization to expand your SDN and NFV technology rollout. Over time it may be that the other groups shrink, or possibly go away altogether, as more and more of your business moves to SDN/NFV-based offerings.
The right approach is 100% based on your company culture and leadership’s willingness to make major changes. As you walk through each of the options in the paragraph above you are requiring more commitment to the future. The dotted line approach indicates a lack of belief that NFV is the future (or at least that it is close enough to ready that you should care right now), and a lack of desire to gamble on major organizational changes on something you aren’t sure will make it. The NFV Engineering and Ops approach shows a complete commitment to the future that SDN and NFV promises, and a willingness to evolve your company to be ready. If you are a leader in your company, these are the messages you are sending based on how you approach this.
Is either end of the spectrum on this wrong? Not really, but if you aren’t already thinking about these things and making plans to execute on this in some manner you are setting yourself up for major failure. Failure that will come even if the technology you deploy is bulletproof, because even perfect tech is going to fail with a poor operational structure behind it.