Technology Blog

Which Should You Upgrade First: The WAN or the Branch?

Aruba Employee
Aruba Employee

This blog is written by Jim Metzler, founder and vice president of Ashton, Metzler Associates. 

enterprise.sw.GettyImages-680316379.jpg
About two years ago I was contacted by the network organization for a large enterprise. The enterprise has over 3,000 branch offices and they wanted my help with a project to upgrade both their WAN and the networking functionality inside their branch offices. It was a challenging project to organize in part because of the extend of the functionality that it encompassed and in part due to the rapidly evolving nature of the enabling technologies. One goal of this blog is to describe the overall project plan we used and another goal is to suggest the changes that I would make to that plan if we were starting fresh today.

 

Breaking the Project into Two Pieces

A lot has happened in the IT industry over the last two years. That is particularly true relative to the development of solutions that apply the concepts of being software defined to the WAN and to the branch office. Today many such solutions are being evaluated and adopted. However, two years ago the wave of articles and reports that preceed the development and adoption of any new technology were just beginning to be written about Software Defined WANs (SD-WANs). At that time little if anything was being written about fundamentally new approaches to branch office networking in general and nothing was being written about Software Defined Networks for branches.

 

The fact that SD-WANs were just beginning to be a hot topic and that new branch office solutions were virtually nonexistent was one of two key factors that caused us to make a couple of fundamental decisions relative to how we ran the project. One decision was to split the project into two components, a WAN component and a branch office component. The other decision was to finish the WAN component prior to starting the branch office component.

 

The second key factor that drove us to split the project into two components was our desire to not take on a project that was so all encompassing that it would take an unacceptable amount of time to complete. Adding fuel to that concern was the realization that back in 2015 there was little if any overlap between the providers of SD-WAN solutions, which were primarily small start-ups, and the providers of branch office networking solutions. Because of that, if we didn’t split the project into two components it would have required us to simultaneously interact with two very different sets of vendors.

 

Creating a Mini-RFI

One common way to approach a project like the one described above is for an enterprise network organization to issue a Request for Proposal (RFP) to a wide array of vendors. In addition to containing a broad range of questions about the vendors’ products and services, RFPs typically ask the vendors to provide detailed network designs and/or detailed pricing. After reviewing the responses and holding face-to-face meetings with some or all of the vendors, most network organizations then issue a second round of questions to a short list of vendors. If the network organization is satisfied with the answers to those questions they typically go forward with a Proof of Concept (POC) trial with one or two vendors. Because of the complex steps that are involved, an RFP-based evaluation project consumes considerable resources and typically takes nine months to a year from the start of the project to when a POC begins.

 

In contrast to an RFP, a Request for Information (RFI) is often less lengthy than an RFP and it doesn’t ask vendors to provide detailed designs or pricing. Since my client had no interest in a lengthy, resource consuming project we went forward with a process based on creating and distributing a small, highly-focused RFI, which we referred to a mini-RFI. Part of my role on both components of the project was to provide my client with a high-level summary of the feasible vendors. My client then used that summary to select a small set of vendors to receive the mini-RFI.

 

One of the goals that my client established for each component of the project was to use a mini-RFI to quickly get to where they were starting a POC and to use the POC to resolve any unanswered questions about what a solution did and how well it performed. While we have not yet finished the mini-RFI that is associated with the branch office component of the project, we are on track to achieve that goal in this component of the project. We achieved that goal with the mini-RFI that was part of the SD-WAN component of the project as it took us just over three months to go from the start of this component of the project to beginning a POC.

 

Evaluating What I Would Do Differently

An evaluation process based on an RFP is the right choice for some organizations in some instances. However, I tend to prefer an evaluation process based on an RFI or a mini-RFI and if I was starting this project fresh today, I would recommend taking that approach.

 

However, breaking the project into two components, which made sense at the time, is not something that I would do again. The reason for that is that we have recently seen the introduction into the market of unified branch solutions. These solutions provide several benefits, including the cost savings that are associated with SD-WANs and the benefit that is of upmost importance to my client – minimizing the complexity that is associated with managing networking in thousands of branch offices. One of the ways that branch-wide solutions reduce this complexity is by enabling all the branch office networking functionality with a single policy that is administered centrally. This includes the wired LAN, the wireless LAN and the WAN. In a growing number of instances, the WAN component of these solutions is an SD-WAN.

 

If I were starting fresh today I would have one project that encompassed both the WAN and the rest of the branch office networking functionality. As before, I would create for my client a list of feasible vendors. This time, however, the vendors would be vendors who provide viable branch-wide solutions that include SD-WAN functionality.

 

 

Jim Metzler is founder and vice president at Ashton, Metzler Associates.

 

Like this blog? Share it on social media or give it a thumbs-up using the buttons below.

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Read all about it! If it’s happening now, it’s in the community.

Check out the latest blogs from your community team, the community experts and other industry sources.
Labels