<p>I've heard many, many different definitions of DevOps.  They include:</p>

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

<p>There is no public consensus on what DevOps actually <em>is</em>.  A few years back we had similar problems with "Agile", and that <a href="http://agilemanifesto.org/" rel="noreferrer">has a written definition</a>.</p>

<p>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 <a href="https://en.wikipedia.org/wiki/Infrastructure_as_Code" rel="noreferrer">infrastructure as code</a>, 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.</p>

CC BY-SA 3.0
2017-04-07T19:07:09.590Z
2017-04-07T19:07:09.590Z
Xiong Chiamiov
<p>The definition I always use in this situation is the following: </p>

<p>“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.”</p>

<p>However, along with the definition, it is also important that they understand WHY we need <a href="http://squadex.com" rel="nofollow noreferrer">DevOps.</a> 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. </p>

CC BY-SA 3.0
2017-12-27T09:09:04.670Z
2017-12-27T09:09:04.670Z
DevOps Jedi
<p>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 <strong>personal</strong> experience DevOps comes in many flavours.</p>

<h1>Organization Patterns</h1>

<p>DevOps Antipatterns:</p>

<ul>
<li><p><strong>NoOps</strong> and <strong>NoDevs</strong> - 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.</p></li>
<li><p><strong>The DevOps Bridge</strong> - this is where one or more teams are given responsibility for taking work from the development teams and "<a href="https://en.wikipedia.org/wiki/Productionisation" rel="noreferrer">Productionizing</a>" it to make it operable.  The challenge comes down to now there are two hand-offs, i.e. Development → DevOps and DevOps → Operations.</p></li>
<li><p><strong>The DevOps Team</strong> - 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".</p></li>
</ul>

<p>DevOps Patterns:</p>

<ul>
<li><p><strong>Embedded DevOps</strong> - more commonly referred to as Platform Engineering, whereby there is someone within the team who is <em>accountable but not responsible</em> 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.</p></li>
<li><p><strong>Institutionalized DevOps</strong> - where a project team jointly is responsible for both development and operation of a software package building shared ownership and positive feedback loops.</p></li>
</ul>

<h1>Practices</h1>

<p>The actual practice of DevOps builds on top of several other practices, namely:</p>

<ul>
<li><a href="https://en.wikipedia.org/wiki/Agile_software_development" rel="noreferrer">Agile Delivery</a></li>
<li><a href="https://www.thoughtworks.com/continuous-integration" rel="noreferrer">Continuous Integration</a></li>
<li><a href="https://devops.stackexchange.com/questions/tagged/continuous-delivery">Continuous Delivery</a></li>
<li><a href="https://devops.stackexchange.com/questions/tagged/continuous-deployment">Continuous Deployment</a></li>
</ul>

<p>Each of the above practices builds upon the other, it's possible to <strong>not</strong> 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 <em>operation of software in production</em>.</p>

<p><a href="https://i.sstatic.net/LCGnq.png" rel="noreferrer"><img src="https://i.sstatic.net/LCGnq.png" alt="DevOps Practices"></a></p>

<h1>The Three Ways</h1>

<p>In <a href="https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO" rel="noreferrer">The Phoenix Project</a> Gene Kim and his co-authors describes the <a href="http://itrevolution.com/the-three-ways-principles-underpinning-devops/" rel="noreferrer">three ways of DevOps</a>:</p>

<h2>Systems Thinking</h2>

<p><a href="https://i.sstatic.net/6LVx9.png" rel="noreferrer"><img src="https://i.sstatic.net/6LVx9.png" alt="Systems Thinking"></a></p>

<blockquote>
  <p>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).</p>
</blockquote>

<p>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 <em>culture</em> aspects of DevOps.</p>

<h2>Amplification of Feedback Loops</h2>

<p><a href="https://i.sstatic.net/RHMCx.png" rel="noreferrer"><img src="https://i.sstatic.net/RHMCx.png" alt="Amplification of Feedback Loops"></a></p>

<blockquote>
  <p>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.</p>
</blockquote>

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

<h2>Culture of Continuous Experimentation and Learning</h2>

<p><a href="https://i.sstatic.net/41mm9.png" rel="noreferrer"><img src="https://i.sstatic.net/41mm9.png" alt="Culture of Continuous Experimentation and Learning"></a></p>

<blockquote>
  <p>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.</p>
</blockquote>

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

