logo_header
  • Topics
  • Research & Analysis
  • Features & Opinion
  • Webinars & Podcasts
  • Videos
  • Event videos
topic

Member Insights

The dilemma of implementing NFV services: How to speed it up

IBM’s Craig Farrell looks at making NFV implementation a reality. First, he examined why NFV is taking so long to move from trials into production services. In this post he addresses the crucial question of what can be done about it.

Craig Farrell, CTO, IBMCraig Farrell, CTO, IBM
14 Nov 2016
The dilemma of implementing NFV services: How to speed it up

The dilemma of implementing NFV services: How to speed it up

In this two-part series, IBM’s Craig Farrell looks at making NFV implementation a reality. In the first part he examined why NFV is taking so long to move from trials into production services. In this post he addresses the crucial question of what can be done about it.

Moving NFV services from trials to production

The dilemma of transformation

For the dilemma of transformation, there are two factors that must be addressed. The issue of cannibalizing existing services means that initially NFV will be more successful when building new services such as 5G or VoLTE than it will at replacing existing services.

As for the need to prioritize NFV over other network projects such as network build-out, this will always come down to the business case. CSPs will have to believe that the benefits promised by transforming to NFV are greater than the benefits of continuing to evolve their networks. The first way to strengthen the business case is to build one that reflects the total cost of ownership (TCO). It has been pointed out that some CSPs built NFV transformation business cases that did not show the cost of maintaining legacy services instead of transitioning to NFV-based services. The cost of maintaining legacy applications supporting a handful of services with high levels of manual effort (including swivel chair) need to be taken into account to make the business case compelling.

In addition to building a business case that properly reflects the TCO, implementing a precursor analytics project to specifically examine incoming service orders and report the number of orders that would be impacted if an equivalent NFV service was available can greatly strengthen the business case and provide a compelling trigger. This approach allows the CSP to get a measure of the impact transforming would have on their actual incoming orders. If built correctly the analytics project to quantify the business case could suggest which services to do first and can be done as a precursor to a strategic redirection solution which will be used to address the second issue predicted by the dilemma of transformation, the issue of the migration strategy.

Strategic redirection approach

The second issue raised by the dilemma of transformation is how to create a migration strategy that mitigates the risk of churn during the migration. I believe this requires a new approach called strategic redirection. The decision to cannibalize a profitable service is always difficult and can slow a transformation initiative as it demands diligent analysis and review. Currently, most CSPs implement some version of a 'cap and grow' approach when transforming from one service to another which has significant risk. Cap and grow is a process where a new (replacement) service is built that implements more (or all) of the features of the old service. The new service is then tested or a limited trial conducted followed by a 'cut over'. After the cut over, all orders are fulfilled on the new service. This approach is expensive since it requires a significant up-front cost to implement the service. Cap and grow is also high risk since cut over is usually an all-or-nothing event rather than a gradual move to the new service as features, coverage and functionality become available.

The alternative to ‘cap and grow’ is strategic redirection. Strategic redirection works by intercepting the incoming service orders and making an on-the-fly decision about whether the order can be fulfilled by the new service as it is currently built. If there is no coverage or some features are not yet available, the order will flow through to the legacy service as before. If the order can be fulfilled using the new service in its current state, then the order is redirected. The incoming order analysis can also be used to guide feature implementation and coverage priorities regardless of whether the order is redirected or not. The strategic redirection approach offers an effective alternative that mitigates both the up-front costs and inherent risk associated with the cap and grow approach.

Potential triggers

Despite widespread agreement in the compelling value proposition of NFV transformation, finding a compelling trigger that necessitates immediate action has proven difficult. What is required is a need that overcomes the naturally conservative nature of CSPs. I believe that the best approach to strengthen the business case and provide a compelling trigger is to do the previously mentioned precursor analytics project. Showing potential improvements using a CSP's current orders provides a more immediate and credible trigger since it reports improvements based upon their own current orders.

In addition to an analytics project, the experience gained since the first trials of EPCs (evolved packet cores) for LTE (long-term evolution) networks has led some CSPs to suggest that the need to implement voice over LTE (VoLTE) may provide a trigger for production NFV network services. Others have suggested that the build-out and adoption of 5G may also provide the necessary trigger for NFV-based production network services.

