Ok, I’ll admit it: I think that Software Defined Networking (SDN) is an exciting alternative to traditional network architectures. But companies don’t implement a technology or an architecture just because it’s exciting, or because it’s all the rage with the press and the analysts. In most cases there has to be a strong business case. That raises a really important question: What’s the business case for implementing SDN?
One way to build a business case for SDN is to quantify the financial benefits that it brings to the IT organization. For example, many vendors claim that SDN will enable IT organizations to centralize configuration management and hence significantly reduce the associated manual labor. If an IT organization wants to take this approach to building a business case, they should start by doing a Proof of Concept (POC) to both prove that the SDN solution works, and to enable the organization to quantify the resulting labor savings. Once this is done, the organization may well be in a position to make the case that an investment of x dollars will result in labor savings that are greater than x. There’s just one problem with that approach: most people who are in a position to approve that business case know that if the people associated with the labor savings all stay with the company, there are no hard dollar savings. If the IT organization doesn’t want to reduce the size of their staff, they can still be successful with this approach to creating a business case, however the organization has to perform two additional tasks. They have to identify the new work that the staff will be able to perform now that less time is taken up doing configuration management and they have to quantify the financial benefits of performing that work. Doable, but not always easy.
Another way to build a business case for SDN is to quantify the financial benefits that it brings to the company’s business unit managers. The good news is that vendors have identified a number of business benefits that are associated with SDN; e.g., increased business agility, or the ability to automatically implement policy. At the Powerpoint level I get the value of those benefits. The bad news, however, is that building a compelling fact-based business case around the financial impact of those benefits can be very challenging. A recent conversation that I had with an IT director illustrates those challenges: the director explained to me that his company has a very strong focus on becoming more agile and innovative. He also said that he was exploring SDN because it has the promise of making the network more agile. Unfortunately, he was having trouble connecting the dots. He didn’t know how to measure the network agility that SDN provides and then demonstrate how that added network agility can lead to a quantified increase in business agility. For example, one way that SDN makes a network more agile is by enabling the network to dynamically respond to an application’s request for L4 – L7 services such as optimization and security. The challenge the IT director had was concretely demonstrating how that added network agility enabled increased business agility, such as being able to bring out new products and services faster.
As I mentioned, I believe that SDN is an exciting new architecture. I would find it even more exciting if we as an industry had a better handle on how to create a business case for implementing SDN. So, what’s an IT organization to do about this? I suggest that the next time a vendor is pitching you their SDN solution and talking about how they implement network virtualization, or talking about which version of OpenFlow they implement, you should ask them: Where’s the business case for doing any of this? If asked this question often enough, vendors will respond.