ITIL evolution: from processes to practices Discussion White Paper

When organizations and their information systems change, so must their ways of working. Process- dominant thinking, which has always been strongly associated with ITIL®, is now being replaced with a method of working that reflects the diverse and dynamic nature of organizations and the information systems they currently use.

Process-dominant thinking has evolved gradually over many years. The development of business applications became mainstream in the 1980s, and IT service management emerged in the 1990s as a way to control the growing number of information systems which were becoming increasingly important for organizations. Application development was stereotypically regarded as creative yet unreliable, and in need of a counterbalance. To provide assurance, the process approach was applied, with its emphasis on structure and defined inputs, outputs, and objectives.

Control came at a price, however, and the quality of the end product, an information system, was paid for with reduced speed of delivery and increased cost. Although this may have been a justifiable trade-off, unexpected negative side effects emerged. Working with rigid processes often led to the creation of silos, each responsible for part of a value chain, but with little regard for, or even understanding of, the other areas involved.

The Agile movement emerged in the 2000s. The increased dependence of organizations on IT services as a business differentiator meant that more speed was needed, sometimes at the cost of control. Or at least at the cost of the illusion of control, because it is always debatable how controllable traditional non-Agile projects are anyway.

There was initially some tension between the different methods of IT service management and the agile development teams. Potentially shippable software was produced in rapid sprints but had to wait, sometimes for months, for approval by change advisory boards before being deployed into production. The DevOps movement that began in the 2010s is seen as the next step: applying Lean, Agile, Safety Culture, and other principles to break down silos and normalize IT. This resulted in highly-automated and continuous integration, delivery, and deployment. In many cases, DevOps has demonstrated that it is possible to achieve fast, frequent, reliable deployments and a stable production environment.

Over the past few decades, organizations and their information systems have become more complex. They now depend on a large number of factors, many of which are not under the control of the organization itself. This means working with processes structured around specific situations is no longer appropriate.

When faced with unpredictability, a more experimental approach works better. An organization’s strategy for working with IT services must include multiple methods, which can be applied in different circumstances. When things are predictable, using set processes and proven practice is a good idea. When they are not, a more dynamic configuration and application of resources is more effective.

ITIL 4 has not abandoned processes but has instead positioned them alongside other resources that can be used to respond to any situation that might arise. In ITIL 4, this is called the four dimensions of service management. Collectively, these are critical to the effective and efficient facilitation of value for customers and other stakeholders in the form of products and services. The four dimensions are constrained or influenced by several external factors that are often beyond the control of IT service management.

Figure 1 The four dimensions of service management

The value streams and processes dimensions represent the activities for which the other three dimensions are needed: organization and people, information and technology, and partners and suppliers.

• Value streams and processes describes the activities and workflows that contribute to the value chain activities, how a practice interfaces with other practices, and applicable techniques, controls and metrics.
• Organizations and people describes roles and types of teams, how responsibilities are allocated, critical skills, attitudes and behaviours, different organizational constructs (depending on, for example, the size of the organization).
• Information and technology describes the information that flows through the IT function, how automation can be used within the IT function, and the requirements for technology.
• Partners and suppliers describes insourcing and outsourcing considerations, outsourcing service requirements and metrics (SLA/XLA).

Each practice comprises a description of ‘minimum viable service management’: the basics that must be addressed. In addition, the practices explore different options to address different situations. The requirements in terms of service management in small organizations differs from those in large organizations. An outsourcing agreement with a highly trusted and engaged partner will differ from a contract with a provider that serves thousands, or even millions, of customers. Digital enterprises place different demands on IT than organizations in which support drives the business.

One of the major updates in ITIL 4 is its increased emphasis on the need for diversity is one of the major updates. It would be irresponsible of an author of guidance to recommend a one-size- fits-all approach. It would be equally foolhardy of the reader to interpret this kind of guidance as prescriptive best practice. To quote Taiichi Ohno, the father of the Toyota Production System (the origin of the Lean movement), “You have to think for yourself and face your own difficulties instead of trying to borrow wisdom.” ITIL 4 describes various approaches with their pros and cons. It is up to each individual organization to configure, and improve, the guidance according to their own unique circumstances. This flexible approach enables ITIL guidance to be used effectively in many situations.