Not everyone knows how to negotiate buying a car, but most people know not to just walk up on the lot and ask the car salesman to tell you what kind of car to buy. Most people would assume the salesman has an interest in getting you to spend as much money as possible. It wouldn’t be a surprise if he tried to convince you the extra features were necessities, or that the 20-year-old jalopy really just needs a buff and a coat of wax and is absolutely worth your entire budget.

The same philosophy should be applied when shopping for business technology services. Don’t ask the Service Providers (SPs) to tell you what to buy. Their goal is to get you to spend as much as possible, which leaves you having to be choosey about what you reveal, to prevent them from leveraging your needs into a higher price. But it doesn’t have to be like this! a simple change in the way you approach the game will dramatically improve the outcomes.

For those of us that aren’t experts in car purchases, a typical approach starts off as conversations with friends and family who know the subject. We use their counsel to better define what type of car we should be looking for, and its approximate value. That may include researching some aspects on the internet. Only when we have a clear general idea of what we want do we approach the car salesman to narrow things down. Instead of asking him what we should buy, we ask him what he has that meets our criteria.

The same applies when shopping for business technology service. If you aren’t sure what you’re looking for, the first thing you should do is find an expert who can advise you objectively, and have them help you define what results your business requires. A good Subject Matter Expert (SME) will also help draw out needs and wants you aren’t even necessarily aware of. Once you have your requirements defined, you can then approach various SPs and have them present the products and pricing they feel best meet your specifications.

Similarly, when defining your specifications, make sure you’re accounting for the right type of ongoing support provisions. If you expect your team to manage the service after installation, then your specification needs to make the access/control requirements clear. If you are expecting the SP or another party to provide support, make sure you are clear on where the funding for those services is coming from. There are several ways in which you might negotiate with SPs to have them subsidize your ongoing support. If your technology support efforts would benefit from staff augmentation, then make sure you’re clear on what level of support you require before you begin shopping.

Whatever you decide your specifications are, what matters is that you’ve defined them before you walk onto the lot and start talking to a salesperson. If you’re not clear on what you need, if you don’t have the time or staff resources to pursue a proper evaluation, or if you want to make sure that your money is being spent wisely, the Comtel Group can help.

Keep Your Team – Reduce Waste – Get Smarter Solutions

Whatever technology services you consume, whether Dial-tone or UCaaS; whether Internet or WAN; whether cloud or premise Infrastructure; whether network or endpoint security, your business needs some combination of any of these services to survive in today’s market. These services are traditionally the wheelhouse of the large and ominous Service Provider or “SP.” SPs are, by definition, large-scale companies that provide technology services to a significant market share. There are, of course, smaller and more local Managed Service Providers, but their size and closeness makes a deep partnership much more tangible and effective. It’s easy to develop an effective partnership with a local MSP, provided they have the right skill sets to meet your needs. The large SPs, though, have spread their reach across a large region, if not fully national or international. They pretty much always have the talent. The problem is that the sheer size of these companies requires a stringent set of rules for processes and behavior. These rules, too numerous to count and too dispersed and shifting to ever know in full, became the groundwork of what is inevitably experienced as a horrendous bureaucracy.

The bureaucracy of large Service Providers is well known by almost all. Communications must follow draconian policies that make it too difficult to quickly transmit clear messages between departments, often leading to the right hand not knowing what the left hand is doing, and making any sort of short term change or correction all but impossible. Implications of personal and corporate liability scare the rank-and-file employees away from touching anything outside of their explicit responsibilities, and ensures that every single billing and repair ticket starts with the provider forcing the customer to prove the problem is the provider’s fault, rather than the provider proving it isn’t. These behaviors culminate in the most aggravating paradox – there will never be a reliable champion for you within their organization. Those that fail miserably are thinned out in the usual ways, but those that excel at their roles are often quickly promoted out of them. While there are definitely some out there who genuinely love their job, most customers have one of two experiences: either a constantly rotating carousel of account managers that are exceptional and/or horrendous, or they have a single account manager that meets expectations enough to not be fired but not enough to ever get promoted up.

