ITIL 4 and DevOps: a cultural perspective Discussion Paper

In addition to how our environment influences us, we tend to stick to our habitual ways of working.

When we become used to a particular style of working, it takes quite an effort to change it. Even more so when the new behaviour is not aligned with “the way we do things around here”. This is crucial in order to understand Change with a capital C. Here are four examples:

1. Process

If, for instance you are used to working in a predictable organizational ‘system’ where it is effective to follow predetermined processes. When faced with a problem, your instinct is to tighten up the processes, applying more control. This is a legitimate approach when the relationship between cause and effect is clear to see.

2. Analyse

Imagine you work with issues that require analysis before you know how to deal with them. You rely on gathering information to guide your approach. When faced with a problem, your tendency will be to keep looking until you have enough information. Which is acceptable when the situation is knowable. But this is ineffective when there is not enough causality to be able to determine all the steps needed for the case in question. When it is simply unknowable.

3. Experiment

Pretend you work in a highly unpredictable system where you can only make progress by taking one step at a time. After each step, you closely examine whether the step has changed the circumstances and therefore the next step. There is no knowable answer, therefore you have to experiment. When faced with problems, your inclination will be to take a step-by-step approach, even when some analysis could provide enough information for several if not all steps needed.

4. Dictate

Your environment is dominated by major incidents that need to be addressed very quickly to prevent damage. There is never enough time for analysis or experimentation. You have to act resolutely and people have to follow your command, otherwise serious damage will occur. When faced with a problem, even if it is not a major incident with these potentially disastrous consequences, your reaction will be to take command and order everybody about.

If you are familiar with complexity thinking and the Cynefin framework, you will probably have already recognized four of the five domains of this sense-making framework: obvious, complicated, complex and chaotic.

Obvious and complicated are predictable domains. Something complicated will need more work to discover the causality. Complex and chaotic are unpredictable domains, the main difference is that chaotic is dangerously unpredictable and therefore needs direct action. There is a fifth domain: disorder. You are in this domain when it is not clear which of the other four domains best describes the current situation. People’s experience, as described above, will often lead them to believe that they are in the domain in which they feel most comfortable.

Many people working in IT service management are used to designing and following processes. ITIL^® v3 guidance describes people, process, product and partners as the four major parts that IT service management is built on. However, process is often the primary focus. This correlated with the common mindset that change to an information system is likely to adversely affect its stability. Change therefore had to be highly controlled, and process is a great tool to control. The premise is that information systems should fail as infrequently as possible, with Mean Time Between Failures (MTBF) as a metric to monitor how well this being achieved.

There is nothing wrong with control. As long as what you are trying to control is controllable, or in other words: predictable. And as long as you are happy paying for control. The cost of control is usually effort and delay. Effort always costs money, and delay usually does. In the past decade or so, a couple of things have changed. Demand and complexity. These changes, highly relevant in the digital enterprise, have influenced how we should think about IT service management.

4.1. DEMAND

Every generation seems to say that life is happening faster than it used to. We need to act quicker. If it involves taking risks, we should take risks. Playing it safe is riskier. Not only do we need to deliver our products quicker, their quality also needs to improve. People are placing higher demands on what we do and how we do it. Just consider your own experience and expectations when dealing with a digital enterprise.

4.2. COMPLEXITY

In the past, information systems were pretty much self-contained. The hardware and software were in one room. There were few dependencies on external factors. When things went wrong, we debugged the system and found out what went wrong. Then we fixed it. There was causality. The mantra was If-Then-Else.

Now we construct our information systems with building blocks from various sources, most of which we can’t influence, let alone control. The cloud provider provides the cloud that they want to provide. You can take it or leave it. We take it. It is convenient. The operating system provides the operating system that they want to provide. You can take it or leave it. We take it. It is convenient.

The price for this convenience is unpredictability. There are so many interacting and constantly changing components that it is impossible to predict and therefore guarantee how things will work. The only thing that we can predict, is that things will go wrong. And they do. We have to live with this uncertainty. The new mantra is ‘If-Then-Maybe’.

This has changed how we think about IT service management. We no longer try to build fail-safe information systems. We build them so that they are safe-to-fail and quick to recover. The emphasis has shifted from Mean Time Between Failures (MTBF) to Mean Time To Recovery (MTTR).

We hear people talking about the digital enterprise and digital transformation, but what are they actually talking about? The terms are poorly defined and loosely used, but here is a definition that some people agree with.

