I follow several threads of thought on the web and elsewhere around “What Is DevOps?”. A common aggravation for several people in the industry is the idea that “DevOps” can be a job title.
In an interview with Derek Collison of Apcera by Kathleen Goolsby at Sandhill, Derek says:
As CIOs move to an IT-as-a-Service model, they are looking for the ability to harness the value of distributed utility computing and realize its benefits. To do this requires a well-integrated platform that is full of capabilities for the developer; contemplates the needs of DevOps; provides command, control and visibility for operations; and is policy-driven, thereby meeting the governance and compliance needs.
In John E. Vincent’s post “DevOps – the Title Match,” John points to this quote and takes a strong stance against using “DevOps” as a job title, or even a role. He parallels it with giving someone the job title of “agile” saying, “You don’t call someone an agile so why would you call them a devop?”
In John’s opinion, DevOps is something that developers do and something that Operations do:
Developers need to understand infrastructure. Operations people need to understand code. People need to [beep]ing work with each other and not just occupy space next to each other.
His past experience is shared with several other people I have talked to about DevOps. A “DevOps” team is created, but it ends up becoming just another silo. Once it becomes a silo, communication fails, it becomes ineffective, and fails.
Whatever form you believe DevOps should take, it should unquestionably be the bridge between developers and operations. This bridge should be constructed using people (whatever their title is), communication, tasks, and technology. When DevOps becomes a silo, you have created an island, not a bridge, and you will need to build more bridges to get to it.
Does this mean that you cannot have a team of “DevOps” people or even a single “DevOps” role? This is where I disagree with John’s point of view.
In smaller companies, especially startups, developers often are the Operations team. They cover everything that is “DevOps.” You do not need a bridge when everyone is on the same island or can easily jump from one island to the other.
But as we move up the scale and companies get larger, the area that work covers is much wider. It makes sense for an organization to be organized. Organization involves departments, or islands of responsibility. Who owns the oceans between these departments? Who is responsible for building and maintaining the bridges between these departments? Do you ask developers to build their half of the bridge and Operations to build their half and hope they meet in the middle? What happens when they cannot agree on where the middle is? When everyone is responsible, nobody is responsible, and human nature dictates that nothing gets done.
Instead, you select a specific team who know how to build and maintain bridges. You assign them the task of building the most efficient bridge they can that satisfies both sides.
The key is in what their mandate is. It is not to “build a great bridge.” That would lead to a silo. They would build you a fantastic golden shiny bridge and pat themselves on the back. They would likely stand on that bridge and look down on the poor developers and Operations teams that have nothing as nice as their bridge. The townsfolk in developer land and Operations land may rarely use the bridge and opt for the slower option of boats. They dislike the bridge builders who did not build the bridge to meet their needs.
Instead, the mandate should be to focus on people and goals. The goal might be to get code from one side of the bridge to the other as efficiently as possible. It is an iterative process. If the people on both sides of the bridge do not feel they have ownership of the bridge, they will feel constrained by what the bridge offers. We feel ownership when we are involved in the process.
When you are building a product and you closely involve your customers at every step of the way, they feel ownership. It is your product, but they have had input and have gained a sense of control that what they are buying has potential to adapt to their needs, rather than them having to adapt to its needs.
It is my view that DevOps can be a role or a team, but if it does become a silo, then you are doing it wrong. DevOps can be people, but should always serve people, enable people, and never dictate to the people.
Read More On DevOps
The Elusiveness of DevOps
I asked DevOps authority John Arundel to limit his definition to just a few words, and this is how he defined DevOps:
“Devops is like obscenity: you know it when you see it. It’s an attitude, a set of priorities, a mutual understanding. It’s also (still) extremely rare.”
DevOps: Who We Are and Where We Are Going
Everything old is new again, including perennial quesions about the human condition. Here at ActiveState, we got to talking the other day about a recent DevOps paper by Dave Zwieback, The Human Side of Postmortems, published by O’Reilly in 2013. This paper discusses human performance under stress, citing a much earlier study by Yerkes and Dodson which examines the effects of stress on cognitive ability in mice.
From DevOps to Private PaaS: Bridging the Divide
Asked about the big trends impacting developers in the enterprise environment, developer evangelist John Wetherill talked about big data, and “the ability for developers to access, manage, control, and analyze that data.” Other trends Wetherill identified included the significance of mobile applications, the convergence of best practices in software development, and the importance of agility and rapid application deployment. “Development teams should be building killer applications, not fiddling with the plumbing,” Wetherill said.
Title photo courtesy of Matthew Morse from Pixabay.
