DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog 5 Definitions of #DevOps

5 Definitions of #DevOps

In my talk at QCon last week I was lucky enough to be the first speaker on the DevOps track so I took the opportunity to poll my fellow speakers for THEIR definition of DevOps and the results where fascinating.
What I ended up with was different 5 Definitions of DevOps:

DevOps Group - Dave's Definition of DevOps
DevOps Group - Matthew's Definition of DevOps
DevOps Group - Anna's Definition of DevOps
DevOps Group - Amy's Definition of DevOps
DevOps Group - Steve's Definition of DevOps

So what are the key take away messages from these DevOps definitions?

Firstly – there is no single, definitive version of what DevOps “is” as you can see from the responses above!

DevOps clearly means different things to different people and we (as the DevOps community) have to ask ourselves is this a good or bad thing? Good in that it’s promoting a diversity of ideas that contribute to the DevOps movement, but “bad” in that is causes confusion amongst people trying to learn more about DevOps.

Secondly – there is a clear message around communication, collaboration and culture being a key part of the DevOps message, which is excellent” #NoMoreSilos!

Thirdly – sadly the name “DevOps” might be seen as being exclusionary in itself and not embracing critical parts of the SDLC community – specifically in Amy’s case the Test community. Amy expands on this in her blog post “DevOps with Testers”.

A number of people would say that DevOps should be called “DevTestOps” or “BizDevOps” but at QCON Dave Farley was arguing that the correct term should be “Continuous Delivery” as DevOps is just a subset of CD. We discussed this earlier in our post on Continuous Obsolescence.

  • So what does DevOps, DevTestOps or BizDevOps means to you?
  • Has the term DevOps had it’s day and should we just extend the definition of Continuous Delivery to embrace the full application lifecycle?
  • Do we need to rename our company? 🙂

Your thoughts in the comments please?


14 thoughts on “5 Definitions of #DevOps

  1. In my engagements I am starting to use the word DevOps less because it means so many things to so many people. In fact, it usually means the wrong things to the clients. Instead I focus on the end goal which I define as “moving towards being a high performance company”. Everything else (CI/CD, waste removal, collaboration, culture, etc.) are things you do to reach the end goal. Thoughts?

    1. Hi Mike – we still use the term DevOps (not least because it’s in the company name :-)) but I take your point 100%.
      We are always leading the client back to “what’s the business need your trying to solve”… and we normally find that the answer is something like “It takes a very long time between the requirements being first elucidated and the time when they are enabled for the end users.” and the business impact of these long cycle times and large batch sizes is that you can’t meet customer needs fast enough so you lose market share and/or you have a (huge) amount of waste on projects that never go anywhere or don’t deliver what the customer wants (because their need has moved on).
      So start with the business goals and strategic objectives and cascade from there. Don’t just “do DevOps” without any context.

      “In my opinion, framing an understanding that everyone in development activities is a developer will rather help the purpose. On the other hand, if we coined a different term where testers would feel included (i.e. by somewhat along the lines of “DevTestOps”), we would underline the silo principle that we want to get rid of so much and probably exclude other roles that we forgot once again.” <- Good Point

  2. DevOps — Dev means Agile process and Ops means ITIL process. I would say DevOps is not subset of Continuous delivery instead DevOps comprises of all Continuous planning, continuous integration, continuous delivery , continuous testing, continuous monitoring, closed feedback and traceability.

  3. Actually, it looks like everyone you polled, other than the tester, have the same (accurate) answer. Yours is the one that stands out as different. Not to be rude, but it also reads as being intentionally over complicated and a tad along the lines of “corporate speak”.
    Further, I think DevOps does have a pretty clear meaning. As I said, I agree with what the people you polled had to say. It seems to me like a pile of consultants have decided it’s better to muddy the meaning so they can take advantage of the momentum of the movement to sell services by tacing a buzzword onto them. It’s a lot harder to sell “restructure your toxic culture so that you aren’t contending with yourselves” because it’s difficult, time consuming and threatening to the exact people who hire consultants.

    1. I realized this sounds accusatory, and it’s not meant to. I have no idea what you offer to clients. I’m simply speaking in general about my experiences with the muddying of the term.

  4. In my experience with DevOps, the generally accepted definition on the internet is dev working alongside ops – blah blah blah but no one really knows what that means.
    My working experience with DEVOPS is becoming a hybrid position, a true blend of development and operations.
    Examples are readily available in the CDN realm where the “communication” is improved between Dev and OPS because the developers are doubling down as systems administrators and the systems administrators are doubling down as developers – managing the system/optimization/delivery/support etc.
    What better way to bridge the communication gap that to create overlapping responsibilities that drive true collaboration?

    1. Hi Adrian – we’ve written in the past about the “DevOps as generalist/hydrid” idea –
      As you can tell from the article, I don’t really buy that argument at a larger scale – specialisation exists for a reason, and it works.
      Whilst is some organisations you might be able to find generalist “Unicorns” that can do everything (well) that’s not a solution for the mainstream – there aren’t enough Unicorns to go around.
      That said – I’m a big supporter of cross-skilling / multi-skilling etc – the people in your DevOps scrum team SHOULD learn from each other and where possible be able to do many of the tasks that were “traditionally” done by one or the other.
      But I still firmly believe that those extra skills are secondary to your main role as a development specialist or an operations specialist!

    2. Yes, have everyone spread their skillset extremely thin, and do things they aren’t particularly good at, all while creating new silos.

Leave a Reply

Your email address will not be published.