Right from the outset, the digital age has brought with it a great many new buzz words and concepts that have an impact on IT. Agile, Scrum, Lean IT and DevOps, to name just four. We are seeing that followers of the various schools of thought are often in conflict. When we more closely examine the background of each concept and the objectives they are aimed at realizing, three common goals can be identified: optimizing the agility of the organization by anticipating change, reducing the time to market of new features, products and business models, and delivering the highest possible customer value while focusing on quality at the source.

After reading this white paper, you will be able to place current developments – and the often heated discussions about the next steps – within the context of your organization, and recognize their relationship to one another. DevOps is the development that links the Agile world’s need for flexibility with the need to guarantee continuity in the provision of services. This paper also links DevOps to a development that has emerged from infrastructure management in order to respond to developments in that domain as well. Ultimately, these developments reinforce one another and, after reading this paper, you will know why.

DevOps is a cohesive approach

Let’s first examine the objectives of the various concepts.

Lean, which came into its own in the automotive industry (the Toyota Way), aims to optimize the value stream by removing as many unnecessary actions and steps as possible. To this end, Lean offers an extensive toolkit in which the focus is on leadership, knowledge of the work floor and continuous improvement.

Agile and Scrum emerged from the world of software development. Here, the Lean mindset is translated into responding to changed insights regarding feasibility and customer value which are identified by the customer and developers during the development process and use of new software. Process improvement and waste reduction are the next step.

DevOps adds user value during the lifecycle to the above. By allowing operations to be performed by the same team that develops the functionality, a direct feedback loop is created which enables the team and the customer to identify priorities from the long-term perspective and to develop software in such a way as to minimize the operations burden throughout the lifecycle of a service.

These differences in origin do not have to be a restriction; the concepts are complementary and can be used together effectively. It is, however, useful to understand the background of each concept, and how more customer value can be delivered when they are combined based on each one’s own specific strength. Application operations versus application development, application domain and infrastructure domain: from the customer perspective there is a growing need for flexible and reliable IT. It is up to you to meet the challenge of fulfilling this need. In this regard, DevOps is a cohesive approach to four areas: Operations, Development, Applications and Infrastructure. At first glance, DevOps is simply the combination of Development & Operations. However, behind this façade there lies a whole new world of thinking which entails making optimal use of new technological opportunities, focusing on team responsibility and integrating processes within the team. This paper aims to reveal the secret behind the term DevOps and thus create more clarity. After all, DevOps is an organizational earthquake which can contribute significantly to the added value delivered to customers and experienced by staff. This paper illustrates what DevOps delivers from four different perspectives in 4 DevOps journeys.

What is DevOps?

DevOps is the merging of the responsibilities for development and operations in order for them to together guarantee the health of the IT service for the user organization. Initially aimed at new software to be developed based on new programming languages, in practice applying DevOps to existing systems (including legacy and ERP systems) has proven equally successful. However, in this regard, it is essential that development is guided by testable acceptance criteria; transparency and improving quality at the source are vital aspects.

Another factor is that the success of DevOps is to a large extent determined by the mindset and actual behavior of staff and management. It is not a ready-for-use recipe that can simply be implemented without any problems.

Challenges and problems have to be tackled creatively and with tenacity to move steadily closer to realizing the goal of responding more quickly to the changing needs of customers by providing high-quality managed solutions. Lean leadership, which is also used in Agile teams, also plays a major role in DevOps. Learning from mistakes with the focus on delivering customer value is a key success factor.

This brings us to the organization of work across multidisciplinary teams that have full responsibility for the ‘health’ of the service involved. Composing the teams in such a way that the required competencies are present is an important factor in maintaining this health. However, team dynamics is also a major element. An interesting point in this regard is that a balanced male-female ratio demonstrably contributes to the quality of the service and the growth that a DevOps team undergoes. Get the systems in one room – diversity within teams is essential to the continuous delivery of improved results.

DevOps focuses strongly on operations processes and change processes and the automation thereof. This involves more than a combination of operations and development because there is also a focus placed on quality at the source and first-time-right as the active ingredient for operating services without rework, and for moving services quickly through the DTAP street (Development - Testing - Acceptance - Production). This means that quality assurance therefore constitutes the third element in DevOps. Continuous integration, automated testing and automated promotion through the DTAP street based on predefined acceptance criteria, and version control of the entire IT stack including the underlying platforms and infrastructure, capitalize on the earlier mentioned success factors and reduce the lead times of change, recovery and incident handling.

The 4 DevOps journeys

