SDN and Organizational Grease

Depending on who you ask, the primary objective of SDN is to improve management and operations. By centralizing control, things like provisioning and troubleshooting can be streamlined, reducing the time and effort it takes to perform tasks. From that central point of control, a number of interfaces exist that make automation more effective, or at least more accessible.

But there is more to operational efficiency than the commands and keystrokes required to get something done.

Friction in any ecosystem is greatest at the boundaries between elements. When two things must work together to perform a task, the act of coordinating comes with some overhead. When these things are systems, the overhead typically shows up as integration cost and some performance hit when state is exchanged. When the elements are people or organizations, the cost shows up in the delays incurred by communicating and passing off tasks (as with ticket handling at large companies).

In networking, it is far too often the case that organizational friction exceeds operational effort. Put more directly, the time it takes to volley requests back and forth between collaborating teams exceeds the actual work time required to make a change. Reducing top-line metrics like Mean Time to Repair (MTTR) and Time to Deploy ends up being dependent on making individual commands easier AND on making the cross-organizational effort more seamless.

With this in mind, it could be that the biggest operational gains that companies will see in SDN environments will not be in the automation of individual workflows but rather in the reduction in organizational boundaries.

Consider that one of the central tenets of SDN is the separation of control and forwarding. This is typically (though not always) implemented via some central controller. By moving the point of control to logically central entity, the entirety of the resource pool can be managed from a single place. The result could be an expansion of management domains to include more and different types of devices. As architectures become more inclusive, you can collapse overlapping management domains into single regions of control.

The whole idea of collapsing control is terrifying from a people and process perspective. Most of us have a very healthy sense of ownership over our domain, and the idea of sharing (or worse, ceding entirely) that domain with another person or team is unnerving at best. Things like process, workflow, and even oversight become nontrivial in shared spaces. And the resultant changes in control model are difficult to predict with enough precision to assuage the fears of everything melting down.

But if the primary business objective is to simplify management in support of driving top-line metrics down, then something has to change. If the time to complete a particular task is dominated by organizational overhead, eking out a few minutes in the manual execution of a task is meaningless when compared to reducing the time it takes to coordinate on activities.

Take for example a multi-site datacenter. For business continuity reasons, maybe you have built out multiple datacenters at different sites. Ideally, you’d like to manage the entire pool of resources in an active-active mode. You probably connect these datacenters through either a WAN gateway running MPLS or maybe using optical transport equipment.

However you have connected the sites, you now have three separate networks: the two datacenters and the interconnect network. If you want to provision end-to-end services, what do you do?

The point here is that you have three separate control domains managed by two or three different teams. When you want to do anything across all three domains, you incur an organizational coordination overhead.

If SDN allows these three control domains to be managed under a single management domain, the organizational element can be reduced. In the short term, you still have two or three teams, so this doesn’t alleviate the problem straight away. But over time, as your organizational convergence catches up with your network convergence, you end up with a streamlined workflow to get end-to-end services.

In this case, I use a multi-site datacenter as the example, but that is not the only place where multiple domains exist. Many IT shops build out dedicated storage networks to handle high volumes of traffic (think: Big Data). If SDN allows those networks to be collapsed into a single network with more central control, you get the same benefit.

It is probably a stretch to suggest SDN was created with organizational boundaries in mind, but the benefits of control might be most profound in how they provide a bit of organizational grease to speed up the process of administrating a network.

[Today’s fun fact: The only jointless bone in your body is the throat. Yeah, I didn’t know the throat was a bone either.]

via Business 2 Community http://ift.tt/1jJMiZL