The ability for IT to change at the pace of business.
These are a few bullet points used by vendors, marketers, and some technology analysts to describe the main goal of IT today. The ability to deploy services quickly sounds great, but I’m not sure this is truly top of mind for most network operators.
First, let’s define what it means for a network to be agile.
An agile network is one that can respond to customer needs very quickly – that means easily deploying new network capabilities, new services, or new policies. The key is speed to facilitate the best end-user experience possible.
But why do we need our networks to be so agile? The reason is that some organizations release new services so frequently or are so customer-facing with their technology that an agile network is a business requirement. When a company sells an application or if the technology is the product, agility is table-stakes.
For example, a software company releasing new iterations of their product very regularly likely needs an infrastructure that can accommodate any changes developers can throw at it.
A large online retail company that updates back-end inventory software and front-end resources frequently will need an infrastructure that can accommodate whatever adjustments the changing services require.
However, is this true for most organizations?
Though I can say it’s true for a small number of the organizations I’ve dealt with in my career, most just don’t deploy new services very often, or at least they don’t deploy the kinds of services that require the network be reconfigured.
So what are most network operators really interested in? To that end, I casually surveyed a few of my current customers about their IT goals by asking this question:
What would you as a network operator at your organization say your one primary goal is for the network operations team?
Lately my customers have been hospitals, school districts, banks, manufacturing companies, and municipal government. All responded with the same answer: availability.
Some answered with something synonymous such as “stability”, “uptime”, or “avoiding outages”, but the message was clear. At least for these few network operators, keeping network resources available with no disruptions is of the utmost importance.
This all started with a conversation with one of my customers, a network manager at a hospital system. We discussed industry trends such as network programmability and management overlays, both in the context of agility. What stuck with me was that he dismissed the need to deploy new services quickly, and he explained it in terms of cost-benefit.
Basically, in a large hospital system with operating rooms, MRI scanners, emergency rooms, helipads, satellite offices, and so on, there is no tolerance for network downtime. Even brief unplanned outages can cost lives.
The risk of deploying new services frequently, having to touch the network often, and pushing new policies at a rate faster than change management can handle, introduced a risk (a cost) that outweighed the benefit of deploying a new service quickly.
In fact, the point was moot because new services took significant time to get buy-in from the C-level and test thoroughly before being introduced to production. Change management in a high-stakes environment like a hospital system with 18,000 employees isn’t just unnecessary bureaucratic nonsense, it’s deliberate risk mitigation.
A network manager of a manufacturing facility responded by explaining that any network downtime meant the automated picker/packer machines that relied on line-of-site wireless would stop and business would grind to a halt. They just didn’t deploy new services to their staff very often, and changes to applications didn’t usually affect the network anyway.
The IT director of a school district with 9,800 students and about 1000 staff explained that school districts are a prime target for ransomware, and since he was perpetually short-staffed, it was all he could do to make sure there was never any network downtime especially in places such as the main offices, bus garages, and the on-premises police stations.
These areas were used to secure the safety of thousands of young people, so a network outage meant calling individual bus drivers on cell phones, paging systems offline, and automatic door security mechanisms not working. Applications? Well, they were mostly in the cloud anyway.
The network manager for a nearby municipal government described at length how emergency 911 services, waste water treatment facilities, traffic sensors, public transportation facilities, and even the local municipal airport all relied on the county network infrastructure. Downtime meant no 911 services, it meant valves on waste water pumps not working, and it meant a loss of connectivity to the air traffic control tower.
He explained that yes, they deployed new services periodically as would any growing organization; nevertheless, agility paled in comparison to the need for a reliable and stable network.
The fact that I’ve come to this conclusion based on inductive reasoning isn’t lost on me. I understand that I’m basing a general conclusion on only a handful of specific anecdotal examples.
I also understand that these aren’t either-or propositions. A forward-thinking NetOps team doesn’t have to focus on agility at the expense of availability, or the other way around.
However, I do sense that the narrative in the industry is skewed and doesn’t accurately reflect what network operators really want more than anything else, namely stable, resilient, and highly available networks.