DevOps: What a Wonderful World it Would Be

The promises of DevOps are clear. They offer faster iterations, allowing ops to keep up with agile development and make an IT organization more responsive to business needs.

DevOps doesn’t make less code. It doesn’t reduce configuration files. It doesn’t eliminate deployment issues (though it might reduce them). It doesn’t eliminate testing; indeed, it creates more if Agile and DevOps are taken to their logical conclusion:  More testing, earlier. DevOps doesn’t reduce the need for security.

In short, it doesn’t reduce workloads. It might automate some of them, freeing up man-hours, which is absolutely a positive result—one of the more positive results, in my opinion. But it also introduces the overhead of the DevOps toolchain, so some of that automated freed-up time is already spoken for.

And automation of testing (for example) is something that’s been around for decades. The first UI-based automated testing system I recall was Microsoft Test. I managed a team that used it extensively to automate test runs of the software we delivered to financial services. It worked well, and there was much gnashing of teeth when Microsoft discontinued the product.

The same is true of most of the time-saving benefits of DevOps: We’ve tried them before, but DevOps approaches them from a different perspective—and, in many cases, a more sustainable perspective.

I’m a DevOps aficionado, make no mistake. The reason I’m stressing what it won’t do here is because misperceptions drag it down. Don’t go into it looking to reduce costs, because at least in the short run you won’t. Don’t go into it looking to save work, because at least in the short term those savings will be minimal. Going into it for the wrong reasons means the things you are measuring will ultimately look like failures, even if all the good DevOps offers is reaped.

Instead, go into it looking to be more responsive. Go into it looking to beat your competition to market. Go into it looking to increase communications across the team. Delve into DevOps for the right reasons, and you’ll be measuring the right outputs.

And remember, it is an iterative process. Don’t overstate expected benefits on the first pass. Low-hanging fruit makes it look as if DevOps will do a lot of things, but low-hanging fruit often has tight ties into firmly rooted trees, making it harder to grab than originally thought. Use a measured approach and look for consistent improvements. In some organizations those improvements might be small at first. But use your knowledge of the organization and application portfolio to create a measured success plan.

Reaping the benefits is worth the change DevOps brings. The ability to tell a line-of-business leader that the new functionality they are considering could be mocked up and ready for review in a week or two is a huge benefit to the organization. And it doesn’t hurt at all that such responsiveness will raise the rest of the organization’s opinion of IT.

So it is a wonderful world, if your goals are the right ones.

— Don Macvittie