We talk about a digital enterprise in organisations where IT is significant for their business model. Technology makes it possible to do different business and do business differently. This often results in IT becoming an integral part of the enterprise’s products and it is usually part of the channels through which customer and enterprise interact. For example, a digital enterprise is also one that makes strategic use of IT to automate the way it manufactures non-digital products that are sold and supported through non-digital channels. When is the use of IT significant enough to be called “strategic”? If IT is on the board’s agenda. If it is not, they probably think they have more important things to do.

Digital transformation refers to major change (the definition of transformation) to how a business uses IT to do different business and do business differently. It is not about major change to how IT services are provided: that is IT transformation. These two concepts, digital transformation and IT transformation, are often linked. When digital transformation places higher demands on IT, IT transformation may be needed. But they are two distinct activities.

Because ITIL and DevOps are primarily for the IT service provider rather than the IT service consumer, they are concerned with IT transformation rather than digital transformation. But digital transformation often leads to higher demand and increased complexity, which triggers IT transformation to a radically different way of working.

In 2015, AXELOS published nine Guiding Principles to help practitioners apply ITIL guidance in a more balanced and effective way rather than just blindly ‘implement’ processes, a misinterpreted but understandable approach. In ITIL^® Foundation, the nine guiding principles have been reduced to seven. This is mostly a combination of closely related principles and some refinement.

The last principle, Optimize and automate, is worth examination. It builds on the central theme of continual improvement and advises “to make something as effective and useful as it needs to be”, using automation where possible and reasonable. As a result it encourages the reader to strike a balance between needs and available resources. This applies to all of ITIL best practice: you should not blindly follow the examples in ITIL. It is about taking the time to think for yourself and finding the best solution. And then taking responsibility for the decision!

The guiding principles are:

• Focus on value: Everything that the organization does needs to map, directly or indirectly, to value for the stakeholders. The focus on value principle encompasses many perspectives, including the experience of customers and users.
• Start where you are: Do not start from scratch and build something new without considering what is already available to be leveraged. There is likely to be a great deal in the current services, processes, programmes, projects and people that can be used to create the desired outcome. The current state should be investigated and observed directly to make sure it is fully understood.
• Progress iteratively with feedback: Do not attempt to do everything at once. Even huge projects must be accomplished iteratively. By organizing work into smaller, manageable sections that can be executed and completed in a timely manner, it is easier to maintain a sharper focus on each effort. Using feedback before, throughout and after each iteration will ensure that actions are focused and appropriate, even if circumstances should change.
• Collaborate and promote visibility: Working together across boundaries produces results that have greater buy-in, more relevance to objectives and better likelihood of long-term success. Achieving objectives requires information, understanding and trust. Work and consequences should be made visible, hidden agendas should be avoided and information should be shared to the greatest degree possible.
• Think and work holistically: No service, or element used to provide a service, stands alone. The outcomes achieved by the service provider and service consumer will suffer unless the organization works on the service as a whole, not just on its parts. Results are delivered to internal and external customers through the effective and efficient management and dynamic integration of information, technology, organization, people, practices, partners and agreements, which should all be coordinated to provide a defined value.
• Keep it simple and practical: If a process, service, action or metric provides no value, or produces no useful outcome, eliminate it. In a process or procedure, use the minimum number of steps necessary to accomplish the objective(s). Always use outcome-based thinking to produce practical solutions that deliver results.
• Optimize and automate: Resources of all types, particularly human resources (HR), should be used to their best effect. Eliminate anything that is wasteful and use technology to achieve whatever it is capable of. Human intervention should only happen where it really contributes value.

Many of these principles address how to manage IT services in the complex and unpredictable digital enterprise. In particular start where you are, work holistically, progress iteratively and observe directly.

These principles inform “the way we do things around here” or in other words: the culture.

DevOps is a hard to define set of cultural norms, principles, technical practices and tooling. It enables fast, frequent and reliable delivery of software while at the same time providing resilient operational IT services. It also fosters a healthy IT workforce.

DevOps is often described in terms of culture, automation, lean, measurement and sharing (CALMS). Automation (for instance of deployment pipelines) is often of great interest and value, however it is culture that is widely acknowledged as the most significant, and the most difficult to change.

The DevOps community has embraced the work of sociologist Ron Westrum¹. Westrum proposes three kinds of organizational culture: pathological, bureaucratic and generative. The latter is regarded as the most desirable:

