Application life cycle management through the DevOps infinite loop of feedback and release.

[Manoj Gangwar]

This influx of articles has made it apparent there are a number of different views of what DevOps actually is. I think it would be interesting to garner the view of anyone who cares to read this as to what they think DevOps is, and to that end, I shall start with my own view.

The Project Management Triangle (of cost, quality, and speed) typically dictates that projects can optimize only two of the three constraints of delivery, to the impairment of the third.

DevOps is a discipline that enables the optimization of all three constraints in the delivery of IT software changes.

DevOps requires People, Processes, and Technology to work effectively. With reference to the first way of Gene Kim's "The Three Ways", DevOps is a system; and (as per Russell L. Ackoff) "A system is not defined by the sum of its components but by the interaction of those components", therefore DevOps is:

• not just a toolchain,
• nor is it just automation,
• nor collaboration,
• or communication.
• It is not just cloud,
• nor is it just a reduced set of gateways,
• or more frequent releases,
• or agile development.

DevOps is all of these working in harmony, as a system, to deliver small incremental changes into production at high frequency and low cost with high quality. It is a fundamentally different way of delivering IT change that requires a culturally different organization to one that typically follows a waterfall approach. Removing any of the components above will result in an ineffective approach that will return to the typical project management triangle of delivery.

There are a number of methods of implementing DevOps, however, they all follow some key themes:

Test Early: One of the key principles for management of W. Edwards Deming (considered by many to be the master of continual quality improvement) states, “Cease dependence on inspection to achieve quality" Effectively don't inspect a product after it is built as that is too late fix bad quality. Build quality into the software by running automated tests before the code is even checked in.

Automate: Use the technology to do what it is good at. Let humans do the thinking and automate all the repetitive steps.

Continually Improve: Taiichi Ohno (considered the father of the Toyota Production System) stated "Progress cannot be generated when we are satisfied with existing situations"; we should always make use of continual feedback loops to constantly improve.

A little bit at a time: The smaller the change; the lower the impact, the lower the risk, the less needs to be tested, the quicker the delivery, the quicker the feedback, and the easier to fix if the quality is flawed.

Responsibility through collaboration: Focus on enterprise goals rather than team or department goals, nothing should be "someone else's problem".

There is a lot more detail that underpins my thoughts on all the above, but for the sake of brevity (and to avoid too many tl;dr) and garner some discussion I shall leave it at that for now. Over to you!

[Simon Carroll]

Manoj,

Thanks for the concise manner you have put this in I agree that DevOps should be viewed as the ecosystem, this made me think where we are at as a organisation on our journey and then consider the vast majority of other organisations that would be at different stages of journey to DevOps or their DevOps maturity.

So in answer to your question - I think if you have only just started the journey from traditional release management and have or are starting with say automation or testing earlier, I would categorise this as DevOps whilst not meeting a DevOps purists view I think that we need to understand that commentary may be a reflection on where that organisation is on their journey and the constraints that hinder or may hinder what level of DevOps they can or have achieved. 

"A marathon runner is still a marathon runner even if he is only completed a part of the way when the leader finishes".

[Dan Breyen]

I totally believe there is value in reviewing your process from time to time.  If you look at the Capability Maturity Model you have different levels.  You need to decide what Development Model works best for you site, but a team has to evolve if it's going to sustain change from many different directions.

[Amanda Barber]

Wow, thanks for this @Manoj Gangwar - this was concise and a great intro for folks who are getting the hang of all things devops. I love the key themes you shared as well.