The 18 Essential SD-WAN Evaluation Criteria | Key to the Black Box #5

At the most fundamental level, one of the very few ways you can guarantee optimized technology spend, is to tie each purchase back to specific organizational-level metrics. While obvious to some, many feel overwhelmed once they set to the task, and it often never gets completed. This only ends up holding IT leaders back, as they are unable to demonstrate R.O.I.. Which ultimately has a ripple effect culturally starting with leadership. The opposite is also true. Tying your purchases to KPIs, and demonstrating that IT spend drives real change, moves IT department from “cost of business” to Strategic Influencer.

Then why is it that many find it so hard to make these connections and show others? In most cases, it is the level of complexity in properly categorizing and assigning these purchases. If it is as impactful as proposed, then it is important that it is done correctly. Sure, everyone knows firewalls are critical to any organization, but does the security aspect tie the firewall to risk-mitigation measurement, or does the VPN capability tie the firewall to the employee productivity measurement?

The way to cut through this ambiguity is a reframing of the problem. First, we have to understand that the products we buy ought not be dissected into the actual technologies contained within them. A firewall, especially in today’s market of Next-Gen and UTM appliances, is a container and server of multiple technologies. The packet inspection, web filtering, and similar aspects of the firewall do, in fact, tie to measurements about risk-mitigation and/or compliances, but so, too, does the VPN functionality directly impact employee productivity. Rather than struggle to categorize the entire firewall, assign the costs of the security aspects to their KPI, and attribute the costs of productivity aspects to their own KPI.

One way to truly understand the value of a particular component technology is to evaluate the iterative configurations of that specific component. The quickest, though most incomplete, way to do this is to simply compare two products that are mostly similar, except one has the technology you are evaluating and the other does not. The price difference will give you some orientation of how big a difference this technology might make. Again, this is an incomplete view, but it is a comparison that is quick and easy to make, and would factor into the final decision anyway.

The main reason this is not a sufficient means of comparison, particularly for SDWAN, is that there are so many providers in the space that are trying to differentiate themselves that there is rarely a comparison of products that only vary in a single factor. This increases the complexity significantly by requiring more comparisons. Instead of falling down that rabbit hole, we’ve compiled a list of the most distinguishing considerations across 5 categories that helps you isolate and define the specific technologies that you’re shopping for, so that you can assess which SDWAN can best serve both your technical needs and the metrics you need to drive.

The 5 categories include the following 18 considerations:
What is the Core Architecture and Deployment Model of the SDWAN solution?
Does the Network Hub reside in the cloud or at premise devices?
Does deployment require physical devices, can you deploy virtual instances, or is it a cloud-based service that requires no on-site computing?
How does the SDWAN support Admin Experience?
Does the orchestrator portal encompass all of the standard expected functionality?
How easily can policies be templatized and applied/modified?
Do rule changes auto-populate all devices, including new additions?
How does the SDWAN improve Application Performance?
If the SDWAN accepts multiple links, does it utilize Link Aggregation or Load Balancing?
Is Forward Error Correction available to mitigate packet loss?
Can Packet Buffering be employed to mitigate jitter and latency?
Are there sufficient bandwidth detection and reporting mechanisms?
Does the SDWAN adjust packet prioritization based on real-time changes in circuit health?
Does the SDWAN adjust transmission routes based on real-time changes to various connection performances?
How well does the SDWAN integrate with Cloud Services?
Are there meaningful integration options w/ Cloud Services?
Is there route diversity at a Local POP level?
Are you able to present your IP addresses at the Cloud-Edge for greater routing control?
Security
Are the SDWAN’s connections secured?
How does the SDWAN interact with your current firewall?
What security options are available within the SDWAN product?
Which cloud security options does the SDWAN integrate with?

We’ve saved you the leg work and tallied up the results for some of the most familiar names in the SDWAN market.

The rest of this SD-WAN series will shift from technical to a more strategy focused. We’ve covered a lot of ground on what SDWAN is and what it can do for you. Now it’s time to turn our attention toward how to evaluate SDWAN solutions (and whether you even should), how to negotiate with Service Providers, and how apply the benefits of SDWAN toward achieving your key organizational metrics, whether they be cost of operations, customer satisfaction, or whatever KPIs matter to your business.