DevOps Zone is brought to you in partnership with:

Having worked as both a developer and an operations manager, I’ve gotten all too familiar with the ever widening gap between what developers and customers consider “done”. In order to help narrow this, I’d like to share some of my ideas and experiences concerning the software development processes with a vision towards actually releasing what customers need. Daniel is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

DevOps: Why Silos Suck And How To Break Them

05.04.2011
| 4092 views |
  • submit to reddit
Divide and conquer, Caesar’s strategy to break huge problems down into smaller parts, is an outdated model for structuring teams and organizations. Breaking teams apart by area like development, QA, operations, product management, etc, creates silo like divisions of labor. Unfortunately, these divisions create so many “walls of confusion” between the silos that your speed and agility is seriously hampered.

But, specialization, divide and conquer for a field of knowledge, is still necessary to cover a field well enough. Consider security or networking – you’d really need to dive very deeply into them to understand all the tiny, little details which make or break your infrastructure.

DevOps To The Rescue

Having specialists, but no silos, is possible using the right culture, management approach and tools. DevOps is a common name for exactly that.

The DevOps Culture

On a cultural level, DevOps means that everyone has to own the overall business goals. It’s of no use to say: “well, my part works, but they can’t get it running”. Instead, everyone has to do his best to realize business value.

Image by eirikrefThe DevOps Process

On a process level, DevOps needs developers to work closely together with QA and operations. They have to make sure that test scenarios are written alongside the code (and not weeks after finishing it), and they have to make sure that they know how their product will behave in operations. The same is true for the other parties as well. QA needs to make sure to be in the process right from the beginning and operations should have critical influence on the runtime architecture of the product.

Tools Facilitate DevOps

If people start owning the whole process instead of just their area of expertise, you’re already well ahead of most of your competitors. But DevOps is more than the process and the mind set: It can be strengthened a lot by using the right tools. Programmable infrastructure is the key here. APIs and automated tools like Puppet and Chef to setup servers, one-click deployments (e.g. using capistrano), all help facilitate the cooperation of the various experts.

Have you already introduced ideas or tools to help you bridge the gap between development and operations? What are your experiences with DevOps? Let us know in the comments!

References
Published at DZone with permission of Daniel Ackerson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)