[trcollinson]

I am a big believer in DevOps to the point where I often consult to "implement DevOps" at organizations. The frustrating part if that organizations seem to want to create "DevOps Teams" to augment their other teams. An organization cannot have a "Development Team", an "Operations Team", and then a "DevOps Team". DevOps is a set of good principles which help to guide the process of making, releasing, and maintaining good software products. These are by no means the only set of principles and organization should live by, but Developers and Operations should work to implement these principles because it will make their process more efficient. It is certainly not a matter of simply tossing in yet another department full of people and hoping that more cost efficient work gets completed.

When I work with clients the inevitable question comes up: "What Principles should we implement then?" and the answers are usually more questions really. How long does it take developers to set up their working environments and get to coding? How is code tested and prepared for deployment? Are stakeholders feeling secure about deploying this new code to production users? Can we deploy effectively every time without deployment related issues? When something bad happens in production, what is the recovery procedure and how long does it take?

The answers to these questions and many others often show that there are a few issues. First, developers and operations aren't speaking to one another enough and aren't really working together. Second, there is very little trust in the current environment and that lack of trust is made up for by adding more human intervention. Third, there is very little automation and this causes the lack of trust but few people what to change their habits to fix it. And finally, there is such a great divid between engineering and operations that the pains felt by one group and not shared by the other.

DevOps has the principles needed to start to solve these problems. However, we don't need a department to implement those principles. We have enough departments.

[sombremesa]

Well said. I think this is what the author of the OP was also getting at - it's better to grow the culture (while sharing responsibility) where it belongs rather than purchasing it wholesale and shoving it down dev throats.

As an employee of a large software focused corporation that does many of these things right, I had no idea how bad things can get for smaller, newer companies that haven't figured all of this out.

[alxndr]

Even small companies can have momentum and unanalyzed patterns that are hard to change.