DevOps is the collision of “development” and “operations”. It is the practice of collaboration and communication between development engineers and operations IT engineers for the purpose of automating software delivery and infrastructure changes. When most people think of “devops” they think “automation”. But it is important to remember what devops is automating (software delivery, e.g., deployments, and changes to the infrastructure used to make those deliveries) and why devops is automating these things (to eliminate errors and process lag caused by the time and effort required to perform these deliveries manually).

DevOps itself is a rather new discipline, arising roughly in the mid-2000s only after the Agile Software Development movement started to gain prominence in the technology field. DevOps is, at its heart, part of the Agile mindset and subscribes to the Agile values and principles outlined in the Agile Manifesto. DevOps employs Agile methodologies and practices and makes extensive use of Agile and automation tools. This mindset, like Agile in general, arose from applying the principles of the Toyota Way to IT systems and infrastructure administration.

How automation is accomplished by a DevOps teams usually follows an incremental adoption methodology that is slaved to both the Theory of Constraints and Gene Kim‘s Three Ways; Systems Thinking, Amplification of Feedback Loops, and Creation of a Culture of Continuous Experimentation and Learning, both of which are explained below. The ultimate goal of all of this being an ecosystem of continuous integration and continuous delivery (CI/CD) that eliminates product downtime and minimizes product delivery times by margins larger than those achievable by a human performing the exact same steps manually*.

Theory of Constraints

The Theory of Constraints grew out of manufacturing and the need to understand limiting factors on production systems. The shorter, more colloquial definition is that a system can be only as productive as its least productive subsystem. The Theory of Constraints focuses on identifying those constraints and restructuring the rest of the production system around them in order to create a move viable, more productive system. This is accomplished through the use of the 5 Focusing Steps:

1. Identify the system’s constraint(s).
2. Determine how best to exploit the system’s constraint(s).
3. Subordinate every other part of the system to the exploitation of the constraint(s) identified in Steps 1 and 2.
4. Evaluate the system’s constraint(s) after the subordination of the system in Step 3.
5. Warning! If the previous steps have alleviated the constraint, start again at Step 1 to continue to optimize the system, but do not allow inertia to create a new system constraint.

The Three Ways

• Systems Thinking – Put the emphasis on the performance of the entire system as a whole and on all value streams enabled by the system instead of focusing on some of the individual subsystems while ignoring others.
• Amplification of Feedback Loops – Put emphasis on increasing feedback and understanding of all of the subsystems and teams that make up the larger whole.
• Creation of a Culture of Continual Experimentation and Learning – Put emphasis on learning from both experimentation and from repetitive practice. Experimentation and risk taking in non-harmful contexts actively promote improvement. Repetitive practice promotes deep understanding. Both experimentation and practice are required for individuals and teams to develop mastery. Mastery is the difference between individuals and teams that struggle to perform and those that perform well even under less than optimal conditions.

* Which brings us to the most dreaded topic in DevOps…

Welcoming Our Robot Overlords and What That Means to Us

Most people, when confronted with automation, somehow tend to immediately believe that automation equals the loss of their jobs. In software development, this could not be further from the truth! In software development, automation is used to perform those low value tasks that no one really wants to do anyway. For example, I worked for a software company that had two offices, one in the US and another in the Philippines. At least once a week, one of the managers would have to come in early or stay late to manually FTP files from one location to the other. Work to be done was sent out and completed work was brought back. And irrespective of who was assigned to perform this task, they universally loathed it because, in large part, it was just sitting around with only the occasional human intervention required. This particular work was a prime candidate for automation. DevOps can and should be used to solve problems and improve the quality of life for everyone involved in the software development process. DevOps is not about automating people out of their jobs. DevOps is about improving both the quality of the delivery of our software products and the quality of the work that we need to do in order to deliver it.​​