DevOps is a way to get to a more continuous capability in your pipeline. Probably easiest way to explain it is to contrast it with the older way of doing things, the things that it's hoping to improve on. So, in the very traditional view of how a software development or a digital program would work, we have a developer, we have a tester, we have an Ops person. The inputs to the developer are in the old world requirements and in the newer world, hopefully something a little more design-centric, user-centric, like Agile user stories, or end or wireframes, things like that where we're showing and we're putting ourselves in the shoes of the user. The outputs are working software basically. The design implemented and handed over to our tester who gets that in the software, and hopefully some notes on what it should do and their job is to make sure it doesn't break. Then say, okay, "Hey Ops, we can go ship this, deploy it, whatever it is that we do with our software." The Ops person hopefully gets the software along with some notes on how it's supposed to work and some notes on how you'll know if it's working properly, it's not working properly. So how to interpret logs or instrumentation, whatever it is that helps us know what the software is doing and whether it's behaving as we expect. Their job is to make sure that the system doesn't break. So, if we look at a summary of this process, there is a lot of natural antagonism here, and it's just the fact that we all measure our efficiency locally and that's what we're going to start from. It takes a lot of focus, and a lot of thoughtfulness, and a lot purpose, to achieve a more interdisciplinary and more outcome-centric working environment. So, if we do things this simple way, the developer is under a lot of pressure from business people, project managers, whatever, to create new features and get them out the door, so that they're meeting their project timelines or they're helping the product get better and make more sales. That is and remains a lot of the pressure on a typical developer. Then this tester is in a position where they have to make sure that the software doesn't break and they may not have enough time to test it. So they're going to naturally introduce delay into this process and want to test more, so nobody says later that, "Hey, you should have tested that more." That remains the job of testing and its nature, and so we have to work hard to make all this stuff make more sense together. Then finally, Ops gets the software and their job is to make sure it doesn't break and take the call at 2:00 AM or whatever on Sunday morning if it does actually break, which I've gotten that call, I know I didn't enjoy it, I don't think anybody does. So, there's a lot of natural antagonism here and it's just the nature of the job and what has to be done, but it's not the best way for everyone to work together and that's really what DevOps is about. How do we do this better with a little more purpose and a little more thoughtfulness? That is really, I would say, at least the overall goal of DevOps. So, how do we make all this work better? There isn't one single thing that's is or isn't DevOps, and if you ask five different people, you'll probably hear DevOps describe 10 different ways, but there are a few key things. One is that the silos between departments are something that you will see in a non-DevOps environment. So, even if these folks are on centralized teams which isn't always the best way to do things, the handoffs between them are very fluid, there are self-service environments where it's really easy for these folks to work together and they're not these kind of gates gating each other's progress. As much as they are, creating an infrastructure on top of this pipeline to help each other go from step A to step B. So, very commonly, you will find at least a few of these folks in interdisciplinary teams rather than silos. You may hear that that's always true. If there is a DevOps department then something is wrong. I think that there's a lot of validity in that statement because you will see situations where they just took the old Ops department that was working in this relatively traditional way, doing the best job they can, but with processes that really aren't the most productive for a lot of situations, and they just renamed it DevOps and so, clearly, that's not really material progress towards DevOps. However, centralized departments of a DevOps nature are often things like a group that creates part of that pipeline for other people to use in the way that they see fit. So, you might see a department called DevOps or DevOps something that creates a continuous integration or continuous delivery platform that teams can then go and use on a self-service basis as they see fit. You'll hear teams for whom that works pretty well, you may also hear about DevOps departments that are coaches advisors to the other teams, and some companies find that, that works well. Really there's two things that I would say at least are the key attributes of a DevOps program, a program that is helping a company move towards a more continuous delivery. One is that, the inter-disciplinary relationships are designed in a way that makes sense and there are retrospectives around them where they're constantly looking at not just did Dev do their job, did Ops do their job, but how's everybody working together, and are we working together towards our shared outcome that we want to have? Is that pulling through the way that everybody interacts with each other in an interdisciplinary way, and are we putting processes in place that facilitate that. Then the second thing is a big focus on automation. None of these things happen unless you take the things that you're doing by hand now, either in testing or in development, or in operations, and you approach them with the question of, how might we do this better with automation to remove grunt work and increase the health of our pipeline? So, I would say those are the top two characteristics of a program of DevOps that is helping you get towards a more continuous capability.