So, if you don’t have one of those magical account managers who absolutely loves what they do, what are you to do when you need to move a behemoth like an AT&T or a Cisco? In over 30 years of experience, Comtel has uncovered 6 specific tactics that have helped us navigate smoothly through numerous large service provider organizations. Please do be warned: these tactics require you to pick up the reigns and lead. If you’ve already got enough on your plate, the Comtel Group can help you in executing, but you will still find these actions to be quite helpful.

• Understand the processes. Arguably the most important, but objectively least sensical, step is understanding what it is the SP needs to do for you. Most reasonable people would say “Wait! Aren’t they supposed to know what they need to do for me?” And the answer is: of course they ought to, but it’s rare that they actually do. With the high rate of turnover, the low incentives, and a culture that reinforces aversion to risk, it is very rare to find an employee that knows enough about what goes on outside their cubicle to tell you what the entire process looks like. This is exactly why we must take it upon ourselves to know where our need is going throughout the organization to be satisfied. In other words, most employees know who hands them their work and who they hand their work to, but not necessarily any further into the process than that. By knowing how your order flows through the provider’s organization, you can track when people are flaking on their responsibilities, passing work in the wrong direction, or generally just not getting the job done.

• Plan from Finish to Start. Once you understand the major milestones to complete the process, you can begin to plan what needs to be done and when. The best way to do this is to start with the ideal outcome in mind. If you want new services to be up and available on a certain date, then use your knowledge of the process to plan what date you need to be at the milestone just before completion. And what date do you need to be at the 2nd to last milestone? And the 3rd to last? And so on. With this methodology, your plan automatically incorporates the necessary deadlines to achieve the results upon the optimal date. This makes it extremely easy to spot early on in the project whether you’re on track for making your date or not. If you don’t hit the current milestone by the prescribed date, you know you’re going to be late.

• Be prepared to drive. SPs often have contracts with SLAs and rules of compensation for their failures. Their aforementioned aversion to liability means they love to point the finger at you, and sometimes they’ll reach for some pretty far-out justification to say you are the reason why something isn’t happening. This is easily circumvented by taking on a leadership mentality, rather than assuming the provider will lead you. This does not mean you have to do everything yourself. It does means you will be the one who has to drive the assignment of responsibilities, as well as holding each person accountable for their assignments. Before you leave a call with an SP team, make sure they’ve all agreed to the responsibilities each one has been assigned, and follow it up with an e-mail memorializing the agreement and due date(s). While it is not the way we think it ought to be, you will find a much greater success rate and shorter time frame if you walk into an engagement with an SP expecting to be the one who has to call the shots and hold people’s feet to the fires.

• Understand which roles are responsible. In order to properly lead a service provider team, you will need to have an understanding of what their jobs actually allow them to do. As mentioned, many SPs are very rigid on how far any individual can reach throughout the organization. Most rank-and-file employees pull their specific set of levers, and never vary from that routine. However, most of the problems you’re likely to encounter occur in roles performed by people other than your point of contact. Raising the heat on them doesn’t actually generate any better results, it just makes that contact person more fearful of engaging with you. Likewise, CCing everyone on the e-mail blast just causes frustrating noise. Therefore, it’s incredibly important to know which employee pulls the lever you need pulled, and it is as equally important that you focus your attention on them, rather than everyone around them. There may be times where a shotgun blast is most appropriate, but honing in with a rifle will more often bring you the results you need.

• Keep the details together. The fewer places you have to look for necessary information, the faster you can validate plans, make decisions, and execute changes. Usually, its not enough to just file everything under its own category. When we’re talking about business technologies, it’s rare that a change to any single technology only affects that technology. Changing dial-tone can impact your PBX, while changing your PBX can impact your network, which is also impacted by your infrastructure decisions. The interconnectedness of these technologies also means that putting everything into the same folder is usually not sufficient, either. In most cases, what is needed is a consolidation of all resources, compiled into a single, easily referenceable inventory document. With the right data recorded in the right ways, this document becomes the living, breathing master version of your configuration, allowing you to quickly see all implications of any individual change to your technology.

• Pull the alarm while there’s still time to put out the fire. The last tactic is just as important as the others, but one of the easiest to put into place. If you smell smoke, investigate. If you see fire, pull the alarm. A lot of people want to be nice to the SP’s employee, and give them a chance to make things right before they ask for escalation, but this only puts you at greater risk. If your SP contact is not performing, it could very well be due to an issue outside of their authority. Or it could be them directly. Either way, you are best served by escalating as soon as you become aware of the issue. You don’t have to be rude or put the person on blast, but you do need to seek correction while there is still time to plan and execute a change in course. If you wait too long to call out a problem, it may be too late to undo the effects.

