I've done / created lots of SCM related presentations, and now I'm trying to "upgrade" to a DevOps successor of it.

What I always try to do in my presentations, is to come up with an introduction slide which somehow includes the message I want to deliver (and which I then elaborate on in the rest of my presentation). When doing so, I try to answer my own question like "What would me 1 to 3 phrases be that I'd want to use if I got like 10 to 20 secs (only!) to explain it to somebody new to it?*".

I thought I knew what DevOps actually means, and what it is about. But I've seen some bizarre usages/contexts of DevOps (even on DevOps.SE ...). It makes me wonder if maybe what I think DevOps is, is completely wrong.

So what is generally agreed to be the definition of DevOps?

  • History of Comments have been moved to chat for record on how a question can be improved.
    – Tensibai
    Commented Apr 6, 2017 at 19:50
  • 1
    The main thing I've learned from talking to many people is that there is no agreed upon definition. Commented Apr 7, 2017 at 17:45
  • merci @XiongChiamiov ... that sounds like you may be aware of one of more other definitions ... Why not try to post them as an extra answer?
    – Pierre.Vriens
    Commented Apr 7, 2017 at 17:47

6 Answers 6


DevOps in a nutshell

From Wikipedia:

DevOps (a clipped compound of "software DEVelopment" and "information technology OPerationS") is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.

It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

From Overview:

enter image description here

Venn diagram showing DevOps as the intersection of development (software engineering), operations and quality assurance (QA)

While there is no single "tool" for DevOps, but rather a set of tools, also known as a DevOps toolchain:

enter image description here

Illustration showing stages in a DevOps toolchain

Illustrations of DevOps

Below are a few quotes from some of the questions on DevOps.SE, which all seem to somehow fit / confirm part of the DevOps description above:

DevOps is NOT a role

Below are a few quotes from some of the questions on DevOps.SE, which all seem to illustrate that DevOps is NOT a role:


I have been practising and advising on DevOps as a consultant with different clients for almost five years now, before my current position, I held roles in software development, web operations and systems administration. In my personal experience DevOps comes in many flavours.

Organization Patterns

DevOps Antipatterns:

  • NoOps and NoDevs - not strictly DevOps in the most strict sense, however, these teams both build and operate software without a dividing line between Development and Operations. The challenges with these teams come down to maturity, Development teams may be expert Software Developers but novice Operators and visa versa.

  • The DevOps Bridge - this is where one or more teams are given responsibility for taking work from the development teams and "Productionizing" it to make it operable. The challenge comes down to now there are two hand-offs, i.e. Development → DevOps and DevOps → Operations.

  • The DevOps Team - this can, arguably, work if the team has responsibility for building tools that support the DevOps enabled Operating Model, however, it should probably be called a "Tools Team" or "Platform Team".

DevOps Patterns:

  • Embedded DevOps - more commonly referred to as Platform Engineering, whereby there is someone within the team who is accountable but not responsible for delivering automation, tools and infrastructure for the provisioning and deployment of the solution, sometimes also including operating the software - in my mind, it's the latter that is actually representative of DevOps.

  • Institutionalized DevOps - where a project team jointly is responsible for both development and operation of a software package building shared ownership and positive feedback loops.


The actual practice of DevOps builds on top of several other practices, namely:

Each of the above practices builds upon the other, it's possible to not follow a practice, however, it means an important feedback cycle is missing which may be indicative of a "missed opportunity". The key differentiator between following any of the other practices and DevOps is the operation of software in production.

DevOps Practices

The Three Ways

In The Phoenix Project Gene Kim and his co-authors describes the three ways of DevOps:

Systems Thinking

Systems Thinking

The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).

In my experience starting to get Developers to consider Operational Concerns and Non-functional requirements achieves this goal. This is very much part of the culture aspects of DevOps.

Amplification of Feedback Loops

Amplification of Feedback Loops

The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.

I generally achieve this through Continuous Integration/Delivery/Deployment and shared monitoring and alerting, thus it very much fits in with the tools component of DevOps.

Culture of Continuous Experimentation and Learning

Culture of Continuous Experimentation and Learning

The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.

