The DevOps version of the ‘wall of confusion’, i.e. what is devops, seems to stem from the lack of distinction between the philosophy of DevOps vs it’s implementation(s).

DevOps needs opinionated implementations

The Agile world has neatly solved this challenge by creating opinionated implementations/methodologies which describe the particular implementations of Agile, e.g.Scrum, XP, Scrum-ban,  allowing for discussions to more easily separate philosophy from implementation. Admittedly, some folks still conflate agile for scrum, which can muddy the waters, but this is exactly the same “muddying” that makes conversations around DevOps frustrating/hard.

For the sake of this post, I’ll give my definition of the DevOps philosophy, which will help to frame what’s to follow. So, DevOps, the one sentence version:

The reduction of friction between the Development and Operations disciplines

extra credit: Check out @jeffsussna‘s post for a different, but complimentary take on the definition of devops: Empathy: The Essence of DevOps

Predominate DevOps implementation patterns

How might these opinionated implementations be defined and formed? There appear to be roughly three broad patterns for implementing DevOps that I’m aware of:

• The ‘Netflix’ pattern. Individuals are responsible for managing both development and operation functions. Generally, these job titles  include the word devops.  What many people appear to assume ‘DevOps’ is all about, and thus the only way to implement.
• The ‘BizarreVioice’ pattern. Fully functional teams, product, dev, test, ops, etc.,  form around the various products the company produces.
• The ‘Traditional separate Dev and Ops groups’ pattern. What many folks are likely working with, but haven’t really figured out how to fully realize the DevOps philosophy.

I’m sure there are other patterns, too, but as of yet, I’m unaware of any proffered  opinions on how to implement any of the patterns.

extra credit: @ernestmueller over at theagileadmin.com has a series of posts going detailing these patterns (amongst the plethora of excellent content you should read).

The reluctance to be opinionated

It’s been my observation that, in general, folks practicing in the DevOps space are happy to share how _they_ have/are implementing DevOps, but they (we?) are reluctant to tell _you_ how to implement DevOps. Given the large variance in the business + culture combinations looking to implement DevOps, this is appears to be a rational response.

So we seem to be at an impasse. I don’t have a/the answer, but I’m keen to keep looking to find one. Thoughts?