These 6 tactics will give you a very strong foundation for managing a bureaucracy, but, as mentioned before, require you to pick up the burden of leading and driving these behemoth companies. In some cases, these tactics need to be paired with a deep understanding of the underlying technology the work revolves around. In other cases, the processes may be so convoluted that it could take hundreds of hours of study to properly understand the processes involved, which is only the first of the six tactics. In other words: understanding and managing SPs can be a lot of brain damage.

Keep Your Team – Reduce Waste – Get Smarter Solutions

Businesses of today are experiencing a significant shift in work process, workforce, and environment. Companies are ramping up the pace at which they migrate data off-prem into the cloud. Workers are also moving off-prem at an increasing rate. To top it all off, the cost of internet services continue to drop every year, with higher bandwidth costing less. The culmination of all of this is that an organization’s WAN now needs to be more accessible, more distributed, more secure, and more reliable than ever before, but it also needs to cost less. SD-WAN is a term that many have heard can solve all of these issues, but the truth is that there is much more nuance to this technology.

If you want to ensure your company is getting the best service for the best price, then you have to consider each of the ways you might leverage SDWAN. With the nuance I just mentioned, that can be a daunting task, but we’ve written this guide specifically to help you navigate the muddy waters of SDWAN evaluation. As we continue to dig into how SDWAN might be able to solve the aforementioned concerns for your organization, we eventually need to address the specific differences between different SDWAN solutions and how those will impact your ability to achieve the outcomes you are seeking. Before we go any further, though, let’s make sure we’ve got good footing.

In the last segment, we discussed the business outcomes that SDWAN can provide. You must have those priorities ranked. It is possible to achieve all of the desired outcomes, but it’s not guaranteed. At some point, you may be required to sacrifice a particular outcome to achieve more important ones. Thus, only after you have clearly identified your business objectives, have a clear idea of what you want SDWAN to do for our organization (as discussed in the previous segment), and know which metrics you will use to measure the outcome, can we truly begin to look at the differences between SDWAN solutions. This framework will be the tool that allows you to put different SDWAN solutions on equal ground for comparison. It will be essential to the rest of this process. Once we have the highest level of decisions made, we can focus on the first layer of decisions that has to do directly with the technology itself. These are the 4 Key Decisions when shopping for an SDWAN solution. It’s worth noting that the following 4 Key Decisions are not listed in any specific order. You will have to define for yourself in which order you address these, but I encourage you to keep in mind that each of these decisions influences your options in the other three areas, so you may find yourself circling back and changing some answers.

Key Decision #1 – Cloud or Premise?
Regardless of which side you choose here, you will end up with either a physical or virtual device located at each premise facility. The real question here is whether each branch connects to a central cloud hub/gateway, or if the SDWAN solution creates an all-sites mesh network. A mesh network will provide a faster site-to-site experience, but is often limited in how well it can manage integrated cloud services. A cloud SDWAN is, unsurprisingly, positioned better to integrate with cloud services, while carrying the drawback that site-to-site communications may be slightly slower, due to having to first traverse to the core, and then be rerouted. The best-case scenarios are the SDWAN solutions that will route site-to-site traffic directly between sites, while all cloud-directed and meta-data/management traffic is routed to the cloud hub. Few solutions offer this level of flexibility.

Key Decision #2 – Bandwidth Aggregation or Load Balancing?
All SDWAN solutions will give you the ability to effectively utilize multiple bandwidth sources, especially from disparate providers. This is key to the Active/Active failover functionality. However, while all SDWAN solutions perform a version of this, any specific SDWAN solution will fall into one of two camps in terms of the mechanisms. Either they will perform a form of advanced load balancing or they will aggregate the bandwidth. Load balancing is a more static experience. Applications will be restricted to a single circuit and it’s current performance. Only when that circuit fails will the traffic then be routed to the alternate circuit. Of course, since this is after the interruption occurs, there is an immediate and noticeable interruption in service to the user. An aggregate solution, however, assigns packets to each circuit based on the intersection of the packet’s priority and the current performance ratings of each circuit. Higher priority packets not only get to go first, but they also get to ride the better performing circuit. Because packet direction is determined on a relatively real-time basis (note: check with the SDWAN provider on how often they are polling internet circuits for health/performance), these types of SDWAN solutions can move traffic between circuits at exceptional speed, effectively treating all available bandwidth as one single pool to use freely, and having proven to be able to keep an application as sensitive as a VOIP call up and running without any effect on the quality of the transmission.

