You're Fast? Great. Are You Efficient?

White House Maker Faire: 10 Cool Inventions

There's a lot of focus lately on software-defined architectures. SDN, SDDC, cloud, and DevOps all share a primary component: the ability to improve the speed of application deployments. Each technology takes a slightly different path to get there, but they all leverage the power of abstraction and programmability.

We hear about the efficiency and speed of provisioning gained through these capabilities as though they were intertwined. Spoiler alert: They're not.

Speed (or velocity, if you prefer) is how quickly you can accomplish a task. Efficiency is a comparison -- a ratio -- of the useful work performed by a machine or in a process to the total work needed to complete a process. Speed and efficiency are related, but they're not synonymous.

The concept of efficiency through automation and orchestration of processes derives from Lean manufacturing and is commonly applied to business and software development through Six Sigma methodology. Agile takes many of its cues from Lean, while DevOps takes its cues from Agile, and SDN -- though its devotees won't admit it yet -- is taking its cues from DevOps. Thus, the notion of improving the speed of deployment across the entire chain of network services is ultimately derived from Lean principles.

[Is your team gathering the right DevOps metrics? Read 'Selling' DevOps With Business Results.]

That's important because it provides a framework for understanding and measuring the efficiency of operational processes.

Processes are considered Lean when their efficiency is 25% or more. That includes provisioning, configuration, maintenance, and scheduled downtime. It's about the whole operational process, not composite individual tasks.

Lean defines a simple equation for determining the efficiency of a (transactional) process:

In every process, there is execution time (tasks) and delay times (handoffs, approvals). A cycle is the sum of the delay and execution time.

Suppose each step of a process takes 30 minutes to execute, and there are three 30-minute delays. The speed of this process is 180 minutes, and the efficiency of this process is 50%. That's pretty lean by definition. Automating the steps to reduce their execution time to five minutes each nets a speed of 105 minutes and an efficiency of 14%.

"Wait a minute," you might say. "Executing faster decreases efficiency? How is that a good thing?"

It's not. That's the point. Executing individual steps in a process faster (automation) does not necessarily net you a gain in efficiency. Efficiency and speed are not the same, in much the same way that automation and orchestration are not the same.

Automation addresses the execution time and improves the speed with which you can accomplish a task. But orchestration is about the whole process and attempts to address the "delay" phases -- that time spent with no forward progress waiting for the next person to execute the next task.

These are the pieces of Lean and Agile that have been adopted by business process management systems, with the result of radically improved efficiency in business processes. Conversely, these are the pieces of DevOps and software-defined everything that IT has yet to recognize, let alone adopt.

It isn't just the speed with which we can provision and configure network services that IT must address to get goods to market fast. We also need to attack the lag between tasks -- the delay phases.

If that seems easy to you, you're wrong.

[When you look forward three or five years, the public cloud cost picture for enterprises is murky, even in light of recent price wars. Do you agree? Take our Cloud ROI Survey and enter to win a Fire HDX.]

Often these delays are attributable to information gathering that is still accomplished by face-to-face meetings. How much of that information could be collected digitally? And how much would that reduce the delay, subsequently improving efficiency? Often a lot, but convincing people to give up their routines isn't easy.

Maybe delays are caused by waiting for approvals on workflows that could be orchestrated to save time. If you think eliminating meetings is tough, try convincing people to relinquish the heady sense of power and control involved in signing off.

These are hurdles business leaders have tackled if your company has gone through a business process optimization exercise. A wealth of expertise may already exist on improving efficiency. IT must seek that experience with an eye toward applying it to operational processes; the goal is improving not just the speed of provisioning, but also its efficiency.

Until you identify and mitigate the causes of delays between steps, you won't truly improve efficiency or speed up network and infrastructure service provisioning as much as you could. At some point, automation will offer no more gains; you'll be executing as fast as you possibly can. But the delays will still be there, and they will be the primary culprit when the business asks, "Why is this taking so long?"

When refining or embarking on DevOps or a software-defined project, evaluate with an eye toward not just automation (speed) but also orchestration (efficiency). Make sure tools, frameworks, platforms, and products are enabled with integration capabilities (like APIs) that can be used to orchestrate a process, not just automate a task.

Here's a step-by-step plan to mesh IT goals with business and customer objectives and, critically, measure your initiatives to ensure that the business is successful. Get the How To Tie Tech Innovation To Business Strategy report today (registration required).