Is There Value in DevOps?


What is DevOps?  Wikipedia defines DevOps as “…a software development method that stresses communication, collaboration (information sharing and web service usage), integration, automation and measurement between software developers and Information Technology (IT) professionals” [1]

I would simplify that definition to be more along the lines of “an IT cultural philosophy that ensures that the operations and development teams are jointly engaged in the full development and maintenance lifecycles for the common purpose to provide a high quality, innovative, and maintainable solution to their customer.”

There are many well written and passionate views about DevOps that are both in the positive and the negative arenas.  The Agile Admin blog looks at some interesting comparisons of DevOps to similar concepts in the Agile Manifesto.  In their posting, they define DevOps in terms of values, principles, methods, practices, and tools.  In the introduction, they also formulate a DevOps definition of their own; “DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.” [2]  I highly encourage readers to review the referenced blog post above for an excellent backdrop to this post.

In a posting by Jeff Knupp, he discusses the troubles with expecting a resource to move from role to role as they navigate the DevOps responsibilities.  He very cleverly uses an analogy of a totem pole to describe those responsibilities.  That totem pole analogy orders those responsibilities as; “Developer is at the top, followed by sysadmin and DBA. QA teams, “operations” people, release coordinators and the like are at the bottom of the totem pole.” [3]  I also highly recommend reading his post in more detail.

When I provided my definition of DevOps, I intentionally used teams vs. individuals to describe the actors.  I believe that the DevOps team and their joint desire to find solutions that mitigate risk while pressing forward with new innovations, platforms, and processes are probably the single most critical measure of the probability of success or failure of the DevOps culture.  A successful DevOps organization always has the view that that no single person can do all things without gaining assistance from both development and operational experts.  How many developers do we know that have information security certification in their repository of skills?  How many security experts have development certifications in their repository of skills?  I encourage us to look back at how valuable we tend find those team leaders that know enough about security and development together so as to bridge the communication and priority gaps between those two heads-down experts.

At the end of my explanation above, I realize that I strayed slightly from my concept of teams and mentioned leaders.  To illustrate in more detail the importance in the use of DevOps leaders as part of the DevOps culture, let me provide a non-IT analogy…

One day, I am driving to work and I hear a noise coming from my car. I don’t know anything about cars other than how to drive them from point A to point B and fill them will fuel, so I call my auto mechanic for advice.  I describe the issue to my mechanic in layman terms.  “My car goes clunk when I drive in the bitter cold of winter.”  My car mechanic listens to my car’s symptoms and applies his expertise in general car repair to build a list of possible causes for the noise.  As part of his investigation, he looks for obvious issues like my muffler dragging on the ground, loose components, over-sized tires, etc. that he knows how to fix for any model of car.  However, at some point he might find that he need to engage with experts to see if there are more significant and specialized issues that could be causing the problem – in this case the auto manufacturer of my car.  The manufacturer has noted that there is a very unique but related defect they have seen only when the shocks that came with their car are used in very low temperature climates.  The auto mechanic turns that specialized information into general options for me to consider to solve the problem and make my car work best in the climate I use it.

By ensuring that the team of actors involved in this analogy have both the ability to 1)  communicate with each other, 2) understand enough about the car as a whole to find specialists as needed, and 3) are willing and able to work together to find the best possible solution to a problem is why my car no longer clunks in cold weather.

Consider how this whole model of interaction would have failed if any one of the actors in the analogy had failed to communicate or respect each others scope of knowledge, strengths, and weaknesses?  What would have happened if my mechanic would have ignored the report of clunking and assumed it was just my imagination?  How many parts would the mechanic have had to throw at the problem without the assistance of the manufacturer’s specific expertise?  What if the manufacturer didn’t care enough about the other actors to research issues found in the real use of their product and communicate possible solutions to mechanics?  Now…replace myself as the software product owner, the mechanic as a operations team member, and the manufacturer as a development team member.  Do we see that level of joint ownership, cooperation and interaction in our non-DevOps world?

I challenge the reader that this is the sweet spot for DevOps in the IT world.  We already know that development, QA, product, and other traditionally Agile-based team members work best when all members are open and trusting of each other in order to deliver on the common effort.  I assert that by adding in the operations teams to represent the needs of the systems, support, monitoring, and other traditionally operations areas into that development team is only adding to the probability of success for the product in both it’s features and it’s maintainability.

[1] Wikipedia – DevOps
[2] What Is DevOps?
[3] How ‘DevOps’ is Killing the Developer