In practice, what people think of DevOps is shown to be highly dependent on the experience they have with it within their own organization. In this paper, we use four DevOps journeys to bring together these different experiences as pieces of a larger puzzle. Each journey describes the development of DevOps from a particular perspective. Each of the four journeys can be regarded as the archetype of a journey an organization can make. These journeys serve as a frame of reference for discussions about the meaning of organizational changes.

In practice, you have probably noticed that within the various parts of your organization people are trying to find a solution to the increasing need for agile and reliable IT. Each part does so from its own perspective. However, this is like trying to convey what an elephant looks like by only describing its trunk or its tail or foot. Each part of the organization is right, to a certain extent. The trick is to make combinations of descriptions which provide a clear picture of an elephant. By understanding the different perspectives, you can combine them powerfully because the underlying goal is a common one.

Journey 1: From waterfall to DevOps

Traditionally, new systems are developed in projects, in a waterfall process. The project ultimately delivers the system (after months, or sometimes years) to the operations organization, which formally accepts the system. In practice, however, these new systems are ‘thrown over the wall’ and remaining points and quality issues have to be resolved in the operations phase.

However, a trend in recent years is to develop (or further develop) systems in short cycles using Agile methods like Scrum. Scrum can be very successful but in reality it turns out that actual deployment to production is a very high hurdle: the ‘wall’ referred to earlier is higher and more solid than had been thought. Operations’ ground rules are difficult to capture in the Definition of Done and hard to pass on in advance to the Scrum teams in the form of requirements or non-functional requirements.

This DevOps journey starts when the Scrum team takes responsibility for resolving incidents and, as result, acquires insight into the functionality and becomes jointly responsible for making the functionality available in the production environment. Taking responsibility for matters ‘on the other side of the wall’ leads to a different awareness of quality. The technical debt and the number of incidents, questions from users and operational issues will hurt; they impede – and will continue to impede – the Scrum team in delivering value quickly. Low quality leads to a congested backlog. This can also be the starting point for assigning multiple operations tasks within the Scrum team; for example, the team will monitor and optimize (automate) the performance of systems. In addition, it becomes important to the team that the technical debt is contained and reduced. The development team

This DevOps journey starts when the Scrum team takes responsibility for resolving incidents and, as result, acquires insight into the functionality and becomes jointly responsible for making the functionality available in the production environment. Taking responsibility for matters ‘on the other side of the wall’ leads to a different awareness of quality. The technical debt and the number of incidents, questions from users and operational issues will hurt; they impede – and will continue to impede – the Scrum team in delivering value quickly. Low quality leads to a congested backlog. This can also be the starting point for assigning multiple operations tasks within the Scrum team; for example, the team will monitor and optimize (automate) the performance of systems. In addition, it becomes important to the team that the technical debt is contained and reduced. The development team not only becomes responsible for the delivery of working software but also for the delivery of the entire service so that a user group can also use this functionality optimally in its own business process. This change is the most common DevOps journey: the journey from development to operations.

Journey 2: From application management to DevOps

This journey starts from application management. In this domain, staff members are mainly organized in silos according to their expertise. This means that service delivery managers, functional application managers, technical application managers and database managers make up separate departments or teams. Processes are focused on channeling the work through the different teams. To facilitate this, ITIL process managers and ITIL coordinators are added to the organization as a function.

To begin with, based on shared features (including customer features) applications are clustered in product lines, information domains, value streams, etc. Key in this is to produce cohesive work packages for identifiable customer groups. Subsequently, the required operations competencies are combined in multidisciplinary operations teams. This second stage starts when the operations teams not only focus on operating and provisioning the contracted service, but also feel increasingly responsible for realizing new functionality in existing services in operation and subsequently also actively take on the role of owner in respect of service innovation. In turn, within these permanent, mature operations teams, this leads to increased awareness and the acquisition of the competencies needed for the teams themselves to realize innovations. Development tasks such as designing, building and testing can be performed within one’s own team. As a consequence, the management reflex to realize every innovation in projects with ad-hoc project teams can be overridden. The focus thus shifts from resource allocation, which is traditionally one of the time-consuming processes within an organization, to task prioritization.

Journey 3: From infrastructure management to DevOps

