A multilevel view of DevOps (with more balance)
September 28, 2011
I don't think it's this simple. Instead I think that the broad label of 'DevOps' is a reaction to three different sets of organizational problems, which I am going to list in decreasing order of severity.
First is the blame problem, where developers get blamed for not delivering features and operations gets blamed for services not being available. If you have the blame problem it trumps everything else, because the interests of developers and operations are fundamentally opposed to each other. All of the communication in the world cannot fix that.
Next is problems of ignorance, where development and operations don't understand each other's environments, problems, and constraints. It's stereotypical for sysadmins (me included) to see this as primarily a development problem where developers have ignored issues like installation, logging, performance, and operational reliability, but I'm sure that there's things about development that operations doesn't get. Fixing this requires education and possibly making development and operations care enough about each other's problems to get that education.
(See Tedd Dziuba for some ways to make developers care.)
The final set of problems are cultural ones, where the two groups are assholes to each other mostly because that's how they've always behaved and it's just how operations and development deal with each other. If this is your only 'DevOps' problem, you can indeed fix it with just better communication and more respect.
(The quibble here is that sometimes cultural issues have roots in things like the amount of respect and pay that goes to various groups, because people are people.)
Each level of organization problem creates the levels of problems below it (unless you're really lucky and have a staff of selfless, motivated saints). An organization with the blame problem is going to have cultural problems and almost certainly ignorance problems; an organization with ignorance issues is going to grow cultural ones. It follows that you need to fix problems from the top down in order to make lasting changes.
(Yes, this is a more balanced view of DevOps than my first entry on it. Sometimes I run a little bit too hard with an idea.)
Written on 28 September 2011.
* * *