Given that SD WAN promises to make networks simple, people sometimes wonder whether they can move to SD WAN and then manage the network themselves.
Is that true?
In our article about DIY vs Managed SD WAN, we discussed some of the drivers that could influence a choice between DIY and Managed SD WAN. It highlights the fact that moving to SD WAN poses questions about who does the work to manage the overlay and the underlay, and who understands the complexity that still remains despite SD WAN.
Here are some questions that you could ask to help decide whether you want to do this work, or whether you would rather have a managed service do it for you.
- Do you want to retain CCIE or equivalent skills to design the network and troubleshoot tricky problems?
- Do you want to manage the procurement and provision of circuits?
- Do you want to project manage the deployment of your WAN?
- Do you want to run a field engineering team to deploy and then support in-life?
- Do you want to supply the WAN helpdesk staff required for 24x7x365 cover?
- Do you want to manage the traditional parts of your network that might still be needed?
- Do you want to be the place where the buck stops?
- Do you want to manage connections to Cloud?
- Do you want your team to manage the network or to concentrate on adding value to your business?
- Why are you using a Managed Network today and how many of those reasons will still apply with SD WAN?
Do you want to retain CCIE or equivalent skills to design the network and troubleshoot tricky problems?
We've seen in our article They said SD WAN was easy! DIY vs Managed SD WAN that moving a network to SD WAN does not make the network intrinsically more simple.
With a DIY SD WAN you would need to manage the devices and software, as well as the circuits, carriers and underlay performance.
Managing SD WAN requires real networking skills in your team, not just field engineers. It might be easy to roll out changes using SD WAN but you still need the CCIE in your team:
- It's easy to break things in a big way;
- Updates and patches are pushed out automatically but someone needs to respond quickly if something goes wrong with them;
- With at least one vendor you still need to understand boolean logic to set it up correctly.
- If you need high speed links between HQ and data centres, or sites in countries that don't allow encryption, then you may need to run traditional networks alongside SD WAN, for which your DIY network will need expertise.
- Some people ask if SD WAN can be set up for them, so that they can manage it themselves going forward. The risk is that, if you don’t retain network expertise of your own, you won’t really understand it when it goes wrong.
Do you want to manage the procurement and provision of circuits?
This question could have been expanded to "Do you want to manage the procurement and provision of circuits across multiple countries, multiple carriers and multiple technologies, in multiple currencies and languages?". Or perhaps justDo you want to manage the carriers?
If you're using a Managed Service today, then circuit procurement and provision is most likely being done for you. SD WAN could make this work more complex, because it will encourage
- Multiple circuits per site;
- Across multiple technologies;
- Quite possibly from multiple carriers, maybe in multiple languages;
- The need for a new security regime as you increase your exposure to the internet
With this additional complexity, moving the management in-house might be non-trivial. If you sit next to one of our Provisioning Managers, you'll hear an endless series of calls to carriers to get wayward circuit deliveries back on track.
Related to this question is the choice of hardware vendor. If you use a managed service, then you can leave it to the service provider to deal with delivery and maintenance of hardware. If you decide to go DIY then this may have a bearing on your choice of SD WAN Vendor. You'll need to ask:
- Does the vendor have global reach?
- Can they deliver WAN replacement hardware everywhere?
- What’s the model for hardware break fix?
It's perfectly possible to manage procurement and provision yourself; you just need to have resource lined up to do it, accept the pain that comes with it, and develop a thick skin for when deployments go wrong.
Do you want to project manage the deployment of your WAN?
When you roll out a new network, whether traditional or SD WAN, good project management can be the difference between success and painful failure.
A good WAN project manager will plan, lead, co-ordinate, schedule and document the deployment of your SD WAN network, often involving transition from the existing network. Project managers do a great deal, but it's their long experience of network deployments that makes the difference.
We can illustrate the project manager’s impact by looking at a few of these areas.
Let's start with scheduling. There are multiple activities that need to be scheduled and co-ordinated at every site, such as
- The procurement of hardware and licences
- The procurement of maintenance contracts
- The procurement of circuits (each with individual lead times)
- The deployment of hardware (often to a staging point before going to site)
- Configuration of hardware (yes, even with SD WAN!)
- Shipping to site
- The delivery of live circuits (usually more than one per site)
- Testing of the circuit
- Installation of the hardware
- Post-install tuning
- On-boarding to the network operations centre
- Handover to support
After deployment considerable documentation must be pulled together so that knowledge is retained and the network can be operated reliably, such as:
- Circuit documentation
- Network diagrams
- Hardware and licence inventory
- IP addresses
- Helpdesk numbers for internal helpdesk, carrier helpdesks and vendor helpdesks
- Processes and procedures
To illustrate the scale of this information, our monitoring and management platform holds up to 150 pieces of meta data on each device. Remember, too, that your infrastructure will have multiple devices in the underlay, not just the SD WAN devices.
All this work requires the co-ordination of multiple roles such as carrier contacts, account teams, provision managers, engineers, warehousing etc.
What makes the project management function so critical is the insight it can bring to bear when it has considerable experience. Here are some examples of how that experience can help:
Third party permissions (or wayleaves)
This is required when landlords or owners need to give permission to allow digging or building works (such as conduits) to be undertaken. A WAN project manager will often find themselves having to obtain permissions from landlords and dealing with solicitors. They'll also be dealing with carriers. An experienced WAN project manager will know from long experience both what to do and how to do it.
Excess Construction Charges
This is when additional work is identified following the initial order for a circuit. Carriers each have their own language and coding that they use to feed back that they need to do additional work (such as digging up a road). An experienced WAN project manager will understand the language of the carrier, and the implications and practical realities of dealing with these situations.
An experienced project manager will know exactly what to expect from a multi-circuit delivery at each site and will know that different circuits from different carriers will all have different delivery stages and published lead times. They will know from experience and documentation that they also have different real lead times. They can use this insight to order circuits at the right times to synchronise their delivery (and avoid multiple engineer visits).
Project Management reduces risk
Project management is a critical function that needs to be resourced, whether by you or a managed service. A managed service should result in you having an experienced project manager with the insight and skill to plan more realistically and slip less often than a beginner.
Do you want to run a field engineering team to deploy and then support in-life?
One of the speakers at a recent conference shared the experience of his company's SD WAN deployment. He asked if anyone believed they could post an SD WAN device to site and have the janitor plug it in. There were titters but no hands went up.
He was pointing out that WAN is a critical resource; that you still need a responsible engineer to turn up when you deploy SD WAN.
The engineer will have to co-ordinate the disconnection and connection of your circuits (which may be new and as yet untested), make sure they're plugged into the correct ports, handle any testing and remedial work, liaise with the network team, take photos to help with future fault resolution, document what’s done, leave the Comms room tidy and not break anything.
If you have a managed service today then this work is most likely being done for you, both for new circuits and for adds, moves and changes. If you move to a DIY model then you’ll need to resource it yourself. Here are some considerations:
- You'll need to set up a deployment process to handle the logistics of getting kit and engineers to site, and then train the engineers on the process and the details of the on-site work.
- If you need new staff then you’ll also need to deal with resourcing for the peaks and troughs in workload.
- In either case, you’ll need to manage holiday and sick cover, skills update and succession planning.
- If the WAN is not their day job, then you will need to mitigate the lack of regular and recent experience of your network.
Do you want to supply the WAN helpdesk staff required for 24x7x365 cover?
How do you keep your WAN running well?
One thing you need is to have people on hand to triage and resolve issues, and to co-ordinate between resolver groups. You typically use a Helpdesk with a range of skill levels to handle alerts, calls and issue resolution.
Helpdesks are best run 24x7. Even if your business doesn't operate around the clock, faults can arise at any time and progressing straight away minimises disruption the following day. It also means that the clock is started on your carrier’s SLA straight away!
To run 24x7 requires a minimum of three people to handle 24-hour working, holiday and sick cover; probably more, to cope with both simple and complex issues. Someone will also need to deal with management, skills updates and succession planning. The cost for this should be part of the calculus for choosing between Managed and DIY.
It's all very well having snazzy SD WAN monitoring; it's what you DO with the monitoring that counts. Who's watching your network, and who's going to deal with issues that arise?
Do you want to manage the traditional parts of your network that might still be needed?
There might be situations where you need to run a more traditional network alongside SD WAN, so it is worth considering whether those situations could apply to you, along with your attitude towards managing them yourself.
One scenario might be that your chosen SD WAN vendor cannot support all of your sites. For example, your SD WAN vendor’s maximum device bandwidth might be insufficient for the data centre or HQ circuits you anticipate.
Another scenario might be that you have sites in countries that do not allow encryption, preventing you from running SD WAN in those locations.
It is helpful to consider whether you will need to run more traditional technology for parts of your network, and how you would prefer to manage the network for them.
Do you want to be the place where the buck stops?
It’s a lonely place to be when a network problem takes out your users, senior people are looking at you, and you’re scratching your head trying to fix it.
One of the attractions of a Managed Service is that it gives you expertise to rely on, and someone to take the pressure from you.
Does SD WAN reduce this pressure?
- In some ways SD WAN can make things more of a worry because it adds complexity but hides it away. We've heard already about the situation in which latency took a dive but SD WAN made it harder to diagnose.
- SD WAN encourages greater use of the internet, which is unpredictable and creates an additional challenge to find and solve poor user-experience.
- When introducing internet to your sites, you’re introducing a new attack surface so you need to have security built-in. Converged security adds a further complication to the network.
An Enterprise WAN manager recently made these points while summarising his SD WAN experience:
- “SD wan updates and patches are really critical as they touch your entire estate.”
- “SD wan is more sensitive to ISP quality than traditional network - we don’t know why yet. You really need a reliable underlay.”
- “When there is a problem I want a service provider to rely on.”
Do you want to manage connections to Cloud?
Cloud connectivity comes with some design choices and management implications that have a bearing on the choice between DIY and managed SD WAN. Examples include:
- Internet connections might be considered cheaper, but egress costs from cloud platforms can be up to 4 times greater
- Private connections to cloud platforms can provide better performance
- Private connections are also inherently more secure
- Either type will need to be designed, scaled and provisioned
- Location of Cloud DCs and cloud network access points will have a bearing on performance and will require you to be clear where your data resides and the latency involved.
This raises the question whether you would prefer to make the design decisions and handle the work yourself or use a managed service.
Do you want your team to manage the network or to concentrate on adding value to your business?
Most businesses have limited IT resources and want to deploy them in the most effective way. A common line of reasoning is that the IT Team should concentrate on things that only they can do, and have the WAN managed by experts.
You might consider the WAN as a haulage or parcel delivery function; perhaps SD WAN as the smarter version that auto-routes around congestion. Amazon would probably build their own capability. The rest of us might prefer to ask a parcel company to manage their deliveries, so that we can focus on the product we build rather than how we’ll deliver it.
Why are you using a Managed Network today and how many of those reasons will still apply with SD WAN?
If you have a Managed WAN but question the value of a Managed SD WAN then it would help to identify all the reasons why you're using the service today and decide which would still apply with SD WAN.
What do you value in your current Managed WAN Service?
- The procurement and provision of circuits and carriers?
- The project management of deployments?
- The field engineering team to deploy and then support in-life?
- The 24x7x365 WAN helpdesk to deal with problems arising?
- Someone to rely on, and with whom the buck stops?
- The design and management of connections to Cloud?
- The provision of networking skills to design the network and troubleshoot tricky problems?
- Having expertise on tap?
- Accountability - the buck stops over there?
- Freeing your team to concentrate on adding value to your business?