SDN: Consider The Problems First

I was one of those annoying Linux advocates in the late 90s/early 2000s. If you asked me, Linux was the cure to all of IT’s ails. Need a router? Linux ipchains. Need to make slides? Linux and LaTeX (careful doing a Google search on that). MP3 jukebox? Linux, and some scripts I wrote one weekend.  

But even I didn’t think the barrage of articles asking “What is your Linux strategy?” made sense. Why would it? The decision to use Linux stems from a problem yielding a strategy (the “how”), giving way to a plan (the “what”) that could be addressed, in part, with using Linux. Starting with Linux didn’t make sense to me because all of my rationales for using Linux were rooted in a use case, not the other way around.

Twenty years later, articles that ask  “What is your SDN strategy?” are as cringe-worthy as my “Linux cures all of IT’s ails” theory. Strategy should be the secondary component, after careful consideration of the problem. How do network problems yield solutions that are best addressed with software-defined networking?

To avoid being carried away by the mindset that SDN is a cure-all for any network issue, thus positioning the organization for a failed deployment from the get-go, organizations need to refocus their attention from the external market to internal systems. So, here are three questions to answer before you start down the SDN road:

1. What is the use case?

It sounds obvious, but the process of really fleshing out the problems your network needs to solve can be more challenging than it appears. Today’s IT environments are complex and consist of many different functions, so there is more pressure on enterprise networks. Identifying the root causes of issues can be intensive for IT managers, but this is a necessary step. It’s crucial to keep in mind the main purpose of a network: To deliver enterprise applications. This means you’ll need a handle on the applications, what these applications need out of the network, and the frequency with which you expect to update the network infrastructure to accommodate application changes.

2. What is needed to enable existing network solutions to solve the issue?

If we’re honest with ourselves, it’s easy to get caught up in the “want “versus the “need.” To break through the hype around industry trends, especially SDN, IT managers need exhaust all options for their current tools before completely reorganizing infrastructure. To start, consider the following questions:

All of these questions drive home a reality check. While it is exciting to get new toys, we all have budgets to abide by and expenses to manage. If there is a way to update the current infrastructure so it can work to meet the demands of the business, even in the short term, you may find it prudent to do so, until the next challenge comes along.

3. If SDN really is the solution, am I ready to deploy it?

This last hurdle goes back to a running theme that I’ve written about for some time now: The talent to drive these next-gen networks is critical. If you need to add someone to your IT team that can help drive automation, or a sysadmin that can bring business-critical apps into this new environment, then talent, not technology, is the first issue to address. The last thing you want to do is have a pile of gear that can’t be rolled out because the manpower to support the transition is not available.

If you have all three of these questions answered – you know the use case, you know why your current network fails to hit the mark, and have the right skills in place to do something with the new technology – you’re off to a great start. You’ve done the legwork to ensure that you and your team have all the right ingredients for deploying SDN and can quickly realize an improvement in business functions.  

At the end of the day, it’s about finding solutions that work for your IT team and your organization’s needs. After all, all we really want is success with our deployments, whether that be SDN or another technology.