Key Decision #3 – Security: In-Line, Onboard, or Cloud?
Security cannot be ignored in any network conversation, especially once we start talking about data that is going off-site, which could very well be all of it! The question here is: what sort of integration do you want between your SDWAN solution and (most commonly) your firewall solution? While numerous other security products can be integrated with SDWAN, they’re typically all 3rd party add-ons. However, when it comes to NextGen Firewall and UTM capabilities, some SDWAN solutions, like Meraki and Barracuda, start from the appliance side of the equation, and thus have stronger onboard capabilities. Solutions like VeloCloud have been working with firewall providers such as Cisco, Juniper, and Palo Alto to create virtualized plug-ins. Other solutions, like Cato Networks, are built around a cloud-hosted firewall, with each location having a private and protected connection to ensure all traffic is sanitized. To decide which of these models works best for you, you’ll need to assess the current state of your security appliance investments, and compare those costs against the benefits of moving to a cloud or “As-A-Service” security posture. There can be quite a bit of discovery and deliberation in this decision, so don’t let the size of this paragraph belie the investment that you might need to make. You may want to consider leveraging a consulting resource to help guide you through more complex decision trees such as this.

Key Decision #4 – As A Service or Owned?
Similar to the question just raised regarding security, would your organization benefit from CAPEX and amortizing hardware that you are responsible for, or would you benefit from a managed service OPEX model? The question may feel a bit loaded, but it needs to be addressed, as it will significantly alter the SDWAN solutions you can consider, and there are positives and negatives for each side. For example, if you own your SDWAN hardware, then you become responsible for creating and/or connecting to a cloud hub. However, As A Service options will be managed by a service provider, meaning there will be some degree of limitation on visibility and reconfigurations. When evaluating this decision, cost often becomes a focal point. If that holds true for you, be sure to include the cost of lost productivity due to outages (resolved by SDWAN’s resiliency), the cost of maintenance for any solution you would own, and the impact to the company when you’ve bought equipment but it ends up being either not enough to support your goals or, even worse, more than you really needed (As A Service models can allow you to scale both up and down on a per-unit level). Many businesses end up preferring a steady and predictable operating expense over an unpredictable and variable capital expense.

By addressing these four questions first in your SDWAN evaluation, you will narrow down the field of contenders to a manageable level, which helps you get your organization on the right track quicker. These questions are also a tactical bridge between your Business Objectives and the actual technologies that you’ll employ to achieve them. By starting at the highest level and narrowing your focus as you go, you will find it’s much easier to weed out the options that don’t align with your needs. However, if your cup already runneth over with your day-to-day responsibilities, you may not have the patience or time to address all of the aspects of a complete evaluation, but that doesn’t make it any less important. If you’d like to offload the burdensome parts of an SDWAN evaluation, the Comtel Group can help.

Keep Your Team – Reduce Waste – Get Smarter Solutions

These days, it would be difficult to claim that virtualization doesn’t help contain and control your IT budget.  While  the “cloud” is still ambiguous in many ways, one specific aspect is relatively easy to understand: use one large computer pretending to be many smaller virtual computers to take advantage of economies of scale.  Now, no two cloud journeys will be exactly the same – each organization has its own specific collection of key focal points- but a lot of them will rhyme. For many businesses, going to the cloud will be a process (some easier, some more complex) of virtualizing their existing infrastructure and applications to one or more off-site servers, typically managed by a service provider. This can include data stores, line-of-business applications, production environments, communications platforms, and more. Such a change often brings significant improvements in fault tolerance, accessibility, and scalability.

