Who is in control of enterprise networking transformations?
Oct 23, 2017
It’s fairly well established at this point that enterprise networking is going to go through a transformation of sorts in most companies. Whether that transformation is best described as an architectural step-function change, or a couple of nuanced tweaks is an interesting question. And the answer is probably not going to be wholly dependent on the intentions of the networking team.
Because enterprise networking evolution has moved at a relative snail’s pace over the last decade, some IT teams are going to find that change might not necessarily happen on their terms. And that can lead to unplanned tension and difficult-to-reconcile direction from outside of the team.
Networking teams will find that to the extent that they can proactively tackle change, they will be in a better position to drive with intent rather than read and react to their environment. And that will make all the difference in successfully executing against a more advanced future.
The drivers for change that come from inside the team are fairly straightforward. Every team in every IT discipline has a breakdown of maintenance and innovation activities that heavily favors things that merely keep the lights on. Let’s face it: managing IT in an enterprise of even moderate sophistication is hard. There are rarely enough people, budgets are scarce, and time is largely nonexistent.
So it should be no surprise that enterprise teams, even if left unmanaged, arrive at the same basic priorities: simpler architectures and more automated operations.
And the desires behind these priorities? There are all kinds of metrics, but for my money, I would bet that most teams just want a little bit of sanity. They want to do good work, and anything that allows them to focus on the hard and more interesting issues is something worth pursuing.
The external drivers that come from the rest of the business are actually not always that different. They just come with a slightly different cover over them, and typically with a lot more urgency.
Security is a major driver behind change in enterprises. Interestingly, most of the people on the ground in enterprise IT teams actually understand how scary their company’s security posture is. They are aware of the versions of code that are running. They know how hard it is to stay current with patches, especially when changes are throttled and gated by expensive process. They know about the hygienic behaviors that lead to a more solid infrastructure. And they know how often good hygiene gets traded off for the sake of expediency.
They have probably even lamented to their management about how they need to be pay down their technical debt, or address some of the weaknesses in their process.
So you can imagine how wonderful it is when the company suddenly gets religion around security. It’s not because it’s necessarily more important than before. It’s just that it’s a news item now. And if one of these weekly breaches hits your company, it’s no longer a mess to cleanup—it’s a stock-moving crisis that gets everyone from the Board to the CEO to the CIO suddenly interested in your discipline.
The problem with urgency
The nice thing about having some external factor drive urgency is that suddenly corporate inertia is not the problem. People are open to change. In fact, they are pretty much expecting it.
But while having everyone ready to change is good, having expectations that change is going to happen in days and weeks is difficult. The issues are are rarely as simple as “This software hasn’t been patched.” Rather, the issue is that regularly monitoring components and having a process to routinely stay current is not happening.
In fact, one of the worst possible outcomes is that the sudden rallying cry for a patch is successful. If people believe that they can manufacture urgency and that IT can basically deliver on a moment’s notice, then there is no real impetus for making the kinds of sustaining change that need to happen for a better longterm situation.
It’s not just security
And while the most visible areas are security-related today, it’s worth noting that it’s not just security. Every time an article about the cloud pops up on the CEOs list of hot articles, there is the risk that the organization is going to suddenly tack right after a hallway conversation where the CEO demands to know the company’s cloud strategy.
In the absence of a planned transition, it’s amazing how quickly the cloud strategy basically becomes “Take what we have now and run it in the cloud!”
You might protest. “But, you realize just picking up what we do and sticking it in the cloud isn’t going to change anything, right?”
But pointy-haired bosses don’t always want to know what the truth is. The article was in Forbes. Cloud is the future. Your competitor just moved a bunch of workloads to AWS or Azure. Get it done.
Plan the strategy as part of your day-to-day
It’s obvious that the right path forward is to thoughtfully plan your strategy. That means understanding not only your start and end point, but also your migration between the two.
But if look at your time allocation (as a team or even as an individual) in a given week, and you have dedicated virtually no time to making the transition, how will you ever make progress towards your desired end state?
Getting permission to spend time on forward-looking projects might require you to include the activities as part of your current day-to-day. Structuring your supplier engagements with a stronger services component that includes more education and jumpstart offerings is a relatively low-friction way to start. This means building these items into your vendor engagements, and making sure that you protect small bits of funding that go along with every purchase.
For instance, when you build out additional data center capacity, you might consider including workflow services so that your teams are better equipped to identify key workflows, and so that you get some services support to automate one or two of them. The goal should not be to automate the data center in one fell swoop, but rather to use every engagement as a means of incrementally improving.
You might consider allocating budget during annual planning time to quarterly training aimed at up-leveling team skills, especially around next-gen architectures (controller- or intent-based management) and operations (automation or event-driven infrastructure).
The bottom line
If you fail to develop a plan and proactively communicate it to your company during times where the urgency is low, you will almost invariably be subjected to external drivers around which the urgency will be high. And while urgency to complete things is healthy, there is no greater threat to sustainable practice than an artificial deadline piled onto a team based on an overreaction to an event that leadership barely understands.
Enterprises that fail to make future planning a core part of their operating principles are going to find that their planning will be done for them. And if you think it’s difficult to grapple with all the new things out in the market today, wait until you are suddenly mandated to roll something out inside a change window that simple isn’t reasonable.
The worst case is not that you will fail under these conditions. It’s that you might succeed, in which case, you basically just established a new normal where you have zero control of your domain.