Although vendor-written, this contributed piece does not promote a product or service and has been edited and approved by Network World editors.
Software Defined Networking (SDN) promises increased agility, enhanced security and automation—all while saving time and money. But the prospect of adopting SDN may seem daunting because it is still a relatively new technology and few long-term examples exist to illustrate best practices for implementation.
Working with government and enterprise customers, I’ve seen a five-step process emerge for efficient, effective SDN implementation. Follow them to reap the benefits of SDN without disrupting your IT environment.
* Define a use case. SDN is a broad, multi-faceted technology. Whether it fits in your organization depends on the problem you want to solve. Too often I see organizations adopt or implement a technology—SDN included—in an attempt to solve all their problems. This is not the best approach for adopting SDN.
Instead, identify a narrow use case or problem that you believe SDN can solve. Whether that problem involves network automation, security or agility, the important thing is to start with just one. (See “Where does SDN make sense? We ask Fidelity’s Director of Global Network Architecture”)
A single use case (with tangible, positive results) offers more reliable, measurable outcomes than implementing SDN across your entire network. Moreover, instead of explaining SDN’s value in abstract, you can proceed backed by proven success.
By familiarizing yourself and your colleagues with SDN on a gradual, focused, limited scope, you can adopt SDN and not disrupt your entire infrastructure and staff.
* Assemble a cross-functional team. SDN is a silo-breaking technology. Implementing it correctly requires a well-rounded team with a broad range of skills and a comprehensive approach. Ideally, that team fosters efficiency and collaboration—both critical to maximize the benefits of SDN.
Consider, for example, a network security issue. To successfully address it with software-defined networking, you need people who define or write security policy, the network engineering team and those charged with network management. Just as importantly, though, you need them all working in tandem, or else something will be overlooked or left out of the solution.
Regrouping IT resources can be difficult. But, even with separation of duty, collaboration is crucial and achievable. It’s also the only way to ensure SDN success.
Remember, this isn’t about eliminating jobs, but increasing efficiency. This way, your IT staff spends less time on operational overhead and more time on engineering and enabling your IT infrastructure to better meet the needs of your mission.
* Test in a less critical network area. Implementing SDN doesn’t require uprooting your entire network. That only leads to angry colleagues and massive risks as you struggle to manage an unfamiliar network.
Just as you tested SDN using a limited use case, the same principle applies to testing it on the network. Find a less critical network area where you can work without disturbing the network as a whole.
This small-scale SDN implementation lets you safely test your use case without subjecting the rest of your team and infrastructure to undue risk. It’s a sandbox—have fun in it!
* Review your test case. After working with SDN for a while, you should have enough data to measure your outcomes against your original goals. While this sounds like a given, many organizations take this type of review for granted.
Without thoroughly reviewing SDN’s effectiveness, you can’t answer three important questions: Did it solve your current problem? Is it a wise investment to expand SDN throughout the network? Do you have the infrastructure (both personnel and technical) to maintain software defined networking across the organization?
With performance, efficiency, security and budget all at stake, it’s important to understand SDN’s results before staking your organization’s IT future on it.
* Gain maturity before expanding deployment. Even if your SDN test case performs beyond expectations, there’s one final step before expanding it across your network. Slowly increase your project’s footprint and gain maturity before fully expanding deployment.
This might seem overly cautious, but there’s a good reason. Even if SDN worked on a limited scope and in a seldom-used portion of the network, the rest of your network and organization might not be ready.
Are you able to set up the cross-functional teams needed for large-scale success? How will SDN affect performance among more-trafficked areas of the network? Are there other basic challenges that software-defined networking might solve?
Sometimes answering these questions leads you back to step one—and that’s OK.
SDN is a powerful technology with a wealth of benefits, but it must be properly implemented to get the results you want. Otherwise you not only risk your network’s security and performance, but also the ability to implement the technology at all. Reap the rewards by doing it right the first time.