Editor’s Note: Why Single Vendor Solutions Dominate New Networking Technologies
There are no accredited standards for exposed interfaces or APIs* in SD-WANs, NFV “virtual appliances,” Virtual Network Functions (VNFs), and access to various cloud networking platforms (each cloud service provider has their own connectivity options and APIs). Those so called “open networking” technologies are in reality closed, single vendor solutions. How could there be anything else if there are no standards for multi-vendor interoperability within a given network?
In other words, “open” is the new paradigm for “closed” with vendor lock-in a given.
* The exception is Open Flow API between Control and Data planes-from ONF.
Yet Gartner Group argues in a new white paper (available free to clients or to non clients for $195), that IT end users should always adopt multi-vendor network architectures. This author strongly agrees, but that’s not the trend in today’s networking industry, especially for the red hot “SD-WANs” where over two dozen vendors are proposing their unique solution in light of no standards for interoperability or really anything else for that matter within a single SD-WAN.
Yes, we know Metro Ethernet Forum (MEF) has started working on SD-WAN policy and security orchestration across multiple provider SD WAN implementations. They’ve also written a white paper “Understanding SD-WAN Managed Services,” which defines SD-WAN fundamental characteristics and service components. However, neither MEF or any other fora/standards body we know of is specifying functionality, interfaces for interoperability within a single SD-WAN.
Here are a few excerpts from the Gartner white paper is titled:
“IT leaders should never rely on a single vendor for the architecture and products of their network, as it can lead to vendor lock-in, higher acquisition costs and technical constraints that limit agility. They should segment their network into logical blocks and evaluate multiple vendors for each.”
Vendors tend to promote end-to-end network architectures that lock clients with their solutions because they are focused on their business goals, rather than enterprise requirements.
Enterprises that make strategic network investments by embracing vendors’ architectures without first mapping their requirements often end up with solutions that are overhyped, over-engineered and more expensive.
Enterprises that do not create and actively maintain a competitive environment can overpay by as much as 50% for the same equipment from the same vendor. Savings can be even greater when comparing to other vendors with a functionally equivalent solution.
IT and Operations leaders focused on network planning should:
- Divide the network into foundational building blocks, defining how they interwork with each other, to enable multiple vendor options for each block.
- Remove proprietary components from the network, replacing them with industry standard elements as they are available, to facilitate new vendors to make competitive proposals.
- Get a technical solution that meets needs at the lowest market purchase price by competitively bidding on each building block.
- Ensure that operations can deal with multiple vendors by planning for network management solutions and processes that can cope with a multivendor environment.
Network technologies have matured in the last 20 years and are a routine component of every IT infrastructure. No vendor can claim a unique “core competency” nor “best-of-breed” capabilities in every area of the network, so there is no reason to treat the network as a monolithic infrastructure entrusted to a single supplier. However, we regularly speak to clients that still give credit to the myth of the single-vendor network. They believe that having only one networking vendor provides the following advantages:
- There is no need to spend time designing a solution, as you simply get what leading vendors recommend.
Products from the same vendor are designed to work seamlessly together, with limited or no integration challenges.
The procurement process is simplified with only one vendor, and there’s no need to deal with time-consuming, vendor-neutral RFPs.
A higher volume of purchases with one vendor would result in a better discount.
You only have a single vendor to hold accountable in case you run into problems, and one that will respond quickly given the loyalty and volume of purchases.
However, these perceived advantages are largely a myth, as much as open networking and complete vendor freedom is a myth. The harsh reality that we frequently hear from clients that followed this single-vendor strategy includes:
- Holistic designs recommended by vendors are not necessarily the best. They are often over-engineered, include products that are not aligned with enterprise needs and are ultimately more expensive to buy and maintain.
- Diverse product lines from the same vendor share the brand, but they are rarely designed to work together from the start, since they often come from independent BUs or acquisitions, making them difficult to integrate.
- A higher volume of purchases does not automatically translate into better discounts. For most vendors, their best discounts are reserved for competitive situations and will generally offer savings of 15% to 50% when compared with the best-negotiated sole-source deals.
- Having to deal with just one vendor for technical issues is simpler, but does not necessarily translate in shorter time to repair and better overall network availability, which is the real goal.
Clients that pursue a multivendor strategy report that time spent on RFPs and evaluation of different vendors is not a waste, because it increases teams’ skills, motivates them to stay abreast of market innovations, prevents suboptimal decisions and pays off — technically and financially.
Divide the Network Into Foundational Building Blocks to Enable Multiple Vendor Options for Each Block
Network planners and architects must break the network infrastructure into smaller, manageable blocks to plan, design and deploy a “fit-for-purpose” infrastructure that addresses the defined usage scenarios and control costs (Figure 1 shows typical building blocks).
*Security is not addressed in this document. Note: There is no hierarchy associated with block positioning in this picture.
Source: Gartner (October 2017)
The key objectives of this activity are to:
- Identify network blocks that have logical and well-defined boundaries.
- Document and standardize as much as possible the interfaces between the various building blocks, to allow choice and enable use of multiple vendors.
This building block approach is useful because not all network segments have the same properties. In some segments little differentiation exists among suppliers, and there is a high degree of substitution within a building block, so enterprises can seek operational and cost advantages. For example, wired LAN switching solutions for branch offices are largely commoditized, and the difference between vendors is hard to discern in the most common use cases.
In other cases, such as in the data center networking market, there is more differentiation among vendors, and the segmentation approach ensures that enterprise architectural decisions align with IT infrastructure strategies and business requirements.
There are no hard-and-fast industry rules on where the boundaries between blocks must be drawn. Each enterprise has to split network infrastructure in a way that makes sense for them. The most common approach is segmentation around functional areas, such as data center leaf and spine switches, WAN edge, WAN connectivity, LAN core and LAN access. Each segment could further be split. For example, LAN access includes wired and wireless, while WAN edge might include WAN optimization and network security services. Another complementary segmentation boundary can be the geographical place, as a large organization with subsidiaries in multiple locations could select different vendors on a regional or country basis for some blocks. Disaggregation is creating another possible segmentation, since hardware and software can be awarded to different vendors for some solutions like white-box Ethernet switching.
Defining building blocks also protects organizations from the “vendor creep” trap. As vendors acquire small companies and startups in adjacent markets, they often encourage enterprises to add these new products or capabilities to the “standardized” solution. If the enterprise defines its foundational requirements, it can easily determine whether the new functionality truly solves a business need, and whether any additional cost is warranted.
Remove Proprietary Components From the Network to Facilitate New Vendors to Make Competitive Proposals
Employment of proprietary protocols and features inside the network limits the ability to segment the network into discrete blocks and makes this activity more difficult.
Within building blocks, it is acceptable to use proprietary technologies, as long as enterprises compare vendors against their business requirements (to avoid over-engineering) and the solution provides a real and indispensable functional advantage. It is important to express the business functionality as a requirement and not to tie requirements to specific proprietary technologies.
Between building blocks, it is critical to avoid proprietary features and use standards, since proprietary protocols favor using certain vendors and disfavor others, leading to loss of purchasing power. Sometimes it’s necessary to employ a proprietary protocol, for example:
To obtain functionality that uniquely meets a critical business need. If so, then it’s critical that these protocols be reviewed regularly and are not automatically propagated into new buying criteria over the long term.
In the early stages of market development, before standards have caught up to innovation. However, once standards exist, or the technology has started to move down the commodity curve, it is imperative that network architects and planners migrate to standards-based solutions (as long as business requirements aren’t compromised). Examples of industry standards that replace previous proprietary solutions are Power over Ethernet Plus (PoE+) and Virtual Router Redundancy Protocol (VRRP) (see Note 1).
In these cases it is essential to document and motivate the exception, so that it can be periodically reviewed. Proprietary technologies should always be avoided in the interface between the network and other components of IT infrastructure (for example, proprietary trunking to connect servers to the data center network).
Get a Technical Solution That Meets Needs at the Lowest Market Purchase Price by Competitively Bidding on Each Building Block
Dividing the network provides a clear definition of what is really needed within each building block, which in turns enables a fit-for-purpose approach and a competitive bidding process.
–>The goal is not to bid on the best technical solution for each block, but on one that is good enough to meet requirements.
This enables real competition across vendors and provides maximum price leverage, since all value-adds to the common denominator can be evaluated separately and matched with the cost difference.
By introducing competition in this thoughtful manner, Gartner has seen clients typically achieve sustained savings of between 10% and 30% and of as much as 300% on specific components like optical transceivers.
Discern the Relationships Between Networking Vendors and Network Management Vendors
You may also find that networking vendors have some level of leverage with certain other vendors specialized in network management. Therefore, it is valuable to understand the arrangement of any partner agreement and whether this can be leveraged to your organization’s benefit.
Editor’s Closing Comment:
The advice provided above by Gartner Group seems very reasonable and mitigates risk of using only a single vendor for a network or sub-network. If so, how can any network operator or enterprise networking customer justify the single vendor SD-WAN solutions that are proliferating today?
Readers are invited to comment in the box below the article (can be anonymous) or contact the author directly (firstname.lastname@example.org).