CC BY-SA 3.0
2017-04-11T13:55:08.897Z
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
CC BY-SA 3.0
2017-04-11T14:01:06.320Z
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.
Richard Slater
CC BY-SA 3.0
2017-04-08T21:09:23.510Z
2017-04-11T14:03:15.613Z
2017-04-13T13:01:29.297Z
Richard Slater
<p>Devops is the development practice of writing applications whose <strong>business domain</strong> 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.</p>

<p>The overriding goal should always be to enable <em>decision-makers</em> to become <em>decision-takers</em>. Imagine your bank's mobile application. When you request a transfer, it happens when you hit the button. You <em>made</em> a decision, then <strong>took</strong> 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.</p>

<p>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 <strong>and the right guard-rails</strong> to the right people so that decision-makers are decision-takers.</p>

CC BY-SA 3.0
2017-04-05T18:06:52.730Z
`whose business domain is operations` : Possible to expand on this, or give some examples?
Dawny33
CC BY-SA 3.0
2017-04-06T18:24:24.130Z
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
CC BY-SA 3.0
2017-04-06T20:06:31.173Z
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
CC BY-SA 3.0
2017-04-05T17:49:28.473Z
2017-04-05T18:18:30.417Z
2017-04-05T18:18:30.417Z
Rob Kinyon
<p>By the following scientific research paper to explore exactly this question,"What is DevOps", the proposed derived definition of DevOps is:</p>

<blockquote>
  <p>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.</p>
</blockquote>

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

CC BY-SA 3.0
2017-06-23T09:14:16.360Z
2017-06-23T10:55:06.617Z
2017-06-23T10:55:06.617Z
Ta Mu
<h3>DevOps in a nutshell</h3>

<p>From <a href="https://en.wikipedia.org/wiki/DevOps" rel="noreferrer">Wikipedia</a>:</p>

