White paper White Quint Wellington Redwood The Sense and Nonsense of DevOps The real value of DevOps Over the past years, we have seen a host of hype words appear: Agile, Scrum, Big Data, BYOD, Lean IT. “DevOps” is probably one of the most enigmatic of them all. This word is used more and more often without it really being clear what it means. In this White Paper, we unravel the sense and nonsense of DevOps and identify its benefits. The term DevOps emerged in a series of “DevOps Days” held in Belgium about five years ago. The aim of the events was to bring together IT experts from both the development side and the operations side of organizations. And that puts the term DevOps in its context: a multidisciplinary team that is fully responsible for the continuous operation and development of a service. Google and Amazon are examples of companies that use a combination of DevOps and continuous delivery to release dozens of changes every day. The definition of DevOps on Wikipedia is interesting: DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and infor- mation technology (IT) operations professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services. The key point here is that, in this definition, DevOps is about producing software rapidly. This completely ignores the real value and aim of DevOps. What is the real value of DevOps achievable with a DevOps approach used to its full extent? Mismatch The way in which IT services are delivered within business which, to an increasing degree, wants many organizations can barely be maintained new functionality to be delivered fast, incidents because the current IT processes were not de- to be resolved quickly, and to have short com- signed to meet a demand from the business for munication lines and high quality IT. fast and flexible IT. This means there is a mismatch between tra- Due to our predominantly silo-driven organiza- ditionally-designed IT organizations and the tional approach, IT processes are unnecessarily business. It is therefore time for a fundamental complex, performance measurements are not review of the structure of IT organizations. transparent, people’s attitude and behavior is Changing nothing and hoping that things will focused internally, and tools are too strongly improve in the long run comes close to Einstein’s concentrated on individual technologies. This definition of insanity: “Doing the same thing over is diametrically opposed to the desire of the and over again and expecting different results.” White Paper: The Sense and Nonsense of DevOps 1 Elements of DevOps Broadly speaking, up until now, various experts tion processes as the solution to IT problems, have looked at DevOps from three dimensions: and refer frequently to Agile, Scrum and other tools, processes and culture. methods. Here, the integration of ITIL processes and development processes appears to be one Tools of the goals. The natural reflex in the world of IT is to use technology to resolve a problem. In itself, this Culture is a sound approach, especially if changes can A significant number of DevOps researchers see be deployed to production more often and more realizing a common culture between Dev and reliably. By using integrated tooling to strictly Ops people as the vital element. This involves manage the movement of units of work through building understanding between developers and a DTAP (Development, Testing, Acceptance and ‘operations people’, and ensuring more collabo- Production) flow, release frequency can be ac- ration between the two camps. For the IT world, celerated to a level that could never be achieved this is not an everyday approach. manually. Tooling is therefore an indispensable element of DevOps. IT processes are unnecessarily complex, performance measurements are not Processes transparent, people’s attitude and behavior is Thinking in terms of processes is part of IT. Many focused internally, and tools are too strongly DevOps thinkers regard development-to-produc- concentrated on individual technologies Combination Relevant arguments can be put in favor of each of mutual understanding is a crucial element. By the dimensions mentioned above. Nonetheless, focusing on behavior instead of on culture, we in practice, it turns out that DevOps people often ensure that the members of a DevOps team choose one of the dimensions above the others. become aware of their own role in the success This is a shame because the strength of DevOps of their team. How managers provide guidance, actually lies in combining these dimensions, and in relation to the maturity of the team and the adding two others. extent of the integration, is also a decisive factor in the success of DevOps teams. To the above three dimensions, we add per- formance (which in some cases is included as Performance a component of processes) and organization. DevOps promises a lot in terms of more, faster Moreover, it has been shown that culture is and better releases. As a result, in the DevOps a difficult dimension to manage. In its place, world, there is a strong trend towards focusing on the ‘Attitude and Behavior’ dimension is much making IT performance measurable. This is giving more closely aligned with the aspects that are some people pause for thought. There is indeed important in DevOps. We argue here for these nothing wrong with an end-to-end approach to five dimensions to be treated as equal and to the delivery of IT services to customers. However, use them all to design the integration of ‘Dev’ is it important to know exactly how many hours and ‘Ops’. are needed to build a use case? Especially given that DevOps was developed to meet customer Attitude and Behavior demand. It is important to recognize – especially at the Another aspect of performance is the use of time: start of the integration – that the behavior of how is time used within the team? What is the developers and operations people is different. balance between innovation and maintenance? Harmonizing attitude and behavior is important in The outcome should be the implementation of making DevOps a success. Of course, creating actions for improvement aimed at redressing 2 Quint Wellington Redwood the balance in favor of innovation without com- Processes promising quality. As mentioned earlier, the processes within an IT organization are usually not clear to the staff. Organization This is because the process flow is comprised One of the least discussed aspects of DevOps of a series of departments which are all only is the organizational dimension. This revolves involved in part of the flow. Staff are thus unclear around adapting the IT organization to bring as to what their role is in the chain as a whole. ‘Dev’ and ‘Ops’ closer together. In practice, In a DevOps team that works with Visual Man- however, it turns out that people primarily work agement, it is possible to optimize processes on improving the communication between ‘Dev’ without involving the departments concerned. and ‘Ops’ rather than on implementing organi- This means that complex manuals make way zational changes. for simple, clear agreements. It turns out that In addition, the management model and the within processes, the key to success is the strict skills of managers turn out to be crucial to the monitoring and management of open units of success of a DevOps team. Various approaches, work. including Lean, offer a wide array of tools (e.g. Visual Management) for efficient management Tooling and tackling problems. Within a DevOps team, a fully automated DTAP In practice, it is now common for operational flow is a prerequisite for guaranteeing speed inventory to be ‘visually’ managed within a Dev and quality. Does this mean that a DevOps team organization. However, managing activities via cannot exist without this tooling? No, the increas- Kanban boards (visual displays of the operational ing automation of the various steps through the flow) is often uncomfortable for ‘Ops’ people. DTAP flow is also a growth scenario. There are Experience has shown that this discomfort dis- also many benefits to be gained through growth appears relatively quickly. The most important in one or more of the other dimensions. aspect of the organizational dimension is paying The aforementioned five dimensions all play a role attention to team-forming. Putting people togeth- in an approach based on DevOps methodology er works to a certain extent, but to gain more and in realizing the intended benefits. benefit, attention should be paid to team-building. Really putting customers first Ultimately, DevOps is about providing permanent it much simpler to determine the value that should IT services for customers. Over the past years, be delivered. it has been clear to see that IT organizations are Based on these basic characteristics, the tech- focusing more on the needs of their customers. nology stack for which the team is responsible Information management was a start, the intro- can be determined. The ‘deeper’ the technology duction of Agile-like methods was a second step. stack, the more knowledge and skills the team But these methods are only partial solutions to requires. In this regard, the rise of cloud technol- a fundamental problem in IT: sticking to a tradi- ogy with its different variants (IaaS, PaaS, SaaS) tional organizational form in which we arrange does make it easier to decouple the team from things on a type-with-type basis. Working with the underlying technology (Figure 1). a DevOps approach breaks down the tradition- al organizational structure of IT departments. In practice, we regularly see DevOps being inte- However, in order to make DevOps a success, grally linked to Agile/Scrum.