Many businesses recognize the potential benefits, and are technologically ready to make the migration, but they will shy away from the upside because of the pricing model: cloud services are almost always subscription based.  Those with an eye on the dollars quickly point out that, given an equal and appropriate timeline, an indefinite monthly subscription fee will mathematically always cost more than a single one-time purchase for hardware.  While such a direct comparison is undeniable, it is an oversimplification of the issue.  It avoids addressing the advantages of a subscription model while overlooking the hindrances ownership. If you’re at the point of cloud strategy development where you’re beginning to consider the price/cost models of subscription versus ownership, then make sure you are including the following four considerations to ensure you are looking at all of the factors of cost.

In regards to total cost of ownership, increased fault tolerance is the most impacting, but it is by most accounts only the second most tangible benefit of a cloud-based service. By “tangible,” we mean “easily recognized by any and all users.” Resiliency is, after all, one of the central pillars of cloud services. Cloud service providers all take advantage of server clusters, high-speed replication, and mesh “fabrics”  to ensure that any individual failure never impacts your ability to use the services.  Since this is their whole reason for existing, they can afford to invest in 50, 100, 1,000 servers to ensure the maximum possible up-time, while most businesses supporting their own servers typically don’t scale beyond a primary or production server and a backup server (which, by the way, is typically for replication only, and can take hours or days to restore). That being the basis for the claim of increased fault tolerance, the reason this is a tangible benefit is because there is a very real and measurable cost for every minute of interruption or lost productivity your organization bears. Sum up the monthly payroll of all affected employees, the monthly cost of rent and electricity, and so on. Determine how much time is being lost, and you’ll quickly be able to see the hard cost of each interruption. There is also the consideration of “lost business” from an outage or failure, but that can be difficult for a business to quantify, whereas it’s usually extremely easy for any business to determine how much payroll and rent was spent during an outage.  Therefore, when comparing the one-time cost of ownership to the monthly subscription model, you’ll need to ensure that you add the annualized cost of lost payroll, rent, and utility fees due to premise-system failures to the one-time cost for the number of years you are evaluating.

Not as readily tangible a benefit, but still heavily impacting the cost of a cloud-based service is the freedom of liability. In particular, this is specifically referencing to the liability of maintaining the hardware and software, and ties heavily into the benefit of resiliency and up-time.  Much like the difference between renting and buying a house, there are many responsibilities that ownership of technology confers that drive up the cost of maintaining your own solution.  The most obvious and frequently dealt with is replacement of failed hardware.  If you own your phone system, and someone’s desk phone fails, you buy a new desk phone (particularly once you’re outside of any warranty periods).  If you’re maintaining your own servers and one of your drives fails, you have to pay for a replacement to be shipped and you’re operating at reduced capacity until it arrives. You may have opted to spend the money in advance and have an extra drive on standby for insurance, but that only affects the time to restoration, and only as long as you actually have the parts that failed. Whether you bought the replacement component in advance as insurance or immediately after in response, it equally increases your cost of ownership of the system. Ownership also puts the onus of updating firmware and software on you. Your team now has to coordinate periods of interruption for patch rollouts (AKA: risk!).  A cloud service simply disconnects the server cluster that needs maintenance, redirecting traffic to other nearby clusters, distributed for balance. And, of course, as more critical components begin to fail, the impact of failure begins to grow, as calculated above.  Therefore, when comparing the one-time cost of ownership to the monthly subscription model, you’ll also need to ensure that you include a budget for hardware replacement and patch administration time.  If you are paying a monthly fee for a support agreement on your equipment, that also needs to be included in the comparison.

The first most tangible benefit, though third most impacting to cost, is that of accessibility. Again, because a cloud service providers entire existence is, by definition, to provide cloud services, they can afford to spend the time and money to build relationships and presences with innumerable data centers and internet exchange points across the world. This means that regardless of where you are, whether at the office, at home, or on vacation, you’ll have access to the most direct route to your data possible- i.e. lowest latency, best user experience. Maintaining your own solution requires you direct all traffic back to “home base,” a behavior that not only creates a wide range of experiences based on how far you might be from the core server, but also requires the location to maintain enough bandwidth to handle hair-pinning remote workers alongside the on-site workers.  You could, if you so desired, put your self-owned solution in a nearby data center, and pay them to provide hands-on maintenance and support, but, to the point of this article, that is the essential idea behind private cloud solutions, and they will require a monthly or annual subscription fee.  Therefore, when comparing the one-time cost of ownership to the monthly subscription model, you’ll need to include the cost of increased bandwidth for remote workers (including people who take work home evening and weekends), and account for lost productivity of remote workers that are further away from the office.