• Pathological cultures are power-oriented and focus on the personal interests and resources of the leadership. Information is processed in a way to benefit certain parties within the organization rather than the whole organization.
• Bureaucratic cultures are rule-oriented and focus on using standard procedures to process information throughout the organization. This works in theory but falls short when real-life issues occur.
• Generative cultures are performance-oriented and tend to be more proactive, focusing on getting the information to the right people in any way needed. Leaders emphasise achieving organizations goals and missions, not personal benefits. In generative cultures:
  • information is actively sought rather than ignored (bureaucratic culture) or hidden (pathological culture)
  • messengers are trained rather than tolerated or ‘shot’ (from the expression ‘don’t shoot the messenger’)
  • responsibilities are shared rather than compartmented or shirked
  • bridging between teams is rewarded rather than allowed or discouraged
  • failure causes enquiry rather than just and merciful treatment, or covering up
  • new ideas are welcomed rather than crushed.

¹ A typology of organization culture, BMJ Quality & Safety 13, no. 2, 2004

The characteristics of the desired generative cultures in the ITIL and DevOps communities are, at first glance, compatible. “Generative” can just as easily be applied to ITIL’s guiding principles. Yet mindsets often differ. Mindsets, that often represent commonly held beliefs, are very much part of the culture. Take for example the model about how change affects the stability of an information system, as mentioned in the IT service management section.

Many IT service management practitioners believe that change disrupts stability, and that stability controls change. The fewer the changes, the lower the risk to stability. And vice versa, the more controlled the system, the more difficult it is to change. This is the traditional IT service management perspective: “less change is good”.

But there is another way of looking at this, one that is very common in DevOps communities. By reducing the size of change, you reduce the risk of disruption. When you have smaller changes, you have more of them, so change happens more frequently. The more frequently you change, the better you are at it. In other words, the organization’s change capability has improved. The increased change capability leads, in turn, to lower risk of disruption. The model has suddenly shifted from “less change is good” to “more change is good”. The new mindset changes the organizational culture.

This change in model is supported by three of the ITIL guiding principles: start where you are, progress iteratively with feedback, and think and work holistically. Start where you are and observe the current metrics regarding speed, frequency and reliability of delivery. Progress iteratively with feedback by experimenting with breaking large changes down into smaller, more frequent changes. Think and work holistically by observing how the experiment affects other parts of the system.

There may be an initial dip in performance due to the learning curve, but in time results should improve. If not, or if the improvement is not enough, another experiment is needed. The value of this approach is that usable increments of functionality are provided quicker than having to wait for the whole large change. In economic terms, the cost of delay is reduced.

This approach is consistent with the Third Way of DevOps, creating a culture that fosters two things:

1. continual experimentation, which requires taking risks and learning from success and failure
2. and the understanding that repetition and practice are the prerequisites of mastery.

This is an example of how open-minded practitioners can achieve cultural change by experimentation. The new insights allow them to re-assess and revise their way of thinking and doing. Changing the culture, slowly but surely. Initially, the change will be restricted to “how our team does things around here” but if it proves valuable enough other teams will follow.

In addition to the strong cultural foundations that can be applied across the whole area of IT service management, DevOps also offers specific guidance in the areas of product and process, architecture, continuous delivery, and lean management and monitoring. This guidance, often in the form of technical practices, often adds another valuable dimension to ITIL guidance. Particularly when IT services are managed in a complex and unpredictable environment.

ITIL guidance has more detail across a broader scope of activities than DevOps’ technical practices. Much of ITIL’s guidance is presented in the form of practices that describe a set of value streams and processes, people and organization, partners and suppliers, and information and technology that interact dynamically according to circumstances. These are examples that should be tailored according to the guiding principle keep it simple and practical. In complex and unpredictable environments, following predetermined practices is by definition inappropriate. The ITIL practices (in particular the processes) can be used to describe possible patterns of behaviour that may or may not occur. It is up to the practitioners to use their experience and judgement and deviate as appropriate.

Culture is “how we do things around here”. We do things differently in the digital enterprise, so we need cultural change. Part of the challenge of “digital” is dealing with increasingly complex and unpredictable systems. The mantra has changed from If-Then-Else to If-Then-Maybe. Rigidly following predetermined processes does not work. Do the right thing right, not the wrong thing right. Practitioners have to be ready, willing and able to act on the fly. ITIL guidance, in particular the Guiding Principles, combines well with DevOps guidance in creating a culture that fosters continual experimentation and the understanding that repetition and practice are the prerequisites of mastery.