A basic understanding of DevOps

Just over a month ago, I wrote that DevOps is not another way to say cloud. I further argued that anyone who thinks the two are interchangeable certainly doesn’t understand the former (and probably not the latter, either). That, however, raises the question, What is DevOps? As you might guess from my last post on the topic, it’s a process framework, which seeks to unify the often disparate portions of IT of development and operations. Applying lessons drawn from manufacturing systems (e.g. the Theory of Constraints and Lean), DevOps applies what is known as the three ways:

1. Systems thinking
2. Amplification of feedback loops
3. Fostering a culture of continual experimentation and learning

In Beyond the Phoenix Project, Gene Kim said:

We always say DevOps is about culture and behaviour, or, DevOps is a human endeavour, that creates performance and quality. Kim, G. and Willis, J.: Beyond the Phoenix project

They also state that DevOps does not have a single, canonical definition, because canonical definitions tend to limit what one can accomplish. Kim and Willis (along with, as far as I can gather, the DevOps community at large) believe that refraining from defining it will allow DevOps to evolve organically over time. In his book the Goal, Dr. Goldratt defined the eponymous goal as follows:

So this is the goal: To make money by increasing net profit, while simultaneously increasing return on investment, and simultaneously increasing cash flow. Goldratt, Eliyahu M.: The Goal: A Process of Ongoing Improvement

This guiding principle carries over to DevOps, too. The goal of DevOps is to ensure that IT aids the business in achieving the goal (as defined above) in the best way possible. This implies delivering better services, quicker (and, preferably, more cheaply).