The last point of comparison requires the longest timeline to quantify, but often times allows a business to completely transform the way they account for the cost of a particular technology.  This is the topic of scalability. Quite simply, the other central pillar of cloud services is the ability to add and remove services on an as-needed basis. Let that soak in for a moment: Expansion and contraction.  Once you purchase ownership of a technology, it becomes the responsibility of you and your company to amortize that expense out over a long enough period of time to make it an acceptable expense.  If you reach the capacity of the system and still need more, then you need to make another purchase, usually of significant size, and begin the amortization process again.  For many businesses, dramatic and difficult-to-predict spikes in capital expense are unfavorable. For many organizations, the predictable and linear nature of paying a fixed “per-unit” operational expense is much easier to digest and plan with. Furthermore, once you’ve bought it, it’s yours and you’re stuck with it.  If two years down the line you end up reducing your consumption to 50% of what you bought, then you’re stuck with twice as much technology as you need and all of the corresponding buyer’s remorse.  Conversely, with a cloud solution, if you find you have purchased more than you’re using, you simply reduce the quantities you are ordering, and return to focusing on your real priorities.  Many businesses take advantage of this and only pay for services when they’re actually using them, even going so far as to turn their cloud services on and off several times throughout any given day. With this flexibility, it is no longer necessary to find ways to leverage technology you bought until you’ve waited long enough to lower the average of what it cost divided by the time you’ve had it.  Therefore, when comparing the one-time cost of ownership to the monthly subscription model, you’ll need to include the cost of expansions, the cost gaining approval for CAPEX vs. approval for OPEX, the cost of risk carried while amortizing, and the cost of risk carried by the unretractable nature of ownership.

In review of these points, we quickly see that there are many costs of ownership that are not only often overlooked when comparing the one-time purchase price to a monthly subscription model, but  actually still end up being recurring expenses.  When these factors are properly accounted for, what was thought to be a one-time technology purchase is actually a combination of large capital expenditures with a handful of monthly operational expenses and an unnecessary amount of risk.  But, of course, the exact amount of risk, and the exact one-time and monthly costs, can take a lot of time and effort to pin down. If you’re looking to quantify the cost of moving to a cloud technology service over continuing to purchase self-managed and/or premise-based solutions, The Comtel Group can help.

With over 30 years of technology thought leadership, Comtel is a privately held professional and managed services firm that invented the industry disrupting “Procurement Exchange Management” or PXM. Not only is PXM a new technology service category altogether, but it provides the most powerful procurement proposition possible. Our offer is simple: eliminate the salespeople who drive little value and have Comtel procure your service provider contracts, and, in exchange, you’ll get to recapture those sales commission dollars from the service providers. You can use those dollars to fund our professional services and to tame those 800lb gorillas for you, or you keep the difference and put it back in your IT budget. Either way, the focus stays on helping you achieve your mission.

Keep Your Team – Reduce Waste – Get Smarter Solutions

Obvious disclaimers out of the way first. On the table right away: we’re going to be talking about SDWAN as an entire category of technology. Your exact mileage will vary depending on the actual SDWAN solution you end up integrating. As of the time of writing, there are some 25-30 different SDWAN solutions, each one focusing on a different aspects of SDWAN as their strength. Because of the nuances of between each solution, there is a lot of value in a complete and proper evaluation of what you really want to get out of your SDWAN solution.

The most widely touted and easiest-to-discuss benefit of SDWAN is lowered cost. This benefit is geared toward those organizations who are currently consuming Multi-Protocol Label Switching (MPLS) technology from their telecom service providers. The private nature of MPLS requires all circuits be with the same carrier. Yet, no carrier can deliver the strongest pricing in all markets in the US, let alone internationally. This conflict led many organizations to simply accepting a very high cost of private WAN services. With SDWAN, the provider’s on-premise terminating device will create IPSEC VPN connections between locations and/or cloud gateway (which then connect to cloud services). This is all done over standard internet connections (either Consumer or Business grade, as is appropriate to your needs), which can be extremely economical and flexible, so you can choose “best of breed” circuits at each of your locations rather than being forced to buy expensive circuits from one provider everywhere. In almost every case, an organization moving from MPLS to SDWAN can improve resiliency and bandwidth or reduce cost, and many can achieve both.