Merging the cultural divide

A solution to the cultural issues of NFV adoption for network staff is more difficult. It has been said that there is no substitute for experience and clearly any resolution to this issue will involve education and learning about how to manage, deploy and maintain NFV services in SDN and cloud environments. Traditional IT and data center staff have been dealing with issues surrounding the integration of cloud environments since they first encountered software such as VMware and were required to design services and applications that could be migrated from machine to machine and even between data centers. These virtualization concepts however are relatively new for some network staff. For many telecommunications companies, the IT data center staff and the network operations staff have traditionally been in completely different organizations. Despite recent efforts to merge them, a challenge like designing new services for cloud-based SDN and NFV execution environments can highlight that even after moving people into the same building and merging the reporting structure, culturally there is still a big divide. Perhaps the best chance of success for CSPs to implement NFV for network services is to follow the approach of IT datacenters. Many IT data centers used an approach of adopting SDN first. SDN can work across the legacy environment, which means operators can begin by offering some services with an ability to modify them on demand, for example a network 'on demand' service where a customer can request to change the bandwidth as required. This is beginning of the transformation to cloud-based, dynamic services which are built using NFV components. The approach supports the agile development paradigm where services can be brought to market sooner, as well as digital service provider paradigm since it embraces self-service.

[Editor's note: This approach is closely related to a TM Forum catalyst project. Find out more here.]

Fast followers

Telecommunications service providers are conservative by nature so shifting from a fast follower culture will be particularly difficult. I believe that one of the best ways to address this issue is for CSPs to look for small projects that could be done as individual projects and can be used to start their NFV transformation. Examples would include projects to transform all firewalls, route reflectors, packet gateways or load balancers to software-only devices. In making this suggestion, I am not advocating a rip-and-replace of existing network hardware. This strategy can be implemented by mandating that from a specific date onwards, all purchases of a network function be supplied by a software device on generic hardware. By starting with smaller projects to transform components, CSPs can avoid the tendency to try to transform entire services in one big program. In addition, CSPs can start smaller projects sooner rather than wait for others to publish successful examples which can be duplicated. Another strategy that has been suggested is for CSPs to adopt a more agile 'fail fast' approach.

Vendor solutions

Vendor solutions have clearly become more mature since the first trials and proof of concepts. The use of techniques such as strategic redirection will also reduce the risk from immature solutions. CSPs insisting on vendors supporting standards and the use of multi-vendor test environments will all help mitigate the risks associated with solution maturity. We are also seeing an increase in the desire by CSPs for outcome-based projects and shared risk/reward business models with vendors to help provide a significant motivation for both CSPs and vendors to move NFV-based network services into production.

What does the future hold?

CSPs, vendors and industry pundits are all forecasting a significant rise in transformation projects aimed at delivering SDN and NFV production network services because NFV is simply too compelling to be ignored forever.

NFV's progress from trials to production services however has been slowed by a handful of factors including: the dilemma of transformation, the lack of a clear trigger, cultural issues, CSP strategy and the maturity of vendor solutions.

For each of these factors we have suggested an approach to address the issue. For the dilemma of transformation, we suggested starting with a precursor analytics project, making sure the business case included the full TCO and using strategic redirection to reduce the risk and up-front costs. To provide a trigger we also suggested a precursor analytics project which would also strengthen the business case. For the culture issues we suggested looking at successful IT data center transformation projects for guidance. The fast follower strategy could be addressed by starting with small projects for service components rather than whole services. Finally, for the vendor solutions we suggested the use of service level agreements as well as shared risk/reward business models.

Addressing these issues will be crucial if we are to see the much-anticipated increase in the number of NFV services move from trials into production services.

The author would like to thank the following people for their insights, reviews, comments and updates. Lloyd Switzer,Telus; Kevin Salvadori, Clearbay Technology; Zygmunt Lozinski, Steve Teitzel, Marcus Buckle, Charlie Hale, Stephen Laufer and Sarah Dudley -- all from IBM.