<blockquote>
  <p>DevOps (a <a href="https://en.wikipedia.org/wiki/Clipped_compound" rel="noreferrer">clipped compound</a> of "<a href="https://en.wikipedia.org/wiki/Software_development" rel="noreferrer">software <strong>DEV</strong>elopment</a>" and "<a href="https://en.wikipedia.org/wiki/Information_technology_operations" rel="noreferrer">information technology <strong>OP</strong>eration<strong>S</strong></a>") is a term used to refer to a set of practices that emphasize the collaboration and communication of both <a href="https://en.wikipedia.org/wiki/Software_developer" rel="noreferrer">software developers</a> and <a href="https://en.wikipedia.org/wiki/Information_technology" rel="noreferrer">information technology</a> (IT) professionals while automating the process of <a href="https://en.wikipedia.org/wiki/Software_delivery" rel="noreferrer">software delivery</a> and infrastructure changes.</p>
  
  <p>It aims at establishing a culture and environment where <a href="https://en.wikipedia.org/wiki/Software_build" rel="noreferrer">building</a>, <a href="https://en.wikipedia.org/wiki/Software_testing" rel="noreferrer">testing</a>, and <a href="https://en.wikipedia.org/wiki/Software_release_life_cycle" rel="noreferrer">releasing software</a> can happen rapidly, frequently, and more reliably.</p>
</blockquote>

<p>From <a href="https://en.wikipedia.org/wiki/DevOps#Overview" rel="noreferrer">Overview</a>:</p>

<blockquote>
  <p><a href="https://i.sstatic.net/odnjG.png" rel="noreferrer"><img src="https://i.sstatic.net/odnjG.png" alt="enter image description here"></a></p>
  
  <p>Venn diagram showing DevOps as the intersection of <a href="https://en.wikipedia.org/wiki/Software_development" rel="noreferrer">development</a>
  (software engineering), <a href="https://en.wikipedia.org/wiki/Information_technology_operations" rel="noreferrer">operations</a> and <a href="https://en.wikipedia.org/wiki/Quality_assurance" rel="noreferrer">quality assurance</a>
  (QA)</p>
</blockquote>

<p>While there is no single "tool" for DevOps, but rather a set of tools, also known as a <a href="https://en.wikipedia.org/wiki/DevOps_toolchain" rel="noreferrer">DevOps toolchain</a>:</p>

<blockquote>
  <p><a href="https://i.sstatic.net/kKb3O.png" rel="noreferrer"><img src="https://i.sstatic.net/kKb3O.png" alt="enter image description here"></a></p>
  
  <p>Illustration showing stages in a DevOps toolchain</p>
</blockquote>

<h3>Illustrations of DevOps</h3>

<p>Below are a few quotes from some of the questions on <a href="https://devops.stackexchange.com/">DevOps.SE</a>, which all seem to somehow fit / confirm part of the DevOps description above:</p>

<ul>
<li><p>From '<a href="https://devops.stackexchange.com/q/86/40">What is the difference between SRE and DevOps?</a>':</p>

<blockquote>
  <p>... DevOps is about maintaining code ...</p>
</blockquote></li>
<li><p>From (an <a href="https://devops.stackexchange.com/a/474/40">answer</a> to) '<a href="https://devops.stackexchange.com/q/468/40">How do I hire a good DevOps, fitting my company?</a>':</p>

<blockquote>
  <p>... It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies ...</p>
</blockquote></li>
<li><p>From '<a href="https://devops.stackexchange.com/q/333/40">Does my organization need adopt Agile Soft. Dev. before adopting DevOps?</a>':</p>

<blockquote>
  <p>... there are still organisations which are not practicing Agile in their software development, who might be interested in adopting DevOps ...</p>
</blockquote></li>
</ul>

<h3>DevOps is NOT a role</h3>

<p>Below are a few quotes from some of the questions on <a href="https://devops.stackexchange.com/">DevOps.SE</a>, which all seem to illustrate that DevOps is <strong>NOT</strong> a role:</p>

<ul>
<li><p>From (an <a href="https://devops.stackexchange.com/a/160/40">answer</a> to) '<a href="https://devops.stackexchange.com/q/157/40">What is the difference between Sysadmin and DevOps Engineer?</a>':</p>

<blockquote>
  <p>... DevOps is not a role (when used as such it's more a buzzword than a real role).</p>
</blockquote></li>
<li><p>From (an <a href="https://devops.stackexchange.com/a/474/40">answer</a> to) '<a href="https://devops.stackexchange.com/q/468/40">How do I hire a good DevOps, fitting my company?</a>':</p>

<blockquote>
  <p>... It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies ...</p>
</blockquote></li>
</ul>

CC BY-SA 3.0
2017-04-06T17:44:02.263Z
2017-04-06T18:08:38.670Z
2017-04-13T13:01:29.297Z
Pierre.Vriens
<p>I've done / created lots of SCM related presentations, and now I'm trying to "upgrade" to a DevOps successor of it.</p>

<p>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?*".</p>

<p>I thought I knew what <strong><em>DevOps</em></strong> actually means, and what it is about. But I've seen some bizarre usages/contexts of <em>DevOps</em> (even on <a href="https://devops.stackexchange.com/">DevOps.SE</a> ...). It makes me wonder if maybe what I think DevOps is, is completely wrong.</p>

<p>So what is generally agreed to be the definition of DevOps?</p>

CC BY-SA 3.0
2017-04-06T19:50:33.293Z
History of Comments have been [moved to chat](http://chat.stackexchange.com/rooms/56681/conversation/improvement-exchange) for record on how a question can be improved.
Tensibai
CC BY-SA 3.0
2017-04-07T17:45:13.523Z
The main thing I've learned from talking to many people is that there is no agreed upon definition.
Xiong Chiamiov
CC BY-SA 3.0
2017-04-07T17:47:50.717Z
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
<terminology><culture>
What could be a valid definition of DevOps to introduce it to a novice?
Pierre.Vriens
# What could be a valid definition of DevOps to introduce it to a novice?

(Asked by: username_0 on 2017-04-05)

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](https://devops.stackexchange.com/) ...). 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?

**Tags:** terminology, culture

> **Comments:**
> **username_1**: History of Comments have been [moved to chat](http://chat.stackexchange.com/rooms/56681/conversation/improvement-exchange) for record on how a question can be improved.  
> **username_2**: The main thing I've learned from talking to many people is that there is no agreed upon definition.  
> **username_0**: 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?  

---

## 6 answers

### Answer by username_0 on 2017-04-06. Score: 13 | Accepted answer

### DevOps in a nutshell

From [Wikipedia](https://en.wikipedia.org/wiki/DevOps):

> DevOps (a [clipped compound](https://en.wikipedia.org/wiki/Clipped_compound) of "[software **DEV**elopment](https://en.wikipedia.org/wiki/Software_development)" and "[information technology **OP**eration**S**](https://en.wikipedia.org/wiki/Information_technology_operations)") is a term used to refer to a set of practices that emphasize the collaboration and communication of both [software developers](https://en.wikipedia.org/wiki/Software_developer) and [information technology](https://en.wikipedia.org/wiki/Information_technology) (IT) professionals while automating the process of [software delivery](https://en.wikipedia.org/wiki/Software_delivery) and infrastructure changes.
>
> It aims at establishing a culture and environment where [building](https://en.wikipedia.org/wiki/Software_build), [testing](https://en.wikipedia.org/wiki/Software_testing), and [releasing software](https://en.wikipedia.org/wiki/Software_release_life_cycle) can happen rapidly, frequently, and more reliably.

From [Overview](https://en.wikipedia.org/wiki/DevOps#Overview):

> [![enter image description here](https://i.sstatic.net/odnjG.png)](https://i.sstatic.net/odnjG.png)
>
> Venn diagram showing DevOps as the intersection of [development](https://en.wikipedia.org/wiki/Software_development)
> (software engineering), [operations](https://en.wikipedia.org/wiki/Information_technology_operations) and [quality assurance](https://en.wikipedia.org/wiki/Quality_assurance)
> (QA)

While there is no single "tool" for DevOps, but rather a set of tools, also known as a [DevOps toolchain](https://en.wikipedia.org/wiki/DevOps_toolchain):

> [![enter image description here](https://i.sstatic.net/kKb3O.png)](https://i.sstatic.net/kKb3O.png)
>
> Illustration showing stages in a DevOps toolchain

### Illustrations of DevOps

Below are a few quotes from some of the questions on [DevOps.SE](https://devops.stackexchange.com/), which all seem to somehow fit / confirm part of the DevOps description above:

* From '[What is the difference between SRE and DevOps?](https://devops.stackexchange.com/q/86/40)':

  > ... DevOps is about maintaining code ...
* From (an [answer](https://devops.stackexchange.com/a/474/40) to) '[How do I hire a good DevOps, fitting my company?](https://devops.stackexchange.com/q/468/40)':

  > ... It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies ...
* From '[Does my organization need adopt Agile Soft. Dev. before adopting DevOps?](https://devops.stackexchange.com/q/333/40)':

  > ... there are still organisations which are not practicing Agile in their software development, who might be interested in adopting DevOps ...

### DevOps is NOT a role

Below are a few quotes from some of the questions on [DevOps.SE](https://devops.stackexchange.com/), which all seem to illustrate that DevOps is **NOT** a role:

* From (an [answer](https://devops.stackexchange.com/a/160/40) to) '[What is the difference between Sysadmin and DevOps Engineer?](https://devops.stackexchange.com/q/157/40)':

  > ... DevOps is not a role (when used as such it's more a buzzword than a real role).
* From (an [answer](https://devops.stackexchange.com/a/474/40) to) '[How do I hire a good DevOps, fitting my company?](https://devops.stackexchange.com/q/468/40)':

  > ... It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies ...


---

### Answer by username_4 on 2017-04-08. Score: 13

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](https://en.wikipedia.org/wiki/Productionisation)" 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.

# Practices

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

* [Agile Delivery](https://en.wikipedia.org/wiki/Agile_software_development)
* [Continuous Integration](https://www.thoughtworks.com/continuous-integration)
* [Continuous Delivery](https://devops.stackexchange.com/questions/tagged/continuous-delivery)
* [Continuous Deployment](https://devops.stackexchange.com/questions/tagged/continuous-deployment)

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](https://i.sstatic.net/LCGnq.png)](https://i.sstatic.net/LCGnq.png)

# The Three Ways

In [The Phoenix Project](https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO) Gene Kim and his co-authors describes the [three ways of DevOps](http://itrevolution.com/the-three-ways-principles-underpinning-devops/):

## Systems Thinking

[![Systems Thinking](https://i.sstatic.net/6LVx9.png)](https://i.sstatic.net/6LVx9.png)

> 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](https://i.sstatic.net/RHMCx.png)](https://i.sstatic.net/RHMCx.png)

> 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](https://i.sstatic.net/41mm9.png)](https://i.sstatic.net/41mm9.png)

> 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.

> **Comments:**
> **username_5**: 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 !  
> **username_4**: 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.  

---

### Answer by username_2 on 2017-04-07. Score: 6

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](http://agilemanifesto.org/).

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](https://en.wikipedia.org/wiki/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.


---

### Answer by username_3 on 2017-12-27. Score: 2

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.](http://squadex.com) 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.


---

### Answer by username_9 on 2017-06-23. Score: 1

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)


---

### Answer by username_6 on 2017-04-05. Score: -2

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.

> **Comments:**
> **username_7**: `whose business domain is operations` : Possible to expand on this, or give some examples?  
> **username_1**: 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)  
> **username_8**: 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.  

---

