As software-defined networking (SDN) and network functions virtualization (NFV) spur massive change in the data center, they also are radically changing how networking products are built, consumed, sold, and supported.

In the pre-SDN/NFV era, products that delivered network services primarily stood alone and were interoperable with other products through IEEE or internet engineering task force (IETF) standards. For emerging SDN/NFV environments, delivering these network services requires deep, cross-product integration and interoperability between products, services, and open-source software from multiple suppliers. To be successful in this new environment, companies that want to be leaders in SDN or NFV must not only transform products, services, form factors, and business models – they also must develop a new class of partner ecosystems.

Historically, the networking industry has had a poor track record of creating partner ecosystems that a) create repeatable economic value to each party that leads to b) establishing sustainable, long-term, symbiotic relationships. Until now, partnerships were a nice-but-not-necessary thing to have for traditional network infrastructure suppliers. SDN and NFV are changing the game, making ecosystems more critical not only for companies themselves, but for development of the industry as a whole.

SDN/NFV Delivery Demands a New Kind of Networking Ecosystem

Traditional networking ecosystems, not unlike many networks themselves, tend to be vertically integrated with one large company (for example, Brocade, Cisco, Juniper, etc.) taking the lead and primary responsibility for support and integration. With SDN and NFV, the network services delivery model shifts from vertically integrated hardware appliances to non-integrated software elements that can theoretically run on any hardware appliance (including servers), hypervisor, or cloud management platform.

Since each network service software element theoretically can combine with any other network service element, an SDN/NFV environment now can host a boundless number of combinations for customers to integrate and deploy on their networks. With this vast potential comes a new level of complexity that threatens to increase sales and deployment cycles – an outcome that is the exact opposite of the promise of SDN and NFV.

Suppliers need to address this complexity head on. As they strategize how to sell and support their products, they need to consider what other elements their products need to interoperate with to deliver a complete solution for customers. This new demand for viable and complete SDN/NFV solutions means even the largest network infrastructure companies have to partner and collaborate with other suppliers to integrate their SDN/NFV products and services with other vendors’ products, confirm that each element works together, and document what is required for the different elements to function together.

To make their own solutions more attractive for customers, suppliers will need to work with other vendors, even competing ones, to develop certified deployment templates. Such cross-vendor templates would give customers a complete list of the different hardware and software elements needed create a whole solution, as well as instructions on how to install and configure each element to make all the pieces work.

Addressing Changing Support Responsibilities

The SDN/NFV delivery model also creates new confusion as players work out who is responsible for assembly, support, warranties, SLA, and the like. For example, in the old days, a vendor like Brocade would build a router, and a service provider would use that router to deliver a service. If the provider needed support for the router, it would call Brocade directly. Clear-cut, no problem.

Today, Brocade produces a virtual router that may run on Linux in a KVM hypervisor that is managed from OpenStack. So now, a networking environment that has the Brocade router may also have that router running on an HP server hardware, running Debian Linux, RedHat’s version of KVM, or Mirantis’ OpenStack distribution. If the router does not work or perform as expected, whom should the provider call? Imagine the number of permutations that would need to be tested and documented if we “just” qualified that these were the only variables (they are not) and if we assumed there were five viable alternatives for server hardware, Linux, KVM, and OpenStack.

Customers clearly need guidance from their suppliers to help them to quickly make decisions to deploy these new technologies. How vendors respond to this challenge can have a significant effect on their ability to gain traction in the marketplace.

Planning and Building a Successful Ecosystem

Vendors must learn how to realign solutions marketing and engineering efforts to focus on key partners. To create a blueprint for a successful ecosystem, we first have to establish a shared vocabulary. Each of the following terms indicates some level of partner ecosystem, with “interoperable” being the most basic and “certified” being the most advanced:

• Interoperable: Both companies likely support some open standard or technology such as OpenFlow or Opendaylight (ODL)
• Validated: Vendors have tested and documented that the products are interoperable
• Certified: Two or more vendors come together to certify that a specific set of products and configurations will work for a specific use case with specific performance metrics and apply an SLA to it.

To build or obtain strong partnering DNA, vendors must create programs that develop sustainable partnerships over time. Simply teaming up with other vendors for the sake of doing so is not enough. Partnerships need to be aligned with specific use cases or deployment scenarios to be truly effective. If you’re not sure where to start, start small: Focus on one use case with a couple of partners and find an early customer to work with.

When it comes to how many partnerships a vendor should develop, more is only better insofar as the affiliations strategically support a focused ecosystem. Vendors should expand their partnerships to include companies that provide network functions they don’t, such as chip vendors, compute/server platform vendors, OS, hypervisor, and cloud orchestration companies.

How to Evaluate SDN/NFV Ecosystems

When customers evaluate SDN and NFV solutions, they need to look critically at existing partnerships between vendors and think about the implications of different ecosystems. At the very least, customers need to make sure make sure that vendor’s definitions match their own expectations, and that ecosystems are organized to support their specific use cases. They also should always feel free to ask vendors for:

• A list of interoperable, verified, and certified solutions
• Documentation on validated and certified tests and performance characteristics
• Joint meetings or calls for verified or certified solutions

Customers can get an idea of how strong a relationship is between partners by a) the number of validated and certified solutions that are jointly supported by both partners; and b) the number of overlapping products (fewer is better). They also should encourage their compute and OS vendors to work with virtualized network function (VNF) vendors.

For example, Dell, Brocade, and Intel recently began collaborating to deliver new NFV solutions for telecommunications service providers. The joint solution runs Brocade’s vRouter in Dell’s NFV platform, which uses new Intel chips and Intel’s DPDK (Data Plane Developers Kit) APIs. And HP recently launched its SDN AppStore that features SDN solutions the tech giant developed jointly with various ISVs (independent software vendors).

SDN and NFV are putting compelling emphasis on networking ecosystems in this new networking wave. As customers debate when or how to make the switch to SDN/NFV systems, having a solid ecosystem of technology partners will be key to vendor success in SDN and NFV. At the industry level, strengthening relationships between component suppliers will be critical for widespread SDN/NFV adoption as a whole.