DevOps is a worthy endeavor, producing a deeper understanding between the development staff and IT operations. Then again, maybe it's just a shell game being played by those charlatans down the hall.
Those seem to be the two poles of misunderstanding about DevOps, Forrester Research analysts Glenn O'Donnell and Kurt Bittner suggest. They published a report Tuesday, "The Seven Habits Of Highly Effective DevOps."
The report at first sounds like the famous line from Cool Hand Luke, "What we have here is a failure to communicate." O'Donnell and Bittner point out that an IT leader who wishes to implement DevOps must clear up a lot of misunderstanding. In the past, what the development team produced didn't always run well in operations, and the feedback offered by the operations staff was viewed as hypercritical by the developers. "The detritus of accumulated and reinforced stereotypes is destructive to organizational harmony," the authors warn in a section called, "Negative Stereotypes Cripple Your Business."
Wait a minute. The introduction of DevOps isn't the first rodeo for legions of IT employees. They have a rich amount of experience on which they base their view of the inadequacies of the other side. This feud has been going on longer than AMC's The Walking Dead.
[ Can Agile close the gap between speed and stability? See Where Agile Development Fails: IT Operations. ]
But the seven habits are not just about better public relations. The authors skillfully summarize how each side, in its isolation, sees the other.
Developers view operations as wedded to their obsolete systems and unable to adapt to developers' demands. They're basically bureaucrats who like to say "no" rather than change. Their incompetence then leads to the failure of the developer team's latest application code, hurting the team's credibility. The application didn't run well because operations "is not creative enough to understand the complex artistry of apps." (I was starting to chuckle at this point.) Operations is constantly "cobbling things together -- it's not engineering." Developers would do much better if they could circumvent ops and go out into the cloud.
I found myself laughing at the end. The characterization of how ops sees the development team was in the same vein.
Developers want to believe anything is possible and have no reality check on what it costs IT to give in to their demands. They like to "play with the latest 'toys.'" The teams "deliver lousy code that negatively affects ops' credibility." Their test environments don't test for what they should -- the ability of the app to sustain itself in production. The developers are "careless, lack discipline ... a bunch of hackers, not real professionals." Operations has to perform heroics day after day to keep their code running. It could do much better by circumventing development and just use packaged software and SaaS.
The two characterizations are stereotypes. Is it any wonder there is a gap, sometimes resembling the Grand Canyon, in communications between the groups? How then do you knit them together into a joint DevOps organization? How do you get development to produce code that works the way operations thinks it should? And how you get operations to help the development team produce the code that's needed, without attacking its "careless" ways?
Not surprisingly, the seven habits of successful DevOps start with getting the two sides to talk to each other. It's a cliché, but talking face to face breaks down stereotypes and allows each side to see the other's daily difficulties and struggles. This is not too deep an insight, but it remains a necessary first step.
"Take an outside-in approach to everything," the authors advise as habit number two. Traditional IT thinking is inside out: "Here's what IT has the resources to do and what we've done with them. Use it to the best of your ability." Instead, have both sides focus on the business customer and what should be done to satisfy his needs. That new application had 10 hours of downtime last week? That's not good for the customer. What do we need to do to produce more stability in production code?