Return to site

Using DevOps Principles to Break up Bottlenecks

A lot of energy and money has been expended to define DevOps in the last few years. My firm belief is, if you get a dozen DevOps practitioners in one room and ask them to define DevOps, you’ll end up with fourteen or fifteen definitions. And they’d all be right, based on their perspectives.

Here at Zivra, we have our own definition, of course, and we focus on DevOps consulting at the enterprise level. But at all levels, the more important question is not “What is DevOps?” The more important question is “Why DevOps?”

What’s the goal of DevOps? At the end of the day, we all have the same goal – create better software faster. In other words, we want to increase the quality of the software. And we also want to get the software out to the user community as fast as possible. So, if you’re saying something like “Duh!” under your breath, I’m confident I’ve made my point.

Software creation is a process, regardless of the methodology you use. The trick is to set up an efficient process, get it moving, and eliminate any bottlenecks along the way. I sense another big “Duh!” coming on, so let me move ahead to my point.

A little history will help illustrate the idea. It hasn’t been all that long since companies viewed the physical activity of writing software as a huge bottleneck. As the ability of computing to help the business became more apparent in the late 60s, companies built massive IT departments to support their operations. An IT department routinely required eighteen months to design, code, test, and deliver a new application. Needless to say, the business side of these companies soon became frustrated by this lead time. One company I worked for created their own separate software shop and called it “Engineering”.

In case you missed it, software development time was the first bottleneck. But it didn’t take long for creative people (and entrepreneurs) to recognize and start solving this problem. New languages were created, object-oriented programming was pioneered, and techniques like Xtreme Programming (XP) were developed. The most sweeping and impactful change may have been the introduction of Agile programming methodologies.

On the other side, companies developed testing techniques. Companies experimented with prototyping tests and generating testing scripts. The concepts of test cases and use cases were additional useful developments.

All of these developments were useful and made parts of the process go faster with better quality. Some of them made significant improvements to speed and quality. And yet, the overall process was not always faster or better. Why? Because of the physical rules that govern process. Two basic process rules are always in effect:

  • If you make a speed improvement in front of a bottleneck, work piles up faster at the bottleneck.
  • If you make a speed improvement after the bottleneck, you get better capacity potential for speed, but no more throughput because the bottleneck still exists.

The only way to get more speed is to improve the throughput at the bottleneck. Another no-brainer, right? But sometimes this fact escapes us when we’re chasing improvement ideas.

It makes a lot of sense to analyze your processes and find the “choke points” – those steps in your process that hold you up. The worst one is usually obvious. It’s the one that causes the biggest current delay in your process.

And what happens when you find and fix that big bottleneck issue? Yep, you guessed it. You find the next bottleneck. So it is clearly an iterative process. Find the worst bottleneck, fix it, observe and repeat.

The good news is, implementing DevOps processes and automations frequently are the solution to many common bottlenecks.

What are some of the other DevOps activities that can break though bottlenecks and speed up your software development process?

Here’s a few areas to consider:

  • Automated Build – Makes the builds faster and more accurate (less human intervention).
  • Automated Deployment – Speeds up deployment and makes it more accurate (again, less human intervention)
  • Continuous Integration (C/I) – Picks up changes as soon as they are made (or shortly thereafter) and confirms that the build still works.
  • Continuous Deployment (CD) – Deploys built software automatically to environments so updated software is immediately available to the rest of the team.
  • CI Testing – Tightens the feedback loop for the developers for quicker turn-around on defects.
  • Code Quality Checks – Promotes standards and quality, which reduces rework and the time required to make changes.
  • On-Demand Environment Provisioning – Shortens the lead time for new environments for testing and other uses.
  • Environment Configuration Management – Ensures that environment configuration changes are applied to all environments so deployment and/or testing events are not delayed.
  • A Built Artifact Repository – Eliminates some of the need for rebuilding software and provides additional rollback options.

More improvement opportunities related to DevOps do exist, but you get the idea.

Now, we are left with a few interesting questions.

  • Which process area should you attack first?
  • Which one is the biggest bottleneck in your process?
  • Which one gets you the most benefit? And is that benefit more speed or more quality, or is that principle a foundational item that you need to implement so that you can build other capabilities on that platform?

The temptation is to come up with and publish a step-by-step process for breaking through the bottlenecks. The problem with this idea is that all software development efforts are different. Thus, the answer to the above questions is as always… “That depends.”

For example, your application may be a traditional database / business logic / website application, or it might be an implementation of SAP or PeopleSoft. Or your application development may be completely managed within an Integration Development Environment (IDE) that doesn’t lend itself easily to traditional DevOps toolsets.

What’s the solution?

First, analysis. Then action. For most organizations, some form of DevOps assessment is needed to better understand the organization’s DevOps capabilities and needs. After the assessment, the organization takes action to address the issues and recommendations from the assessment.

A good assessment would be conducted by an independent party that is tool-agnostic, so you are getting unbiased advice. It would include a statement of where you are, issues, risks, recommendations, quick wins, and what bottlenecks you need to fix to increase your DevOps capability and thus, your speed and quality of software production.

In small, simple software shops, an internal inspection and review may be what is needed. In large enterprises, a formal assessment by an unbiased, outside entity may be the best approach.

No matter what techniques you use, the bottom line of the effort will usually look something like this:

  • Find the most limiting bottleneck in your software development process,
  • Figure out the best way to increase its throughput,
  • Plan your solution,
  • Implement your plan,
  • Revalidate against high level plans, and
  • Rinse and Repeat

Join us again in a couple of weeks for the next Zivra Blog. We’ll be discussing more ideas about DevOps and other related subjects.


Kimberly Megahee – Zivra, LLC – SCM Practice Director

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly