The desire to deploy quality code and to do so more rapidly is driving many IT organizations to adopt the practice of DevOps software development. However, this new approach to software development requires more than implementing an open source tool. To better understand how to achieve the end goal -- dev and ops groups working together -- it may help to understand how the idea of DevOps came to be and how it can be applied to enterprise IT.
"A lot of the DevOps purists are saying DevOps did not come from Agile, it did not come from open source, it did not come from innovative uses of automation, it did not come from change management practices, and it did not come from the breaking down of big Waterfall silos. And I disagree," Paul Peissner, director of business development at CollabNet, said. "I think [DevOps] came from all of those, and all of those created the perfect storm where we could question the infrastructure of siloed IT."
Siloed IT -- and the specialists who control the silos -- were a response to the technology itself. "The technology, when you left mainframe, was fragile, distributed and competitive. [So, specialists] created rules that limited the scope and impact that developers could have in the existing infrastructure," Peissner said. These rules, according to Peissner, came in the form of ITIL, governance and compliance, and they slowed down developers and created bureaucracy.
DevOps began as grass-roots movement
The pain from these rules was felt most heavily around release management. "DevOps started out as very much a grass-roots movement from the ops side and it's really grown in a number of ways. It has created a new tooling market around the automation side of release management and having continuous delivery or deployment -- two terms that mean similar things," Michael Azoff, principal analyst at Ovum, said.
Chris Rileyfounder and DevOps analyst, Fixate IO
"DevOps started with release management because that was the most broken piece in IT," Peissner said. "Release was the slowest-moving piece in all of IT. It could take us years to invent, months to QA, but we would sit indefinitely staring at each other saying, 'When is the right time to release this?' We physically didn't have the cultural capacity to introduce changes and recover from that gracefully. It was an 'aha moment' that we could release if we listened to each other," Peissner said.
Although tools can help facilitate release management and continuous delivery, experts are careful to de-emphasize their role in a company's move to adopt DevOps software development. "Culture first, process second and then tools. Everyone wants to lead with tools. Vendors are guilty of creating this problem, because they imply that if you use our tools, you will be DevOps," said Chris Riley, founder and DevOps analyst at Fixate IO. "DevOps-in-a-box is just not possible. You can't put people variables inside a box."
A large number of companies use Puppet and Chef and are on the path to better software quality, but Riley said that doesn't make them DevOps software development shops. "I estimate the number of people doing DevOps to be fewer than 25%, because it is such a new idea. Some organizations still believe Waterfall is the best way or they are just learning Agile, and that's the result of a culture built on business processes," Riley said.
People need to be tied to business gains
According to Peissner, many IT organizations haven't made the organizational changes necessary for DevOps or Agile. "Both [Agile and DevOps] are flawed because the reward system, when they hire you, is still a siloed system. You can be a superhero in a portion of the software conversation that doesn't affect the business, and bring efficiencies and improvements to your segment, but if it doesn't transfer to the business, you'll see zero impact. Until you tie people to business gains and efficiency gains that are measurable and attainable, you're just throwing money at segmented groups," he said.
David Linthicum, senior vice president at Cloud Technology Partners, said there's always a reorganization that comes with moving to DevOps. "The objective is to remove some of the latency in terms of how [organizations] deliver software. It's a matter of putting everyone in the same room and having everyone report to one consistent leader, someone who controls the money and the group's destiny. If you leave the ops organization out and the developers or CTO are supposed to influence the group but no one can fire people or control the money, there are not going to be a lot of changes."
Ovum's Azoff agreed. "With experience, you find you need executive support, someone right at the top to mandate a change in approach to deal with the need to get products out to the market a lot quicker," he said. "One of the things about DevOps is having closer collaboration in IT and business areas, so it's also an approach to how you work rather than a process. so you have a better idea of what's coming upstream or downstream. There are fewer surprises."
The bottom line, according to Fixate IO's Riley: Start with people. "This culture element doesn't have anything to do with anything fuzzy or wishy-washy. I would say it always has to be people first, because where [DevOps] fails is the highly variable people part, and all that it needs is that you're deliberate. Instead of letting culture define itself and evolve organically, you are deliberate about it," he said.
DevOps in the cloud
The future of Agile and DevOps