Unfortunately, I’ve seen too many SD-WAN and SASE proofs of concepts (PoCs) fail. It’s usually not down to the technology (per se) or a lack of enthusiasm. On the contrary: companies dive headfirst into their PoC. But they forget to check beforehand: what is it exactly that I’m trying to achieve? And: who needs to be on board and which sites, services and users should be included in the PoC for a representative outcome? By skipping these vital steps, they risk losing huge amounts of time and money.
Companies that are looking into secure connectivity aren’t naive. Or lazy. They step into the game with the best intentions. They have even sought out the best technology for the job. But that’s where it goes wrong: they focus only on technology. Business objectives and expectations are too vaguely defined – if the technology does what it promises, we’re good right? Sure, the technology might be spot on, but if you haven’t taken the time preparing for your PoC, you’ll risk escalating costs and dragging timelines.
It’s like this: you’ve seen Dutch speed skater Ireen Wüst win the 1500 meters at the Olympics, and you want to be on that podium as well. But if you have no idea what it takes to be a top athlete, if you don’t set goals, don’t surround yourself with a team that will support you all the way, and don’t follow a strict training regime, you’ll never get to that stage. The same is true for SASE: if you don’t know what your objectives are, what you expect the solution to deliver, and why it benefits the business, how can you really know if the test was successful?
What a good PoC looks like
So, what does a good PoC look like? Well, you start by assembling the right team and getting the external parties on board. For a proper PoC, your team requires a business owner, a project lead, and a technical lead. These functions can sometimes be combined in a single person, of course. Also, you might need support from local staff for on-site installation support and from business users to help test applications and services.
Securing proper support from your SASE vendor or solution provider is equally important and should be a selection criterion as well, in my opinion. I’ve seen far too many cases where technical experts were so far removed from the customer that the customer never achieved what they had in mind. That’s what happens if a shared pool of centralized vendor or provider resources works on many projects simultaneously, without having much knowledge of, or dedication to, a specific customer project. If you want to achieve the solution you want, you’ll want to get up close and personal with your tech support.
How will the business benefit?
After the right people are in place and relations are set up, you start with the preparation setting up the business objectives, success criteria and the test plan. The objectives obviously define the results for the business. It is the why, the urgency of the purchase, the reason you can’t move on without SASE or SD-WAN. Therefore, you can’t just look at it from an IT perspective, you need to know why the business will benefit in the long run.
Once the objectives are clear, you decide what criteria the solution or service needs to meet in order to deliver the business objectives, and for the test to be successful. It’s the how of the project. The what is the detailed test plan for the solution or service you’re planning to use. The plan outlines how the success criteria should be tested: what’s going to be tested? By whom, when, how. And what is the expected outcome of the test?
A good preparation will prevent delays
Companies often tend to skip the preparation phase because it takes time to formulate business objectives, success criteria and a detailed plan. But if you invest in this phase, you will be able to provide a clear direction and structure to the PoC. It will prevent frustrations, delays or even cancellation due to a lack of clear goals and a clear process. And it will also provide a clear-cut view on any solution, service, or organizational shortcomings at an early stage, enabling you to assess the likelihood of success and decide if you’re ready to start testing at all.
Part of the preparation is also investigating if all the conditions for a successful SD-WAN or SASE PoC are in place. For example: how’s your data governance? Do you know who needs access to what data? You’ll need to know this for SASE policies. But also investigate the overall topology. I run into a lot of companies who have a limited or inaccurate view of their topology. Even though I can understand why – enterprises often have legacy on top of legacy – it’s bad practice to start a network transformation without knowing exactly what needs to be transformed in the first place.
Start with a proper inventory
If you start with the wrong information, you will need to make exceptions or new designs on the fly, causing project delays, burdening the project team, and eventually leading to decreasing business support. So start with a good inventory of the existing network and security environment, and agree upon a limited number of standardized SD-WAN or SASE site designs. Sure, you’ll need some flexibility for non-standard site configurations, but a good inventory and agreed standardized site designs will keep these to a minimum and render them manageable.
As you can probably tell by now, I believe that companies underestimate the importance of good preparation. They also underestimate the benefits you can gain from that preparation: a successfully and timely delivered PoC that provides the business with a clear outcome to make an informed decision about their investment in SD-WAN or SASE. A key factor in this decision is that the PoC is conducted with a representative scope of services and locations.
Test all core services and applications
For a solid PoC, you need to test all core services and applications at different branch locations, for different remote and at-home users, and in different key geographies. That means that you need to include your datacenters, public cloud services, such as Azure and AWS, but also key SaaS services and a few branch locations that are representative for other branch offices.
If you have all these locations in your sights, you can prepare a high-level design as well as low-level designs for the locations and services involved. But keep in mind that these locations are not isolated; they need to communicate with the rest of the network continuously. So you’ll also need an implementation and migration plan, which includes interoperability aspects and a roll-back plan.
A good start is half the work
The benefit for including these different locations and planning for their operability, is two-fold. First, you’ll run into significantly less trouble once you decide to implement the SD-WAN or SASE solution for real. Second, you’ve already done half the work for the full roll-out. The PoC designs can be considered as blueprint designs for the rest of the network. I believe that the true purpose of a PoC is not only to test if the solution does what it should do, but that you can also test and optimize designs and plans before mass roll-out starts.
To cut a long story short: it’s not a luxury to take your time for a PoC. It will save costs, blood, sweat and tears in the long run. OK, it might mean that you first need to get the right people on board. You need to look beyond the technical benefits of the solution, do some digging around to get all the information on the table, and to ensure that the PoC represents the actual roll-out. It might take some more time now, but in the end, you’ll save time and yourself some grey hairs.
Are you ready to take your SD-WAN or SASE PoC serious? Please contact us.
Author: Ferran van den Berg, Managing Director at Cerebo Networks
