Conversely, an organization fully committed to cultural change but unwilling or unable to adopt agile methods and automated tools will find that the cultural change is simply too difficult to sustain, in practice. With manual steps, a heavyweight process and ill-fitting, cumbersome legacy tools still in place, the expectations for faster delivery go unmet and the transformation is eventually abandoned as a failed initiative. FRAMING DEVOPS So far we’ve talked about DevOps in terms of a culture based on certain principles and in terms of the trinity of people, process and tools. The truth is that there are several models for defining and describing DevOps, and all of them can lead to a deeper, fuller understanding as well as a smoother DevOps implementation. One good example is the Three Ways of DevOps described by Gene Kim and his co-authors in their insightful book The Phoenix Project. Of course, these ways – systems thinking, amplification of feedback loops and a culture of continual experimentation and learning – overlap significantly with the principles outlined earlier. Another good example is the CAMS model, which overlaps similarly with its focus on culture, automation, management and sharing. Returning to the idea of the trinity, there is one more way to frame DevOps that resonates with many in IT. In this framework, the software development lifecycle is viewed as having upstream (development) and downstream (operations) halves. The two halves are part of the same software delivery process but in many non-DevOps IT organizations these halves are highly disconnected (Figure 1). Figure 1: The disconnect between upstream and downstream people, process and tools. What is DevOps? 5