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:
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:
More improvement opportunities related to DevOps do exist, but you get the idea.
Now, we are left with a few interesting questions.
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:
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
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly