DevOps: A Culture Shift, Not A Technology

DevOps is not a new technology or a product, contends Andi Mann, VP of strategic solutions at CA Technologies. Although his company offers a list of DevOps products, Mann advises, "if someone tells you, 'I'll sell you DevOps,' get up and leave the meeting." Likewise, it's not a specific discipline or methodology. Nor is it a new role in IT.

"It's an approach or culture" of software development that seeks stability and performance at the same time that it speeds software deliveries to the business, said Mann, who co-authored the popular handbook "Visible Ops -- Private Cloud" and, most recently, "The Innovative CIO."

The primary goal of DevOps is making reliably performing production software that can be changed rapidly. To do so, development teams have to accept the feedback of operational teams, who typically view the software they receive from developers with a jaded eye because its stability is still unproven.

Operations, in turn, must accept frequent updates to the software that it's running, which has been anathema to their goal of keeping production systems stable. The most frequent cause of outages is poorly executed updates. Many companies are discussing these conflicting goals, and Microsoft, PayPal, and Rackspace, among others, have already been through the stability-versus-rapid-update debate. They've resolved the issue in favor of a DevOps approach. Satya Nadella ascended to the CEO's role at Microsoft in part because he insisted that the Windows software group take a more DevOps approach and made it stick.

[Want to learn more about interactions between developers and operations? See Where Agile Development Fails: IT Operations.]

"The term 'DevOps' is a horrible one," said Mann at a talk on "What Smart Businesses Know About DevOps" at the InformationWeek Conference in Las Vegas March 31, and also in an interview afterward. DevOps suggests that the life of a software application "begins with development and ends with operations," when in fact it may be under continuous development to reflect changing business conditions. Mann said he favors the terms "continuous delivery" or "continuous integration" over DevOps, but DevOps enjoys greater currency at the moment. The other two terms focus more on a sustained ability to reliably modify production systems.

Much of the know-how associated with both software development and operations resides in the minds of experienced old hands in the two organizations. They not only don't talk to each other but sometimes encourage skepticism and mistrust between the two organizations. What knowledge they do have is "tribal knowledge" that disappears as they move on or retire. DevOps imparts more structure and procedure on interactions between the two and tries to make reliable operational performance a more conscious goal.

Getting the two organizations talking to each other is a primary goal, said Mann. That can be done through meetings at work, but also through more informal encounters, such as an excursion together to a paintball park. "Just don't set up opposing paintball teams, development vs. operations," he said with a laugh.

CA commissioned a survey on DevOps by the British firm Vanson Bourne. Of the 1,300 IT managers surveyed, 39% said they were already using DevOps to some degree and 27% said they had a DevOps strategy they were preparing to implement, but 16% said they didn't know what DevOps was. Mann said that figure has been higher in some of CA Technologies' own surveys.

Of those companies that say they've initiated DevOps, 67% of them say its improvements in software delivery have led to revenue increases, Mann noted.

Implementing DevOps doesn't start with one side or the other but "getting both developers and operations managers connected to the business," Mann at the InformationWeek Conference.

Agile development methods consciously do this, but it doesn't matter what technique a company uses, as long as both operations and development come to an understanding that they jointly share responsibility for delivering software to the business as it needs it. "Give them the feeling that they are on the same team, not enemies," he said. The latter is often the status quo in how you find them regarding each other.

Operations must not only provide measured and accurate feedback on the performance of new software but accept the fact it is going to have to mesh frequent updates into production systems. "If you want to be in the mobile game, you need this," he said.

To get software delivery schedules better aligned with the business, it's important to avoid imposing too many bureaucratic processes and approvals on development teams, even though they might guarantee a measure of the desired collaboration among the parties involved. "Streamline processes. I can't emphasize that enough," said Mann. Too much process will interfere with the main goal, which is rapid delivery of software features and function.

"Share responsibility for performance in production. Developers wear pagers (the same as IT operations managers). They're called when things go wrong and asked to explain why the software might be behaving the way it is. Being called out of bed confronts developers with the kinds of issues operations constantly deals with," he said.

"It's very much about continuous feedback loops, continuous collaboration, continuous delivery, and continuous innovation," he said. It's also about both development and operations practicing "continuous secure use to enable this speed of delivery, rather than slow it down," he said.

DevOps grew out of the companies that were trying to build Web-scale applications that needed to scale out to millions of users and rapidly add new features. But that doesn't mean it's only suitable to such companies. "It scales down really well" to smaller companies engaged in more traditional types of businesses, he added.

Can the trendy tech strategy of DevOps really bring peace between developers and IT operations -- and deliver faster, more reliable app creation and delivery? Also in the DevOps Challenge issue of InformationWeek: Execs charting digital business strategies can't afford to take Internet connectivity for granted.