This fits very much in the culture space, although it depends heavily on tools and process to enable the culture to grow.

  • Excellent answer ! though I did stumble on that graph comparisons of different practices... especially regarding agile. I think it is much too broad a term to belong there. Testing is excluded though some agile methodologies put testing at the core of their practices. Once could argue that DevOps is (or can be depending on how it is implemented) very much agile. The agile manifesto depicts more of a philosophy than a well bound practice rules. Nitpicking more than complaining mind you, it is a really nice answer !
    – Newtopian
    Commented Apr 11, 2017 at 13:55
  • I can't take full credit for that diagram, it's been drawn by many a consultant before me on many whiteboards around the world. I guess it is describing the practice of agile where teams focused on building potentially usable products in short iterations, CI followed as a practice that automated some of that work, C. Delivery automated as far as preparing a build for deployment, C. Deployment actually deployed that build and DevOps operates the software in production. Commented Apr 11, 2017 at 14:01

I've heard many, many different definitions of DevOps. They include:

  • Developers handling operations tasks
  • One person doing twice as much work (in the same amount of time)
  • Developers and operations teams working with each other
  • Operations work for developer tooling (in the vein of "Web Ops")
  • A job title for someone who creates and maintains developer tooling
  • The use of automation in operations
  • The use of public clouds in operations
  • A job that combines aspects of operations, development, and quality assurance
  • A job that entails helping the development and operations teams work together
  • A philosophy of breaking down barriers between teams
  • Treating infrastructure as code
  • What you get when former software engineers move into operations
  • A completely meaningless buzzword

There is no public consensus on what DevOps actually is. A few years back we had similar problems with "Agile", and that has a written definition.

When introducing your concepts to a newcomer, I'd focus on introducing the concepts, rather than applying a label, or else they'll end up hearing conflicting definitions and being confused. For instance, if you're trying to talk about infrastructure as code, tell them that you're talking about infrastructure as code. The more specific you can be, the better, as even with agreed-upon definitions most companies focus more on certain parts of a philosophy.


The definition I always use in this situation is the following:

“A software creation culture that emphasizes communication and collaboration between software development and operations teams while automating the software delivery process and infrastructure changes. The goal of DevOps is to make software building, testing and deployment process as frequent, fast and as possible.”

However, along with the definition, it is also important that they understand WHY we need DevOps. Be sure to tell them that DevOps mitigates software defects faster, allows for better resource management, less human error, better version control, stable operating environment etc.


By the following scientific research paper to explore exactly this question,"What is DevOps", the proposed derived definition of DevOps is:

DevOps is a development methodology aimed at bridging the gap between Development (Dev) and Operations (Ops), emphasizing communication and collaboration, continuous integration, quality assurance and delivery with automated deployment utilizing a set of development practices.

[Jabbari et al.] "What is DevOps?: A Systematic Mapping Study on Definitions and Practices" (2016)


Devops is the development practice of writing applications whose business domain is operations. Where most application development focuses on building applications which do finance or health care or logistics or cat videos, devops focuses on applications which enable builds, deployments, monitoring, and metrics gathering.

The overriding goal should always be to enable decision-makers to become decision-takers. Imagine your bank's mobile application. When you request a transfer, it happens when you hit the button. You made a decision, then took the decision. Same thing with your operations. When the appropriate person decides some work is ready to deploy to production, they should be able to hit a button and the "Right Things Happen". Similarly, they should have all the necessary information they need to make correct business decisions.

It's not about giving business people shell access to servers - that's confusing purpose with implementation. It's about providing the correct knobs and levers with the right information and the right guard-rails to the right people so that decision-makers are decision-takers.

  • 1
    whose business domain is operations : Possible to expand on this, or give some examples?
    – Dawny33
    Commented Apr 5, 2017 at 18:06
  • I disagree, devops is an organisation model to support software developments not a development practice in itself, you can do extreme programming in a devops model (mixin dev, ops, clients and testers for example) (The remaining of the answer have good points btw)
    – Tensibai
    Commented Apr 6, 2017 at 18:24
  • The basic definition of "Devops is the development practice of writing applications whose business domain is operations" is not one I've ever seen anyone else subscribe to. Writing applications, regardless of domain or purpose, is development, not DevOps.
    – Adrian
    Commented Apr 6, 2017 at 20:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.