You might ask: What about additional latency, now that we’ve gone from private MPLS to encrypted VPN? And, to be fair, that does add a few milliseconds. However, SDWAN includes a couple considerations that help improve resiliency and application performance, and they tend to do so to a greater degree than what is lost via encryption. Going back to the core of SDWAN, we are able to virtualize high-end routers on low-cost hardware. This allows us to achieve the horsepower necessary to aggregate bandwidth between multiple networks. Some SDWAN solutions manage this via traditional load-balancing behavior, while others are able to offer a more true aggregation of bandwidth. In either case, we can leverage this ability by combining two or more circuits from disparate underlying providers to build a high level of inherent fault tolerance into our network. SDWAN solutions will poll each connection and determine the best path for your traffic based on real-time responses. SDWAN is also able to prioritize all traffic within its IPSEC tunnels, the same as MPLS, and because you’re connecting through a cloud gateway, you can ensure that your most sensitive applications are first in line on both the upload and the download, unlike traditional internet services. In short, the active-active links and application-aware routing allow a dynamic level of responsiveness that quickly adjusts to combat latency.

Let’s turn our attention to the idea of a cloud gateway for a moment. One will quickly recognize that not every SDWAN solution includes a cloud gateway. Meraki, Ecessa, and Barracuda are a few examples of “premise-based” or site-to-site SDWAN solutions. They still offer the same single pane of glass to orchestrate all devices, and it is accessible from the cloud, but that’s just an administration portal. Other solutions, such as VeloCloud, Cato, and Versa all offer a node on the network defined as the cloud gateway, which acts as the hub of your SDWAN network. On one hand, a Cloud Gateway allows virtualized access to each and every data center that the SDWAN provider partners with, allowing layer 2 connectivity with other cloud services hosted inside those same datacenters. On the other hand, the cloud gateway can also act as the ingress/egress point for connectivity to public cloud services. Cloud gateways can even present your IP addresses to the world, regardless of which physical circuit is actually handling the traffic, allowing you to have seamless inbound traffic failover – not only within a single location, but even between locations! This direct and secure connection allows for a seamless extension of the WAN to multiple clouds, both private and public. This allows for real-time performance management for cloud apps like MS Office 365 and SalesForce, as well as optimization of workflows for cloud infrastructure environments like AWS and Azure.

At a general level, SDWAN also reinforces network security. As already described, SDWAN offers application-specific policies with end-to-end real-time access control. With this as a strong foundation for monitoring and management, integration of threat detection and response becomes exceptionally empowered. Some SDWAN solutions, like VeloCloud, allow integration of virtualized NextGen firewalls and UTM. Other solutions, such as Cato Networks, are built around cloud-based firewalls. And others, still, like Meraki and Barracuda, are the result of security appliances beginning their evolution to the cloud. Regardless of which form it takes, SDWAN is well positioned to enable a distributed yet unified approach to security across multiple branch locations.

And, lastly, as touched on briefly before, the most tangible benefit of SDWAN is cloud-accessible orchestration. All SDWAN solutions offer a single, centralized, cloud-delivered management dashboard for configuration and reporting of WAN activity. With template-based “zero-touch” provisioning for all locations, whether branch, campus, or cloud, operations are simplified by magnitudes, not just margins. Detailed reporting of application and WAN performance are combined with a certain degree of business analytics to allow SDWAN solutions to shape routing and adjust policies based on typical network behavior. This enables such capabilities as bandwidth forecasting, which allows for optimal utilization of “on-demand” bandwidth services, which, in turn, leads to an even lower overall cost.

As mentioned at the start, there is not a single SDWAN solution that can accomplish all of these features. There are, however, numerous solutions that do some or even most of this extremely well. However, some of the smallest technical variances between solutions can result in some of the most impactful changes to your network performance, so it is always essential to ensure you have a clear spec, either by designing it yourself (See our article on Controlling your Procurement Outcomes), or leverage an expert resource, such as the Comtel Group, that can lead you through an SDWAN evaluation.

Keep Your Team – Reduce Waste – Get Smarter Solutions