You’re ready to embrace DevOps. Or you’re in the midst of building a DevOps organization. Now what?
First off, congratulations on making a smart decision. DevOps makes good business sense so long as it’s done with intention. But there, of course, lies the challenge – how to make sure your organization is really prepared to transform the way you work.
In this post, I’ll provide a breakdown of what many people think DevOps is and what ReactiveOps (RO) thinks it is (“the RO Solution”). I’ll go further to explain why DevOps matters, what cultural and philosophical changes are needed to implement DevOps effectively and how you can know whether your organization will embrace the shift in thinking required.
I have a lot to say on these matters, so this post will be followed by a few others. Think of this post and the ones that follow as a self-assessment or self-reflection, one that I hope will help CIOs better understand if their organization is prepared for big change. My goal is to provide some insight that might help ensure you implement the DevOps solution that best serves your business.
What Is DevOps?
Let’s start by talking about DevOps generally. DevOps is a closer interface or connection between product development and product operations, deployment and management. Sounds straightforward, right?
It’s not. Actually, there’s no common, shared understanding of what DevOps is. If you ask 10 people, you’ll get 10 different answers (many of them contradictory). It’s hard to agree upon the definition, so many fall back on the argument that DevOps is fundamentally about empathy—developers’ empathy for operations staff, and operations’ empathy for developers.
This definition makes DevOps almost seem like a hugfest, a psychological experiment of sorts, rather than a tactical way of working that, when done strategically, amps up team productivity, shortens release cycles and leads to substantial time savings and financial gains.
Let’s take a step back and think about how the DevOps idea was born. The scenario goes something like this – organizations are under constant pressure to release software quickly. The speed with which software is developed and deployed traditionally doesn’t allow a lot of time for collaboration and engagement between engineers and operations staff.
Conversations and alignment are key. But oftentimes that alignment is lacking. As a result, developers may find that their platform isn’t configured in a way that best meets their needs, and operations may feel that the product code is simply “thrown over the wall” (to use a DevOps cliché). The operations team may not sufficiently understand software and feature requirements and may overprovision or underprovision resources accordingly. What happens next is no mystery – operations teams are held responsible for engineering decisions that negatively impact the performance and reliability of apps and services, which is conceptually problematic. Worse, it leads to poor outcomes, including impacts on the organization’s bottom line.
The RO Take on DevOps
Application performance suffers in siloed organizations. Silos simply don’t work. But eliminating silos is easier said than done. To further complicate matters, silos aren’t limited to development teams and operations teams. Some organizations historically have lots of independent handoffs from this team to that. It’s probably no surprise that these handoffs can turn into a high-pressure game of hot potato, where software is passed from one group to the next with little clarity or efficiency. After all, it’s easier to point blame that way. (It’s engineering’s fault! No, it’s operations’ fault! QA signed off on the software release, so it’s their fault!)
Consider the benefits of a more integrated approach that encourages and optimizes the involvement of a variety of people from the product team. As just one example, QA, marketing, sales and customer service often get wind of new features only after they land in production. What benefits might organizations see by involving these teams earlier in the process?
Let’s wrap back around to the earlier discussion and say that DevOps truly is about empathy. Assuming so, then why not broaden the conventional definition of DevOps and encourage empathy across the entire organization? Rather than enabling two subgroups of a product team to work more closely together, why not add other groups to the mix, such as QA, design, UX/UI, QA, product management, training and support? The way we see it at RO, DevOps involves closer interface and connection among all facets of product development and all members of the product team.
And by product team, I mean everyone who’s involved in building a product and releasing it to end users. How can you deliver the best outcome both for your organization and for all these diverse stakeholders? The answer to this question should form the baseline of any organization’s DevOps approach.
In the next post, I’ll get less philosophical and provide some thoughts about why DevOps implementations make good business sense. I’ll consider the ways in which DevOps is similar to Agile and Continuous Integration/Continuous Development, as well as describe some of the key benefits of DevOps.