Last week, in Step 2 of our building a better, more agile, network blog series, we covered the importance of segmenting your network down to its basic building blocks. This week we’ll dive into Step 3.

It feels unnatural to suggest that enterprise networks should be a domain for increased risk taking, or that doing so would actually result in a better, more agile network. After all, the network team carries a disproportionately high degree of responsibility for overall IT systems availability. A single network outage can impact dozens of applications and hundreds to thousands of end users.

With such a heavy focus on maintaining high-availability infrastructures, we end up with strong culture of risk aversion built on incremental change. The downside to this incrementalism is a reluctance to consider new ideas, architectures, and technologies.

In their April 2017 foundational research report, Avoid These ‘Bottom Ten’ Networking Worst Practices, Gartner analysts Andrew LernerDanellie YoungVivek Bhalla contend that this risk aversion preference for incremental change leads to:

  • Reluctance to evaluate newer architectures and designs
  • Reticence to evaluate non-incumbent vendors
  • Overbuilding solutions in the name of future scale
  • Relying on reference architectures without adapting them to an appropriate scale

“This perspective can stifle innovation when universally applied to the network infrastructure, and ultimately results in expensive, over-engineered solutions that under-perform,” according to the Gartner analysts who based their assertions on some 2,000 client interactions and 3,500 inquiries on networking from 2015 to 2017.

Turning risk into reward

Turning risk into reward requires a willingness to move beyond incremental change and often beyond incumbent vendors. We have a number of clients that operate mission critical contact centers, some of whom also support 911 emergency responses. One such client was running an Avaya distributed call center, supporting each contact center with a high availability architecture including dual MPLS links.

With the proven technologies and architecture, every time a primary link would fail, their 99.999% highly available network would quickly failover to the backup link. Despite this high availability architecture, however, due to a slight delay in the failover process, measured in milliseconds, they would lose continuity with the remote call manager and the whole site would go into reboot mode, taking it offline for minutes at a time. An unacceptable outcome costing them tens of thousands in lost productivity, down time, and customer good will.

To solve the problem, they took a big risk — moving beyond incremental change to a new architecture and a range of new technologies. While to most it would seem counter intuitive, they elected to scrap MPLS links for a mix of Ethernet Private Lines and broadband internet, combined with an inexpensive x86 SD-WAN overlay at the edge. Their reward has been 100% up-time at their contact centers for more than a year now.

As they say, nothing ventured, nothing gained. I’d be happy to share more details about how these simple technologies are solving a wide range of challenges, while improving performance and simplifying management of hybrid enterprise IT environments.

Next week, we’ll dig into Step 4 on the path to a better network: Implement network automation.

How can we help? 

We love talking about software-defined networks and the cloud! Let us know if we can help by filling out the form. Cheers!