So you've decided to pursue SD-WAN for your network, which can make sense for many clients, given the rich feature-sets offered that address many of the challenges of large & complex WAN deployments.
You may have chosen your solution already, technical requirements all checked off, giddy engineers waiting in the wings, ready to kiss goodbye to WAN CLI configs and wondering what to do with all the time they'll free up.
While that's all well and good, have you looked at SD-WAN from a service perspective? Why do I need to? The brochures have already assured me that I'll save costs, and my VAR & Carriers assure me that SD-WAN will solve all the operational issues we've been wrestling (unsuccessfully) for years.
Well, let's take a quick look under the hood and consider some of the ugly truths.
What are your drivers for SD-WAN migration? These typically fall under one or more of these categories.
Operational Velocity (make global changes & spin up new sites quickly & efficiently).
Let's consider how your existing VAR & Carriers have performed in these areas, and look for opportunities for improvements and additional value.
Security & Governance The key here is effective solution design from the start. Who designed your current solution, including its flaws? Does your VAR have a proven track record delivering in this area, do they have competent architects and have they delivered successfully in this area for yourself, or other enterprises? These are key questions, if your SD-WAN solution is not effectively designed based on your requirements, you'll just end up with another ineffective WAN that serves as a business constraint rather than a business enabler. It is critical that your solution designer (VAR or In-Source) works closely with your security and risk management teams, and that requirements are baked into the solution from day one. You really want to avoid any "oops" moments as you realize considerations for HIPAA or ITAR requirements were never considered.
Operational Velocity What are your current operational headaches? Many clients I've worked with have been frustrated by their VARs operational processes and workflows. You may spin up a fancy new SD-WAN solution, capable of pushing changes to thousands of endpoints in seconds, but that's no use if your VAR hides these features behind slow and inefficient workflows, and it takes 2 months to get a ticket into the right queue. This applies to all parts of the ITIL service cycle, see the graphic later in this section for an overview. Also, consider that SD-WAN is dependent on the underlying WAN fabric, so when deploying new sites you will be subject to the traditional procurement delays and costs for private WAN circuits, Internet Circuits, and 4G services as applicable for your design.
Cost Savings Although SD-WAN may deliver some savings on the CapEx side of your budget, the real opportunities are on the OpEx side, and this is exactly where you should pressure the VAR for savings and value-add. Challenge your VAR, hard, to deliver savings and value on the OpEx side of the solution. In cost models, don’t forget the underlying WAN fabric. You still need the underlying fabric, be it MPLS, Internet, 4G, other or a combination of some or all. You still need these services, and the associated CapEx/OpEx costs must be included in your cost model.
Recommendations When selecting an SD-WAN technical and service solution, ensure you have clearly identified pain-points and constraints within your existing WAN services, along with the accountable parties. This way you can clearly determine what service components have an opportunity for improvement and drive your VAR to deliver value in these areas.
Ideally, we want to avoid putting the Fox back in charge of the Henhouse, if your VAR has failed to deliver with your current WAN, how can you ensure success with the same VAR delivering an SD-WAN solution?
Below is an infographic to help guide your VAR discussions and negotiations, key questions to ask for each service component are:
What is the value-add for this service component?
How does the cost compare to the equivalent component in your current WAN solution?
Can the selected SD-WAN technology break-out the management of this component?
Does it make sense to manage this service component In-Source or using a VAR?
What strategy can be employed to migrate this service component post-implementation, to an alternate VAR or In-Source resource if necessary?
Using this approach, you can drive VAR negotiations from a position of strength and agility. Component by component you can challenge the VAR to deliver value and position yourself to effectively decouple from the VAR if they fail to deliver.