Everything about devops sounds great. It's a practice that emphasizes collaboration and communication between software developers and other IT staffers and management, while automating tasks such as software delivery and infrastructure updates.
With devops, the development, testing, and release of software can be accelerated and made more reliable, and that's vital for companies looking to survive in an ultracompetitive market.
There are plenty of examples of how devops works well and delivers tangible improvements for companies in a variety of industries. But sometimes it doesn't work well. Things can go wrong with devops just as they can with any other aspect of IT.
Following are some examples of devops initiatives that failed on at least some level and what the organizations involved did to address the problems or prevent them from happening again.
Lack of a project vision
IBM began what would become the company's foray into devops in 2003 -- a few years before the term was even coined -- when it launched an agile software development initiative for one of its new products. The company invested in agile, a set of principles for software development that encourages rapid and flexible response to change, because it wanted to speed up its software releases to customers.
It was a less-than-successful endeavor. "The problem with agile is it only takes you so far," says Mustafa Kapadia, North American cloud and devops service line leader for Global Business Services at IBM. "The development side was really fast but operations was slow to respond, so it didn't really matter. Customers didn't get products faster."
The company, as part of a move into devops, then decided to automate the deployment of code in addition to adhering to the agile methodology. But that didn't make the software delivery cycle faster either. IBM conducted a "value chain analysis," and found that the biggest impediment wasn't agile or automation, but the overall development and operational environment. Even with these various efforts to speed up development of the product, there was still too much lag time in the completion of the project.
Ultimately, IBM's devops debacle was due to a lack of vision by those putting these efforts into place, Kapadia says. "We needed to answer some basic questions and determine the problems we were trying to solve. That's where we failed," he said. "If you don't know how the work is actually done, you don't know which problems are worth solving. We were grasping at [imaginary] problems that came from vendor hype, not from seeing what was really slowing us down."
Once managers gained a better understanding of workflows and where processes were being slowed, they were able to make changes and get true value out of devops.
Sign up for Computerworld eNewsletters.