Strategic CIO // Enterprise Agility
Commentary
6/30/2014
09:06 AM
Lori MacVittie
Lori MacVittie
Commentary
Connect Directly
RSS
E-Mail
50%
50%

You're Fast? Great. Are You Efficient?

Jumping hurdles at record speed doesn't mean much if you stroll between them. IT leaders must eliminate process-driven delays or trip on DevOps and SDN efforts.

White House Maker Faire: 10 Cool Inventions
White House Maker Faire: 10 Cool Inventions
(Click image for larger view and slideshow.)

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).

Lori MacVittie is a subject matter expert on cloud computing, cloud and application security, and application delivery and is responsible for education and evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
nasimson
50%
50%
nasimson,
User Rank: Strategist
7/28/2014 | 1:42:57 AM
The difference
Thanks Lori. For the first time I have been able to distinguish between speed and efficiency. The diagram really helped.
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
7/22/2014 | 6:08:52 PM
So speeding up steps makes the delays (inefficiencies) more obvious?
If I'm following this, speeding up the steps just makes the delays more obvious, and that shows up in a poorer efficiency statistic. The end-to-end process would still be completed more quickly if you decreased the length of time required to complete each step (unless, in the process, you somehow introduce new delays).

Or am I misunderstanding?
ChrisMurphy
50%
50%
ChrisMurphy,
User Rank: Author
7/22/2014 | 6:01:50 PM
Re: Eye opening
We just posted a column by GE Capital's CTO that offers an example of this -- of a legal/compliance review process that took too long compared with the speed needed to turn agile iterations. Legal and security became part of the Agile review cycles. Article below:   

http://www.informationweek.com/strategic-cio/enterprise-agility/why-enterprises-need-to-adapt-to-agile/a/d-id/1297414
Lorna Garey
50%
50%
Lorna Garey,
User Rank: Author
6/30/2014 | 6:27:43 PM
Re: Eye opening
True story: At a long-ago employer that had an open office before open offices were a thing, many of my coworkers smoked. There were about 10 people, and every 90 minutes like clockwork, at least five of them would head outside for 15 minutes (it was Texas -- lots of smokers, nice weather).

During that time, everyone else picked up the slack. It was kinda like a series of wasteful meetings.

Then, we got a new manager who announced that nonsmokers got to leave two hours early every Friday to make up for the time we were at our desks while the other people were out bullshitting in the parking lot. Suddenly, I spent way less time scrambling to do other peoples' work.

It's all about incentive to change.
pcharles09
50%
50%
pcharles09,
User Rank: Moderator
6/30/2014 | 6:18:31 PM
Re: Eye opening
But how else would you get to share the donuts & coffee?

I kid but realized very early in the game. Meetings are pointless & can 99.9% of the time be summed up in a 1-2 paragraph email. But often, this is avoided to kill time & unfortunately productivity.
Lorna Garey
50%
50%
Lorna Garey,
User Rank: Author
6/30/2014 | 2:27:58 PM
Eye opening
When editing this, I ran that calculation a few times (on two calulators) because that drop in efficiency seemed impossibly steep. If anything can get people to stop already with the meetings ...
What The Business Really Thinks Of IT: 3 Hard Truths
What The Business Really Thinks Of IT: 3 Hard Truths
They say perception is reality. If so, many in-house IT departments have reason to worry. InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business views IT's performance in delivering services - and, more important, powering innovation. The news isn't great.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest September 23, 2014
Intrigued by the concept of a converged infrastructure but worry you lack the expertise to DIY? Dell, HP, IBM, VMware, and other vendors want to help.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.