If you’re reading this, odds are you’ve either already got a definition of DevOps in mind or you’re trying to find one. I’m of the firm belief that there is no one single definition that will adequately suffice. Instead there are multiple definitions that you “grow through” on your path. This post contains my thoughts on some of the experiences that individuals in several different roles and departments in an organization may have of DevOps, and a different perspective that may help you realize greater success at providing value to your customers.
But First: A Tangent
Before I get into definitions (wrong or right), there’s a little history on the concepts, practices, and behaviors discussed in “DevOps” circles. First of all, the practices predate the term, some by hundreds of years. Unlike Agile, DevOps is not “something” you are. It’s not the tools you use either. In the computing world, consultants with a sufficient understanding of the history and practices will be able to trace some of the concepts back to mainframe days, through the initial days of distributed computing, into the shared services structures of the 1980s and the outsourcing binge in the 1990s, and—yes—even into the Agile movements that came next. Indeed, in some respects, Agile and DevOps practices act like focusing mirrors for one another, but DevOps is best described as a culture.
While early Agile transformations focus on delivery of new software services through personal interactions and incremental delivery of value, DevOps practices focus on building tools and technologies which remove distractions from the value stream discussion. These DevOps practices provide enriched information upon which personal interactions can occur and decisions can be made and reduce delays between the actions of creators and the result of the usage of their results. More recently, enterprise Agile transformations have begun to focus on the development of new services beyond just software, while DevOps promoters have deeply expanded research and effort on understanding the pipeline of provisioning, delivery, and execution of services in a more generic sense.
DevOps Misconceptions and Truths
Here are some misconceptions, misunderstandings, and contextual views on DevOps in certain departments and roles. While they may not be true for you, these embody what I have encountered as an Agile/DevOps consultant.
|Department or Role||Misconception of DevOps||A Better Frame of Reference|
|IT Operations||The use of containers and automation exists to isolate and limit the impact developers can have on on-going operational responsibilities, and avoid dependency and configuration management. This way we can impose operational responsibility on development, and minimize production issues through tight environmental controls.||We, as operators, provide the tools and infrastructure that developers need so their primary focus is on providing value, and they are not distracted by things that have no direct impact on that value. Since developers are the ones responsible for value creation, we additionally help them understand the business value by helping them define the measure and meters to place in their code, provide access to those metrics, and help them understand how the environment affects them. This provides a means to create a bridge of trust between developers and end-users and directly links the value of dependable and trustworthy services to value propositions in the backlog.|
|IT Development||The use of containers and automation exists so new services can be developed quickly without having to consider operational configuration, dependency management, or capacity planning. We can build it however we want, and when we hand it off to operations they just have to deploy our container as-is.||Because we want to understand the value we are providing to our customers we work in collaboration with operations to get feedback on the application services we create, and the changes we make to them. |
Developers want feedback on changes quickly and often, not just from an IT perspective, but on how it has impacted users, customers, and clients (both internal and external). Our collaboration with IT Operations helps us know more about how our applications are used and the value of the changes we make.
|IT Management||The elimination of “development” vs “operations” arguments, budgets, and issues, which allows us to reduce staff, reduce budget, and let development teams add operational responsibilities (or vice versa) with a few simple tools.||DevOps is a constant review of tools, practices, and techniques with the objective of enriching personal interactions, creating and improving a stable pipeline, and delivering of new value. As such we can only recognize quality by providing needed infrastructure, expertise, and information when they are needed, and ensuring a unified team from conception through delivery.|
|Business Operator||DevOps is the latest buzzword that signifies collaboration between new service development and on-going operations that allows us to add new services while continuing to depend upon the services we need to continue providing existing services.||DevOps, along with Agile in general, is a change from attempting to define a contracted deliverable to another team within our organization, to an ongoing collaboration between the members of an expanded team for the delivery of new services that can be used to meet revenue, cost, or business objectives over the long-haul.|
|Security||The blurring of the roles and responsibilities of developers and operators, as well as the increasing of risk in the organization.||DevOps is an opportunity to look at new ways to meet regulations with greater involvement from all stakeholders the new service development process, so Security can ensure the entire process meets regulations and is executed safely. As active participants in the team, we aren’t the last to look at the product; instead we are engaged throughout service development. This also means we have to become Agile ourselves so that our tools and techniques for identifying security risks can be incorporated into processes earlier, consistently, and reliably.|
|Executive||A silver-bullet set of technologies and tools that will insure we can run more digital services for a lower cost, with fewer people, and less risk.||DevOps is an organization-wide change in thinking that places emphasis on adding, changing, or more importantly removing tools and practices that distract from, hinder, or reduce the value of people and their interactions. Ideally the only tools in use are those that provide information rapidly on the effect of changes made by the people in your organization, enrich interpersonal interactions, and supports the organization’s needs to create and implement solutions to business objectives.|
Ok, some of these are rather extreme, but they are a pretty accurate expression of what I’ve lived through in the past. What they all have in common is that each department has their own individual concerns about and aspirations for DevOps. Perhaps they had concerns about and aspirations for Agile and feel like DevOps will provide the missing piece to the puzzle, but chances are that the pieces are in place; it’s just that you’re not using them right, or you need a good coach. It’s a change in thinking not a changing of the guards. The tools and technologies will change, but if you have more agility and a DevOps culture, then you likely already have the only real tool you’ll ever need: good dedicated engaged people.