DevOps for Adults

Michael Huetterman's picture

It is 2018, and although the term DevOps was coined nine years ago, there are still lot of misunderstandings of what the essence of DevOps is. Meanwhile, a lot of companies plan to implement DevOps, or did implement it already, successfully, in order to profit from its advantages. Thus it is time to summarize the key parts again, which you will see in this post. I will give you some pointers to follow-ups, too. Now, let’s start with a quick introduction.


The term DevOps is a blend of development (representing software developers, including programmers, testers and quality assurance personnel) and operations (representing the experts who put software into production and manage the production infrastructure, including system administrators, database administrators and network technicians). DevOps describes practices that streamline the software delivery process, emphasizing the learning by streaming feedback from production to development, by streaming good practices from development to operations and improving the cycle time. DevOps does not only empower you to deliver software more quickly, but it will also help you to produce higher-quality software that is more aligned with individual requirements and basic conditions.

DevOps encompasses numerous activities and aspects, including:

  • Culture: People over processes and tools. Software is made by and for people.

  • Automation: Automation is essential for DevOps to gain quick feedback.

  • Measurement: DevOps finds a specific path to measurement. Quality and shared (or at least aligned) incentives are critical.

  • Sharing: Create a culture where people share ideas, processes and tools. This can also mean that teams grow aligned with t-shaped skills, see Figure 1.

Figure 1: DevOps includes sharing knowledge and experience, across teams and inside a team, while still appreciating classic division of work.

One factor of DevOps initiatives is spanning functions, which is covered next.

DevOps spanning different functions

Agile efforts often end at the transition phase from development to operations, shown in Figure 2. DevOps broadens the scope to also include delivery of software and services. DevOps provides patterns to foster collaboration among project stakeholders and uses processes as well as tools to streamline the software delivery process.

Figure 2: DevOps enriches agile development by including the last mile, that is operations.

DevOps has strong interfaces to many disciplines, above all business; see Figure 3. Also configuration management, release management, test management, build management, integration management and deployment management are involved and cross-cutting non-functional requirements such as security are surely still important with DevOps. In other words, DevOps is a means to cover the entire agile Application Lifecycle Management (ALM).

Figure 3: DevOps brings together many different functions, above all development and operations, and business is always involved.

The comparison of tasks and views of development and operations shows that the two teams have divergent goals and incentives and that these divergences lead to conflict. Development strives for change (e.g., new features and bug fixes), whereas the operations team strives for stability. Often, those groups are paid precisely for these tasks: development obtains bonus payments if the software is delivered, whereas operations is rewarded if production systems are stable. The development department desires a high flow of newly provided functionality, whereas the operations department prefers to avoid putting any new release into production.

Both teams follow their respective goals by focusing on their individual tasks and by fulfilling their obligations to obtain positive attention from management and visibility for doing a great job. To achieve their respective goals, development and operations often use their own processes and tools - sets of processes and tools are optimized locally (for each group) to obtain the best local result. Although these approaches are great from their isolated viewpoints, the total flow of software is reduced, and the overall project (or company) goal is thwarted. As a result, silos are constructed, conflicts exist on a daily basis and people are working against one another instead of with one another to provide the best solution possible.

Using the right DevOps enablement tool for a specific job can already boost productivity. Enterprises will gain the maximal value of DevOps if they align goals, processes and tools, across functions, what is covered next.

The Essence of DevOps: goals, processes, tools

One key aspect of DevOps is using and optimizing shared goals. The cycle time is a shared goal between different functions above all of development and operations. It expresses that you are flexible in delivering high quality changes, quickly. It fosters a competitive advantage. It measures the time from start to end of a process. Although creating your own definitions helps, often used endpoints include the time from Git push of a change to deploying it on production, available for end users. The cycle time is often visualized and then improved by deriving pipelines from value stream maps. Pipelines are doughnuts, not tubes - tools are glued together, based on Jenkins and quality gates are utilized while implementing a high degree of automation.

To establish shared goals, concepts and tools are very important. It is essential to choose good DevOps practices and to integrate DevOps enablement tools. Taking the right tool, aligned with your processes, requirement, and basic conditions, and integrating it with ecosystem, i.e. platforms and tools used by you, should be strongly aligned with organizational as well as technical and regulatory drivers; see Figure 4.

Figure 4: DevOps is also about tools, and integrating those tools with others to work productively. Finding the correct tool depends on many aspects including organizational, technical and regulatory drivers. 

To give you one example: Jenkins could be the best choice in many setups, whereas in others the CloudBees Jenkins Enterprise tool could be the better choice to make Jenkins “enterprise-ready” e.g. by providing additional features or implementing specific non-functional requirements for security, scaling and resilience, on cloud-native, Dockerized platfoms. CloudBees developed the DevOps Maturity Model to help you to find the best tool, delivers a huge set of DevOps entry points and those facets are discussed in DevOps Radio continuously.


This closes my quick discussion of DevOps. There are more aspects, and many more details. In following contributions, I’d like to zoom in to different aspects of what makes up DevOps, and will discuss DevOps practices and DevOps enablement tools in more detail, also emphasizing tool integration in order to implement your holistic DevOps initiative.

Happy DevOps!


Michael Hüttermann, Agile ALM, Manning, 2011

Michael Hüttermann, DevOps for Developers, Apress, 2012

Eliyahu M. Goldratt, The Goal: A Process of Ongoing Improvement, North River Press; 30th Anniversary Edition edition, 2014

About the author

Michael Hüttermann is a leading subject matter expert in Continuous Delivery, DevOps and SCM/ALM. He has written a couple of books including “DevOps for Developers”, 2012, and “Agile ALM”, 2011. He was recognized to be a Oracle Java Champion in 2006 and Oracle Developer Champion in 2017. He is Principal DevOps Consultant at CloudBees. Follow him on Twitter: @huettermann.





Add new comment