The third DevOps journey described in this paper is relatively unknown within the domain of DevOps, but it is essential to facilitating the journeys set out above. The starting point of this journey is the infrastructure management domain (from running infra via changing infra to providing self-service infra). Infrastructure as code and platform as code are terms you will hear in this regard. Making virtual infrastructure provisioning available to the DevOps teams allows them to respond flexibly to their changing needs for suitable infrastructure. The flipside is that this flexibility can only be realized if the underlying platforms and infrastructure have been standardized and the lifecycle management of hardware, OS, databases and middleware has been implemented explicitly. This flexibility and maintaining the platforms and infrastructure provided, lie at the heart of infrastructure-based service provision. Enforced processes (change and release management, automated promotion of software through the DTAP street based on test and acceptance criteria) mean that the DevOps teams demonstrably keep to the rules within the organization. We often see that on paper ITIL processes look great but in reality they are applied insufficiently. In a DevOps world, it is also desirable that the DevOps teams make sure they – and other teams – keep to the processes. Moreover, this is much easier because all the people in the process are in one room and thus the processes are very short and efficient instead of being long and burdensome. What is more, processes are increasingly described in the form of behavior rules and agreements rather than in process documents. This also applies to the processes in the other journeys.

In this way, a giant step is made towards realizing infrastructure management that is in line with the need for IT services to be agile and available. This step towards facilitating change has become possible in recent years thanks to a wide array of tools and methods (that are often open source) which are aimed at automating parts of the development process and the deployment process. As a result of the virtualization of infrastructure – infrastructure as code – the standards from the development domain (version control, full scripting of the promotion of software as well as modifications to infrastructure and platforms) are applied to compatible standards.

Does this mean that Dev has triumphed over Ops? No! That is certainly not the case. Although the commitment to innovation within the infrastructure domain has been strengthened, success is equally due to life-cycle thinking in the operations domain in terms of availability, continuity and stability. It is this cross-pollination that has brought Dev and Ops closer together. Quality at the source enables the divide between Dev and Ops to be bridged.

Journey 4: The step to Lean IT

That brings us to the fourth DevOps journey. A next step is taken in this journey. The DevOps teams seek to respond to the application domain’s need to reduce time to market. Infrastructure facilitates these teams optimally with appropriately modified platform and infrastructure services. As the quality is demonstrably under control, the added value of the division between run and change becomes steadily lower and new possibilities are created for further expanding the change domain. After all, the continuity of service delivery is safeguarded. Through value-stream optimization (Lean IT) new possibilities are created for shortening processes. We have called this journey Lean IT (‘handing over the keys to the kingdom’) because it optimizes the Lean IT value stream. What we see is that from a Lean perspective, the focus is on creating added value, and non-value activities and necessary non-value activities are reduced. By automating large parts of the operations processes and activities, greater transparency is created regarding the status of operations and updates. In fact, the effect of the operations standards increases because these standards are routinely applied and outage is measured and minimized (continuous improvement).

A step is thus made away from operational management in the form of reactive monitoring of components towards proactive management of the entire service in the chain. Of course, this had always been the intention and, in principle, had always been possible. However, when we look at how things turn out in practice, it is often not the case. Through far-reaching standardization and shortening of operations processes, collecting monitoring data (big data) and providing the DevOps teams that are responsible for the health of the service with access to this data, proactive management becomes the key to continuously increasing the tempo of updates and not drowning in incidents and fire-fighting.

Mature operations teams manage and update the services on a daily basis. In this situation, operations (or infrastructure operations) can hand the DevOps team the key without jeopardizing the availability of the service. What is more, if this key is not handed over, the delivery of customer value will be jeopardized. Today, customers require services which are in line with their current needs and not necessarily the contracted services of several years ago. Change becomes the norm but these services have to remain available.

This fourth journey thus shows how the application domain and the infrastructure domain work together to increase the agility of IT as a whole, while never compromising the basic need to safeguard continuity.

The DevOps journeys above provide a frame of reference for various stakeholders to consult one another about the goals an organization seeks to achieve, and how the different parts of the organization can contribute to achieving them. A common view and language are vital to this end. In addition, it is useful if people recognize and learn from one another’s contributions. Developers should learn that continuity requirements and operations tasks have value and can – and must – be optimized in order to safeguard agility in the long term as well. At the same time, people in infrastructure learn to use the development standards when developing and maintaining cloud-compliant infrastructures. The common goal of delivering more value, faster, requires new steps and working methods from every perspective. It is essential here to break down ‘walls’ and facilitate flow within the various IT domains and between the business and IT.

The business can also take the initiative

There is still one more journey: one that starts from the business process (BusDevOps). In this journey, in the development towards DevOps, IT is regarded as a business support function.

This fifth journey falls outside the scope of this paper and will be dealt with separately elsewhere.

Conclusion

DevOps is a different way of working and organizing but, above all, it is a different way of thinking. It is made for change. DevOps makes the organization ready for change. It is a concept that is perfectly aligned with our increasingly more digitalized world because the different functions, silos and islands are merged into a single end-to-end responsibility. DevOps is an inescapable step towards maximizing the quality of the customer experience.

Source : Quint Wellington Redwood